linux-kernel - Re: [RFC] readdir mess

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:	Sun, 24 Aug 2008 11:10:14 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jan Harkes <jaharkes@...cmu.edu>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] readdir mess

On Fri, Aug 15, 2008 at 09:58:31AM -0700, Linus Torvalds wrote:

> because the "filldir()" functions should all do the right thing anyway. 
> But there's certainly nothing wrong with doing it either.

Not all, but those won't hit coda.
 
> However, I think the real fix is something like this. This 
> 
>  - fixes all the callers
> 
>  - removes more lines than it adds
> 
>  - simplifies and clarifies the code
> 
>  - avoids pointless goto's
> 
>  - makes error handling of vfs_readdir() consistent among the callers
>    (some callers already did the error handling _correctly_ before this 
>    patch - this makes everybody do it the same way)

One obvious note: that'll break old_readdir() on coda.  There you need to
change the existing check (you need to check buf.result, then ignore error
unless buf.result ended up 0).

I agree that such transition plan makes sense, but that'll take more
preliminary work than in your patch; there are other vfs_readdir() and
->readdir() callers, not just the obvious syscall ones.

BTW, there are several places that call specific foo_readdir() or its helper
functions, passing odd stuff as filldir (afs implements ->lookup() that way,
for one; ocfs2 checks that directory is empty; gfs2 does ->get_name() -
with filldir returning 1 on match, at that; etc.).  We obviously do not care
about those in the beginning of patch series - they won't be affected,
but once we start converting foofs_readdir() to returning what filldir had
returned, we'll need to watch out for complications from those (BTW, another
fun place in that respect is __fat_readdir())
--
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/