linux-stable.git/include/uapi/linux, branch v7.2.6 Linux kernel stable tree xsk: align TX metadata layout across ABIs 2026-09-14T11:41:05+00:00 Stanislav Fomichev sdf.kernel@gmail.com 2026-08-19T16:05:33+00:00 0e00ea9e97a390856a64dab09cfff7db5c46f24e [ Upstream commit bd7d30bd1d3856d8354b5acef947d68ad1faf886 ] Add explicit padding before launch_time so xsk_tx_metadata has the same layout on 32-bit and 64-bit systems. On several architectures (csky, i386, nios2, m65k, openrisc, sh), the old native 32-bit layout put launch_time at offset 12 and had a natural size of 20 bytes. Using sizeof(struct xsk_tx_metadata) as tx_metadata_len was already rejected because the length must be a multiple of eight, so the straightforward use of the interface was broken on those ABIs. Userspace could still register a padded length of 24 bytes, though; mixing the old and new layouts then silently reads launch_time from the wrong offset and misprograms packet launch times. This intentionally replaces that incompatible layout because the affected architectures are unlikely to have any notable users. (x86_64 and arm64 have the most users and are _not_ affected) Fixes: ca4419f15abd ("xsk: Add launch time hardware offload support to XDP Tx metadata") Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20260819160535.1472459-2-sdf@fomichev.me Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit bd7d30bd1d3856d8354b5acef947d68ad1faf886 ]

Add explicit padding before launch_time so xsk_tx_metadata has the same
layout on 32-bit and 64-bit systems.

On several architectures (csky, i386, nios2, m65k, openrisc, sh), the old
native 32-bit layout put launch_time at offset 12 and had a natural size of
20 bytes. Using sizeof(struct xsk_tx_metadata) as tx_metadata_len was already
rejected because the length must be a multiple of eight, so the
straightforward use of the interface was broken on those ABIs. Userspace
could still register a padded length of 24 bytes, though; mixing the old and
new layouts then silently reads launch_time from the wrong offset and
misprograms packet launch times. This intentionally replaces that
incompatible layout because the affected architectures are unlikely to
have any notable users. (x86_64 and arm64 have the most users and are _not_
affected)

Fixes: ca4419f15abd ("xsk: Add launch time hardware offload support to XDP Tx metadata")
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260819160535.1472459-2-sdf@fomichev.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
nfsd: add protocol support for CB_NOTIFY 2026-09-14T11:40:35+00:00 Jeff Layton jlayton@kernel.org 2026-06-16T11:58:45+00:00 0a7908d48ea04cc977c362314f2e4205b79b2557 [ Upstream commit a0ac2a63d4b21455985436fbc70192da14a163fd ] Add the necessary bits to nfs4_1.x and remove the duplicate definitions from nfs4.h and the uapi nfs4 header. Regenerate the xdr files. Note that regenerating these files caused conflicts with the definitions of NFS4_VERIFIER_SIZE and NFS4_FHSIZE in include/uapi/linux/nfs4.h. These constants are defined by the RFC, and are not part of the kernel API. They have been removed. Userspace consumers who require those constants should plan to get them from more authoritative sources. The nfsstat4 enum defined in the .x is fed to the xdrgen-generated wire encoder and decoder, which treat every enumerated value as legal on the wire. Do not carry the NFS4ERR_FIRST_FREE sentinel (which is not a protocol error code) into the .x; keeping it would make 10097 a value that could leak onto the wire. Instead base nfsd's internal error codes (NFSERR_EOF and friends) at an impossible nfsstat4 value, as lockd does for its nlm__int__* status codes. Signed-off-by: Jeff Layton <jlayton@kernel.org> Link: https://patch.msgid.link/20260616-dir-deleg-v7-2-6cbc7eac0ade@kernel.org Signed-off-by: Chuck Lever <cel@kernel.org> Stable-dep-of: ec5a7c2dceb0 ("xdrgen: Emit a blank line ahead of enum declarations") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit a0ac2a63d4b21455985436fbc70192da14a163fd ]

Add the necessary bits to nfs4_1.x and remove the duplicate definitions
from nfs4.h and the uapi nfs4 header. Regenerate the xdr files.

Note that regenerating these files caused conflicts with the definitions
of NFS4_VERIFIER_SIZE and NFS4_FHSIZE in include/uapi/linux/nfs4.h.
These constants are defined by the RFC, and are not part of the kernel
API. They have been removed. Userspace consumers who require those
constants should plan to get them from more authoritative sources.

The nfsstat4 enum defined in the .x is fed to the xdrgen-generated wire
encoder and decoder, which treat every enumerated value as legal on the
wire. Do not carry the NFS4ERR_FIRST_FREE sentinel (which is not a
protocol error code) into the .x; keeping it would make 10097 a value
that could leak onto the wire. Instead base nfsd's internal error codes
(NFSERR_EOF and friends) at an impossible nfsstat4 value, as lockd does
for its nlm__int__* status codes.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://patch.msgid.link/20260616-dir-deleg-v7-2-6cbc7eac0ade@kernel.org
Signed-off-by: Chuck Lever <cel@kernel.org>
Stable-dep-of: ec5a7c2dceb0 ("xdrgen: Emit a blank line ahead of enum declarations")
Signed-off-by: Sasha Levin <sashal@kernel.org>
y2038: uapi: Use 64-bit __kernel_old_timespec::tv_nsec on x32 2026-09-14T11:39:18+00:00 Thomas Weißschuh thomas.weissschuh@linutronix.de 2026-05-04T06:32:26+00:00 ad25b583d5919e75eee6512559070955ea6386f6 [ Upstream commit 79ced850e549e8c86b772a79ea417a1425b5c04b ] 'struct __kernel_old_timespec' represents the 'native' time ABI of the kernel. On 32-bit systems it uses 32-bit fields and on 64-bit systems it uses 64-bit fields. However the x86 x32 ABI uses the 64-bit time ABI natively. This is correctly handled for the 'tv_sec' fields, through the typedefs of '__kernel_old_time_t' -> '__kernel_long_t' -> 'long long'. The same treatment was missed for 'tv_nsec'. In practice this might not make much of a difference as the value of 'tv_nsec' will always fit into 32 bits and the missing bits fall into the padding of the structure. When introspecting the structure however, a difference can be observed. Switch to 64-bit tv_nsec on x32. No other architectures or ABIs are affected. While this could be interpreted as violating the POSIX requirement of 'timespec::tv_nsec' being 'long': * __kernel_old_timespec is not actually the POSIX timespec type * the requirement is gone in newer versions of POSIX * this matches glibc Fixes: 94c467ddb273 ("y2038: add __kernel_old_timespec and __kernel_old_time_t") Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260504-timespec-x32-v2-1-0739c9047fc4@linutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 79ced850e549e8c86b772a79ea417a1425b5c04b ]

'struct __kernel_old_timespec' represents the 'native' time ABI of the
kernel. On 32-bit systems it uses 32-bit fields and on 64-bit systems
it uses 64-bit fields.

However the x86 x32 ABI uses the 64-bit time ABI natively.  This is
correctly handled for the 'tv_sec' fields, through the typedefs of
'__kernel_old_time_t' -> '__kernel_long_t' -> 'long long'. The same
treatment was missed for 'tv_nsec'.

In practice this might not make much of a difference as the value of
'tv_nsec' will always fit into 32 bits and the missing bits fall
into the padding of the structure.

When introspecting the structure however, a difference can be observed.

Switch to 64-bit tv_nsec on x32.  No other architectures or ABIs are
affected.

While this could be interpreted as violating the POSIX requirement of
'timespec::tv_nsec' being 'long':

  * __kernel_old_timespec is not actually the POSIX timespec type

  * the requirement is gone in newer versions of POSIX

  * this matches glibc

Fixes: 94c467ddb273 ("y2038: add __kernel_old_timespec and __kernel_old_time_t")
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260504-timespec-x32-v2-1-0739c9047fc4@linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation 2026-09-07T15:36:59+00:00 Günther Noack gnoack@google.com 2026-08-13T09:31:53+00:00 0c3204aacbe8c07f9e87e3028f28ec6c166a1075 commit 672fa082d48b21e1fb62cdb184fee41513e53421 upstream. Whiteout objects are used in the upper layer of an OverlayFS to indicate that the file with this name does not exist in the unified view, even if it is present in one of the lower layer file systems. For the userspace implementations of OverlayFS (fuse-overlayfs), whiteout objects can be created from userspace as well: * mknod(2) with S_IFCHR and makedev(0, 0) * renameat2(2) with RENAME_WHITEOUT, creating the whiteout in the old place of the moved file. This commit guards whiteout creation in both of these cases with LANDLOCK_ACCESS_FS_MAKE_REG. Whiteout objects are *not* considered character devices and are not bound to a driver. LANDLOCK_ACCESS_FS_MAKE_REG describes the same permission class as a whiteout object: creating one is the only S_IFCHR creation that the VFS exempts from CAP_MKNOD, so it is as unprivileged as creating a regular file, while LANDLOCK_ACCESS_FS_MAKE_CHAR and LANDLOCK_ACCESS_FS_MAKE_BLOCK keep meaning the creation of devices that expose a kernel interface [1]. For the mknod(2) case, introduce a Landlock erratum. The creation of whiteout objects through mknod(2) was previously guarded using LANDLOCK_ACCESS_FS_MAKE_CHAR, and it is now guarded using LANDLOCK_ACCESS_FS_MAKE_REG. For the renameat2(2) case, fix a bug: Before this commit, renameat2(2) with RENAME_WHITEOUT would create a directory entry even when all LANDLOCK_ACCESS_FS_MAKE_* rights were denied. This does not affect normal renames within layered OverlayFS mounts: When doing a regular rename() on a mounted fuse-overlayfs, it is the fuse-overlayfs daemon that exercises renameat2() with RENAME_WHITEOUT, and only the Landlock domain of that daemon is checked there. Suggested-by: Christian Brauner <brauner@kernel.org> Suggested-by: Mickaël Salaün <mic@digikod.net> Cc: stable@vger.kernel.org Fixes: cb2c7d1a1776 ("landlock: Support filesystem access-control") Depends-on: 49c9e09d9610 ("landlock: Fix handling of disconnected directories") Depends-on: fe72ce6710cb ("landlock: Add errata documentation section") Signed-off-by: Günther Noack <gnoack@google.com> Link: https://patch.msgid.link/20260720.chow9ohYie5b@digikod.net [1] Link: https://patch.msgid.link/20260813093157.1436894-3-gnoack@google.com [mic: Record why LANDLOCK_ACCESS_FS_MAKE_REG is the matching right, and add link(2) to the user doc] Signed-off-by: Mickaël Salaün <mic@digikod.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 672fa082d48b21e1fb62cdb184fee41513e53421 upstream.

Whiteout objects are used in the upper layer of an OverlayFS to
indicate that the file with this name does not exist in the unified
view, even if it is present in one of the lower layer file systems.

For the userspace implementations of OverlayFS (fuse-overlayfs),
whiteout objects can be created from userspace as well:

* mknod(2) with S_IFCHR and makedev(0, 0)
* renameat2(2) with RENAME_WHITEOUT,
  creating the whiteout in the old place of the moved file.

This commit guards whiteout creation in both of these cases with
LANDLOCK_ACCESS_FS_MAKE_REG.  Whiteout objects are *not* considered
character devices and are not bound to a driver.

LANDLOCK_ACCESS_FS_MAKE_REG describes the same permission class as a
whiteout object: creating one is the only S_IFCHR creation that the VFS
exempts from CAP_MKNOD, so it is as unprivileged as creating a regular
file, while LANDLOCK_ACCESS_FS_MAKE_CHAR and
LANDLOCK_ACCESS_FS_MAKE_BLOCK keep meaning the creation of devices that
expose a kernel interface [1].

For the mknod(2) case, introduce a Landlock erratum.  The creation of
whiteout objects through mknod(2) was previously guarded using
LANDLOCK_ACCESS_FS_MAKE_CHAR, and it is now guarded using
LANDLOCK_ACCESS_FS_MAKE_REG.

For the renameat2(2) case, fix a bug: Before this commit, renameat2(2)
with RENAME_WHITEOUT would create a directory entry even when all
LANDLOCK_ACCESS_FS_MAKE_* rights were denied.

This does not affect normal renames within layered OverlayFS mounts:
When doing a regular rename() on a mounted fuse-overlayfs, it is the
fuse-overlayfs daemon that exercises renameat2() with RENAME_WHITEOUT,
and only the Landlock domain of that daemon is checked there.

Suggested-by: Christian Brauner <brauner@kernel.org>
Suggested-by: Mickaël Salaün <mic@digikod.net>
Cc: stable@vger.kernel.org
Fixes: cb2c7d1a1776 ("landlock: Support filesystem access-control")
Depends-on: 49c9e09d9610 ("landlock: Fix handling of disconnected directories")
Depends-on: fe72ce6710cb ("landlock: Add errata documentation section")
Signed-off-by: Günther Noack <gnoack@google.com>
Link: https://patch.msgid.link/20260720.chow9ohYie5b@digikod.net [1]
Link: https://patch.msgid.link/20260813093157.1436894-3-gnoack@google.com
[mic: Record why LANDLOCK_ACCESS_FS_MAKE_REG is the matching right, and
add link(2) to the user doc]
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ipvs: separate destination availability state 2026-08-10T18:23:35+00:00 Yizhou Zhao zhaoyz24@mails.tsinghua.edu.cn 2026-07-31T14:27:43+00:00 cdcc4e46180df8161f4d2f3c6fd6beaf6990133d IPVS configuration paths update destination availability while connection accounting updates destination overload state. The two independent states share dest->flags, so their read-modify-write updates can race and lose one another. Keep OVERLOAD in flags, where the preceding patch serializes its updates with dst_lock, and move AVAILABLE to cflags. This keeps configuration- controlled availability out of the scheduler hot cacheline until a scheduler needs to check it. It also prevents availability updates from clobbering overload state. The destination status bits are not exposed through the IPVS sockopt or netlink interfaces, so keep their definitions in the internal IPVS header. Readers can still observe stale destination state; this does not provide a cross-field snapshot. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn> Reported-by: Ao Wang <wangao@seu.edu.cn> Reported-by: Xuewei Feng <fengxw06@126.com> Reported-by: Qi Li <qli01@tsinghua.edu.cn> Reported-by: Ke Xu <xuke@tsinghua.edu.cn> Link: https://lore.kernel.org/all/8913381c-1e02-35c7-0ec4-61de5a12fd35@ssi.bg/ Assisted-by: Claude-Code:GLM-5.2 Suggested-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Acked-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> 
IPVS configuration paths update destination availability while connection
accounting updates destination overload state. The two independent states
share dest->flags, so their read-modify-write updates can race and lose one
another.

Keep OVERLOAD in flags, where the preceding patch serializes its updates
with dst_lock, and move AVAILABLE to cflags. This keeps configuration-
controlled availability out of the scheduler hot cacheline until a
scheduler needs to check it. It also prevents availability updates from
clobbering overload state.

The destination status bits are not exposed through the IPVS sockopt or
netlink interfaces, so keep their definitions in the internal IPVS header.

Readers can still observe stale destination state; this does not provide a
cross-field snapshot.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Reported-by: Ao Wang <wangao@seu.edu.cn>
Reported-by: Xuewei Feng <fengxw06@126.com>
Reported-by: Qi Li <qli01@tsinghua.edu.cn>
Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
Link: https://lore.kernel.org/all/8913381c-1e02-35c7-0ec4-61de5a12fd35@ssi.bg/
Assisted-by: Claude-Code:GLM-5.2
Suggested-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Merge tag 'io_uring-7.2-20260724' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux 2026-07-25T02:58:03+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-07-25T02:58:03+00:00 73387b89d99f7b588870c5a98eb6a89689c65a1a Pull io_uring fixes from Jens Axboe: - Fix a missing ERESTARTSYS conversion in the read paths, which got messed up back when some code consolidation was done for read multishot support - zcrx UAPI rename, dropping the abbreviated "notif" naming in favor of "event" for consistency and to be less ambiguous for users. This was added for 7.2, so let's rename it while we still can. No functional or code changes, just a strict rename * tag 'io_uring-7.2-20260724' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: io_uring/zcrx: rename notif to event io_uring/zcrx: rename ZCRX_NOTIF_NO_BUFFERS io_uring/zcrx: drop "notif" from stats struct names io_uring/rw: fix missing ERESTARTSYS conversion in read paths 
Pull io_uring fixes from Jens Axboe:

 - Fix a missing ERESTARTSYS conversion in the read paths, which got
   messed up back when some code consolidation was done for read
   multishot support

 - zcrx UAPI rename, dropping the abbreviated "notif" naming in favor of
   "event" for consistency and to be less ambiguous for users. This was
   added for 7.2, so let's rename it while we still can. No functional
   or code changes, just a strict rename

* tag 'io_uring-7.2-20260724' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
  io_uring/zcrx: rename notif to event
  io_uring/zcrx: rename ZCRX_NOTIF_NO_BUFFERS
  io_uring/zcrx: drop "notif" from stats struct names
  io_uring/rw: fix missing ERESTARTSYS conversion in read paths
io_uring/zcrx: rename notif to event 2026-07-22T15:48:42+00:00 Pavel Begunkov asml.silence@gmail.com 2026-07-22T13:42:17+00:00 e366c15e1610ef11d0717ecd875ae63050282676 "Notification" is too long and the abbreviated version is used in several places, which is inconsistent and more ambiguous for users. Rename it to event, which is easier to keep consistent. To keep the change small, only change uapi/ + do necessary fix ups, and the rest of internals can be adjusted in the next release. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://patch.msgid.link/f95ca6717da3c8d3649a1a7f0d883a563f545052.1784726895.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk> 
"Notification" is too long and the abbreviated version is used in
several places, which is inconsistent and more ambiguous for users.
Rename it to event, which is easier to keep consistent. To keep the
change small, only change uapi/ + do necessary fix ups, and the rest of
internals can be adjusted in the next release.

Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://patch.msgid.link/f95ca6717da3c8d3649a1a7f0d883a563f545052.1784726895.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
io_uring/zcrx: rename ZCRX_NOTIF_NO_BUFFERS 2026-07-22T15:48:42+00:00 Pavel Begunkov asml.silence@gmail.com 2026-07-22T13:42:16+00:00 201e30810223a40275f17c5e6ee410fa857b6b44 ZCRX_NOTIF_NO_BUFFERS tells when page pool fails to allocate memory from zcrx. "No buffers" could be more confusing, rename it to ZCRX_NOTIF_ALLOC_FAIL. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://patch.msgid.link/29bd4fc069bc89691868beba0627ffbe570c2722.1784726895.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk> 
ZCRX_NOTIF_NO_BUFFERS tells when page pool fails to allocate memory from
zcrx. "No buffers" could be more confusing, rename it to
ZCRX_NOTIF_ALLOC_FAIL.

Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://patch.msgid.link/29bd4fc069bc89691868beba0627ffbe570c2722.1784726895.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
io_uring/zcrx: drop "notif" from stats struct names 2026-07-22T15:48:41+00:00 Pavel Begunkov asml.silence@gmail.com 2026-07-22T13:42:15+00:00 af78c0020480aba3132fb9fa4db0fd1fb949feaa Keep zcrx statistics generic and don't stick "notif" to its uapi definitions. Stats dosn't need to be bound to notification details, it makes it cleaner and more readable. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://patch.msgid.link/6a39676b6f71b67d3f89c6ebab7a3739873834a3.1784726895.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk> 
Keep zcrx statistics generic and don't stick "notif" to its uapi
definitions. Stats dosn't need to be bound to notification details,
it makes it cleaner and more readable.

Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://patch.msgid.link/6a39676b6f71b67d3f89c6ebab7a3739873834a3.1784726895.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Merge tag 'for-7.2-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux 2026-07-21T15:06:24+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-07-21T15:06:24+00:00 51f247c4b293b470723e69a321e2cc5ecf9080db Pull btrfs fixes from David Sterba: "I'm catching up with the fix backlog in the development branch, so here's a number of them and will probably send one more for this or the next rc: - relocation fixes: - skip attempting compression on reloc inodes - exclude inline extents from file extent offset checks - fix minor memory leak after error when adding reloc root - fix root cleanup after inserting and merging - fix clearing folio tags after writeback - clear logging flag of extent map before splitting - fix unsigned 32/64 type conversions when accounting dirty metadata, leading to continually exceeding threshold - fix regression in 32bit compat ioctl for subvolume info - fix type of SEARCH_TREE ioctl buffer in UAPI header - fix expression in ASSERT expression which can be unconditionally evaluated on some compilers - only account delalloc bytes for regular inodes" * tag 'for-7.2-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: fix GET_SUBVOL_INFO after compat refactor btrfs: free mapping node on duplicate reloc root insert btrfs: fix a regression where PAGECACHE_TAG_DIRTY is never cleared btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps btrfs: fix u32 to s64 type conversion in dirty_metadata_bytes accounting btrfs: fix NULL pointer deref during assertion in btrfs_backref_free_node() btrfs: only account delalloc bytes for regular file inodes in btrfs_getattr() btrfs: reject inline file extents item in get_new_location() btrfs: do not try compression for data reloc inodes btrfs: declare btrfs_ioctl_search_args_v2::buf as __u8 btrfs: fix reloc root cleanup in merge_reloc_roots() btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol() 
Pull btrfs fixes from David Sterba:
 "I'm catching up with the fix backlog in the development branch, so
  here's a number of them and will probably send one more for this or
  the next rc:

   - relocation fixes:
     - skip attempting compression on reloc inodes
     - exclude inline extents from file extent offset checks
     - fix minor memory leak after error when adding reloc root
     - fix root cleanup after inserting and merging

   - fix clearing folio tags after writeback

   - clear logging flag of extent map before splitting

   - fix unsigned 32/64 type conversions when accounting dirty metadata,
     leading to continually exceeding threshold

   - fix regression in 32bit compat ioctl for subvolume info

   - fix type of SEARCH_TREE ioctl buffer in UAPI header

   - fix expression in ASSERT expression which can be unconditionally
     evaluated on some compilers

   - only account delalloc bytes for regular inodes"

* tag 'for-7.2-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
  btrfs: fix GET_SUBVOL_INFO after compat refactor
  btrfs: free mapping node on duplicate reloc root insert
  btrfs: fix a regression where PAGECACHE_TAG_DIRTY is never cleared
  btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps
  btrfs: fix u32 to s64 type conversion in dirty_metadata_bytes accounting
  btrfs: fix NULL pointer deref during assertion in btrfs_backref_free_node()
  btrfs: only account delalloc bytes for regular file inodes in btrfs_getattr()
  btrfs: reject inline file extents item in get_new_location()
  btrfs: do not try compression for data reloc inodes
  btrfs: declare btrfs_ioctl_search_args_v2::buf as __u8
  btrfs: fix reloc root cleanup in merge_reloc_roots()
  btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol()