loop: Fix the max_loop commandline argument treatment when it is set to 0
authorIsaac J. Manjarres <isaacmanjarres@google.com>
Thu, 8 Dec 2022 21:29:01 +0000 (13:29 -0800)
committerJens Axboe <axboe@kernel.dk>
Wed, 14 Dec 2022 17:55:20 +0000 (10:55 -0700)
commit85c50197716c60fe57f411339c579462e563ac57
treeb875332ea75af46ad494d8fa5f7d4e4202f553a4
parentff1cc97b1f4c10db224f276d9615b22835b8c424
loop: Fix the max_loop commandline argument treatment when it is set to 0

Currently, the max_loop commandline argument can be used to specify how
many loop block devices are created at init time. If it is not
specified on the commandline, CONFIG_BLK_DEV_LOOP_MIN_COUNT loop block
devices will be created.

The max_loop commandline argument can be used to override the value of
CONFIG_BLK_DEV_LOOP_MIN_COUNT. However, when max_loop is set to 0
through the commandline, the current logic treats it as if it had not
been set, and creates CONFIG_BLK_DEV_LOOP_MIN_COUNT devices anyway.

Fix this by starting max_loop off as set to CONFIG_BLK_DEV_LOOP_MIN_COUNT.
This preserves the intended behavior of creating
CONFIG_BLK_DEV_LOOP_MIN_COUNT loop block devices if the max_loop
commandline parameter is not specified, and allowing max_loop to
be respected for all values, including 0.

This allows environments that can create all of their required loop
block devices on demand to not have to unnecessarily preallocate loop
block devices.

Fixes: 732850827450 ("remove artificial software max_loop limit")
Cc: stable@vger.kernel.org
Cc: Ken Chen <kenchen@google.com>
Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
Link: https://lore.kernel.org/r/20221208212902.765781-1-isaacmanjarres@google.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
drivers/block/loop.c