Re: [syzbot ci] Re: nbd: skip queue limits update for size-only reconfigure

Krystian Kaniewski <[email protected]> Tue, 21 Jul 2026 22:43:40 +0200
Newsgroups dev.linux.lists.syzbot
Message-ID <[email protected]>
Please generate a v3 patch for syzbot issue f272bbfbf8498ddadea5, `INFO: 
task hung in queue_limits_commit_update_frozen`. The reviewed v2 job is 
`e5538deb-f4ac-4b3b-a22a-b47c828fc99e`. Start from the original base 
commit `8cd9520d35a6c38db6567e97dd93b1f11f185dc6`.

The main v2 fix is correct and should remain unchanged. The supplied 
reproducer leaves NBD I/O in flight against an unresponsive server, then 
sends a size-only `NBD_CMD_RECONFIGURE`. Calling 
`queue_limits_commit_update_frozen()` for that request waits 
indefinitely for the queue to drain while generic netlink serialization 
is held. Since the effective block size and all other queue limits are 
unchanged, updating `config->bytesize` and disk capacity directly is the 
right fix.

Keep these parts of v2:

1. Keep the small helper which publishes the existing NBD capacity 
update, including `GD_NEED_PART_SCAN`, `set_capacity_and_notify()`, and 
the fallback `KOBJ_CHANGE` event.
2. Keep the generic netlink capacity-only path which validates the byte 
size, stores `config->bytesize`, and avoids queue-limit update and queue 
freezing when the effective block size is unchanged.
3. Keep initial connect behavior. When `nbd->pid` is zero, store the 
requested size without notifying a live disk, then let 
`nbd_start_device()` perform the full queue-limits update.
4. Keep zero block-size normalization before comparison and keep 
validation of invalid nonzero block sizes.
5. Keep real generic netlink block-size changes on `nbd_set_size()`.
6. Keep `NBD_SET_BLKSIZE`, `NBD_SET_SIZE`, and `NBD_SET_SIZE_BLOCKS` on 
their existing full `nbd_set_size()` path. Legacy `NBD_SET_FLAGS` 
followed by a size ioctl must still republish flag-derived queue limits.

Required corrections:

1. Remove `nbd_total_devices--` from `nbd_dev_remove()`. The corrected 
code diff should otherwise be identical to the v2 code diff.
2. Remove the `Added decrement of nbd_total_devices in nbd_dev_remove()` 
bullet from the v2 changelog. Do not change `nbd_total_devices`, add a 
device limit, or attempt another accounting fix in this patch.
3. Correct the opening commit reference. Commit `242a49e5c878` is titled 
`nbd: freeze the queue for queue limits updates`, not `nbd: fix queue 
freeze vs limits lock order`.

The counter change must be removed because `nbd_dev_remove()` may run 
from asynchronous destroy-on-disconnect work. V2 decrements the plain 
counter after releasing `nbd_index_mutex`, while `nbd_dev_add()` 
increments it outside that mutex and `nbd_genl_status()` uses it to size 
an skb. Concurrent removal and creation can lose an update, and a later 
removal can make the counter negative. This can make status enumeration 
fail or turn the skb estimate into a very large unsigned allocation 
size. The decrement also cannot fix `MAX_LOCKDEP_KEYS`: device creation 
does not consult this counter, and changing the count does not release 
lockdep classes. The final test result therefore does not justify the line.

Use this subject:

nbd: skip queue limits update for size-only reconfigure

Keep the commit message narrowly scoped. Explain that capacity-only 
generic netlink reconfiguration no longer freezes the queue, while 
startup and real block-size changes retain the frozen limits update. Do 
not claim that all NBD reconfiguration hangs are fixed, since a real 
block-size change still requires queue serialization.

Keep this exact tag:

Fixes: 242a49e5c878 ("nbd: freeze the queue for queue limits updates")

Preserve the syzbot report and issue tags for f272bbfbf8498ddadea5.

On 7/21/2026 11:32 AM, syzbot ci wrote:
> syzbot ci has tested the following series
>
> [v2] nbd: skip queue limits update for size-only reconfigure
> https://lore.kernel.org/all/[email protected]
> * [PATCH RFC v2] nbd: skip queue limits update for size-only reconfigure
>
> and found no issues.
>
> Full report is available here:
> https://ci.syzbot.org/series/409945b0-159c-4d52-ae37-bc7c04383918
>
> ***
>
> If these findings have caused you to resend the series or submit a
> separate fix, please add the following tag to your commit message:
>    Tested-by: [email protected]
>
> ---
> This report is generated by a bot. It may contain errors.
> syzbot ci engineers can be reached at [email protected].