linux-next.git/drivers/block, branch master

Merge branch 'master' of git://git.code.sf.net/p/tomoyo/tomoyo.git

2026-07-10T12:27:20+00:00

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git

2026-07-10T12:27:01+00:00

Merge branch 'vfs.all' of https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git

2026-07-10T10:32:58+00:00

# Conflicts: # fs/bpf_fs_kfuncs.c # tools/testing/selftests/filesystems/.gitignore # tools/testing/selftests/filesystems/Makefile

Merge branch 'block-7.2' into for-next

2026-07-09T22:21:50+00:00

* block-7.2: xen-blkfront: fix double completion of split requests on resume

xen-blkfront: fix double completion of split requests on resume

2026-07-09T22:21:44+00:00

When a block request is too large for a single ring entry and the backend does not support indirect descriptors, blkfront splits it across two ring requests. This only happens when the frontend runs on a 64K-page kernel (e.g. arm64): there, even a single-page request may not fit in one ring slot and must be split. blkif_ring_get_request() is called twice and both shadow slots (shadow[id] and shadow[extra_id]) point at the *same* struct request, linked through associated_id. blkif_completion() collapses the pair on the normal completion path, recycling the second slot and completing the request once. The suspend/resume walk in blkfront_resume() does not: it visits every shadow slot with ->request set and calls blk_mq_end_request() or re-queues ->request. For an in-flight split request it therefore processes the shared struct request twice on resume/migration -- a double completion. Skip the secondary slot of a split request in the resume walk so each logical request is processed exactly once. The secondary slot is the linked one (associated_id != NO_ASSOCIATED_ID) that carries no scatter-gather list (num_sg == 0); the first slot always keeps the sg list. The bug is only reachable on suspend/resume or live migration of such a guest, so it has no local reproducer. Fixes: 6cc568339047 ("xen/blkfront: Handle non-indirect grant with 64KB pages") Assisted-by: 0sec:claude-opus-4-8 Signed-off-by: Doruk Tan Ozturk Acked-by: Roger Pau Monné Link: https://patch.msgid.link/20260709100853.7489-1-doruk@0sec.ai Signed-off-by: Jens Axboe

loop: Fix NULL pointer dereference in lo_rw_aio()

2026-07-06T10:59:38+00:00

This is an experimental patch for testing. syzbot is reporting NULL pointer dereference in lo_rw_aio() [1][2]. An analysis by the Gemini AI collaborator [3] considers that this problem is caused by a timing shift primarily exposed by commit 65565ca5f99b ("block: unify the synchronous bi_end_io callbacks"), along with helper refactorings like commit 92c3737a2473 ("block: add a bio_submit_or_kill helper"). But due to difficulty of reproducing this race, discussion about what is happening and how to fix this problem is stalling. Also, we haven't identified how many filesystems are subjected to this problem. Therefore, this patch introduces a grace period for flushing pending I/O requests (which should be a good thing from the perspective of defensive programming) so that we won't hit NULL pointer dereference problem, and also emits BUG: message in order to help filesystem developers identify the caller of an I/O request that failed to wait for completion so that filesystem developers can fix such caller to wait for completion. Note that emitting BUG: message is enabled only if CONFIG_KCOV=y, for this check is a waste of computation resources for almost all users. Since Al Viro is reporting a problem with xfs/259 [4], this time also emit debug messages when unmount fails with -EBUSY. Link: https://syzkaller.appspot.com/bug?extid=cd8a9a308e879a4e2c28 [1] Link: https://syzkaller.appspot.com/bug?extid=bc273027d5643e48e5b3 [2] Link: https://lkml.kernel.org/r/fbb3edda-f108-4e5b-acf2-266f043f8125@I-love.SAKURA.ne.jp [3] Link: https://lkml.kernel.org/r/20260609175013.GH2636677@ZenIV [4] Signed-off-by: Tetsuo Handa

Replace by more specific (c files)

2026-07-03T05:38:17+00:00

Replace the #include of by the more specific where applicable. For most cases the include can be dropped completely, only a few drivers need one or two headers added. Acked-by: Danilo Krummrich Acked-by: Takashi Sakamoto Acked-by: Bjorn Helgaas Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub)

Merge branch 'block-7.2' into for-next

2026-07-02T12:28:26+00:00

* block-7.2: ublk: snapshot batch commands before preparing I/O

ublk: snapshot batch commands before preparing I/O

2026-07-02T12:25:21+00:00

The batch prepare path rereads its userspace element array when rolling back a partially prepared batch. Userspace can change an already processed tag before the second read, causing rollback to reject the replacement tag and leave earlier I/O slots prepared. The WARN_ON_ONCE() in the rollback path then fires. Copy the bounded batch into kernel memory before changing any I/O state and use the same snapshot for preparation and rollback. Commit and fetch batches retain the existing chunked userspace walk. Fixes: b256795b3606 ("ublk: handle UBLK_U_IO_PREP_IO_CMDS") Reported-by: syzbot+1a67ee1aa79484801ec6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1a67ee1aa79484801ec6 Signed-off-by: Yousef Alhouseen Reviewed-by: Ming Lei Link: https://patch.msgid.link/20260630211827.50475-1-alhouseenyousef@gmail.com Signed-off-by: Jens Axboe

rnbd: use scoped_with_init_fs() for block device open

2026-06-29T08:44:06+00:00

Use scoped_with_init_fs() to temporarily override current->fs for the bdev_file_open_by_path() call so the path lookup happens in init's filesystem context. process_msg_open() ← rnbd_srv_rdma_ev() ← RDMA completion callback ← ib_cq_poll_work() ← kworker (InfiniBand completion workqueue) Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-6-77ee053060e0@kernel.org Signed-off-by: Christian Brauner (Amutable)