Drop the directory lock immediately after the ovl_create_real() call and
take a separate lock later for cleanup in ovl_cleanup_unlocked() - if
needed.
This makes way for future changes where locks are taken on individual
dentries rather than the whole directory.
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: NeilBrown <neil@brown.name>
Link: https://lore.kernel.org/20250716004725.1206467-6-neil@brown.name
Signed-off-by: Christian Brauner <brauner@kernel.org>
In ovl_copy_up_workdir() unlock immediately after the rename. There is
nothing else in the function that needs the lock.
Signed-off-by: NeilBrown <neil@brown.name>
Link: https://lore.kernel.org/20250716004725.1206467-5-neil@brown.name
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
ovl currently locks a directory or two and then performs multiple actions
in one or both directories. This is incompatible with proposed changes
which will lock just the dentry of objects being acted on.
This patch moves calls to ovl_create_temp() out of the locked regions and
has it take and release the relevant lock itself.
The lock that was taken before this function was called is now taken
after. This means that any code between where the lock was taken and
ovl_create_temp() is now unlocked. This necessitates the use of
ovl_cleanup_unlocked() and the creation of ovl_lookup_upper_unlocked().
These will be used more widely in future patches.
Now that the file is created before the lock is taken for rename, we
need to ensure the parent wasn't changed before the lock was gained.
ovl_lock_rename_workdir() is changed to optionally receive the dentries
that will be involved in the rename. If either is present but has the
wrong parent, an error is returned.
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: NeilBrown <neil@brown.name>
Link: https://lore.kernel.org/20250716004725.1206467-4-neil@brown.name
Signed-off-by: Christian Brauner <brauner@kernel.org>
ovl_copy_up_workdir() currently take a rename lock on two directories,
then use the lock to both create a file in one directory, perform a
rename, and possibly unlink the file for cleanup. This is incompatible
with proposed changes which will lock just the dentry of objects being
acted on.
This patch moves the call to ovl_create_index() earlier in
ovl_copy_up_workdir() to before the lock is taken.
ovl_create_index() then takes the required lock only when needed.
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: NeilBrown <neil@brown.name>
Link: https://lore.kernel.org/20250716004725.1206467-3-neil@brown.name
Signed-off-by: Christian Brauner <brauner@kernel.org>
If ovl_copy_up_data() fails the error is not immediately handled but the
code continues on to call ovl_start_write() and lock_rename(),
presumably because both of these locks are needed for the cleanup.
Only then (if the lock was successful) is the error checked.
This makes the code a little hard to follow and could be fragile.
This patch changes to handle the error after the ovl_start_write()
(which cannot fail, so there aren't multiple errors to deail with). A
new ovl_cleanup_unlocked() is created which takes the required directory
lock. This will be used extensively in later patches.
In general we need to check the parent is still correct after taking the
lock (as ovl_copy_up_workdir() does after a successful lock_rename()) so
that is included in ovl_cleanup_unlocked() using new ovl_parent_lock()
and ovl_parent_unlock() calls (it is planned to move this API into VFS code
eventually, though in a slightly different form).
Signed-off-by: NeilBrown <neil@brown.name>
Link: https://lore.kernel.org/20250716004725.1206467-2-neil@brown.name
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Case folding is often applied to subtrees and not on an entire
filesystem.
Disallowing layers from filesystems that support case folding is over
limiting.
Replace the rule that case-folding capable are not allowed as layers
with a rule that case folded directories are not allowed in a merged
directory stack.
Should case folding be enabled on an underlying directory while
overlayfs is mounted the outcome is generally undefined.
Specifically in ovl_lookup(), we check the base underlying directory
and fail with -ESTALE and write a warning to kmsg if an underlying
directory case folding is enabled.
Suggested-by: Kent Overstreet <kent.overstreet@linux.dev>
Link: https://lore.kernel.org/linux-fsdevel/20250520051600.1903319-1-kent.overstreet@linux.dev/
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Link: https://lore.kernel.org/20250602171702.1941891-1-amir73il@gmail.com
Reviewed-by: Kent Overstreet <kent.overstreet@linux.dev>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Add internal helper backing_file_set_user_path() for the only
two cases that need to modify backing_file fields.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Link: https://lore.kernel.org/20250607115304.2521155-2-amir73il@gmail.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
The fsl,mpc8349-gpio, fsl,mpc8572-gpio, and fsl,mpc8610-gpio compatibles
are already documented in fsl,qoriq-gpio.yaml. Add the additional
compatibles that use fsl,mpc8349-gpio as a fallback. With that,
the 8xxx_gpio.txt binding document is redundant and can be removed.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Link: https://lore.kernel.org/r/20250714202941.3013390-1-robh@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Many simple GPIO controllers without interrupt capability have the same
schema other than their compatible value. Combine all these bindings
into a single schema. The criteria to be included here is must use 2
cells, have no interrupt capability, have 0 or 1 "reg" entries, and
have no other resources (like clocks).
Note that "ngpios" is now allowed in some cases it wasn't before and
constraints on it have been dropped.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250714201959.2983482-1-robh@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Convert the TI TWL4030 PMIC GPIO binding to DT schema format. The number
of #interrupt-cells was wrong compared to what is in use. Correct it to
be 1.
Reviewed-by: Andreas Kemnade <andreas@kemnade.info>
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250714202829.3011298-1-robh@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Convert the TI Keystone DSP GPIO binding to DT schema format. The
"ti,syscon-dev" property was wrong and should be "gpio,syscon-dev"
instead.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250714202850.3011952-1-robh@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Convert the Cavium Octeon 3860 GPIO binding to DT schema format. It's a
straight forward conversion.
Looks like Octeon has no maintainers, so Bartosz is listed.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250714202927.3012974-1-robh@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The patch converting the driver to using new GPIO line value setters
only converted the set() callback and missed set_multiple(). Fix it now.
Fixes: 1919ea19a4 ("gpio: xilinx: use new GPIO line value setter callbacks")
Acked-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20250717131116.53878-1-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.
Reviewed-by: Romain Gantois <romain.gantois@bootlin.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20250717130357.53491-2-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
As of commit 92ac7de317 ("gpiolib: don't allow setting values on input
lines"), the GPIO core makes sure values cannot be set on input lines.
Remove the unnecessary check.
Reviewed-by: Romain Gantois <romain.gantois@bootlin.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20250717130357.53491-1-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The hccs_get_all_spec_port_idle_sta() will tell user which port
is busy when firmware doesn't allow to decrease HCCS lane number.
However, the current log prints the index of die and port instead
of the hardware ID user perceived.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
The drm_gem ioctls were documented in internal file drm_gem.c
instead of uapi header drm.h. Move them there and change to
appropriate kerneldoc formatting.
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20250717143556.857893-3-David.Francis@amd.com
CRIU restore of drm buffer objects requires the ability to create
or import a buffer object with a specific gem handle.
Add new drm ioctl DRM_IOCTL_GEM_CHANGE_HANDLE, which takes
the gem handle of an object and moves that object to a
specified new gem handle.
This ioctl needs to call drm_prime_remove_buf_handle,
but that function acquires the prime lock, which the ioctl
needs to hold for other purposes.
Make drm_prime_remove_buf_handle not acquire the prime lock,
and change its other caller to reflect this.
The rest of the kernel patches required to enable CRIU can be
found at
https://lore.kernel.org/dri-devel/20250617194536.538681-1-David.Francis@amd.com/
v2 - Move documentation to UAPI headers
v3 - Always return 0 on success
Signed-off-by: David Francis <David.Francis@amd.com>
Acked-by: Felix Kuehling <felix.kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20250717143556.857893-2-David.Francis@amd.com
Use min()/max() to reduce the code and improve its readability.
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250715121721.266713-8-rongqianfeng@vivo.com
In scheduled scan mode, the current probe request only includes the SSID
IE, but omits the Basic Rate IE. Some APs do not respond to such
incomplete probe requests, causing net-detect failures. To improve
interoperability and ensure APs respond correctly, add the Basic Rate IE
to the probe request in driver.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250716122926.6709-1-pkshih@realtek.com
Update the min, max ranges of the PLL clocks according to the latest
datasheet to be coherent in the driver. This patch solves the issues in
configuring the clocks related to peripherals with the desired frequency
within the range.
Fixes: 33013b43e2 ("clk: at91: sam9x7: add sam9x7 pmc driver")
Suggested-by: Patrice Vilchez <Patrice.Vilchez@microchip.com>
Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
Link: https://lore.kernel.org/r/20250714093512.29944-1-varshini.rajendran@microchip.com
Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Only one fix:
Correct the name of the A523's EMAC0 to GMAC0, as seen in the SoC's
datasheets. The matching DT binding change is in the net tree.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCgAsFiEE2nN1m/hhnkhOWjtHOJpUIZwPJDAFAmh2iT4OHHdlbnNAY3Np
ZS5vcmcACgkQOJpUIZwPJDCMJBAAuauzK0XFSSwuzxlkd2b4fb9iY8V8U+h4T6E0
T83snFr3IDZxRU3z9+6EKhIAyh/yHpu8wv27jMNyb6UAbafzhqYaCENXdIrI7lDX
CzgDCJJWPTJ9L/Iq5EY+BXSBNaHQz1PLrryjdLJeNSzxXWP4k62oPCE09HioYIvK
hMEUIyH9jdTK6h4jfp0J0YHYfDZPr4ix33Ua33ToPnTYeaMeowaWDZ2I/IXyhmG7
q+XRzdNrpcMuKQH5hpSTDYI1TjonWa1jovpYH9uktuzb7CHHz2C9f3wxz9X2xpui
nxa44UoqKF0XfP3Luur9cfXHS6zq5HqKRaXkCP9EiXoIpocjo5rCHqvIabyC+6QU
ACRrbp/9rCJ/XZm5MRvXD3+JlcF+SFJ3vYhZgk1iLXFFEPGgfUezf0s6hAUv5xGc
OnxmF2ztxxXVAKCkRFG7JVbyHzQmKojX9lZUVWQP1dRZCfaQ1dqAN6oCO1NuVvLc
mPVgftt3N2XDaM/XCp054RFBu0Dmjm6oIUNJy2Jc59ED5FF+Erit+xTqYfv9iZGu
PfyBk43lPhFr+6twsYsaivoh45px7aCRAuKnwY4AizIjr01ZeVjc1snauiUS7pzo
jtdIESYuaRnmTE1tiY0keAB5y4OH/jxB61jJ4IwIUIEGzySrmG8HchizVnd0UYoA
eJsh/Jw=
=j8oj
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmh56IgACgkQmmx57+YA
GNkLmBAAhe2cre+Xw4DJu7jTKIcHJM5T7Ug93Jfa8rJ17vg6ksk+/PDwTATS5EmS
trcw4H0ch23ZI/KQ0Lkf2fVAUwZkhbk16xlHLPzhfx8I6hn5VmhQc0JV1lsGgxu6
SJSMwMsmDJH2BKkQUQHkx3vYtv4MF9FduNWLj2UgJUFaZH6QbeTmnTr+ksVfZJ7M
F0sLlHBGYJybHk4yJsV6zdvuLIy1lZ5EU7NAD6ZDCl9uzp79LgzLKEEoc2ip9B0g
NxvBDyc71MqqqSnEoCVPBQi3N6HFXVWSwGnzyhkmKmG57oiKyudagMHga4rIN3Iw
DBkXYBp1LduiA6v64lKtXjCcXmidFi/hQDlll9eyOzwRjUBdHrNZe0Lt3sdrHKdb
l12SCgEmHG0BNDP1YOOQSnrA1DyLcoK0Y45YkzDHjUkSpZY1uxeC6RBUiKMCCrxS
shSZLSfQlK0IcZ130eIHENkwqm75T/Kje0vnJN0PdqechYgQFLn9z4nT0P/oYUhk
+TrLUjukL4H9CGR3sFpeQmpobIQcBU50G7xG9K9kgLk+BawIcrbPcABJ/WkgkWnF
GXCaIDqdiYn2ihZ4xwQGUHt2ft6T59YnvcARKcJak3Vqic+ASnNGsjvpCKV3c6FK
PF2nJJHyFAPBSBCzVjDd5m70Of+M6gJj0197a7KMYhBHaVahoTU=
=5gpa
-----END PGP SIGNATURE-----
Merge tag 'sunxi-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/fixes
Allwinner fixes for 6.16
Only one fix:
Correct the name of the A523's EMAC0 to GMAC0, as seen in the SoC's
datasheets. The matching DT binding change is in the net tree.
* tag 'sunxi-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
arm64: dts: allwinner: a523: Rename emac0 to gmac0
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
When the chip is not powered on correctly (like during driver
development) rtw89_fwdl_check_path_ready_ax() can fail.
read_poll_timeout_atomic() with a delay of 1 µs and a timeout of
400000 µs can take 50 seconds with USB because of the time it takes to
send a USB control message. The firmware upload is tried 5 times, so
in total it takes 250 seconds.
Lower the timeout to 3200 for USB in order to reduce the time
rtw89_fwdl_check_path_ready_ax() takes from 50 seconds to less than 1
second.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/af0b25d0-ea67-455e-91f2-8e4c18ae4328@gmail.com
This read_poll_timeout_atomic() with a delay of 1 µs and a timeout of
1000000 µs can take ~250 seconds in the worst case because sending a
USB control message takes ~250 µs.
Lower the timeout to 4000 for USB in order to reduce the maximum polling
time to ~1 second.
This problem was observed with RTL8851BU while suspending to RAM with
WOWLAN enabled. The computer sat for 4 minutes with a black screen
before suspending.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/09313da6-c865-4e91-b758-4cb38a878796@gmail.com
The variable 'path' from rtw89_phy_get_syn_sel() as index of array could
be 3, but array size is 2. Fortunately, current chip->rf_path_num is
smaller or equal to 2, so it is safe. To prevent mistakes in the future,
add a checking and avoid Coverity warnings.
Addresses-Coverity-ID: linux-next: 1644716 ("Out-of-bounds write")
Addresses-Coverity-ID: linux-next: 1644717 ("Out-of-bounds write")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250715035259.45061-6-pkshih@realtek.com
The queued and obsoleted scan events can be wrongly treated as events of
new scan request, causing unexpected scan result. Attach a software
sequence number to scan request and its corresponding events. When a new
scan request is acknowledged by firmware, purge the scan events if its
sequence number is not belong to current request.
Normal case:
mac80211 event work event BH
------------- ---------- --------
scan req #1 ---->o
|
<----o <...........................o
o
|
<--------------------------+
ieee80211_scan_completed()
Abnormal case (late event work):
mac80211 event work event BH
------------- ---------- --------
scan req #1 ---->o
|
<----o <...........................o
o #1
scan cancel #2 ->o
|
<----o <...........................o
o #2
| (patch to avoid this)
scan req #3 ---->o |
| |
<----o <..........|................o
| o #3
<--------------------------+
ieee80211_scan_completed()
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250715035259.45061-5-pkshih@realtek.com
When the 'Disabled Subchannel Bitmap' within the EHT Operation
element is changed, mac80211 parse and pass it to the driver.
The driver is then updated with this puncturing bitmap to
optimize bandwidth usage and prevent interference from
degrading performance across the entire channel.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250715035259.45061-4-pkshih@realtek.com
Since the RX counter in the PPDU status is not used,
it is disabled to reduce the waste of DLE quota.
Signed-off-by: Chia-Yuan Li <leo.li@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250715035259.45061-3-pkshih@realtek.com
In order for the situation where the dispatcher blocking
causes HAXIDMA to be unable to TX to be reported as
a TX stuck, so that subsequent recovery can be handled.
Signed-off-by: Chia-Yuan Li <leo.li@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250715035259.45061-2-pkshih@realtek.com
- SR-IOV fixes for GT reset and TLB invalidation
- Fix memory copy direction during migration
- Fix alignment check on migration
- Fix MOCS and page fault init order to correctly
account for topology
-----BEGIN PGP SIGNATURE-----
iQJNBAABCgA3FiEE6rM8lpABPHM5FqyDm6KlpjDL6lMFAmh5u3IZHGx1Y2FzLmRl
bWFyY2hpQGludGVsLmNvbQAKCRCboqWmMMvqUyViEAChO4zJ11v29mILYOJwYCir
hZ0gUvbDVd3/uYMDTFbZnva6fA5vDwRFRXrlS2VYzWmYcnyg7/sLc5s1pc0u6ir+
9WSm9z+msF4GDqe4wIpKALpA8Jxo6iIimmRHqhY+Ak24h4fA+OrDSNHUEaHwcCbK
oX2uszmHPj1N00aEwtXdP2S09GKqONpGD0948iZ/vjrXojfe7+IhiHjtCMQftZ5x
NBqTotbJgXo4bK3PWqpL3jEQ0qkl+mVnLb8OWbRSrowupxxF6BTvrJRpAo4OgV9o
866kfK99OE1OLAihn+0gCqBVjFfrjdu1R8LqlL/8m7ThJEFf+AQzMGy6Bnt25+MQ
XCytRnSDn7GO0T/HIJ5psYSTkUcQzKfRfSP+SwLMDo2yfaqcaD/TC70pzt9MKgDI
ZLcZ8C8pUcICUzqqUQKtOkwZWimb6SVa+3s9dm5s93giL25QKdnCdTeCmURSGnEf
wlK729MsiBODHfdfLpCZbE4D1Kjxw/eATUtqIabRNMUC6W28e93svAG2AsJlcwEV
382SaQiDSZULPEwl4BycVXlZgSOqAsR3YJhKf+CcHYMA8YKUWNkmFRpg+gjQhMNe
zR4VNSMxzHboD9KkzSmdpwhJ3ucJwlU/XutVuNvPduZ3WHV3x1PDG2hkiLza3VMK
w8jZH43uviE3QJ9li/W6Mg==
=mpnW
-----END PGP SIGNATURE-----
Merge tag 'drm-xe-fixes-2025-07-17' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes
Driver Changes:
- SR-IOV fixes for GT reset and TLB invalidation
- Fix memory copy direction during migration
- Fix alignment check on migration
- Fix MOCS and page fault init order to correctly
account for topology
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/6jworkgupwstm4v7aohbuzod3dyz4u7pyfhshr5ifgf2xisgj3@cm5em5yupjiu
We observed a regression in our customer’s environment after enabling
CONFIG_LAZY_RCU. In the Android Update Engine scenario, where ioctl() is
used heavily, we found that callbacks queued via call_rcu_hurry (such as
percpu_ref_switch_to_atomic_rcu) can sometimes be delayed by up to 5
seconds before execution. This occurs because the new grace period does
not start immediately after the previous one completes.
The root cause is that the wake_nocb_gp_defer() function now checks
"rdp->nocb_defer_wakeup" instead of "rdp_gp->nocb_defer_wakeup". On CPUs
that are not rcuog, "rdp->nocb_defer_wakeup" may always be
RCU_NOCB_WAKE_NOT. This can cause "rdp_gp->nocb_defer_wakeup" to be
downgraded and the "rdp_gp->nocb_timer" to be postponed by up to 10
seconds, delaying the execution of hurry RCU callbacks.
The trace log of one scenario we encountered is as follow:
// previous GP ends at this point
rcu_preempt [000] d..1. 137.240210: rcu_grace_period: rcu_preempt 8369 end
rcu_preempt [000] ..... 137.240212: rcu_grace_period: rcu_preempt 8372 reqwait
// call_rcu_hurry enqueues "percpu_ref_switch_to_atomic_rcu", the callback waited on by UpdateEngine
update_engine [002] d..1. 137.301593: __call_rcu_common: wyy: unlikely p_ref = 00000000********. lazy = 0
// FirstQ on cpu 2 rdp_gp->nocb_timer is set to fire after 1 jiffy (4ms)
// and the rdp_gp->nocb_defer_wakeup is set to RCU_NOCB_WAKE
update_engine [002] d..2. 137.301595: rcu_nocb_wake: rcu_preempt 2 FirstQ on cpu2 with rdp_gp (cpu0).
// FirstBQ event on cpu2 during the 1 jiffy, make the timer postpond 10 seconds later.
// also, the rdp_gp->nocb_defer_wakeup is overwrite to RCU_NOCB_WAKE_LAZY
update_engine [002] d..1. 137.301601: rcu_nocb_wake: rcu_preempt 2 WakeEmptyIsDeferred
...
...
...
// before the 10 seconds timeout, cpu0 received another call_rcu_hurry
// reset the timer to jiffies+1 and set the waketype = RCU_NOCB_WAKE.
kworker/u32:0 [000] d..2. 142.557564: rcu_nocb_wake: rcu_preempt 0 FirstQ
kworker/u32:0 [000] d..1. 142.557576: rcu_nocb_wake: rcu_preempt 0 WakeEmptyIsDeferred
kworker/u32:0 [000] d..1. 142.558296: rcu_nocb_wake: rcu_preempt 0 WakeNot
kworker/u32:0 [000] d..1. 142.558562: rcu_nocb_wake: rcu_preempt 0 WakeNot
// idle(do_nocb_deferred_wakeup) wake rcuog due to waketype == RCU_NOCB_WAKE
<idle> [000] d..1. 142.558786: rcu_nocb_wake: rcu_preempt 0 DoWake
<idle> [000] dN.1. 142.558839: rcu_nocb_wake: rcu_preempt 0 DeferredWake
rcuog/0 [000] ..... 142.558871: rcu_nocb_wake: rcu_preempt 0 EndSleep
rcuog/0 [000] ..... 142.558877: rcu_nocb_wake: rcu_preempt 0 Check
// finally rcuog request a new GP at this point (5 seconds after the FirstQ event)
rcuog/0 [000] d..2. 142.558886: rcu_grace_period: rcu_preempt 8372 newreq
rcu_preempt [001] d..1. 142.559458: rcu_grace_period: rcu_preempt 8373 start
...
rcu_preempt [000] d..1. 142.564258: rcu_grace_period: rcu_preempt 8373 end
rcuop/2 [000] D..1. 142.566337: rcu_batch_start: rcu_preempt CBs=219 bl=10
// the hurry CB is invoked at this point
rcuop/2 [000] b.... 142.566352: blk_queue_usage_counter_release: wyy: wakeup. p_ref = 00000000********.
This patch changes the condition to check "rdp_gp->nocb_defer_wakeup" in
the lazy path. This prevents an already scheduled "rdp_gp->nocb_timer"
from being postponed and avoids overwriting "rdp_gp->nocb_defer_wakeup"
when it is not RCU_NOCB_WAKE_NOT.
Fixes: 3cb278e73b ("rcu: Make call_rcu() lazy to save power")
Co-developed-by: Cheng-jui Wang <cheng-jui.wang@mediatek.com>
Signed-off-by: Cheng-jui Wang <cheng-jui.wang@mediatek.com>
Co-developed-by: Lorry.Luo@mediatek.com
Signed-off-by: Lorry.Luo@mediatek.com
Tested-by: weiyangyang@vivo.com
Signed-off-by: weiyangyang@vivo.com
Signed-off-by: Tze-nan Wu <Tze-nan.Wu@mediatek.com>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.upadhyay@kernel.org>
There was a lot of common code in the codepaths used to convert an
inline directory and to creaet a new directory. To address this,
rename ext4_init_dot_dotdot() to ext4_init_dirblock() and then move
common code into that function.
This reduces the lines of code count in fs/ext4/inline.c and
fs/ext4/namei.c, as well as reducing the size of their object files.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Link: https://patch.msgid.link/20250712181249.434530-3-tytso@mit.edu
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The strcpy() function is considered dangerous and eeeevil by people
who are using sophisticated code analysis tools such as "grep". This
is true even when a quick inspection would show that the source is a
constant string ("." or "..") and the destination is a fixed array
which is guaranteed to have enough space. Make the "grep" code
analysis tool happy by using memcpy() isstead of strcpy(). :-)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Link: https://patch.msgid.link/20250712181249.434530-2-tytso@mit.edu
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
In a discussion over a proposed patch, "ext4: replace strcpy() with
'.' assignment"[1], I had asserted that directory entries in ext4 were
not NUL terminated, and hence it was safe to replace strcpy() with a
direct assignment. As it turns out, this was incorrect. It's true
for all all directory entries *except* for '.' and '..' where the
kernel was using strcmp() and where e2fsck actually checks and offers
to fix things if '.' and '..' are not NUL terminated.
[1] https://lore.kernel.org/r/202505191316.JJMnPobO-lkp@intel.com
We can't change this without breaking old kernel versions, but in the
spirit of "be liberal in what you receive", use direct comparison of
de->name_len and de->name[0,1] instead of strcmp(). This has the side
benefit of reducing the compiled text size by 96 bytes on x86_64.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Link: https://patch.msgid.link/20250712181249.434530-1-tytso@mit.edu
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Currently we clear BH_New bit in case of error and also in the standard
ext4_write_end() handler (in block_commit_write()). However
ext4_journalled_write_end() misses this clearing and thus we are leaving
stale BH_New bits behind. Generally ext4_block_write_begin() clears
these bits before any harm can be done but in case blocksize < pagesize
and we hit some error when processing a page with these stale bits,
we'll try to zero buffers with these stale BH_New bits and jbd2 will
complain (as buffers were not prepared for writing in this transaction).
Fix the problem by clearing BH_New bits in ext4_journalled_write_end()
and WARN if ext4_block_write_begin() sees stale BH_New bits.
Reported-by: Baolin Liu <liubaolin12138@163.com>
Reported-by: Zhi Long <longzhi@sangfor.com.cn>
Fixes: 3910b513fc ("ext4: persist the new uptodate buffers in ext4_journalled_zero_new_buffers")
Signed-off-by: Jan Kara <jack@suse.cz>
Link: https://patch.msgid.link/20250709084831.23876-2-jack@suse.cz
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
In ext4_io_end_defer_completion(), check if io_end->list_vec is empty to
avoid adding an io_end that requires no conversion to the
i_rsv_conversion_list, which in turn prevents starting an unnecessary
worker. An ext4_emergency_state() check is also added to avoid attempting
to abort the journal in an emergency state.
Additionally, ext4_put_io_end_defer() is refactored to call
ext4_io_end_defer_completion() directly instead of being open-coded.
This also prevents starting an unnecessary worker when EXT4_IO_END_FAILED
is set but data_err=abort is not enabled.
This ensures that the check in ext4_put_io_end_defer() is consistent with
the check in ext4_end_bio(). Otherwise, we might add an io_end to the
i_rsv_conversion_list and then call ext4_finish_bio(), after which the
inode could be freed before ext4_end_io_rsv_work() is called, triggering
a use-after-free issue.
Fixes: ce51afb8cc ("ext4: abort journal on data writeback failure if in data_err=abort mode")
Signed-off-by: Baokun Li <libaokun1@huawei.com>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://patch.msgid.link/20250708111504.3208660-1-libaokun@huaweicloud.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Fix following compiling errors:
In file included from ../drivers/cxl/core/pmu.c:10:
../drivers/cxl/core/core.h: In function ‘cxl_decoder_detach’:
../drivers/cxl/core/core.h:65:1: error: no return statement in function returning non-void [-Werror=return-type]
}
^
cc1: some warnings being treated as errors
CC [M] drivers/nvdimm/claim.o
make[6]: *** [../scripts/Makefile.build:287: drivers/cxl/core/pmu.o] Error 1
make[6]: *** Waiting for unfinished jobs....
CC [M] drivers/infiniband/core/verbs.o
Fixes: b3a8822551 ("cxl/region: Consolidate cxl_decoder_kill_region() and cxl_region_detach()")
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
Link: https://patch.msgid.link/20250717031251.1043825-1-lizhijian@fujitsu.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
