Re: [GIT PULL] overlay filesystem v25

2014-10-28 Thread Paul E. McKenney
On Tue, Oct 28, 2014 at 10:55:13PM +, Al Viro wrote: > On Mon, Oct 27, 2014 at 09:11:27PM -0700, Paul E. McKenney wrote: > > On Tue, Oct 28, 2014 at 01:12:14AM +, Al Viro wrote: > > > On Mon, Oct 27, 2014 at 10:36:21AM -0700, Paul E. McKenney wrote: > > > > Code making direct use of smp_rea

Re: [GIT PULL] overlay filesystem v25

2014-10-28 Thread Al Viro
On Mon, Oct 27, 2014 at 09:11:27PM -0700, Paul E. McKenney wrote: > On Tue, Oct 28, 2014 at 01:12:14AM +, Al Viro wrote: > > On Mon, Oct 27, 2014 at 10:36:21AM -0700, Paul E. McKenney wrote: > > > Code making direct use of smp_read_barrier_depends() is harder to read, > > > in my experience, bu

Re: [GIT PULL] overlay filesystem v25

2014-10-27 Thread Paul E. McKenney
On Tue, Oct 28, 2014 at 01:12:14AM +, Al Viro wrote: > On Mon, Oct 27, 2014 at 10:36:21AM -0700, Paul E. McKenney wrote: > > Code making direct use of smp_read_barrier_depends() is harder to read, > > in my experience, but good point on the sparse noise. Maybe a new > > lockless_dereference()

Re: [GIT PULL] overlay filesystem v25

2014-10-27 Thread Al Viro
On Mon, Oct 27, 2014 at 10:36:21AM -0700, Paul E. McKenney wrote: > Code making direct use of smp_read_barrier_depends() is harder to read, > in my experience, but good point on the sparse noise. Maybe a new > lockless_dereference() primitive? Maybe something like the following? > (Untested, prob

Re: [GIT PULL] overlay filesystem v25

2014-10-27 Thread Paul E. McKenney
On Mon, Oct 27, 2014 at 05:28:01PM +, Al Viro wrote: > On Mon, Oct 27, 2014 at 08:59:01AM -0700, Paul E. McKenney wrote: > > > Indeed, life is hard here. Keep in mind that lock acquisition is not > > guaranteed to prevent prior operations from being reordered into the > > critical section, po

Re: [GIT PULL] overlay filesystem v25

2014-10-27 Thread Al Viro
On Mon, Oct 27, 2014 at 08:59:01AM -0700, Paul E. McKenney wrote: > Indeed, life is hard here. Keep in mind that lock acquisition is not > guaranteed to prevent prior operations from being reordered into the > critical section, possibly as follows: > > CPU1: > grab lock > i

Re: [GIT PULL] overlay filesystem v25

2014-10-27 Thread Paul E. McKenney
On Mon, Oct 27, 2014 at 09:06:54AM +0100, Miklos Szeredi wrote: > [Paul McKenney added to CC] > > On Sat, Oct 25, 2014 at 7:06 PM, Al Viro wrote: > > On Sat, Oct 25, 2014 at 11:53:52AM +0200, Miklos Szeredi wrote: > > > >> Yes, but it's not about race with copy-up (which the ovl_path_upper() > >>

Re: [GIT PULL] overlay filesystem v25

2014-10-27 Thread Miklos Szeredi
[Paul McKenney added to CC] On Sat, Oct 25, 2014 at 7:06 PM, Al Viro wrote: > On Sat, Oct 25, 2014 at 11:53:52AM +0200, Miklos Szeredi wrote: > >> Yes, but it's not about race with copy-up (which the ovl_path_upper() >> protects against), but race of two fsync calls with each other. If >> there'

Re: [GIT PULL] overlay filesystem v25

2014-10-25 Thread Al Viro
On Sat, Oct 25, 2014 at 11:53:52AM +0200, Miklos Szeredi wrote: > Yes, but it's not about race with copy-up (which the ovl_path_upper() > protects against), but race of two fsync calls with each other. If > there's no synchronization between them, then that od->upperfile does > indeed count as lo

Re: [GIT PULL] overlay filesystem v25

2014-10-25 Thread Al Viro
On Fri, Oct 24, 2014 at 09:24:45AM +0200, Miklos Szeredi wrote: > The reason I didn't do your "fix" is that it > > - adds more lines than it takes, > > - I wasn't sure at all if the lockless access is actually correct > without the ACCESS_ONCE and all the memory barrier magic that might be >

Re: [GIT PULL] overlay filesystem v25

2014-10-25 Thread Miklos Szeredi
On Sat, Oct 25, 2014 at 10:18 AM, Al Viro wrote: > On Fri, Oct 24, 2014 at 09:24:45AM +0200, Miklos Szeredi wrote: > >> The reason I didn't do your "fix" is that it >> >> - adds more lines than it takes, >> >> - I wasn't sure at all if the lockless access is actually correct >> without the ACCES

Re: [GIT PULL] overlay filesystem v25

2014-10-24 Thread Geert Uytterhoeven
Hi Al, On Fri, Oct 24, 2014 at 5:24 AM, Al Viro wrote: > On Fri, Oct 24, 2014 at 03:20:55AM +0100, Al Viro wrote: >> Why the hell do you hold ->i_mutex across the entire opening of underlying >> directory? All you need is to serialize one assignment; the side that loses >> the race will simply f

Re: [GIT PULL] overlay filesystem v25

2014-10-24 Thread Miklos Szeredi
On Fri, Oct 24, 2014 at 5:24 AM, Al Viro wrote: > On Fri, Oct 24, 2014 at 03:20:55AM +0100, Al Viro wrote: >> Why the hell do you hold ->i_mutex across the entire opening of underlying >> directory? All you need is to serialize one assignment; the side that loses >> the race will simply fput() wh

Re: [GIT PULL] overlay filesystem v25

2014-10-23 Thread Al Viro
On Fri, Oct 24, 2014 at 03:20:55AM +0100, Al Viro wrote: > Why the hell do you hold ->i_mutex across the entire opening of underlying > directory? All you need is to serialize one assignment; the side that loses > the race will simply fput() what it opened... > > Oh, well - that goes under "weird

Re: [GIT PULL] overlay filesystem v25

2014-10-23 Thread Al Viro
On Fri, Oct 24, 2014 at 01:25:39AM +0200, Miklos Szeredi wrote: > Linus, > > Please pull > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs.v25 > > Plenty of bugs fixed relative to the previous version, thanks to Al Viro's > review and is now officially be BugFree(TM)

[GIT PULL] overlay filesystem v25

2014-10-23 Thread Miklos Szeredi
Linus, Please pull git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs.v25 Plenty of bugs fixed relative to the previous version, thanks to Al Viro's review and is now officially be BugFree(TM). Also passes the unionmount-testsuite by David Howells. Thanks, Miklos --- A