lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241118112632.gfnhr7ldcjdi6d2z@quack3>
Date: Mon, 18 Nov 2024 12:26:32 +0100
From: Jan Kara <jack@...e.cz>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: brauner@...nel.org, viro@...iv.linux.org.uk, jack@...e.cz,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] vfs: move getattr in inode_operations to a more commonly
 read area

On Mon 18-11-24 01:20:24, Mateusz Guzik wrote:
> Notabaly occupied by lookup, get_link and permission.
> 
> This pushes unlink to another cache line, otherwise the layout is the
> same on that front.
> 
> Signed-off-by: Mateusz Guzik <mjguzik@...il.com>
> ---
> 
> Probably more can be done to rearrange struct. If someone is down to do
> it, I'm happy with this patch being dropped.

This makes some sense to me although I'd like to establish some higher
level guidelines (and document them in a comment) about what goes where in
the inode_operations struct. A lot of accesses to inode->i_op actually do
get optimized away with inode->i_opflags (e.g. frequent stuff like
.permission or .get_inode_acl) so there are actually high chances there's
only one access to inode->i_op for the operation we are doing and in such
case the ordering inside inode_operations doesn't really matter (it's
likely cache cold anyway). So I'm somewhat uncertain what the right
grouping should be and if it matters at all.

								Honza

> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 7e29433c5ecc..972147da71f9 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2140,6 +2140,8 @@ struct inode_operations {
>  	const char * (*get_link) (struct dentry *, struct inode *, struct delayed_call *);
>  	int (*permission) (struct mnt_idmap *, struct inode *, int);
>  	struct posix_acl * (*get_inode_acl)(struct inode *, int, bool);
> +	int (*getattr) (struct mnt_idmap *, const struct path *,
> +			struct kstat *, u32, unsigned int);
>  
>  	int (*readlink) (struct dentry *, char __user *,int);
>  
> @@ -2157,8 +2159,6 @@ struct inode_operations {
>  	int (*rename) (struct mnt_idmap *, struct inode *, struct dentry *,
>  			struct inode *, struct dentry *, unsigned int);
>  	int (*setattr) (struct mnt_idmap *, struct dentry *, struct iattr *);
> -	int (*getattr) (struct mnt_idmap *, const struct path *,
> -			struct kstat *, u32, unsigned int);
>  	ssize_t (*listxattr) (struct dentry *, char *, size_t);
>  	int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start,
>  		      u64 len);
> -- 
> 2.43.0
> 
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ