linux-stable.git/drivers/block, branch v4.19.321

null_blk: Fix the WARNING: modpost: missing MODULE_DESCRIPTION()

2024-06-16T11:23:35+00:00

[ Upstream commit 9e6727f824edcdb8fdd3e6e8a0862eb49546e1cd ]

No functional changes intended.

Fixes: f2298c0403b0 ("null_blk: multi queue aware block test driver")
Signed-off-by: Zhu Yanjun 
Reviewed-by: Chaitanya Kulkarni 
Link: https://lore.kernel.org/r/20240506075538.6064-1-yanjun.zhu@linux.dev
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

null_blk: Fix missing mutex_destroy() at module removal

2024-06-16T11:23:25+00:00

[ Upstream commit 07d1b99825f40f9c0d93e6b99d79a08d0717bac1 ]

When a mutex lock is not used any more, the function mutex_destroy
should be called to mark the mutex lock uninitialized.

Fixes: f2298c0403b0 ("null_blk: multi queue aware block test driver")
Signed-off-by: Zhu Yanjun 
Link: https://lore.kernel.org/r/20240425171635.4227-1-yanjun.zhu@linux.dev
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

Revert "loop: Remove sector_t truncation checks"

2024-05-02T14:17:14+00:00

This reverts commit f92a3b0d003b9f7eb1f452598966a08802183f47, which
was commit 083a6a50783ef54256eec3499e6575237e0e3d53 upstream.  In 4.19
there is still an option to use 32-bit sector_t on 32-bit
architectures, so we need to keep checking for truncation.

Since loop_set_status() was refactored by subsequent patches, this
reintroduces its truncation check in loop_set_status_from_info()
instead.

I tested that the loop ioctl operations have the expected behaviour on
x86_64, x86_32 with CONFIG_LBDAF=y, and (the special case) x86_32 with
CONFIG_LBDAF=n.

Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

loop: loop_set_status_from_info() check before assignment

2024-04-13T10:50:10+00:00

[ Upstream commit 9f6ad5d533d1c71e51bdd06a5712c4fbc8768dfa ]

In loop_set_status_from_info(), lo->lo_offset and lo->lo_sizelimit should
be checked before reassignment, because if an overflow error occurs, the
original correct value will be changed to the wrong value, and it will not
be changed back.

More, the original patch did not solve the problem, the value was set and
ioctl returned an error, but the subsequent io used the value in the loop
driver, which still caused an alarm:

loop_handle_cmd
 do_req_filebacked
  loff_t pos = ((loff_t) blk_rq_pos(rq) << 9) + lo->lo_offset;
  lo_rw_aio
   cmd->iocb.ki_pos = pos

Fixes: c490a0b5a4f3 ("loop: Check for overflow while configuring loop")
Signed-off-by: Zhong Jinghua 
Reviewed-by: Chaitanya Kulkarni 
Link: https://lore.kernel.org/r/20230221095027.3656193-1-zhongjinghua@huaweicloud.com
Signed-off-by: Jens Axboe 
Signed-off-by: Genjian Zhang 
Signed-off-by: Greg Kroah-Hartman

loop: Check for overflow while configuring loop

2024-04-13T10:50:10+00:00

[ Upstream commit c490a0b5a4f36da3918181a8acdc6991d967c5f3 ]

The userspace can configure a loop using an ioctl call, wherein
a configuration of type loop_config is passed (see lo_ioctl()'s
case on line 1550 of drivers/block/loop.c). This proceeds to call
loop_configure() which in turn calls loop_set_status_from_info()
(see line 1050 of loop.c), passing &config->info which is of type
loop_info64*. This function then sets the appropriate values, like
the offset.

loop_device has lo_offset of type loff_t (see line 52 of loop.c),
which is typdef-chained to long long, whereas loop_info64 has
lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h).

The function directly copies offset from info to the device as
follows (See line 980 of loop.c):
	lo->lo_offset = info->lo_offset;

This results in an overflow, which triggers a warning in iomap_iter()
due to a call to iomap_iter_done() which has:
	WARN_ON_ONCE(iter->iomap.offset > iter->pos);

Thus, check for negative value during loop_set_status_from_info().

Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e

Reported-and-tested-by: syzbot+a8e049cd3abd342936b6@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Reviewed-by: Matthew Wilcox (Oracle) 
Signed-off-by: Siddh Raman Pant 
Reviewed-by: Christoph Hellwig 
Link: https://lore.kernel.org/r/20220823160810.181275-1-code@siddh.me
Signed-off-by: Jens Axboe 
Signed-off-by: Genjian Zhang 
Signed-off-by: Greg Kroah-Hartman

loop: Factor out configuring loop from status

2024-04-13T10:50:10+00:00

[ Upstream commit 0c3796c244598122a5d59d56f30d19390096817f ]

Factor out this code into a separate function, so it can be reused by
other code more easily.

Signed-off-by: Martijn Coenen 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jens Axboe 
Signed-off-by: Genjian Zhang 
Signed-off-by: Greg Kroah-Hartman

loop: properly observe rotational flag of underlying device

2024-04-13T10:50:10+00:00

[ Upstream commit 56a85fd8376ef32458efb6ea97a820754e12f6bb ]

The loop driver always declares the rotational flag of its device as
rotational, even when the device of the mapped file is nonrotational,
as is the case with SSDs or on tmpfs. This can confuse filesystem tools
which are SSD-aware; in my case I frequently forget to tell mkfs.btrfs
that my loop device on tmpfs is nonrotational, and that I really don't
need any automatic metadata redundancy.

The attached patch fixes this by introspecting the rotational flag of the
mapped file's underlying block device, if it exists. If the mapped file's
filesystem has no associated block device - as is the case on e.g. tmpfs -
we assume nonrotational storage. If there is a better way to identify such
non-devices I'd love to hear them.

Cc: Jens Axboe 
Cc: linux-block@vger.kernel.org
Cc: holger@applied-asynchrony.com
Signed-off-by: Holger Hoffstätte 
Signed-off-by: Gwendal Grignou 
Signed-off-by: Benjamin Gordon 
Reviewed-by: Guenter Roeck 
Signed-off-by: Jens Axboe 
Signed-off-by: Genjian Zhang 
Signed-off-by: Greg Kroah-Hartman

loop: Refactor loop_set_status() size calculation

2024-04-13T10:50:10+00:00

[ Upstream commit b0bd158dd630bd47640e0e418c062cda1e0da5ad ]

figure_loop_size() calculates the loop size based on the passed in
parameters, but at the same time it updates the offset and sizelimit
parameters in the loop device configuration. That is a somewhat
unexpected side effect of a function with this name, and it is only only
needed by one of the two callers of this function - loop_set_status().

Move the lo_offset and lo_sizelimit assignment back into loop_set_status(),
and use the newly factored out functions to validate and apply the newly
calculated size. This allows us to get rid of figure_loop_size() in a
follow-up commit.

Signed-off-by: Martijn Coenen 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jens Axboe 
Signed-off-by: Genjian Zhang 
Signed-off-by: Greg Kroah-Hartman

loop: Factor out setting loop device size

2024-04-13T10:50:10+00:00

[ Upstream commit 5795b6f5607f7e4db62ddea144727780cb351a9b ]

This code is used repeatedly.

Signed-off-by: Martijn Coenen 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jens Axboe 
Signed-off-by: Genjian Zhang 
Signed-off-by: Greg Kroah-Hartman

loop: Remove sector_t truncation checks

2024-04-13T10:50:10+00:00

[ Upstream commit 083a6a50783ef54256eec3499e6575237e0e3d53 ]

sector_t is now always u64, so we don't need to check for truncation.

Signed-off-by: Martijn Coenen 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jens Axboe 
Signed-off-by: Genjian Zhang 
Signed-off-by: Greg Kroah-Hartman