Revision tags: v6.6.67, v6.6.66, v6.6.65, v6.6.64, v6.6.63, v6.6.62, v6.6.61, v6.6.60, v6.6.59, v6.6.58, v6.6.57 |
|
#
fac59652 |
| 10-Oct-2024 |
Andrew Jeffery <andrew@codeconstruct.com.au> |
Merge tag 'v6.6.56' into for/openbmc/dev-6.6
This is the 6.6.56 stable release
|
Revision tags: v6.6.56, v6.6.55, v6.6.54, v6.6.53, v6.6.52, v6.6.51, v6.6.50, v6.6.49, v6.6.48, v6.6.47, v6.6.46, v6.6.45, v6.6.44, v6.6.43, v6.6.42, v6.6.41, v6.6.40, v6.6.39, v6.6.38, v6.6.37 |
|
#
b66ff9a3 |
| 27-Jun-2024 |
Christoph Hellwig <hch@lst.de> |
loop: don't set QUEUE_FLAG_NOMERGES
[ Upstream commit 667ea36378cf7f669044b27871c496e1559c872a ]
QUEUE_FLAG_NOMERGES isn't really a driver interface, but a user tunable. There also isn't any good r
loop: don't set QUEUE_FLAG_NOMERGES
[ Upstream commit 667ea36378cf7f669044b27871c496e1559c872a ]
QUEUE_FLAG_NOMERGES isn't really a driver interface, but a user tunable. There also isn't any good reason to set it in the loop driver.
The original commit adding it (5b5e20f421c0b6d "block: loop: set QUEUE_FLAG_NOMERGES for request queue of loop") claims that "It doesn't make sense to enable merge because the I/O submitted to backing file is handled page by page." which of course isn't true for multi-page bvec now, and it never has been for direct I/O, for which commit 40326d8a33d ("block/loop: allow request merge for directio mode") alredy disabled the nomerges flag.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20240627124926.512662-2-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.36, v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23 |
|
#
1188f7f1 |
| 10-Feb-2024 |
Andrew Jeffery <andrew@codeconstruct.com.au> |
Merge tag 'v6.6.14' into dev-6.6
This is the 6.6.14 stable release
|
Revision tags: v6.6.16, v6.6.15, v6.6.14, v6.6.13 |
|
#
96e84339 |
| 17-Jan-2024 |
Christoph Hellwig <hch@lst.de> |
loop: fix the the direct I/O support check when used on top of block devices
[ Upstream commit baa7d536077dcdfe2b70c476a8873d1745d3de0f ]
__loop_update_dio only checks the alignment requirement for
loop: fix the the direct I/O support check when used on top of block devices
[ Upstream commit baa7d536077dcdfe2b70c476a8873d1745d3de0f ]
__loop_update_dio only checks the alignment requirement for block backed file systems, but misses them for the case where the loop device is created directly on top of another block device. Due to this creating a loop device with default option plus the direct I/O flag on a > 512 byte sector size file system will lead to incorrect I/O being submitted to the lower block device and a lot of error from the lock layer. This can be seen with xfstests generic/563.
Fix the code in __loop_update_dio by factoring the alignment check into a helper, and calling that also for the struct block_device of a block device inode.
Also remove the TODO comment talking about dynamically switching between buffered and direct I/O, which is a would be a recipe for horrible performance and occasional data loss.
Fixes: 2e5ab5f379f9 ("block: loop: prepare for supporing direct IO") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20240117175901.871796-1-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3 |
|
#
c900529f |
| 12-Sep-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
Merge drm/drm-fixes into drm-misc-fixes
Forwarding to v6.6-rc1.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
|
Revision tags: v6.5.2, v6.1.51, v6.5.1 |
|
#
1ac731c5 |
| 30-Aug-2023 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
Merge branch 'next' into for-linus
Prepare input updates for 6.6 merge window.
|
Revision tags: v6.1.50 |
|
#
511fb5ba |
| 28-Aug-2023 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge tag 'v6.6-vfs.super' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull superblock updates from Christian Brauner: "This contains the super rework that was ready for this cycle. Th
Merge tag 'v6.6-vfs.super' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull superblock updates from Christian Brauner: "This contains the super rework that was ready for this cycle. The first part changes the order of how we open block devices and allocate superblocks, contains various cleanups, simplifications, and a new mechanism to wait on superblock state changes.
This unblocks work to ultimately limit the number of writers to a block device. Jan has already scheduled follow-up work that will be ready for v6.7 and allows us to restrict the number of writers to a given block device. That series builds on this work right here.
The second part contains filesystem freezing updates.
Overview:
The generic superblock changes are rougly organized as follows (ignoring additional minor cleanups):
(1) Removal of the bd_super member from struct block_device.
This was a very odd back pointer to struct super_block with unclear rules. For all relevant places we have other means to get the same information so just get rid of this.
(2) Simplify rules for superblock cleanup.
Roughly, everything that is allocated during fs_context initialization and that's stored in fs_context->s_fs_info needs to be cleaned up by the fs_context->free() implementation before the superblock allocation function has been called successfully.
After sget_fc() returned fs_context->s_fs_info has been transferred to sb->s_fs_info at which point sb->kill_sb() if fully responsible for cleanup. Adhering to these rules means that cleanup of sb->s_fs_info in fill_super() is to be avoided as it's brittle and inconsistent.
Cleanup shouldn't be duplicated between sb->put_super() as sb->put_super() is only called if sb->s_root has been set aka when the filesystem has been successfully born (SB_BORN). That complexity should be avoided.
This also means that block devices are to be closed in sb->kill_sb() instead of sb->put_super(). More details in the lower section.
(3) Make it possible to lookup or create a superblock before opening block devices
There's a subtle dependency on (2) as some filesystems did rely on fill_super() to be called in order to correctly clean up sb->s_fs_info. All these filesystems have been fixed.
(4) Switch most filesystem to follow the same logic as the generic mount code now does as outlined in (3).
(5) Use the superblock as the holder of the block device. We can now easily go back from block device to owning superblock.
(6) Export and extend the generic fs_holder_ops and use them as holder ops everywhere and remove the filesystem specific holder ops.
(7) Call from the block layer up into the filesystem layer when the block device is removed, allowing to shut down the filesystem without risk of deadlocks.
(8) Get rid of get_super().
We can now easily go back from the block device to owning superblock and can call up from the block layer into the filesystem layer when the device is removed. So no need to wade through all registered superblock to find the owning superblock anymore"
Link: https://lore.kernel.org/lkml/20230824-prall-intakt-95dbffdee4a0@brauner/
* tag 'v6.6-vfs.super' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (47 commits) super: use higher-level helper for {freeze,thaw} super: wait until we passed kill super super: wait for nascent superblocks super: make locking naming consistent super: use locking helpers fs: simplify invalidate_inodes fs: remove get_super block: call into the file system for ioctl BLKFLSBUF block: call into the file system for bdev_mark_dead block: consolidate __invalidate_device and fsync_bdev block: drop the "busy inodes on changed media" log message dasd: also call __invalidate_device when setting the device offline amiflop: don't call fsync_bdev in FDFMTBEG floppy: call disk_force_media_change when changing the format block: simplify the disk_force_media_change interface nbd: call blk_mark_disk_dead in nbd_clear_sock_ioctl xfs use fs_holder_ops for the log and RT devices xfs: drop s_umount over opening the log and RT devices ext4: use fs_holder_ops for the log device ext4: drop s_umount over opening the log device ...
show more ...
|
Revision tags: v6.5, v6.1.49, v6.1.48 |
|
#
fdebffeb |
| 23-Aug-2023 |
Dave Airlie <airlied@redhat.com> |
BackMerge tag 'v6.5-rc7' into drm-next
Linux 6.5-rc7
This is needed for the CI stuff and the msm pull has fixes in it.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
a3dd14c0 |
| 21-Aug-2023 |
Georgi Djakov <djakov@kernel.org> |
Merge tag 'v6.5-rc6' into icc-next
The fixes that got merged into v6.5-rc6 are needed here.
Signed-off-by: Georgi Djakov <djakov@kernel.org>
|
Revision tags: v6.1.46, v6.1.45 |
|
#
ab6860f6 |
| 11-Aug-2023 |
Christoph Hellwig <hch@lst.de> |
block: simplify the disk_force_media_change interface
Hard code the events to DISK_EVENT_MEDIA_CHANGE as that is the only useful use case, and drop the superfluous return value.
Signed-off-by: Chri
block: simplify the disk_force_media_change interface
Hard code the events to DISK_EVENT_MEDIA_CHANGE as that is the only useful use case, and drop the superfluous return value.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Message-Id: <20230811100828.1897174-9-hch@lst.de> Signed-off-by: Christian Brauner <brauner@kernel.org>
show more ...
|
Revision tags: v6.1.44 |
|
#
2612e3bb |
| 07-Aug-2023 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
Merge drm/drm-next into drm-intel-next
Catching-up with drm-next and drm-intel-gt-next. It will unblock a code refactor around the platform definitions (names vs acronyms).
Signed-off-by: Rodrigo V
Merge drm/drm-next into drm-intel-next
Catching-up with drm-next and drm-intel-gt-next. It will unblock a code refactor around the platform definitions (names vs acronyms).
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
show more ...
|
#
9f771739 |
| 07-Aug-2023 |
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> |
Merge drm/drm-next into drm-intel-gt-next
Need to pull in b3e4aae612ec ("drm/i915/hdcp: Modify hdcp_gsc_message msg sending mechanism") as a dependency for https://patchwork.freedesktop.org/series/1
Merge drm/drm-next into drm-intel-gt-next
Need to pull in b3e4aae612ec ("drm/i915/hdcp: Modify hdcp_gsc_message msg sending mechanism") as a dependency for https://patchwork.freedesktop.org/series/121735/
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
show more ...
|
#
bf184299 |
| 04-Aug-2023 |
Arnaldo Carvalho de Melo <acme@redhat.com> |
Merge remote-tracking branch 'torvalds/master' into perf-tools-next
To pick up the fixes that were just merged from perf-tools/perf-tools for v6.5.
Signed-off-by: Arnaldo Carvalho de Melo <acme@red
Merge remote-tracking branch 'torvalds/master' into perf-tools-next
To pick up the fixes that were just merged from perf-tools/perf-tools for v6.5.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
show more ...
|
Revision tags: v6.1.43 |
|
#
1346e933 |
| 31-Jul-2023 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
Merge 6.5-rc4 into char-misc-next
We need the char-misc fixes in here as well for testing.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
014acf26 |
| 27-Jul-2023 |
Jakub Kicinski <kuba@kernel.org> |
Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Cross-merge networking fixes after downstream PR.
No conflicts or adjacent changes.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
3b9adfbb |
| 27-Jul-2023 |
Takashi Iwai <tiwai@suse.de> |
Merge tag 'asoc-fix-v6.5-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v6.5
A collection of device specific fixes, none particularly remarkabl
Merge tag 'asoc-fix-v6.5-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v6.5
A collection of device specific fixes, none particularly remarkable. There's a set of repetitive fixes for the RealTek drivers fixing an issue with suspend that was replicated in multiple drivers.
show more ...
|
Revision tags: v6.1.42 |
|
#
a32e0834 |
| 25-Jul-2023 |
Takashi Iwai <tiwai@suse.de> |
Merge tag 'asoc-v6.6-early' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
ASoC: Updates for v6.6
Here's an initial batch of updates for ASoC for this release cycle.
Merge tag 'asoc-v6.6-early' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
ASoC: Updates for v6.6
Here's an initial batch of updates for ASoC for this release cycle. We've got a bunch of new drivers in here, a bit of core work from Morimoto-san and quite a lot of janitorial work. There's several updates that pull in changes from other subsystems in order to build on them:
- An adaptor to allow use of IIO DACs and ADCs in ASoC which pulls in some IIO changes. - Create a library function for intlog10() and use it in the NAU8825 driver. - Include the ASoC tests, including the topology tests, in the default KUnit full test coverage. This also involves enabling UML builds of ALSA since that's the default KUnit test environment which pulls in the addition of some stubs to the driver. - More factoring out from Morimoto-san. - Convert a lot of drivers to use the more modern maple tree register cache. - Support for AMD machines with MAX98388 and NAU8821, Cirrus Logic CS35L36, Intel AVS machines with ES8336 and RT5663 and NXP i.MX93.
show more ...
|
Revision tags: v6.1.41 |
|
#
61b73694 |
| 24-Jul-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
Merge drm/drm-next into drm-misc-next
Backmerging to get v6.5-rc2.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
|
#
447281e7 |
| 23-Jul-2023 |
Mark Brown <broonie@kernel.org> |
regulator: Merge up fixes from mainline
There's several things here that will really help my CI.
|
#
9c214af0 |
| 23-Jul-2023 |
Mark Brown <broonie@kernel.org> |
regmap: Merge up fixes from mainline
There's several things here that will really help my CI.
|
#
0b201982 |
| 23-Jul-2023 |
Mark Brown <broonie@kernel.org> |
spi: Merge up fixes from mainline
There's several things here that will really help my CI.
|
#
de1b43a5 |
| 23-Jul-2023 |
Mark Brown <broonie@kernel.org> |
ASoC: Merge up fixes from mainline
There's several things here that will really help my CI.
|
#
1477c794 |
| 23-Jul-2023 |
Mark Brown <broonie@kernel.org> |
ASoC: Merge up fixes from mainline
There's several things here that will really help my CI.
|
Revision tags: v6.1.40 |
|
#
f036d67c |
| 22-Jul-2023 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge tag 'block-6.5-2023-07-21' of git://git.kernel.dk/linux
Pull block fixes from Jens Axboe:
- Fix for loop regressions (Mauricio)
- Fix a potential stall with batched wakeups in sbitmap (Dav
Merge tag 'block-6.5-2023-07-21' of git://git.kernel.dk/linux
Pull block fixes from Jens Axboe:
- Fix for loop regressions (Mauricio)
- Fix a potential stall with batched wakeups in sbitmap (David)
- Fix for stall with recursive plug flushes (Ross)
- Skip accounting of empty requests for blk-iocost (Chengming)
- Remove a dead field in struct blk_mq_hw_ctx (Chengming)
* tag 'block-6.5-2023-07-21' of git://git.kernel.dk/linux: loop: do not enforce max_loop hard limit by (new) default loop: deprecate autoloading callback loop_probe() sbitmap: fix batching wakeup blk-iocost: skip empty flush bio in iocost blk-mq: delete dead struct blk_mq_hw_ctx->queued field blk-mq: Fix stall due to recursive flush plug
show more ...
|
#
bb5faa99 |
| 20-Jul-2023 |
Mauricio Faria de Oliveira <mfo@canonical.com> |
loop: do not enforce max_loop hard limit by (new) default
Problem:
The max_loop parameter is used for 2 different purposes:
1) initial number of loop devices to pre-create on init 2) maximum numbe
loop: do not enforce max_loop hard limit by (new) default
Problem:
The max_loop parameter is used for 2 different purposes:
1) initial number of loop devices to pre-create on init 2) maximum number of loop devices to add on access/open()
Historically, its default value (zero) caused 1) to create non-zero number of devices (CONFIG_BLK_DEV_LOOP_MIN_COUNT), and no hard limit on 2) to add devices with autoloading.
However, the default value changed in commit 85c50197716c ("loop: Fix the max_loop commandline argument treatment when it is set to 0") to CONFIG_BLK_DEV_LOOP_MIN_COUNT, for max_loop=0 not to pre-create devices.
That does improve 1), but unfortunately it breaks 2), as the default behavior changed from no-limit to hard-limit.
Example:
For example, this userspace code broke for N >= CONFIG, if the user relied on the default value 0 for max_loop:
mknod("/dev/loopN"); open("/dev/loopN"); // now fails with ENXIO
Though affected users may "fix" it with (loop.)max_loop=0, this means to require a kernel parameter change on stable kernel update (that commit Fixes: an old commit in stable).
Solution:
The original semantics for the default value in 2) can be applied if the parameter is not set (ie, default behavior).
This still keeps the intended function in 1) and 2) if set, and that commit's intended improvement in 1) if max_loop=0.
Before 85c50197716c: - default: 1) CONFIG devices 2) no limit - max_loop=0: 1) CONFIG devices 2) no limit - max_loop=X: 1) X devices 2) X limit
After 85c50197716c: - default: 1) CONFIG devices 2) CONFIG limit (*) - max_loop=0: 1) 0 devices (*) 2) no limit - max_loop=X: 1) X devices 2) X limit
This commit: - default: 1) CONFIG devices 2) no limit (*) - max_loop=0: 1) 0 devices 2) no limit - max_loop=X: 1) X devices 2) X limit
Future:
The issue/regression from that commit only affects code under the CONFIG_BLOCK_LEGACY_AUTOLOAD deprecation guard, thus the fix too is contained under it.
Once that deprecated functionality/code is removed, the purpose 2) of max_loop (hard limit) is no longer in use, so the module parameter description can be changed then.
Tests:
Linux 6.4-rc7 CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 CONFIG_BLOCK_LEGACY_AUTOLOAD=y
- default (original)
# ls -1 /dev/loop* /dev/loop-control /dev/loop0 ... /dev/loop7
# ./test-loop open: /dev/loop8: No such device or address
- default (patched)
# ls -1 /dev/loop* /dev/loop-control /dev/loop0 ... /dev/loop7
# ./test-loop #
- max_loop=0 (original & patched):
# ls -1 /dev/loop* /dev/loop-control
# ./test-loop #
- max_loop=8 (original & patched):
# ls -1 /dev/loop* /dev/loop-control /dev/loop0 ... /dev/loop7
# ./test-loop open: /dev/loop8: No such device or address
- max_loop=0 (patched; CONFIG_BLOCK_LEGACY_AUTOLOAD is not set)
# ls -1 /dev/loop* /dev/loop-control
# ./test-loop open: /dev/loop8: No such device or address
Fixes: 85c50197716c ("loop: Fix the max_loop commandline argument treatment when it is set to 0") Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20230720143033.841001-3-mfo@canonical.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|