kernel/git/stable/linux.git/fs/reiserfs/xattr.c, branch master

reiserfs: The last commit

2024-10-21T14:29:38+00:00

Deprecation period of reiserfs ends with the end of this year so it is time to remove it from the kernel. Acked-by: Darrick J. Wong Acked-by: Christian Brauner Signed-off-by: Jan Kara

reiserfs: move reiserfs_xattr_handlers to .rodata

2023-10-10T11:49:19+00:00

This makes it harder for accidental or malicious changes to reiserfs_xattr_handlers at runtime. Cc: reiserfs-devel@vger.kernel.org Signed-off-by: Wedson Almeida Filho Link: https://lore.kernel.org/r/20230930050033.41174-23-wedsonaf@gmail.com Signed-off-by: Christian Brauner

reiserfs: convert to ctime accessor functions

2023-07-24T08:30:04+00:00

In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Signed-off-by: Jeff Layton Reviewed-by: Jan Kara Message-Id: <20230705190309.579783-70-jlayton@kernel.org> Signed-off-by: Christian Brauner

reiserfs: rework priv inode handling

2023-03-06T08:57:13+00:00

Reiserfs is the only filesystem that removes IOP_XATTR without also using a set of dedicated inode operations at the same time that nop all xattr related inode operations. This means we need to have a IOP_XATTR check in vfs_listxattr() instead of just being able to check for ->listxatt() being implemented. Introduce a dedicated set of nop inode operations that are used when IOP_XATTR is removed, allowing us to remove that check from vfs_listxattr(). This in turn allows us to completely decouple POSIX ACLs from IOP_XATTR. Cc: reiserfs-devel@vger.kernel.org Signed-off-by: Christian Brauner (Microsoft)

reiserfs: rework ->listxattr() implementation

2023-03-06T08:57:12+00:00

Rework reiserfs so it doesn't have to rely on the dummy xattr handlers in its s_xattr list anymore as this is completely unused for setting and getting posix acls. Cc: reiserfs-devel@vger.kernel.org Signed-off-by: Christian Brauner (Microsoft)

fs: port ->permission() to pass mnt_idmap

2023-01-19T08:24:28+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 ->mkdir() to pass mnt_idmap

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

fs: port ->create() to pass mnt_idmap

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

fs: port ->setattr() to pass mnt_idmap

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

Change calling conventions for filldir_t

2022-08-17T21:25:04+00:00

filldir_t instances (directory iterators callbacks) used to return 0 for "OK, keep going" or -E... for "stop". Note that it's *NOT* how the error values are reported - the rules for those are callback-dependent and ->iterate{,_shared}() instances only care about zero vs. non-zero (look at emit_dir() and friends). So let's just return bool ("should we keep going?") - it's less confusing that way. The choice between "true means keep going" and "true means stop" is bikesheddable; we have two groups of callbacks - do something for everything in directory, until we run into problem and find an entry in directory and do something to it. The former tended to use 0/-E... conventions - -E on failure. The latter tended to use 0/1, 1 being "stop, we are done". The callers treated anything non-zero as "stop", ignoring which non-zero value did they get. "true means stop" would be more natural for the second group; "true means keep going" - for the first one. I tried both variants and the things like if allocation failed something = -ENOMEM; return true; just looked unnatural and asking for trouble. [folded suggestion from Matthew Wilcox ] Acked-by: Christian Brauner (Microsoft) Signed-off-by: Al Viro