lwn.git/fs/xfs/xfs_symlink.c, branch v6.5-rc1

fs: port fs{g,u}id helpers to mnt_idmap

2023-01-19T08:24:30+00:00

Convert to struct mnt_idmap. Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conversion to struct mnt_idmap. Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevent on the mount level. Especially for non-vfs developers without detailed knowledge in this area this can be a potential source for bugs. Once the conversion to struct mnt_idmap is done all helpers down to the really low-level helpers will take a struct mnt_idmap argument instead of two namespace arguments. This way it becomes impossible to conflate the two eliminating the possibility of any bugs. All of the vfs and all filesystems only operate on struct mnt_idmap. Acked-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner (Microsoft)

fs: port inode_init_owner() to mnt_idmap

2023-01-19T08:24:28+00:00

xfs: replace inode fork size macros with functions

2022-07-12T18:17:27+00:00

Replace the shouty macros here with typechecked helper functions. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner

xfs: Directory's data fork extent counter can never overflow

2022-04-13T07:02:07+00:00

The maximum file size that can be represented by the data fork extent counter in the worst case occurs when all extents are 1 block in length and each block is 1KB in size. With XFS_MAX_EXTCNT_DATA_FORK_SMALL representing maximum extent count and with 1KB sized blocks, a file can reach upto, (2^31) * 1KB = 2TB This is much larger than the theoretical maximum size of a directory i.e. XFS_DIR2_SPACE_SIZE * 3 = ~96GB. Since a directory's inode can never overflow its data fork extent counter, this commit removes all the overflow checks associated with it. xfs_dinode_verify() now performs a rough check to verify if a diretory's data fork is larger than 96GB. Reviewed-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Chandan Babu R

Merge tag 'xfs-5.17-merge-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux

2022-01-11T23:01:50+00:00

Pull xfs updates from Darrick Wong: "The big new feature here is that the mount code now only bothers to try to free stale COW staging extents if the fs unmounted uncleanly. This should reduce mount times, particularly on filesystems supporting reflink and containing a large number of allocation groups. Everything else this cycle are bugfixes, as the iomap folios conversion should be plenty enough excitement for anyone. That and I ran out of brain bandwidth after Thanksgiving last year. Summary: - Fix log recovery with da btree buffers when metauuid is in use. - Fix type coercion problems in xattr buffer size validation. - Fix a bug in online scrub dir leaf bestcount checking. - Only run COW recovery when recovering the log. - Fix symlink target buffer UAF problems and symlink locking problems by not exposing xfs innards to the VFS. - Fix incorrect quotaoff lock usage. - Don't let transactions cancel cleanly if they have deferred work items attached. - Fix a UAF when we're deciding if we need to relog an intent item. - Reduce kvmalloc overhead for log shadow buffers. - Clean up sysfs attr group usage. - Fix a bug where scrub's bmap/rmap checking could race with a quota file block allocation due to insufficient locking. - Teach scrub to complain about invalid project ids" * tag 'xfs-5.17-merge-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: warn about inodes with project id of -1 xfs: hold quota inode ILOCK_EXCL until the end of dqalloc xfs: Remove redundant assignment of mp xfs: reduce kvmalloc overhead for CIL shadow buffers xfs: sysfs: use default_groups in kobj_type xfs: prevent UAF in xfs_log_item_in_current_chkpt xfs: prevent a WARN_ONCE() in xfs_ioc_attr_list() xfs: Fix comments mentioning xfs_ialloc xfs: check sb_meta_uuid for dabuf buffer recovery xfs: fix a bug in the online fsck directory leaf1 bestcount check xfs: only run COW extent recovery when there are no live extents xfs: don't expose internal symlink metadata buffers to the vfs xfs: fix quotaoff mutex usage now that we don't support disabling it xfs: shut down filesystem if we xfs_trans_cancel with deferred work items

xfs: don't expose internal symlink metadata buffers to the vfs

2021-12-21T17:49:41+00:00

Ian Kent reported that for inline symlinks, it's possible for vfs_readlink to hang on to the target buffer returned by _vn_get_link_inline long after it's been freed by xfs inode reclaim. This is a layering violation -- we should never expose XFS internals to the VFS. When the symlink has a remote target, we allocate a separate buffer, copy the internal information, and let the VFS manage the new buffer's lifetime. Let's adapt the inline code paths to do this too. It's less efficient, but fixes the layering violation and avoids the need to adapt the if_data lifetime to rcu rules. Clearly I don't care about readlink benchmarks. As a side note, this fixes the minor locking violation where we can access the inode data fork without taking any locks; proper locking (and eliminating the possibility of having to switch inode_operations on a live inode) is essential to online repair coordinating repairs correctly. Reported-by: Ian Kent Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner

fs: port higher-level mapping helpers

2021-12-05T09:28:57+00:00

Enable the mapped_fs{g,u}id() helpers to support filesystems mounted with an idmapping. Apart from core mapping helpers that use mapped_fs{g,u}id() to initialize struct inode's i_{g,u}id fields xfs is the only place that uses these low-level helpers directly. The patch only extends the helpers to be able to take the filesystem idmapping into account. Since we don't actually yet pass the filesystem's idmapping in no functional changes happen. This will happen in a final patch. Link: https://lore.kernel.org/r/20211123114227.3124056-9-brauner@kernel.org (v1) Link: https://lore.kernel.org/r/20211130121032.3753852-9-brauner@kernel.org (v2) Link: https://lore.kernel.org/r/20211203111707.3901969-9-brauner@kernel.org Cc: Seth Forshee Cc: Christoph Hellwig Cc: Al Viro CC: linux-fsdevel@vger.kernel.org Reviewed-by: Amir Goldstein Reviewed-by: Seth Forshee Signed-off-by: Christian Brauner

xfs: replace XFS_FORCED_SHUTDOWN with xfs_is_shutdown

2021-08-19T17:07:13+00:00

Remove the shouty macro and instead use the inline function that matches other state/feature check wrapper naming. This conversion was done with sed. Signed-off-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong

xfs: convert mount flags to features

2021-08-19T17:07:12+00:00

Replace m_flags feature checks with xfs_has_() calls and rework the setup code to set flags in m_features. Signed-off-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong

xfs: replace xfs_sb_version checks with feature flag checks

2021-08-19T17:07:12+00:00

Convert the xfs_sb_version_hasfoo() to checks against mp->m_features. Checks of the superblock itself during disk operations (e.g. in the read/write verifiers and the to/from disk formatters) are not converted - they operate purely on the superblock state. Everything else should use the mount features. Large parts of this conversion were done with sed with commands like this: for f in `git grep -l xfs_sb_version_has fs/xfs/*.c`; do sed -i -e 's/xfs_sb_version_has$.*$(&$.*$->m_sb)/xfs_has_\1(\2)/' $f done With manual cleanups for things like "xfs_has_extflgbit" and other little inconsistencies in naming. The result is ia lot less typing to check features and an XFS binary size reduced by a bit over 3kB: $ size -t fs/xfs/built-in.a text data bss dec hex filenam before 1130866 311352 484 1442702 16038e (TOTALS) after 1127727 311352 484 1439563 15f74b (TOTALS) Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong