linux-stable.git/block, branch v6.13.5

partitions: mac: fix handling of bogus partition table

2025-02-21T13:11:08+00:00

commit 80e648042e512d5a767da251d44132553fe04ae0 upstream.

Fix several issues in partition probing:

 - The bailout for a bad partoffset must use put_dev_sector(), since the
   preceding read_part_sector() succeeded.
 - If the partition table claims a silly sector size like 0xfff bytes
   (which results in partition table entries straddling sector boundaries),
   bail out instead of accessing out-of-bounds memory.
 - We must not assume that the partition table contains proper NUL
   termination - use strnlen() and strncmp() instead of strlen() and
   strcmp().

Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn 
Link: https://lore.kernel.org/r/20250214-partition-mac-v1-1-c1c626dffbd5@google.com
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

block: don't revert iter for -EIOCBQUEUED

2025-02-17T10:36:32+00:00

commit b13ee668e8280ca5b07f8ce2846b9957a8a10853 upstream.

blkdev_read_iter() has a few odd checks, like gating the position and
count adjustment on whether or not the result is bigger-than-or-equal to
zero (where bigger than makes more sense), and not checking the return
value of blkdev_direct_IO() before doing an iov_iter_revert(). The
latter can lead to attempting to revert with a negative value, which
when passed to iov_iter_revert() as an unsigned value will lead to
throwing a WARN_ON() because unroll is bigger than MAX_RW_COUNT.

Be sane and don't revert for -EIOCBQUEUED, like what is done in other
spots.

Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

blk-cgroup: Fix class @block_class's subsystem refcount leakage

2025-02-17T10:36:24+00:00

commit d1248436cbef1f924c04255367ff4845ccd9025e upstream.

blkcg_fill_root_iostats() iterates over @block_class's devices by
class_dev_iter_(init|next)(), but does not end iterating with
class_dev_iter_exit(), so causes the class's subsystem refcount leakage.

Fix by ending the iterating with class_dev_iter_exit().

Fixes: ef45fe470e1e ("blk-cgroup: show global disk stats in root cgroup io.stat")
Reviewed-by: Michal Koutný 
Cc: Greg Kroah-Hartman 
Cc: stable@vger.kernel.org
Acked-by: Tejun Heo 
Signed-off-by: Zijun Hu 
Link: https://lore.kernel.org/r/20250105-class_fix-v6-2-3a2f1768d4d4@quicinc.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

block: mark GFP_NOIO around sysfs ->store()

2025-02-17T10:36:16+00:00

commit 7c0be4ead1f8f5f8be0803f347de0de81e3b8e1c upstream.

sysfs ->store is called with queue freezed, meantime we have several
->store() callbacks(update_nr_requests, wbt, scheduler) to allocate
memory with GFP_KERNEL which may run into direct reclaim code path,
then potential deadlock can be caused.

Fix the issue by marking NOIO around sysfs ->store()

Reported-by: Thomas Hellström 
Cc: stable@vger.kernel.org
Signed-off-by: Ming Lei 
Reviewed-by: Christoph Hellwig 
Reviewed-by: John Garry 
Link: https://lore.kernel.org/r/20250113015833.698458-1-ming.lei@redhat.com
Link: https://lore.kernel.org/linux-block/Z4RkemI9f6N5zoEF@fedora/T/#mc774c65eeca5c024d29695f9ac6152b87763f305
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

block: Ensure start sector is aligned for stacking atomic writes

2025-02-08T09:00:57+00:00

[ Upstream commit 6564862d646e7d630929ba1ff330740bb215bdac ]

For stacking atomic writes, ensure that the start sector is aligned with
the device atomic write unit min and any boundary. Otherwise, we may
permit misaligned atomic writes.

Rework bdev_can_atomic_write() into a common helper to resuse the
alignment check. There also use atomic_write_hw_unit_min, which is more
proper (than atomic_write_unit_min).

Fixes: d7f36dc446e89 ("block: Support atomic writes limits for stacked devices")
Reviewed-by: Christoph Hellwig 
Signed-off-by: John Garry 
Reviewed-by: Martin K. Petersen 
Link: https://lore.kernel.org/r/20250109114000.2299896-2-john.g.garry@oracle.com
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

partitions: ldm: remove the initial kernel-doc notation

2025-02-08T09:00:56+00:00

[ Upstream commit e494e451611a3de6ae95f99e8339210c157d70fb ]

Remove the file's first comment describing what the file is.
This comment is not in kernel-doc format so it causes a kernel-doc
warning.

ldm.h:13: warning: expecting prototype for ldm(). Prototype was for _FS_PT_LDM_H_() instead

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Randy Dunlap 
Cc: Richard Russon (FlatCap) 
Cc: linux-ntfs-dev@lists.sourceforge.net
Cc: Jens Axboe 
Link: https://lore.kernel.org/r/20250111062758.910458-1-rdunlap@infradead.org
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

block: fix queue freeze vs limits lock order in sysfs store methods

2025-02-08T09:00:55+00:00

[ Upstream commit c99f66e4084a62a2cc401c4704a84328aeddc9ec ]

queue_attr_store() always freezes a device queue before calling the
attribute store operation. For attributes that control queue limits, the
store operation will also lock the queue limits with a call to
queue_limits_start_update(). However, some drivers (e.g. SCSI sd) may
need to issue commands to a device to obtain limit values from the
hardware with the queue limits locked. This creates a potential ABBA
deadlock situation if a user attempts to modify a limit (thus freezing
the device queue) while the device driver starts a revalidation of the
device queue limits.

Avoid such deadlock by not freezing the queue before calling the
->store_limit() method in struct queue_sysfs_entry and instead use the
queue_limits_commit_update_frozen helper to freeze the queue after taking
the limits lock.

This also removes taking the sysfs lock for the store_limit method as
it doesn't protect anything here, but creates even more nesting.
Hopefully it will go away from the actual sysfs methods entirely soon.

(commit log adapted from a similar patch from  Damien Le Moal)

Fixes: ff956a3be95b ("block: use queue_limits_commit_update in queue_discard_max_store")
Fixes: 0327ca9d53bf ("block: use queue_limits_commit_update in queue_max_sectors_store")
Signed-off-by: Christoph Hellwig 
Reviewed-by: Ming Lei 
Reviewed-by: Damien Le Moal 
Reviewed-by: Martin K. Petersen 
Reviewed-by: Nilay Shroff 
Reviewed-by: Johannes Thumshirn 
Link: https://lore.kernel.org/r/20250110054726.1499538-7-hch@lst.de
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

block: add a store_limit operations for sysfs entries

2025-02-08T09:00:55+00:00

[ Upstream commit a16230649ce27f8ac7dd8a5b079d9657aa96de16 ]

De-duplicate the code for updating queue limits by adding a store_limit
method that allows having common code handle the actual queue limits
update.

Note that this is a pure refactoring patch and does not address the
existing freeze vs limits lock order problem in the refactored code,
which will be addressed next.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Ming Lei 
Reviewed-by: Damien Le Moal 
Reviewed-by: Martin K. Petersen 
Reviewed-by: Nilay Shroff 
Reviewed-by: Johannes Thumshirn 
Reviewed-by: John Garry 
Link: https://lore.kernel.org/r/20250110054726.1499538-6-hch@lst.de
Signed-off-by: Jens Axboe 
Stable-dep-of: c99f66e4084a ("block: fix queue freeze vs limits lock order in sysfs store methods")
Signed-off-by: Sasha Levin

block: add a queue_limits_commit_update_frozen helper

2025-02-08T09:00:55+00:00

[ Upstream commit aa427d7b73b196f657d6d2cf0e94eff6b883fdef ]

Add a helper that freezes the queue, updates the queue limits and
unfreezes the queue and convert all open coded versions of that to the
new helper.

Signed-off-by: Christoph Hellwig 
Reviewed-by: John Garry 
Reviewed-by: Ming Lei 
Reviewed-by: Damien Le Moal 
Reviewed-by: Martin K. Petersen 
Reviewed-by: Nilay Shroff 
Reviewed-by: Johannes Thumshirn 
Link: https://lore.kernel.org/r/20250110054726.1499538-3-hch@lst.de
Signed-off-by: Jens Axboe 
Stable-dep-of: c99f66e4084a ("block: fix queue freeze vs limits lock order in sysfs store methods")
Signed-off-by: Sasha Levin

block: don't update BLK_FEAT_POLL in __blk_mq_update_nr_hw_queues

2025-02-08T09:00:55+00:00

[ Upstream commit d432c817c21a48c3baaa0d28e4d3e74b6aa238a0 ]

When __blk_mq_update_nr_hw_queues changes the number of tag sets, it
might have to disable poll queues.  Currently it does so by adjusting
the BLK_FEAT_POLL, which is a bit against the intent of features that
describe hardware / driver capabilities, but more importantly causes
nasty lock order problems with the broadly held freeze when updating the
number of hardware queues and the limits lock.  Fix this by leaving
BLK_FEAT_POLL alone, and instead check for the number of poll queues in
the bio submission and poll handlers.  While this adds extra work to the
fast path, the variables are in cache lines used by these operations
anyway, so it should be cheap enough.

Fixes: 8023e144f9d6 ("block: move the poll flag to queue_limits")
Signed-off-by: Christoph Hellwig 
Reviewed-by: Ming Lei 
Reviewed-by: Damien Le Moal 
Reviewed-by: Martin K. Petersen 
Reviewed-by: Johannes Thumshirn 
Reviewed-by: Nilay Shroff 
Link: https://lore.kernel.org/r/20250110054726.1499538-5-hch@lst.de
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin