mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-13 07:31:07 +00:00
1,187,117 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Yury Norov
|
c1d2ba10f5 |
lib/bitmap: drop optimization of bitmap_{from,to}_arr64
bitmap_{from,to}_arr64() optimization is overly optimistic on 32-bit LE
architectures when it's wired to bitmap_copy_clear_tail().
bitmap_copy_clear_tail() takes care of unused bits in the bitmap up to
the next word boundary. But on 32-bit machines when copying bits from
bitmap to array of 64-bit words, it's expected that the unused part of
a recipient array must be cleared up to 64-bit boundary, so the last 4
bytes may stay untouched when nbits % 64 <= 32.
While the copying part of the optimization works correct, that clear-tail
trick makes corresponding tests reasonably fail:
test_bitmap: bitmap_to_arr64(nbits == 1): tail is not safely cleared: 0xa5a5a5a500000001 (must be 0x0000000000000001)
Fix it by removing bitmap_{from,to}_arr64() optimization for 32-bit LE
arches.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/lkml/20230225184702.GA3587246@roeck-us.net/
Fixes:
|
||
|
Yury Norov
|
c4c14c2906 |
lib/test_bitmap: increment failure counter properly
The tests that don't use expect_eq() macro to determine that a test is failured must increment failed_tests explicitly. Reported-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/lkml/20230225184702.GA3587246@roeck-us.net/ Signed-off-by: Yury Norov <yury.norov@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> |
||
Linus Torvalds
|
dad9774dea |
A single regression fix for a regression fix:
For a long time the tick was aligned to clock MONOTONIC so that the tick event happened at a multiple of nanoseconds per tick starting from clock MONOTONIC = 0. At some point this changed as the refined jiffies clocksource which is used during boot before the TSC or other clocksources becomes usable, was adjusted with a boot offset, so that time 0 is closer to the point where the kernel starts. This broke the assumption in the tick code that when the tick setup happens early on ktime_get() will return a multiple of nanoseconds per tick. As a consequence applications which aligned their periodic execution so that it does not collide with the tick were not longer guaranteed that the tick period starts from time 0. The fix for this regression was to realign the tick when it is initially set up to a multiple of tick periods. That works as long as the underlying tick device supports periodic mode, but breaks under certain conditions when the tick device supports only one shot mode. Depending on the offset, the alignment delta to clock MONOTONIC can get in a range where the minimal programming delta of the underlying clock event device is larger than the calculated delta to the next tick. This results in a boot hang as the tick code tries to play catch up, but as the tick never fires jiffies are not advanced so it keeps trying for ever. Solve this by moving the tick alignement into the NOHZ / HIGHRES enablement code because at that point it is guaranteed that the underlying clocksource is high resolution capable and not longer depending on the tick. This is far before user space starts, so at the point where applications try to align their timers, the old behaviour of the tick happening at a multiple of nanoseconds per tick starting from clock MONOTONIC = 0 is restored. -----BEGIN PGP SIGNATURE----- iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmSTUNQTHHRnbHhAbGlu dXRyb25peC5kZQAKCRCmGPVMDXSYoQQjD/4+zHK7IxRK+1k1lIStxksEudVeNuqK 7RZKNTawZFSChrxGmv5uhmqYDK9/tudnZot+uyAXI81JHnnGSXbco+VrAA2DQ2v2 w/oxhAHIAobJWDzUuCqT2YsseDVNoTGMrTTPrL4klXqhVtShVOLTI/603+macEiw Olqmd7XxlyhCloNqoMIh18EwSNIs78kP3YAQHUmq3NoRkJT5c3wWKvZy38WOxSJ9 Jjpw75tePfcwWte9fGVq+oJ8hOWkPAKN5hFL8420RrEgdIkxKlhVmuyG48ieZKH1 LE1brB5iaU8+M91PevZMRlD7oio8u/d6xX1vT3Cqz9UBe1NLj1I0ToX6COhwSNxm 50U0HJ5wGlpodu4IyBHXTG45UAVwpOg/EgDlFigeP3Nxl6h45ugrA010r6FqE1zV KltjNGsk/OD5d8ywW+yManU2mySm9znqmWN2zbjRGm138Tuz7vglcBhFB6jEJFUF V8vYPLwI4J2gqifx8NoFBIfLuZp/+D4LOQiJ7XRc9CVm3JLK8Xi8fxnHGTBwJHIn 45WU4hzmY7fjR/gGhAyG7lH6tlo7VTC9/lrO+YtAy2hL2sK14+m/ZH7836I5bAhw EgSyVlcfR6tgO55I3JgkbNIyO5TUAZPZIAY1TlyR53xXvMkb9aZTh9UMm1xMJ3uX +sQaLAuDFNUQSg== =/uvx -----END PGP SIGNATURE----- Merge tag 'timers-urgent-2023-06-21' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fix from Thomas Gleixner: "A single regression fix for a regression fix: For a long time the tick was aligned to clock MONOTONIC so that the tick event happened at a multiple of nanoseconds per tick starting from clock MONOTONIC = 0. At some point this changed as the refined jiffies clocksource which is used during boot before the TSC or other clocksources becomes usable, was adjusted with a boot offset, so that time 0 is closer to the point where the kernel starts. This broke the assumption in the tick code that when the tick setup happens early on ktime_get() will return a multiple of nanoseconds per tick. As a consequence applications which aligned their periodic execution so that it does not collide with the tick were not longer guaranteed that the tick period starts from time 0. The fix for this regression was to realign the tick when it is initially set up to a multiple of tick periods. That works as long as the underlying tick device supports periodic mode, but breaks under certain conditions when the tick device supports only one shot mode. Depending on the offset, the alignment delta to clock MONOTONIC can get in a range where the minimal programming delta of the underlying clock event device is larger than the calculated delta to the next tick. This results in a boot hang as the tick code tries to play catch up, but as the tick never fires jiffies are not advanced so it keeps trying for ever. Solve this by moving the tick alignement into the NOHZ / HIGHRES enablement code because at that point it is guaranteed that the underlying clocksource is high resolution capable and not longer depending on the tick. This is far before user space starts, so at the point where applications try to align their timers, the old behaviour of the tick happening at a multiple of nanoseconds per tick starting from clock MONOTONIC = 0 is restored" * tag 'timers-urgent-2023-06-21' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: tick/common: Align tick period during sched_timer setup |
||
|
Linus Torvalds
|
0070349771 |
virtio: bugfix
A last minute revert to fix a regression. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> -----BEGIN PGP SIGNATURE----- iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmSSsb0PHG1zdEByZWRo YXQuY29tAAoJECgfDbjSjVRpteMH/RRAiEYfWD+/DqFvxeBdFQsistVphMj7/3hh 9tKbVHXIJGl9SVodfjL/vvgk4QwZg3CgmKGDAWGpPO1SjFHCg7JgII7AE6Wu5Ff+ an4FguPA5Wc+7dmzsVH3yPg9N5Im9XtR5Y9avlhDmDEmLcKSzBEEtWrfQtKLLuyi /dZZTEkzDgAP/wkrOEp90U9ION/bZ/hxFDbGWMr2XAg9ZR90GivCOleG63qPyLcq k9asAF55tjNhNmqH6OpR5BcfFZhJli3IJa56Bypr//dJkzjQSrRhkz2UcwXNwu/b GxAmBo/ObgnuSOUsDve9jZowGLa/MgocuCMcf05P9D3CtYsIqIs= =gmrq -----END PGP SIGNATURE----- Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost Pull virtio fix from Michael Tsirkin: "A last minute revert to fix a regression" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: Revert "virtio-blk: support completion batching for the IRQ path" |
||
|
Linus Torvalds
|
69cbeb61ff |
Revert "efi: random: refresh non-volatile random seed when RNG is initialized"
This reverts commit |
||
|
Linus Torvalds
|
2214170caa |
spi: Fix for v6.4
One last fix for SPI, just a simple fix for incorrect handling of probe deferral for DMA in the Qualcomm GENI driver. -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmSS8esACgkQJNaLcl1U h9Cm1Qf+PD5lKhoc4Grecs5EbrI/Fzg0y3y6aLP2dghc+XbGnNcCtBYExavRWpJa AsmqgH+Q7lARZ6T7vrsVyyV3Pn6mLem4aNWo1omKTbmfOD4zf9IT3pnoMQSBo8VC /7f5nlP+0aVtHXwhZeGP3biZKZ25c2tkDsFb5yKBKFSohSi23RJCErHLhnVZv8Ne 2OymxblxbcGV3Mu63EvZbnP0q8r0toK4VgAKn86onV2D/jrH/EjNZDTSXWLHhCkk IptQ8vCv9suIF1aZApvBlOWqE8xs1dp/OVNuD2MtVFKWCm/9DS65QPXVxz5VUQVx J0GF1m8uvLWdWfZwqS75orCpUYpuGQ== =/Lry -----END PGP SIGNATURE----- Merge tag 'spi-fix-v6.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fix from Mark Brown: "One last fix for SPI, just a simple fix for incorrect handling of probe deferral for DMA in the Qualcomm GENI driver" * tag 'spi-fix-v6.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: spi-geni-qcom: correctly handle -EPROBE_DEFER from dma_request_chan() |
||
|
Linus Torvalds
|
6e6fb54de1 |
regulator: Fix for v6.4
One simple fix for v6.4, some incorrectly specified bitfield masks in the PCA9450 driver. -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmSS8qMACgkQJNaLcl1U h9AuQwf7BY16m/8M/3aHCzkj6d/NzzDOmsvgLuelAp7WAhoCd/+7jrp1rgt+M/CS hiZZlhIaQVhEOjBzfDIEAY5aTW7rpZB/PsA0cVOSffVASAFNMkfAKo2zLPQ+IN/V kcFHYRDtctQnENZZ3a4L9gxU0NuKwjvdX1tBhDk7fGzZLc2S+J3G/ea9z5NUNj97 ycUwbmOyLMmqh+Yb+nUrMBwvMpm8HsjzS3Ln3Xlz4rZUCKIfzOfewjmLO3ZbqwQZ bjeiFB4XoyfwacQBPgeR1vCNZRXPw21Th2CYE7p4nqTUdpqHFU5k43ILl1nrpcBE jS9INrLBU88EWvkE6Mh67qIyFey/FQ== =naq9 -----END PGP SIGNATURE----- Merge tag 'regulator-fix-v6.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fix from Mark Brown: "One simple fix for v6.4, some incorrectly specified bitfield masks in the PCA9450 driver" * tag 'regulator-fix-v6.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: pca9450: Fix LDO3OUT and LDO4OUT MASK |
||
|
Linus Torvalds
|
e075d681a2 |
regmap: One more fix for v6.4
The earlier fix to take account of the register data size when limiting raw register writes exposed the fact that the Intel AVMM bus was incorrectly specifying too low a limit on the maximum data transfer, it is only capable of transmitting one register so had set a transfer size limit that couldn't fit both the value and the the register address into a single message. -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmSS8bEACgkQJNaLcl1U h9B1zwf/emwrogeLq+eQ03Q9O4oE7OmbYmbTKKhZHtdwtUxZ4qsZ9aNekcgPw1Kv riZHiL2EC7EKFAqTl1KiGsoJTWQONt32DFcc+27fW6IyXAFc4AMDf2JPnKMtZC83 0R+H0vC/FDVO6lzxNerPuC62ydaBr38XdimyCwYgLtzNWwsZUNh6leXgjFbF3sh7 MEi/SaLH9hcBr0suERnXh3DZUAT7d2kvwL1krSDHF7pvhQ+Z2pn96B1NVnaVVhM1 OlyfQLieRZz1Q2yF2LASI3I9n2IWeToR9i2iaWn2RlGiBzXpo5E5YpEFtH7umCH0 AjoI5Cf44xFXh5asJskRydgI7iKwPQ== =yQ+K -----END PGP SIGNATURE----- Merge tag 'regmap-fix-v6.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap Pull regmap fix from Mark Brown: "One more fix for v6.4 The earlier fix to take account of the register data size when limiting raw register writes exposed the fact that the Intel AVMM bus was incorrectly specifying too low a limit on the maximum data transfer, it is only capable of transmitting one register so had set a transfer size limit that couldn't fit both the value and the the register address into a single message" * tag 'regmap-fix-v6.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: spi-avmm: Fix regmap_bus max_raw_write |
||
Michael S. Tsirkin
|
afd384f0db |
Revert "virtio-blk: support completion batching for the IRQ path"
This reverts commit |
||
|
Linus Torvalds
|
8ba90f5cc7 |
19 hotfixes. 8 of these are cc:stable.
This includes a wholesale reversion of the post-6.4 series "make slab shrink lockless". After input from Dave Chinner it has been decided that we should go a different way. Thread starts at https://lkml.kernel.org/r/ZH6K0McWBeCjaf16@dread.disaster.area. -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQTTMBEPP41GrTpTJgfdBJ7gKXxAjgUCZJH/qAAKCRDdBJ7gKXxA jq7uAP9AtDGHfvOuW5jlHdYfpUBnbfuQDKjiik71UuIxyhtwQQEAqpOBv7UDuhHj NbNIGTIi/xM5vkpjV6CBo9ymR7qTKwo= =uGuc -----END PGP SIGNATURE----- Merge tag 'mm-hotfixes-stable-2023-06-20-12-31' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull hotfixes from Andrew Morton: "19 hotfixes. 8 of these are cc:stable. This includes a wholesale reversion of the post-6.4 series 'make slab shrink lockless'. After input from Dave Chinner it has been decided that we should go a different way [1]" Link: https://lkml.kernel.org/r/ZH6K0McWBeCjaf16@dread.disaster.area [1] * tag 'mm-hotfixes-stable-2023-06-20-12-31' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: selftests/mm: fix cross compilation with LLVM mailmap: add entries for Ben Dooks nilfs2: prevent general protection fault in nilfs_clear_dirty_page() Revert "mm: vmscan: make global slab shrink lockless" Revert "mm: vmscan: make memcg slab shrink lockless" Revert "mm: vmscan: add shrinker_srcu_generation" Revert "mm: shrinkers: make count and scan in shrinker debugfs lockless" Revert "mm: vmscan: hold write lock to reparent shrinker nr_deferred" Revert "mm: vmscan: remove shrinker_rwsem from synchronize_shrinkers()" Revert "mm: shrinkers: convert shrinker_rwsem to mutex" nilfs2: fix buffer corruption due to concurrent device reads scripts/gdb: fix SB_* constants parsing scripts: fix the gfp flags header path in gfp-translate udmabuf: revert 'Add support for mapping hugepages (v4)' mm/khugepaged: fix iteration in collapse_file memfd: check for non-NULL file_seals in memfd_create() syscall mm/vmalloc: do not output a spurious warning when huge vmalloc() fails mm/mprotect: fix do_mprotect_pkey() limit check writeback: fix dereferencing NULL mapping->host on writeback_page_template |
||
|
Linus Torvalds
|
e660abd551 |
ACPI fix for 6.4-rc8
Fix a kernel crash during early resume from ACPI S3 that has been present since the 5.15 cycle when might_sleep() was added to down_timeout(), which in some configurations of the kernel caused an implicit preemption point to trigger at a wrong time. -----BEGIN PGP SIGNATURE----- iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmSRzgISHHJqd0Byand5 c29ja2kubmV0AAoJEILEb/54YlRx7xAP/ifRMO55I2+K4oGO36Iol07TJASzSU6Q mVk5/rw4LbcS/WnONO3T77hkBTCQ/uILkMImV/OwPQgOA+n6Fg5fKQMdGG8tamQb FAJUE0TBDFLSGLl3YjoqYz3euA1ldZvivAukPSfom8G1Xoqcyrx6PfHqMKzL5JQt fLb+8WOPkxtMt6fJ/iWFewkXHMU2/ZqiOpvaCOG3+SrBtf6S+EKnZmiQSxLaZ3o1 LK2Dx5lIWVT+aR6EgrF+3Vvrex0vry7MOI/7da8g3ou9newklAgtGAgUH1sqMDfp dlQv0gksdCnNeBn5mtbcb3ZGsedaoy77WNrdzWod2psySCo0mgE+F8c7iEFBccZW ss9a4Ev7fCtaghrxv/SSvn3CHFdM7wBvRnfrBJhCHTcr93hu8HiSS5GZKEDuRQye wYSCgxHA7YTIetHcb0FZxnJgYHKihqD3qoaKlXcbd2cQXvGJGIGRcWw7COggNpw8 D3TR6/kJiePzEwuTV7EVlsGS26UjSBA73eXsMTxn4CyzJbO5oveLsMmkzMjVathg s/pJIBXnU4i3nTdLjTezioAODhfIAkA7i/c61ZO3Y+bNgve5EoyT5MuFOsejBX3L SJus945AFKNFLzuGVxsvlG+dc1P2fApo10gf5jE5gG9Xo1HLyiHfYK+1Lu5+dKW0 5LLGa6rd/NOs =FyLX -----END PGP SIGNATURE----- Merge tag 'acpi-6.4-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fix from Rafael Wysocki: "Fix a kernel crash during early resume from ACPI S3 that has been present since the 5.15 cycle when might_sleep() was added to down_timeout(), which in some configurations of the kernel caused an implicit preemption point to trigger at a wrong time" * tag 'acpi-6.4-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: sleep: Avoid breaking S3 wakeup due to might_sleep() |
||
|
Linus Torvalds
|
c74e2ac238 |
Thermal control fix for 6.4-rc8
Fix a regression introduced during the 6.3 cycle and causing intel_soc_dts_iosf to report incorrect temperature values due to a coding mistake (Hans de Goede). -----BEGIN PGP SIGNATURE----- iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmSRzXQSHHJqd0Byand5 c29ja2kubmV0AAoJEILEb/54YlRx64cP/0t73vzzBYmtyarWT/akpz/XK+ND82te E8uOutsmINLn6ALAkgXqGFTQlcZVX3eZMPDL0BukDd7IktvqTxzGFD16SREBNv6A XSiSDZnjrXfbuBhiBTjynVq7m1YW1+VEuYQL3yhGOTGWlszpiSo8K1AYkuW6gOiS 0Lmkq89q+QNpHyEZb8dRfcY95bXLQkwb+22mrizoN8WqC2ybiEt7y2GyzPeqSXge Zcu/kC28iQsDzNTPv5s+qL0SJPywyACLIQgPEech2TL+TFY5q62PoPpkok/tQ9SS o1YDUdDjanW4ubG0lt5qWs0srn1ScywwRM9sp/Kn0QyrB3z1DPwYKJtEoP01/z2R z6mxGrGh0Bhi/iKo8YYkDi2ALnunOOINH7myZayd7XtrMmRqF0wtfobo2EF4Duq9 bm6vgoTRcK+A2mlKXRKZKNf8JbeQAsXTC6mMQ7YjAAXbm0NL/1Y2HQVxY7x4lRvr jaqlT0oPipPzdJUIvWGQSVu1a5LzznvC4Bn0o+bB6VldACpynutyiWXqjvi+GGab 7CXY/DJt2K+Uj8hPqpucwYJ2qrL3GMtg9a7bjK4wyHxMAVA5GNDibWMKGepRA+qM Sov8Bgc1VzSKqy1YpLNqeCA09lSRSC9OvDMZt+0LteEK62WbX4dJFDKXv9ruDhZh qSYGJ66QSrvQ =dLDl -----END PGP SIGNATURE----- Merge tag 'thermal-6.4-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull thermal control fix from Rafael Wysocki: "Fix a regression introduced during the 6.3 cycle causing intel_soc_dts_iosf to report incorrect temperature values due to a coding mistake (Hans de Goede)" * tag 'thermal-6.4-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: thermal/intel/intel_soc_dts_iosf: Fix reporting wrong temperatures |
||
|
Linus Torvalds
|
2e30b97343 |
Tracing fixes for 6.4:
- Fix MAINTAINERS file to point to proper mailing list for rtla and rv
The mailing list pointed to linux-trace-devel instead of
linux-trace-kernel. The former is for the tracing libraries
and the latter is for anything in the Linux kernel tree.
The wrong mailing list was used because linux-trace-kernel did not
exist when rtla and rv were created.
- User events:
. Fix matching of dynamic events to their user events
When user writes to dynamic_events file, a lookup of the
registered dynamic events are made, but there were some cases
that a match could be incorrectly made.
. Add auto cleanup of user events
Have the user events automatically get removed when the last
reference (file descriptor) is closed. This was asked for to
prevent leaks of user events hanging around needing admins
to clean them up.
. Add persistent logic (but not let user space use it yet)
In some cases, having a persistent user event (one that does not
get cleaned up automatically) is useful. But there's still
debates about how to expose this to user space. The infrastructure
is added, but the API is not.
. Update the selftests
Update the user event selftests to reflect the above changes.
-----BEGIN PGP SIGNATURE-----
iIoEABYIADIWIQRRSw7ePDh/lE+zeZMp5XQQmuv6qgUCZJGrABQccm9zdGVkdEBn
b29kbWlzLm9yZwAKCRAp5XQQmuv6qgRDAQDvF8ktlcn+gqyUxt2OcTlbBh0jqS0b
FKXYdq6FTgfWYQD/ctunFbPdzn4D6Kc/lG8p4QxpMmtA19BUOPwEt3CkAwM=
=CDzr
-----END PGP SIGNATURE-----
Merge tag 'trace-v6.4-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull tracing fixes from Steven Rostedt:
- Fix MAINTAINERS file to point to proper mailing list for rtla and rv
The mailing list pointed to linux-trace-devel instead of
linux-trace-kernel. The former is for the tracing libraries and the
latter is for anything in the Linux kernel tree. The wrong mailing
list was used because linux-trace-kernel did not exist when rtla and
rv were created.
- User events:
- Fix matching of dynamic events to their user events
When user writes to dynamic_events file, a lookup of the
registered dynamic events is made, but there were some cases that
a match could be incorrectly made.
- Add auto cleanup of user events
Have the user events automatically get removed when the last
reference (file descriptor) is closed. This was asked for to
prevent leaks of user events hanging around needing admins to
clean them up.
- Add persistent logic (but not let user space use it yet)
In some cases, having a persistent user event (one that does not
get cleaned up automatically) is useful. But there's still debates
about how to expose this to user space. The infrastructure is
added, but the API is not.
- Update the selftests
Update the user event selftests to reflect the above changes"
* tag 'trace-v6.4-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
tracing/user_events: Document auto-cleanup and remove dyn_event refs
selftests/user_events: Adapt dyn_test to non-persist events
selftests/user_events: Ensure auto cleanup works as expected
tracing/user_events: Add auto cleanup and future persist flag
tracing/user_events: Track refcount consistently via put/get
tracing/user_events: Store register flags on events
tracing/user_events: Remove user_ns walk for groups
selftests/user_events: Add perf self-test for empty arguments events
selftests/user_events: Clear the events after perf self-test
selftests/user_events: Add ftrace self-test for empty arguments events
tracing/user_events: Fix the incorrect trace record for empty arguments events
tracing: Modify print_fields() for fields output order
tracing/user_events: Handle matching arguments that is null from dyn_events
tracing/user_events: Prevent same name but different args event
tracing/rv/rtla: Update MAINTAINERS file to point to proper mailing list
|
||
|
Linus Torvalds
|
4b0c7a1ba0 |
for-6.4-rc7-tag
-----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE8rQSAMVO+zA4DBdWxWXV+ddtWDsFAmSR56sACgkQxWXV+ddt WDvdORAAk3IVO8V6md56wSQBC0S2itaMomSYlzBJL8fqriKZwhaG6C/pJPyt0wyQ zj1ZsJqX3WwhDssVWIYNrj6CLr7gOQiMpbX363PYTFc6Hvrw8FqDVk/VjworsSmC IyVo3K11HCLIapbYrB1QLxzufDqYieYw6c2jS1elnwUUssvPHxonlfc2IZ1nef9z jLS9ZBbEjO7KaUwKrDJ1g4OFljwSnuYCW41fZWFaoXnvlBk84BbBvcRisFY69a++ Kv0ux1Z2NJXmBOzKG4ZXCCNamwHj/oHqOT2cZm7ZzWrruIo5IP/Q4lzXHxKkbxA0 7cUfS+O7UqwBDzZZsBEos6Pn82q1rj9RFQkw8B6gCazwRN16TiA2U3AqOkjPZolL RXMhLB1oEpQbyxB/PMhk63yV3uHs7VxVvyycuG9qlynFCRVFNxj4hE4TXFJu97DD TBOXmUaCBbyRMX72BycziW4hwsbWafkmZqRWV8wHqRXOD4nd7QCj51ZOFTIsNmbq Gpo2cJxmzEeYJC/o4Kq+ABCcmrphMhgALugR8T0TBP9gqp0WVs6NmixTzFEc9Zo6 VbcN721J7R7yYBknJIUQ5GuJJddhu4Ya86vk/N2eBsGVSq0KxCtJoHbM4RBYTaTl NiXcdXu1Cr4TojoZN5W6cH6BBSCvIcEBruQtNkoIj5G0Wfrvt0U= =IFO0 -----END PGP SIGNATURE----- Merge tag 'for-6.4-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fix from David Sterba: "One more regression fix for an assertion failure that uncovered a nasty problem with stripe calculations. This is caused by a u32 overflow when there are enough devices. The fstests require 6 so this hasn't been caught, I was able to hit it with 8. The fix is minimal and only adds u64 casts, we'll clean that up later. I did various additional tests to be sure" * tag 'for-6.4-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: fix u32 overflows when left shifting stripe_nr |
||
Russ Weight
|
c8e796895e |
regmap: spi-avmm: Fix regmap_bus max_raw_write
The max_raw_write member of the regmap_spi_avmm_bus structure is defined as: .max_raw_write = SPI_AVMM_VAL_SIZE * MAX_WRITE_CNT SPI_AVMM_VAL_SIZE == 4 and MAX_WRITE_CNT == 1 so this results in a maximum write transfer size of 4 bytes which provides only enough space to transfer the address of the target register. It provides no space for the value to be transferred. This bug became an issue (divide-by-zero in _regmap_raw_write()) after the following was accepted into mainline: commit |
||
|
Linus Torvalds
|
99ec1ed7c2 |
four smb3 server fixes, all also for stable
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEE6fsu8pdIjtWE/DpLiiy9cAdyT1EFAmSNFQcACgkQiiy9cAdy
T1F/0gwAs396WKBsx5fEiHPucWOdBemT/IqSW+ZTY5LNwB6A4B71W7D8w5by/0MU
bXprt3XJuPnb21euW2L8BlGg9jJyd3GBcJWv4/GbOzQ//ZMkyT50sZbrWSDP2luq
jELbe+CS+xOimOSBnIEDxYWqWxetTfDUwlbUHTrHaMGCCZcRJZmEXsJEGelSUx4+
uipbj0sMUB3x4H7MyEND0bbGxhMKzZXsymRvKTsS3aR1qTioQ8FoNrmDlUBCgN4u
qbEsG7GGQTj/WrdUrzbQ9DkZa17C+2PNV/j1xKGu/9hBpr2lZSyNmj46MqmPegKD
4lPwG0GmWEXWuRP7QCXNzS9p9Rkms2C1MnPH7x2NqzoOXsJSZFb4j/fp0oKG4mu1
zoIjZ5cA+wsOxoJTyOHNdWYFzBcPnUIQ5ZP6696alejA9TtdxqrQdhEBNO9YnsCP
xreIMADWX8pIjcdDx6DSQ8ZzhyB5Uu46j0K1Ve1e/58HX8FhGrBcOQGFexIXjuMa
8655VONz
=yfOS
-----END PGP SIGNATURE-----
Merge tag '6.4-rc6-smb3-server-fixes' of git://git.samba.org/ksmbd
Pull smb server fixes from Steve French:
"Four smb3 server fixes, all also for stable:
- fix potential oops in parsing compounded requests
- fix various paths (mkdir, create etc) where mnt_want_write was not
checked first
- fix slab out of bounds in check_message and write"
* tag '6.4-rc6-smb3-server-fixes' of git://git.samba.org/ksmbd:
ksmbd: validate session id and tree id in the compound request
ksmbd: fix out-of-bound read in smb2_write
ksmbd: add mnt_want_write to ksmbd vfs functions
ksmbd: validate command payload size
|
||
Qu Wenruo
|
a7299a18a1 |
btrfs: fix u32 overflows when left shifting stripe_nr
[BUG] David reported an ASSERT() get triggered during fio load on 8 devices with data/raid6 and metadata/raid1c3: fio --rw=randrw --randrepeat=1 --size=3000m \ --bsrange=512b-64k --bs_unaligned \ --ioengine=libaio --fsync=1024 \ --name=job0 --name=job1 \ The ASSERT() is from rbio_add_bio() of raid56.c: ASSERT(orig_logical >= full_stripe_start && orig_logical + orig_len <= full_stripe_start + rbio->nr_data * BTRFS_STRIPE_LEN); Which is checking if the target rbio is crossing the full stripe boundary. [100.789] assertion failed: orig_logical >= full_stripe_start && orig_logical + orig_len <= full_stripe_start + rbio->nr_data * BTRFS_STRIPE_LEN, in fs/btrfs/raid56.c:1622 [100.795] ------------[ cut here ]------------ [100.796] kernel BUG at fs/btrfs/raid56.c:1622! [100.797] invalid opcode: 0000 [#1] PREEMPT SMP KASAN [100.798] CPU: 1 PID: 100 Comm: kworker/u8:4 Not tainted 6.4.0-rc6-default+ #124 [100.799] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552-rebuilt.opensuse.org 04/01/2014 [100.802] Workqueue: writeback wb_workfn (flush-btrfs-1) [100.803] RIP: 0010:rbio_add_bio+0x204/0x210 [btrfs] [100.806] RSP: 0018:ffff888104a8f300 EFLAGS: 00010246 [100.808] RAX: 00000000000000a1 RBX: ffff8881075907e0 RCX: ffffed1020951e01 [100.809] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 0000000000000001 [100.811] RBP: 0000000141d20000 R08: 0000000000000001 R09: ffff888104a8f04f [100.813] R10: ffffed1020951e09 R11: 0000000000000003 R12: ffff88810e87f400 [100.815] R13: 0000000041d20000 R14: 0000000144529000 R15: ffff888101524000 [100.817] FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000 [100.821] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [100.822] CR2: 000055d54e44c270 CR3: 000000010a9a1006 CR4: 00000000003706a0 [100.824] Call Trace: [100.825] <TASK> [100.825] ? die+0x32/0x80 [100.826] ? do_trap+0x12d/0x160 [100.827] ? rbio_add_bio+0x204/0x210 [btrfs] [100.827] ? rbio_add_bio+0x204/0x210 [btrfs] [100.829] ? do_error_trap+0x90/0x130 [100.830] ? rbio_add_bio+0x204/0x210 [btrfs] [100.831] ? handle_invalid_op+0x2c/0x30 [100.833] ? rbio_add_bio+0x204/0x210 [btrfs] [100.835] ? exc_invalid_op+0x29/0x40 [100.836] ? asm_exc_invalid_op+0x16/0x20 [100.837] ? rbio_add_bio+0x204/0x210 [btrfs] [100.837] raid56_parity_write+0x64/0x270 [btrfs] [100.838] btrfs_submit_chunk+0x26e/0x800 [btrfs] [100.840] ? btrfs_bio_init+0x80/0x80 [btrfs] [100.841] ? release_pages+0x503/0x6d0 [100.842] ? folio_unlock+0x2f/0x60 [100.844] ? __folio_put+0x60/0x60 [100.845] ? btrfs_do_readpage+0xae0/0xae0 [btrfs] [100.847] btrfs_submit_bio+0x21/0x60 [btrfs] [100.847] submit_one_bio+0x6a/0xb0 [btrfs] [100.849] extent_write_cache_pages+0x395/0x680 [btrfs] [100.850] ? __extent_writepage+0x520/0x520 [btrfs] [100.851] ? mark_usage+0x190/0x190 [100.852] extent_writepages+0xdb/0x130 [btrfs] [100.853] ? extent_write_locked_range+0x480/0x480 [btrfs] [100.854] ? mark_usage+0x190/0x190 [100.854] ? attach_extent_buffer_page+0x220/0x220 [btrfs] [100.855] ? reacquire_held_locks+0x178/0x280 [100.856] ? writeback_sb_inodes+0x245/0x7f0 [100.857] do_writepages+0x102/0x2e0 [100.858] ? page_writeback_cpu_online+0x10/0x10 [100.859] ? __lock_release.isra.0+0x14a/0x4d0 [100.860] ? reacquire_held_locks+0x280/0x280 [100.861] ? __lock_acquired+0x1e9/0x3d0 [100.862] ? do_raw_spin_lock+0x1b0/0x1b0 [100.863] __writeback_single_inode+0x94/0x450 [100.864] writeback_sb_inodes+0x372/0x7f0 [100.864] ? lock_sync+0xd0/0xd0 [100.865] ? do_raw_spin_unlock+0x93/0xf0 [100.866] ? sync_inode_metadata+0xc0/0xc0 [100.867] ? rwsem_optimistic_spin+0x340/0x340 [100.868] __writeback_inodes_wb+0x70/0x130 [100.869] wb_writeback+0x2d1/0x530 [100.869] ? __writeback_inodes_wb+0x130/0x130 [100.870] ? lockdep_hardirqs_on_prepare.part.0+0xf1/0x1c0 [100.870] wb_do_writeback+0x3eb/0x480 [100.871] ? wb_writeback+0x530/0x530 [100.871] ? mark_lock_irq+0xcd0/0xcd0 [100.872] wb_workfn+0xe0/0x3f0< [CAUSE] Commit |
||
|
Linus Torvalds
|
692b7dc87c |
hyperv-fixes for 6.4-rc8
-----BEGIN PGP SIGNATURE----- iQFHBAABCgAxFiEEIbPD0id6easf0xsudhRwX5BBoF4FAmSQ3ioTHHdlaS5saXVA a2VybmVsLm9yZwAKCRB2FHBfkEGgXpREB/9nMJ5PbgsxpqKiV3ckodXZp7wLkFAv VK12KBZcjAr8kbZON0CHXWssC/QLBV9+UYDjvA7ciEjkzBZoIY8GMAjFZ4NNveTm ssZPaxg0DHX7SzVO6qDrZBwjyGmjPh8vH5TDsb6QPYk8WMuwYy+QZMWTEcxr7QU4 o3GRbt+JShS05s5Q1B3pSeztyxDxJh1potyoTfaY1sbih0c+r6mtewlpRW3KgoSc ukssybTmNyRRpDos/PlT2e0gRpIzlYQnzE+sj4mGOOQFh4wGOR8wGcNPr4yirrcI gy/4nvIwxp0uLW0C30FBlqzNt9dirOSRflXq/Pp4MdQcSM3hpeONbDxx =0aJ5 -----END PGP SIGNATURE----- Merge tag 'hyperv-fixes-signed-20230619' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux Pull hyperv fixes from Wei Liu: - Fix races in Hyper-V PCI controller (Dexuan Cui) - Fix handling of hyperv_pcpu_input_arg (Michael Kelley) - Fix vmbus_wait_for_unload to scan present CPUs (Michael Kelley) - Call hv_synic_free in the failure path of hv_synic_alloc (Dexuan Cui) - Add noop for real mode handlers for virtual trust level code (Saurabh Sengar) * tag 'hyperv-fixes-signed-20230619' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: PCI: hv: Add a per-bus mutex state_lock Revert "PCI: hv: Fix a timing issue which causes kdump to fail occasionally" PCI: hv: Remove the useless hv_pcichild_state from struct hv_pci_dev PCI: hv: Fix a race condition in hv_irq_unmask() that can cause panic PCI: hv: Fix a race condition bug in hv_pci_query_relations() arm64/hyperv: Use CPUHP_AP_HYPERV_ONLINE state to fix CPU online sequencing x86/hyperv: Fix hyperv_pcpu_input_arg handling when CPUs go online/offline Drivers: hv: vmbus: Fix vmbus_wait_for_unload() to scan present CPUs Drivers: hv: vmbus: Call hv_synic_free() if hv_synic_alloc() fails x86/hyperv/vtl: Add noop for realmode pointers |
||
Mark Brown
|
0518dbe97f |
selftests/mm: fix cross compilation with LLVM
Currently the MM selftests attempt to work out the target architecture by using CROSS_COMPILE or otherwise querying the host machine, storing the target architecture in a variable called MACHINE rather than the usual ARCH though as far as I can tell (including for x86_64) the value is the same as we would use for architecture. When cross compiling with LLVM we don't need a CROSS_COMPILE as LLVM can support many target architectures in a single build so this logic does not work, CROSS_COMPILE is not set and we end up selecting tests for the host rather than target architecture. Fix this by using the more standard ARCH to describe the architecture, taking it from the environment if specified. Link: https://lkml.kernel.org/r/20230614-kselftest-mm-llvm-v1-1-180523f277d3@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Tom Rix <trix@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
Ben Dooks
|
823b37e8a7 |
mailmap: add entries for Ben Dooks
I am going to be losing my sifive.com address soon and I also realised my old Simtec address (from >10 years ago) is also not been updates so update .mailmap for both. Link: https://lkml.kernel.org/r/20230615081820.79485-1-ben.dooks@codethink.co.uk Signed-off-by: Ben Dooks <ben.dooks@sifive.com> Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
Ryusuke Konishi
|
782e53d0c1 |
nilfs2: prevent general protection fault in nilfs_clear_dirty_page()
In a syzbot stress test that deliberately causes file system errors on nilfs2 with a corrupted disk image, it has been reported that nilfs_clear_dirty_page() called from nilfs_clear_dirty_pages() can cause a general protection fault. In nilfs_clear_dirty_pages(), when looking up dirty pages from the page cache and calling nilfs_clear_dirty_page() for each dirty page/folio retrieved, the back reference from the argument page to "mapping" may have been changed to NULL (and possibly others). It is necessary to check this after locking the page/folio. So, fix this issue by not calling nilfs_clear_dirty_page() on a page/folio after locking it in nilfs_clear_dirty_pages() if the back reference "mapping" from the page/folio is different from the "mapping" that held the page/folio just before. Link: https://lkml.kernel.org/r/20230612021456.3682-1-konishi.ryusuke@gmail.com Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com> Reported-by: syzbot+53369d11851d8f26735c@syzkaller.appspotmail.com Closes: https://lkml.kernel.org/r/000000000000da4f6b05eb9bf593@google.com Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
Qi Zheng
|
71c3ad65fa |
Revert "mm: vmscan: make global slab shrink lockless"
This reverts commit |
||
|
Qi Zheng
|
7cee360319 |
Revert "mm: vmscan: make memcg slab shrink lockless"
This reverts commit |
||
|
Qi Zheng
|
d6ecbcd70f |
Revert "mm: vmscan: add shrinker_srcu_generation"
This reverts commit |
||
|
Qi Zheng
|
1a554ecc97 |
Revert "mm: shrinkers: make count and scan in shrinker debugfs lockless"
This reverts commit |
||
|
Qi Zheng
|
c534f7cca6 |
Revert "mm: vmscan: hold write lock to reparent shrinker nr_deferred"
This reverts commit |
||
|
Qi Zheng
|
07252b0f97 |
Revert "mm: vmscan: remove shrinker_rwsem from synchronize_shrinkers()"
This reverts commit |
||
|
Qi Zheng
|
47a7c01c3e |
Revert "mm: shrinkers: convert shrinker_rwsem to mutex"
Patch series "revert shrinker_srcu related changes". This patch (of 7): This reverts commit |
||
|
Ryusuke Konishi
|
679bd7ebdd |
nilfs2: fix buffer corruption due to concurrent device reads
As a result of analysis of a syzbot report, it turned out that in three cases where nilfs2 allocates block device buffers directly via sb_getblk, concurrent reads to the device can corrupt the allocated buffers. Nilfs2 uses sb_getblk for segment summary blocks, that make up a log header, and the super root block, that is the trailer, and when moving and writing the second super block after fs resize. In any of these, since the uptodate flag is not set when storing metadata to be written in the allocated buffers, the stored metadata will be overwritten if a device read of the same block occurs concurrently before the write. This causes metadata corruption and misbehavior in the log write itself, causing warnings in nilfs_btree_assign() as reported. Fix these issues by setting an uptodate flag on the buffer head on the first or before modifying each buffer obtained with sb_getblk, and clearing the flag on failure. When setting the uptodate flag, the lock_buffer/unlock_buffer pair is used to perform necessary exclusive control, and the buffer is filled to ensure that uninitialized bytes are not mixed into the data read from others. As for buffers for segment summary blocks, they are filled incrementally, so if the uptodate flag was unset on their allocation, set the flag and zero fill the buffer once at that point. Also, regarding the superblock move routine, the starting point of the memset call to zerofill the block is incorrectly specified, which can cause a buffer overflow on file systems with block sizes greater than 4KiB. In addition, if the superblock is moved within a large block, it is necessary to assume the possibility that the data in the superblock will be destroyed by zero-filling before copying. So fix these potential issues as well. Link: https://lkml.kernel.org/r/20230609035732.20426-1-konishi.ryusuke@gmail.com Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com> Reported-by: syzbot+31837fe952932efc8fb9@syzkaller.appspotmail.com Closes: https://lkml.kernel.org/r/00000000000030000a05e981f475@google.com Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
Florian Fainelli
|
6a59cb5158 |
scripts/gdb: fix SB_* constants parsing
--0000000000009a0c9905fd9173ad Content-Transfer-Encoding: 8bit After |
||
Prathu Baronia
|
2049a7d0cb |
scripts: fix the gfp flags header path in gfp-translate
Since gfp flags have been shifted to gfp_types.h so update the path in
the gfp-translate script.
Link: https://lkml.kernel.org/r/20230608154450.21758-1-prathubaronia2011@gmail.com
Fixes:
|
||
Mike Kravetz
|
b7cb382190 |
udmabuf: revert 'Add support for mapping hugepages (v4)'
This effectively reverts commit |
||
David Stevens
|
c8a8f3b4a9 |
mm/khugepaged: fix iteration in collapse_file
Remove an unnecessary call to xas_set(index) when iterating over the
target range in collapse_file. The extra call to xas_set reset the xas
cursor to the top of the tree, causing the xas_next call on the next
iteration to walk the tree to index instead of advancing to index+1. This
returned the same page again, which would cause collapse_file to fail
because the page is already locked.
This bug was hidden when CONFIG_DEBUG_VM was set. When that config was
used, the xas_load in a subsequent VM_BUG_ON assert would walk xas from
the top of the tree to index, causing the xas_next call on the next loop
iteration to advance the cursor as expected.
Link: https://lkml.kernel.org/r/20230607053135.2087354-1-stevensd@google.com
Fixes:
|
||
Roberto Sassu
|
935d44acf6 |
memfd: check for non-NULL file_seals in memfd_create() syscall
Ensure that file_seals is non-NULL before using it in the memfd_create()
syscall. One situation in which memfd_file_seals_ptr() could return a
NULL pointer when CONFIG_SHMEM=n, oopsing the kernel.
Link: https://lkml.kernel.org/r/20230607132427.2867435-1-roberto.sassu@huaweicloud.com
Fixes:
|
||
Lorenzo Stoakes
|
95a301eefa |
mm/vmalloc: do not output a spurious warning when huge vmalloc() fails
In __vmalloc_area_node() we always warn_alloc() when an allocation
performed by vm_area_alloc_pages() fails unless it was due to a pending
fatal signal.
However, huge page allocations instigated either by vmalloc_huge() or
__vmalloc_node_range() (or a caller that invokes this like kvmalloc() or
kvmalloc_node()) always falls back to order-0 allocations if the huge page
allocation fails.
This renders the warning useless and noisy, especially as all callers
appear to be aware that this may fallback. This has already resulted in
at least one bug report from a user who was confused by this (see link).
Therefore, simply update the code to only output this warning for order-0
pages when no fatal signal is pending.
Link: https://bugzilla.suse.com/show_bug.cgi?id=1211410
Link: https://lkml.kernel.org/r/20230605201107.83298-1-lstoakes@gmail.com
Fixes:
|
||
Liam R. Howlett
|
77795f900e |
mm/mprotect: fix do_mprotect_pkey() limit check
The return of do_mprotect_pkey() can still be incorrectly returned as
success if there is a gap that spans to or beyond the end address passed
in. Update the check to ensure that the end address has indeed been seen.
Link: https://lore.kernel.org/all/CABi2SkXjN+5iFoBhxk71t3cmunTk-s=rB4T7qo0UQRh17s49PQ@mail.gmail.com/
Link: https://lkml.kernel.org/r/20230606182912.586576-1-Liam.Howlett@oracle.com
Fixes:
|
||
Rafael Aquini
|
54abe19e00 |
writeback: fix dereferencing NULL mapping->host on writeback_page_template
When commit |
||
|
Linus Torvalds
|
dbad9ce939 |
AFS fixes
-----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEqG5UsNXhtOCrfGQP+7dXa6fLC2sFAmSQXCQACgkQ+7dXa6fL C2v84w//c6bOgcf8M/bA7xu+5I8COMuD0LcohZ9CK9EYMPdOMyFNTDrE0QUrPEwS Ga6tANOsUNeVsuhRMmpt0FjeMzvnw1yYFT6c6PxLSqv2bgzUJbUswMIGgRp///8Z vpNOCyPBhNwYXXniJNqqK0KuEfkQ0xyKWPniEHWeWFFR9p44lOSloYaGX3YNNsxO NYIep8U7zMRExyuVAsNOyk9A6fvHGoH91e6I6zKJK3D0rN30VoowkQPU48e3iqAP j/GE1mk5QsaQIoSNmP0Osvu+9ayhg9kRFprkhLFZ3gRw+1Br2Mi5ePfLFPkJ4C9C kVeruiJIObv0G66cKzGLPHzIqM3ay/1senaa+LtOdgSub804i0DD4pCSQCmgrVOE IclrYbDPcQisD0mykMvJ3t6nRqJxMSs8p3UlTvXKE1+6ACyT0L/7vbPO6pENs0SZ bIvijWvyFbxWIQVGtEk6J3SF60EA5rWC8Vfjpz/IXvpEnD2T6Ej2YgADCvTHDeiB FNaRLUupZSygwrZHsZiDSKG0SQCshr9HdHgV4O4fer89tHPTy0wEtadR6/Gm8ZPj khO18Gb6VwydlMzI6N53f4Y8b7WV0G45/Xytq7d+wfrfn2dXr/cz3AiI3bfy1JXT I6ADC416ZBVheOKFKHEXWxQIPoja7lyYrk0kKn6LAwLFtJmyoPc= =CfQg -----END PGP SIGNATURE----- Merge tag 'afs-fixes-20230719' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs Pull AFS writeback fixes from David Howells: - release the acquired batch before returning if we got >=5 skips - retry a page we had to wait for rather than skipping over it after the wait * tag 'afs-fixes-20230719' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: afs: Fix waiting for writeback then skipping folio afs: Fix dangling folio ref counts in writeback |
||
Teresa Remmet
|
7257d930aa |
regulator: pca9450: Fix LDO3OUT and LDO4OUT MASK
L3_OUT and L4_OUT Bit fields range from Bit 0:4 and thus the
mask should be 0x1F instead of 0x0F.
Fixes:
|
||
Vishal Moola (Oracle)
|
819da022dd |
afs: Fix waiting for writeback then skipping folio
Commit |
||
|
Vishal Moola (Oracle)
|
a2b6f2ab3e |
afs: Fix dangling folio ref counts in writeback
Commit |
||
|
Linus Torvalds
|
45a3e24f65 | Linux 6.4-rc7 v6.4-rc7 | ||
|
Linus Torvalds
|
8c1f0c38b3 |
SCSI fixes on 20230618
Four fixes, all in drivers: three fairly obvious small ones and a large one in aacraid to add block queue completion mapping and fix a CPU offline hang. Signed-off-by: James E.J. Bottomley <jejb@linux.ibm.com> -----BEGIN PGP SIGNATURE----- iJwEABMIAEQWIQTnYEDbdso9F2cI+arnQslM7pishQUCZI8E7CYcamFtZXMuYm90 dG9tbGV5QGhhbnNlbnBhcnRuZXJzaGlwLmNvbQAKCRDnQslM7pishZ0gAQCDspWA 8p9dHHJKjtIXb1DlPBPunOLJaheGFqr/dkrcBAD+PjH4NAhHO3SnqCqL5ncf16ED oBE8rc8gBHK/2V6uIJ8= =rubj -----END PGP SIGNATURE----- Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Four fixes, all in drivers: three fairly obvious small ones and a large one in aacraid to add block queue completion mapping and fix a CPU offline hang" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: lpfc: Fix incorrect big endian type assignment in bsg loopback path scsi: target: core: Fix error path in target_setup_session() scsi: storvsc: Always set no_report_opcodes scsi: aacraid: Reply queue mapping to CPUs based on IRQ affinity |
||
|
Linus Torvalds
|
ecbcffe3b7 |
ata fixes for 6.4-rc7
- Avoid deadlocks on resume from sleep by delaying scsi rescan until
the scsi device is also fully resumed.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQSRPv8tYSvhwAzJdzjdoc3SxdoYdgUCZI50JAAKCRDdoc3SxdoY
ds+rAQCKnd8/Vmdh76a1DJTEwCQ/+2bAR0RSf6kOX8nwEUc1BgD/fhDIUBBFEWK9
nszZA2BreiTkx5iUycVn0vOedeeDoAc=
=lrpe
-----END PGP SIGNATURE-----
Merge tag 'ata-6.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata
Pull ata fix from Damien Le Moal:
- Avoid deadlocks on resume from sleep by delaying scsi rescan until
the scsi device is also fully resumed.
* tag 'ata-6.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata:
ata: libata-scsi: Avoid deadlock on rescan after device resume
|
||
|
Linus Torvalds
|
1dbbfe254d |
parisc architecture fixes for kernel v6.4-rc7:
- Drop redundant register definitions to fix build with latest binutils -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCZI6RBwAKCRD3ErUQojoP X/n5AP4vtOgq4XHMC0gAaGPvIg3JN6LBgRcbd/iR1NpmTrLH2gEAxX36EivSiI+A 8IiTxM4KShPuMd9OGGsEeZQcoAIOHwE= =NqkQ -----END PGP SIGNATURE----- Merge tag 'parisc-for-6.4-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fix from Helge Deller: - Drop redundant register definitions to fix build with latest binutils * tag 'parisc-for-6.4-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Delete redundant register definitions in <asm/assembly.h> |
||
|
Liam R. Howlett
|
606c812eb1 |
mm/mmap: Fix error path in do_vmi_align_munmap()
The error unrolling was leaving the VMAs detached in many cases and
leaving the locked_vm statistic altered, and skipping the unrolling
entirely in the case of the vma tree write failing.
Fix the error path by re-attaching the detached VMAs and adding the
necessary goto for the failed vma tree write, and fix the locked_vm
statistic by only updating after the vma tree write succeeds.
Fixes:
|
||
Dexuan Cui
|
067d6ec7ed |
PCI: hv: Add a per-bus mutex state_lock
In the case of fast device addition/removal, it's possible that
hv_eject_device_work() can start to run before create_root_hv_pci_bus()
starts to run; as a result, the pci_get_domain_bus_and_slot() in
hv_eject_device_work() can return a 'pdev' of NULL, and
hv_eject_device_work() can remove the 'hpdev', and immediately send a
message PCI_EJECTION_COMPLETE to the host, and the host immediately
unassigns the PCI device from the guest; meanwhile,
create_root_hv_pci_bus() and the PCI device driver can be probing the
dead PCI device and reporting timeout errors.
Fix the issue by adding a per-bus mutex 'state_lock' and grabbing the
mutex before powering on the PCI bus in hv_pci_enter_d0(): when
hv_eject_device_work() starts to run, it's able to find the 'pdev' and call
pci_stop_and_remove_bus_device(pdev): if the PCI device driver has
loaded, the PCI device driver's probe() function is already called in
create_root_hv_pci_bus() -> pci_bus_add_devices(), and now
hv_eject_device_work() -> pci_stop_and_remove_bus_device() is able
to call the PCI device driver's remove() function and remove the device
reliably; if the PCI device driver hasn't loaded yet, the function call
hv_eject_device_work() -> pci_stop_and_remove_bus_device() is able to
remove the PCI device reliably and the PCI device driver's probe()
function won't be called; if the PCI device driver's probe() is already
running (e.g., systemd-udev is loading the PCI device driver), it must
be holding the per-device lock, and after the probe() finishes and releases
the lock, hv_eject_device_work() -> pci_stop_and_remove_bus_device() is
able to proceed to remove the device reliably.
Fixes:
|
||
|
Dexuan Cui
|
a847234e24 |
Revert "PCI: hv: Fix a timing issue which causes kdump to fail occasionally"
This reverts commit |
||
|
Dexuan Cui
|
add9195e69 |
PCI: hv: Remove the useless hv_pcichild_state from struct hv_pci_dev
The hpdev->state is never really useful. The only use in hv_pci_eject_device() and hv_eject_device_work() is not really necessary. Signed-off-by: Dexuan Cui <decui@microsoft.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Acked-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230615044451.5580-4-decui@microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> |
||
|
Dexuan Cui
|
2738d5ab79 |
PCI: hv: Fix a race condition in hv_irq_unmask() that can cause panic
When the host tries to remove a PCI device, the host first sends a
PCI_EJECT message to the guest, and the guest is supposed to gracefully
remove the PCI device and send a PCI_EJECTION_COMPLETE message to the host;
the host then sends a VMBus message CHANNELMSG_RESCIND_CHANNELOFFER to
the guest (when the guest receives this message, the device is already
unassigned from the guest) and the guest can do some final cleanup work;
if the guest fails to respond to the PCI_EJECT message within one minute,
the host sends the VMBus message CHANNELMSG_RESCIND_CHANNELOFFER and
removes the PCI device forcibly.
In the case of fast device addition/removal, it's possible that the PCI
device driver is still configuring MSI-X interrupts when the guest receives
the PCI_EJECT message; the channel callback calls hv_pci_eject_device(),
which sets hpdev->state to hv_pcichild_ejecting, and schedules a work
hv_eject_device_work(); if the PCI device driver is calling
pci_alloc_irq_vectors() -> ... -> hv_compose_msi_msg(), we can break the
while loop in hv_compose_msi_msg() due to the updated hpdev->state, and
leave data->chip_data with its default value of NULL; later, when the PCI
device driver calls request_irq() -> ... -> hv_irq_unmask(), the guest
crashes in hv_arch_irq_unmask() due to data->chip_data being NULL.
Fix the issue by not testing hpdev->state in the while loop: when the
guest receives PCI_EJECT, the device is still assigned to the guest, and
the guest has one minute to finish the device removal gracefully. We don't
really need to (and we should not) test hpdev->state in the loop.
Fixes:
|