linux-kernel - Re: vfs-scale, keep the errno

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, 14 Jan 2011 14:17:11 +0100
From:	"Hans-Peter Jansen" <hpj@...la.net>
To:	Nick Piggin <npiggin@...il.com>
Cc:	"J. R. Okajima" <hooanon05@...oo.co.jp>,
	"linux-fsdevel" <linux-fsdevel@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: vfs-scale, keep the errno

On Friday 14 January 2011, 05:01:37 Nick Piggin wrote:
> On Fri, Jan 14, 2011 at 2:38 PM, J. R. Okajima <hooanon05@...oo.co.jp> 
wrote:
> > When open(2) without O_DIRECTORY opens an existing dir, it should
> > return EISDIR. In do_last(), the variable 'error' is initialized
> > EISDIR, but it is changed by d_revalidate() which returns any
> > positive to represent 'the target dir is valid.'
> > Should we keep and return the initialized 'error' in this case.
>
> Great, thank you very much. I just changed a few variable names but
> applied it. Would you please add you Signed-off-by: on patches from
> now on?
>
> Good reviewing work. Are you finding these by review or testing? I
> think ltptests on an nfs mount should find this kind of bug... which
> I should do.

Nick, Junjiro is well known as a very smart (and|but) humble guy in the 
kernel niche of layered filesystems. Be assured, that almost every live 
distribution (one, that is runnable from RO media directly) _relies_ on 
his work: aufs (http://aufs.sourceforge.net/) to get the job done. Also 
many diskless setups (as do mine) relies on aufs.

It's a real pity, that all other approaches to layered filesystems (or 
filesystem unification, overlay filesystems), that are done by others, 
are either
 - technically inferior
 - restricted in usage scenarios
 - simply unfinished

but get more attention in the kernel guild. All, that Junjiro's approach 
takes is exporting a handful of symbols in order to be able to build it 
as a module also (and the number decreases as other lately merged 
subsystems do need them as well, i.e. apparmor). That's all. 

Layered filesystems are a killer feature, that could have been in the 
kernel for years, but is still missing for hard to follow (e.g. 
political, emotional) reasons. There are many interesting things, that 
can be done with layered filesystems, hard to archive up to impossible 
to be done otherwise). 

Sadly,
Pete
--
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/