linux-kernel - Re: [patch 2/5] VFS: pass open file to ->getattr()

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <E1IYpj8-00024f-00@dorka.pomaz.szeredi.hu>
Date:	Fri, 21 Sep 2007 23:07:54 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	adilger@...sterfs.com
CC:	miklos@...redi.hu, akpm@...ux-foundation.org, hch@...radead.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [patch 2/5] VFS: pass open file to ->getattr()

> On Sep 21, 2007  14:23 +0200, Miklos Szeredi wrote:
> > @@ -1212,7 +1212,8 @@ struct inode_operations {
> > -	int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *);
> > +	int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *,
> > +			struct file *file);
> 
> It's not much of an inode operation anymore if you need to pass a file
> to it...  Since the attributes are really part of the inode and not
> the file, this seems like a bit of a hack.

Well, the data is part of the inode and not the file as well.  So why
are read/write special?

OK, I realize now, that with special files (device, fifo) the I/O is
actually on the open file and _not_ on the inode.  So the above is
only true for regular files.

And so it really would make sense to make a separate fgetattr() file
operation, so we only get it for regular files and not for special
files.  Because for the specail file case it really doesn't make sense
to pass the file pointer to the filesystem, since the filesystem knows
nothing about the open file.

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/