Re: [GIT PULL] Block updates for 7.3

[Mike Snitzer <snitzer@kernel.org>]

On Wed, Aug 19, 2026 at 09:09:12PM -0400, Mike Snitzer wrote:
> On Wed, Aug 19, 2026 at 02:30:37PM -0600, Jens Axboe wrote:
> > Hi Linus,
> > 
> > The bulk of this is NVMe and MD, both via merges, but the core block
> > changes are the more interesting part. In detail:
> > 
> > - NVMe updates via Keith:
> >        - Enable Clang context analysis for the nvme host driver, adding
> >          context annotations across core, fabrics, rdma, tcp and pci
> >        - nvmet reservation state exposed through a new namespace-level
> >          debugfs directory, plus ABI documentation for the host sysfs
> >          and target configfs interfaces
> >        - nvme-tcp host memory disclosure fixes on the read path: reject a
> >          read that transferred too few bytes, don't accept C2HData based
> >          on blk_rq_payload_bytes() alone, and fix the R2T case for a read
> >          command
> >        - Parallelize nvme-rdma I/O queue allocation and startup (Surabhi)
> >        - Apple nvme fixes and quirks: page aligned admin queue buffers,
> >          destroy the admin queue on removal, and various DMA/NVMMU
> >          correctness fixes
> >        - A large pile of nvmet and host fixes for out-of-bounds reads,
> >          refcount/resource leaks, and NULL derefs across auth, zns,
> >          passthru, pci-epf, rdma and configfs
> >        - Various other fixes and cleanups
> > 
> > - MD updates via Yu Kuai:
> >        - llbitmap reshape support, the large series wiring exact bitmap
> >          mapping and reshape lifecycle through raid5 and raid10, growing
> >          the page cache in place, and remapping checkpointed bits as
> >          reshape progresses
> >        - raid5 fixes for lockless max_nr_stripes and recovery_offset
> >          accesses, a reshape deadlock with more failed devices than max
> >          degraded, and bitmap batch counter consistency
> >        - Atomic write handling for raid1/raid10, and removal of the
> >          REQ_NOWAIT support from raid1/10/456
> >        - raid5-ppl use-after-free fix in ppl_do_flush()
> >        - A batch of smaller fixes across md core and the bitmap code
> > 
> > - s390/dasd ESE full-track write support and the surrounding
> >   infrastructure, plus enabling CONTEXT_ANALYSIS for s390/block
> > 
> > - RWF_DONTCACHE support for block devices, built on new task-context
> >   bio completion infrastructure, and wiring it up for the iomap and
> >   buffer dropbehind writeback paths
> > 
> > - Async io_uring zone reset all, plus zone management command cleanups
> >   allowing REQ_NOWAIT and tightening conventional zone rejection
> > 
> > - Block integrity refactoring: lift BIP_CHECK_FLAGS to the shared
> >   header, handle nogenerate/noverify properly in fs-integrity, and
> >   drop the blk-integrity.h include from bdev.c
> > 
> > - Split out a new blk_plug.h header
> > 
> > - ublk improvements: add UBLK_F_IO_DESC_SIZE, split request validation
> >   from io_desc init, reject non-power-of-2 zone sizes in SET_PARAMS,
> >   and a series of hardening fixes around map/unmap and auto buf reg
> > 
> > - null_blk cleanups and configfs serialization fixes
> > 
> > - nbd queue freeze removal on the setup paths, and a new
> >   pre_defined_connections module parameter for pre-created devices
> > 
> > - blk-cgroup fixes for the race between policy activation and blkg
> >   destruction, and accounting per-cpu stats over possible CPUs across
> >   blk-stat, iolatency, iocost and kyber
> > 
> > - Various dio fixes: leak on metadata mapping error, validate user
> >   space vectors during extraction, and set dma_alignment from the
> >   backing file for loop and zloop direct I/O
> 
> Hey Jens,
> 
> I just encountered this today, so figured I'd share: I think there is
> a post-merge fixup needed once Linus were to merge your block changes,
> due to vfs iomap changes from vfs-7.3-rc1.iomap (which Linus already
> merged).
> 
> Specifically commit 36f199c8d0ee4 ("iomap: add simple dio path for
> small direct I/O") added a new caller for bio_iov_iter_get_pages and
> Keith's commit 14b007e178811 ("block: validate user space vectors
> during extraction") added a new argument to bio_iov_iter_get_pages.

Linus, Jens did already mention this conflict in his PR -- as coming
from XFS tree.

I knew it to have originated from vfs-7.3-rc1.iomap (so I didn't
notice I was raising the very same thing Jens had already pointed
out). Sorry for the noise.

Mike