linux-kernel - Re: [PATCH 1/3] enhanced lookup ESTALE error handling (v3)

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]

Date:	Mon, 10 Mar 2008 23:03:04 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	akpm@...ux-foundation.org
CC:	staubach@...hat.com, linux-kernel@...r.kernel.org,
	linux-nfs@...r.kernel.org, trond.myklebust@....uio.no,
	linux-fsdevel@...r.kernel.org, viro@...iv.linux.org.uk, hch@....de,
	haveblue@...ibm.com
Subject: Re: [PATCH 1/3] enhanced lookup ESTALE error handling (v3)

> > This is a patch to enhance ESTALE error handling during the
> > lookup process.  The error, ESTALE, can occur when out of data
> > dentries, stored in the dcache, is used to translate a pathname
> > component to a dentry.  When this occurs, the dentry which
> > contains the pointer to the inode which refers to the non-existent
> > file is dropped from the dcache and then the lookup process
> > started again.  Care is taken to ensure that forward process is
> > always being made.  If forward process is not detected, then the
> > lookup process is terminated and the error, ENOENT, is returned
> > to the caller.
> 
> This collides in non-trivial ways with the always-coming-never-arrives
> r-o-bind-mounts patches.
> 
> I have an old version of those patches in -mm and I believe that Al
> is/was/has set up some git tree with these patches and perhaps other stuff.
> 
> So some coordination is required please.  I'd suggest that if Al indeed
> does have such a tree, he hand over the URL so I can get it into -mm and
> that you then redo these patches on top of that.
> 
> Please also Cc Al and Christoph on these patches, as they are hitting files
> which they maintain and develop.

Also my objection about breaking backward compatibility for fuse
filesystems is still seemingly unaddressed.

I know it would be more convenient to push this problem into the fuse
filesystems, but they are unfortunately on the other side of the
stable kernel ABI, so this is not an option.

I've already presented a solution (which wasn't greeted with big
enthusiasm), and I'm open to discussion about other ways to solve
this.

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/