linux-kernel - Re: [PATCH 3/4] unionfs: restructure unionfs

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]

Message-Id: <200712190114.lBJ1Ean2023273@agora.fsl.cs.sunysb.edu>
Date:	Tue, 18 Dec 2007 20:14:36 -0500
From:	Erez Zadok <ezk@...sunysb.edu>
To:	Hugh Dickins <hugh@...itas.com>
Cc:	Erez Zadok <ezk@...sunysb.edu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] unionfs: restructure unionfs_setattr 

In message <Pine.LNX.4.64.0712190030390.5639@...nde.wat.veritas.com>, Hugh Dickins writes:
> On Tue, 18 Dec 2007, Erez Zadok wrote:
> > In message <Pine.LNX.4.64.0712182213300.28390@...nde.wat.veritas.com>, Hugh Dickins writes:
> > > In order to fix unionfs truncation, we need to move the lower notify_change
> > > out of the loop in unionfs_setattr.  But when I came to do that, I couldn't
> > [...]
> > 
> > Hugh, I want to understand how patches 3/4 and 4/4 are related.  In patch 3
> > you say "in order to fix truncation" but you mention a truncation problem
> > only in patch 4; is there a patch ordering problem, or they're both related
> > to the same issue (with 3/4 being a code cleanup, and 4/4 actually fixing
> > the problem)?
> 
> I needed to move that notify_change out of the loop, to fix the truncation
> problem, but had great difficulty understanding the loop.  So, just as you
> say, made the code cleanup first in 3/4, then fixed the problem in 4/4.
> 
> But that cleanup does need your review and testing.

A quick look at your setattr patches seems very promising.  And I've further
realized more cleanup is possible: because we call revalidate_chain at the
opening to ->setattr, we're guaranteed to have a valid lower dentry, so for
example we can remove the else case for "if (lower_dentry)".

I'll be testing this and your other patches, plus look into the locking
issues you brought up.

Thanks,
Erez.
--
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/