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
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,
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, but good
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
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()
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,
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,
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
>
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()
>
[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
>>
[Paul McKenney added to CC]
On Sat, Oct 25, 2014 at 7:06 PM, Al Viro v...@zeniv.linux.org.uk 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
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 v...@zeniv.linux.org.uk 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
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
if
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, possibly
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,
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()
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
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
>
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
On Sat, Oct 25, 2014 at 10:18 AM, Al Viro v...@zeniv.linux.org.uk 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
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
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
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
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()
On Fri, Oct 24, 2014 at 5:24 AM, Al Viro v...@zeniv.linux.org.uk 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
Hi Al,
On Fri, Oct 24, 2014 at 5:24 AM, Al Viro v...@zeniv.linux.org.uk 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
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
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
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
---
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
---
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). Also
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
32 matches
Mail list logo
