kernel/linux.git/fs/libfs.c, branch v6.6.132

better lockdep annotations for simple_recursive_removal()

2025-08-28T14:28:15+00:00

[ Upstream commit 2a8061ee5e41034eb14170ec4517b5583dbeff9f ] We want a class that nests outside of I_MUTEX_NORMAL (for the sake of callbacks that might want to lock the victim) and inside I_MUTEX_PARENT (so that a variant of that could be used with parent of the victim held locked by the caller). In reality, simple_recursive_removal() * never holds two locks at once * holds the lock on parent of dentry passed to callback * is used only on the trees with fixed topology, so the depths are not changing. So the locking order is actually fine. AFAICS, the best solution is to assign I_MUTEX_CHILD to the locks grabbed by that thing. Reported-by: syzbot+169de184e9defe7fe709@syzkaller.appspotmail.com Signed-off-by: Al Viro Signed-off-by: Sasha Levin

libfs: Use d_children list to iterate simple_offset directories

2025-02-01T17:37:54+00:00

[ Upstream commit b9b588f22a0c049a14885399e27625635ae6ef91 ] The mtree mechanism has been effective at creating directory offsets that are stable over multiple opendir instances. However, it has not been able to handle the subtleties of renames that are concurrent with readdir. Instead of using the mtree to emit entries in the order of their offset values, use it only to map incoming ctx->pos to a starting entry. Then use the directory's d_children list, which is already maintained properly by the dcache, to find the next child to emit. One of the sneaky things about this is that when the mtree-allocated offset value wraps (which is very rare), looking up ctx->pos++ is not going to find the next entry; it will return NULL. Instead, by following the d_children list, the offset values can appear in any order but all of the entries in the directory will be visited eventually. Note also that the readdir() is guaranteed to reach the tail of this list. Entries are added only at the head of d_children, and readdir walks from its current position in that list towards its tail. Signed-off-by: Chuck Lever Link: https://lore.kernel.org/r/20241228175522.1854234-6-cel@kernel.org Signed-off-by: Christian Brauner [ cel: adjusted to apply to origin/linux-6.6.y ] Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman

libfs: Replace simple_offset end-of-directory detection

2025-02-01T17:37:54+00:00

[ Upstream commit 68a3a65003145644efcbb651e91db249ccd96281 ] According to getdents(3), the d_off field in each returned directory entry points to the next entry in the directory. The d_off field in the last returned entry in the readdir buffer must contain a valid offset value, but if it points to an actual directory entry, then readdir/getdents can loop. This patch introduces a specific fixed offset value that is placed in the d_off field of the last entry in a directory. Some user space applications assume that the EOD offset value is larger than the offsets of real directory entries, so the largest valid offset value is reserved for this purpose. This new value is never allocated by simple_offset_add(). When ->iterate_dir() returns, getdents{64} inserts the ctx->pos value into the d_off field of the last valid entry in the readdir buffer. When it hits EOD, offset_readdir() sets ctx->pos to the EOD offset value so the last entry is updated to point to the EOD marker. When trying to read the entry at the EOD offset, offset_readdir() terminates immediately. It is worth noting that using a Maple tree for directory offset value allocation does not guarantee a 63-bit range of values -- on platforms where "long" is a 32-bit type, the directory offset value range is still 0..(2^31 - 1). For broad compatibility with 32-bit user space, the largest tmpfs directory cookie value is now S32_MAX. Fixes: 796432efab1e ("libfs: getdents() should return 0 after reaching EOD") Signed-off-by: Chuck Lever Link: https://lore.kernel.org/r/20241228175522.1854234-5-cel@kernel.org Signed-off-by: Christian Brauner [ cel: adjusted to apply to origin/linux-6.6.y ] Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman

Revert "libfs: Add simple_offset_empty()"

2025-02-01T17:37:54+00:00

[ Upstream commit d7bde4f27ceef3dc6d72010a20d4da23db835a32 ] simple_empty() and simple_offset_empty() perform the same task. The latter's use as a canary to find bugs has not found any new issues. A subsequent patch will remove the use of the mtree for iterating directory contents, so revert back to using a similar mechanism for determining whether a directory is indeed empty. Only one such mechanism is ever needed. Signed-off-by: Chuck Lever Link: https://lore.kernel.org/r/20241228175522.1854234-3-cel@kernel.org Reviewed-by: Yang Erkun Signed-off-by: Christian Brauner [ cel: adjusted to apply to origin/linux-6.6.y ] Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman

libfs: Return ENOSPC when the directory offset range is exhausted

2025-02-01T17:37:53+00:00

[ Upstream commit 903dc9c43a155e0893280c7472d4a9a3a83d75a6 ] Testing shows that the EBUSY error return from mtree_alloc_cyclic() leaks into user space. The ERRORS section of "man creat(2)" says: > EBUSY O_EXCL was specified in flags and pathname refers > to a block device that is in use by the system > (e.g., it is mounted). ENOSPC is closer to what applications expect in this situation. Note that the normal range of simple directory offset values is 2..2^63, so hitting this error is going to be rare to impossible. Fixes: 6faddda69f62 ("libfs: Add directory operations for stable offsets") Cc: stable@vger.kernel.org # v6.9+ Reviewed-by: Jeff Layton Reviewed-by: Yang Erkun Signed-off-by: Chuck Lever Link: https://lore.kernel.org/r/20241228175522.1854234-2-cel@kernel.org Signed-off-by: Christian Brauner [ cel: adjusted to apply to origin/linux-6.6.y ] Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman

shmem: Fix shmem_rename2()

2025-02-01T17:37:53+00:00

[ Upstream commit ad191eb6d6942bb835a0b20b647f7c53c1d99ca4 ] When renaming onto an existing directory entry, user space expects the replacement entry to have the same directory offset as the original one. Link: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15966 Fixes: a2e459555c5f ("shmem: stable directory offsets") Signed-off-by: Chuck Lever Link: https://lore.kernel.org/r/20240415152057.4605-4-cel@kernel.org Signed-off-by: Christian Brauner Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman

libfs: Add simple_offset_rename() API

2025-02-01T17:37:53+00:00

[ Upstream commit 5a1a25be995e1014abd01600479915683e356f5c ] I'm about to fix a tmpfs rename bug that requires the use of internal simple_offset helpers that are not available in mm/shmem.c Signed-off-by: Chuck Lever Link: https://lore.kernel.org/r/20240415152057.4605-3-cel@kernel.org Signed-off-by: Christian Brauner Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman

libfs: Fix simple_offset_rename_exchange()

2025-02-01T17:37:53+00:00

[ Upstream commit 23cdd0eed3f1fff3af323092b0b88945a7950d8e ] User space expects the replacement (old) directory entry to have the same directory offset after the rename. Suggested-by: Christian Brauner Fixes: a2e459555c5f ("shmem: stable directory offsets") Signed-off-by: Chuck Lever Link: https://lore.kernel.org/r/20240415152057.4605-2-cel@kernel.org Signed-off-by: Christian Brauner [ cel: adjusted to apply to origin/linux-6.6.y ] Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman

libfs: Add simple_offset_empty()

2025-02-01T17:37:53+00:00

[ Upstream commit ecba88a3b32d733d41e27973e25b2bc580f64281 ] For simple filesystems that use directory offset mapping, rely strictly on the directory offset map to tell when a directory has no children. After this patch is applied, the emptiness test holds only the RCU read lock when the directory being tested has no children. In addition, this adds another layer of confirmation that simple_offset_add/remove() are working as expected. Reviewed-by: Jan Kara Signed-off-by: Chuck Lever Link: https://lore.kernel.org/r/170820143463.6328.7872919188371286951.stgit@91.116.238.104.host.secureserver.net Signed-off-by: Christian Brauner Stable-dep-of: 5a1a25be995e ("libfs: Add simple_offset_rename() API") Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman

libfs: Define a minimum directory offset

2025-02-01T17:37:53+00:00

[ Upstream commit 7beea725a8ca412c6190090ce7c3a13b169592a1 ] This value is used in several places, so make it a symbolic constant. Reviewed-by: Jan Kara Signed-off-by: Chuck Lever Link: https://lore.kernel.org/r/170820142741.6328.12428356024575347885.stgit@91.116.238.104.host.secureserver.net Signed-off-by: Christian Brauner Stable-dep-of: ecba88a3b32d ("libfs: Add simple_offset_empty()") Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman