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:	Fri, 5 Dec 2008 11:02:00 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Howells <dhowells@...hat.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>, bfields@...ldses.org,
	hugh@...itas.com, hch@...radead.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] EXPORTFS: Don't return NULL from fh_to_dentry()/fh_to_parent()
 [ver #4]



On Fri, 5 Dec 2008, David Howells wrote:
> 
> The d_obtain_alias() function will immediately return -ESTALE if given a NULL
> inode, though, and sometimes it'll return some other error.
> 
> It would also seem odd to sometimes return NULL to indicate an error, and
> sometimes return a -ve error code to indicate an error.  Perhaps one or the
> other should be selected for consistency.

Well, the thing is, returning NULL is probably the most natural thing to 
do for a filesystem that doesn't really _have_ a valid error code for the 
situation. It's more of a "I can't do this" thing, than an error. 

Sure, we can make all filesystems return -ESTALE, but not only is the 
patch fairly big, it really doesn't look at all better or make any more 
sense. ESTALE is really strictly a NFS thing - it doesn't tend to make 
sense for other filesystems (well, sure, other filesystems may have inode 
versions too and decide to use ESTALE for things, so I'm not claiming that 
it's _purely_ a NFS thing, but I think you see my point).

So it really seems to make more sense to just make the ESTALE handling be 
a NFS issue. 

And notice that I'm not arguing that "fh_to_dentr/parent()" should 
_always_ return NULL for errors. There may be real reasons why a 
filesystem might want to return some actual error, like EIO. And maybe a 
filesystem actually wants to return an explicit ESTALE when that makes 
sense (ie when the filesystem _does_ find an inode that matches, but the 
generation doesn't match).

But I'm just looking at your patch, and seeing things like

	        if (fh_len <= 2)
	-               return NULL;
	+               return ERR_PTR(-ESTALE);

and going "That really didn't make the code any prettier or easier to 
understand".

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ