linux-kernel - Re: [PATCH 05/16] GFS2: File and inode operations

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: <1158568042.11901.267.camel@quoit.chygwyn.com>
Date:	Mon, 18 Sep 2006 09:27:22 +0100
From:	Steven Whitehouse <swhiteho@...hat.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	linux-kernel@...r.kernel.org,
	Russell Cattelan <cattelan@...hat.com>,
	David Teigland <teigland@...hat.com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH 05/16] GFS2: File and inode operations

Hi,

On Sat, 2006-09-16 at 14:39 +0100, Christoph Hellwig wrote:
> > 
> > >+struct file gfs2_internal_file_sentinal = {
> > >+	.f_flags = O_NOATIME|O_RDONLY,
> > >+};
> 
> Statically allocation a struct file is not allowed.  Where do you use
> gfs2_internal_read?  It really shouldn't be needed.
> 
The sentinel is used as a flag value only. Its passed through to the
underlying address space operations of readpage(s) to indicate that the
glock for the inode is already held and therefore locking isn't required
at the address space operations level. The glock is used to ensure
consistancy when reading certain "internal" files.

For example, the resource index contains a list of all the resource
groups on disk and is written through the gfs2meta filesystem when the
filesystem is expanded. We need a way to read the resource index in, in
such a way as to ensure its not being updated in the middle of the read.
So we use gfs2_internal_read to do that, holding the glock for the
entire operation.

It has a similar use for some of the other internal files as well.

> > >+static int gfs2_readdir(struct file *file, void *dirent, filldir_t filldir)
> > >+{
> > >+	int error;
> > >+
> > >+	if (strcmp(current->comm, "nfsd") != 0)
> > 
> > Is not there a better way to do this? Note that there is also a "nfsd4" process
> 
> This is in fact not allowed at at all.  Please fix you readdir code not to
> need special cases for nfsd.
> 
Perhaps you can suggest a solution to the problem.... We have a bz
#201015 (in bugzilla.redhat.com) tracking this.

The problem is caused by the way in which nfsd does a stat from
readdir's filldir routine. We have to acquire and drop the directory
glock in filldir otherwise it may deadlock with the glocks which are
taken by stat. As a result of this, we then have to revalidate the
position in the directory on each call to filldir, rather than locking
the whole readdir call as the "normal" version does, so the current nfs
variant of readdir is much slower than the "normal" one even though it
could otherwise potentially be used for both cases.

I will try and have a look at this problem in more detail some time this
week,

Steve.

-
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/