That patch looks fine to me. Having the s_readonly_remount infrastructure
around certainly makes things easier.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-i
On Fri, Oct 04, 2013 at 10:37:29AM +0200, Christoph Hellwig wrote:
> On Fri, Oct 04, 2013 at 03:53:51AM +0100, Al Viro wrote:
> > Speaking of those two - I really want to see file_table.c one killed.
> > Christoph, do you have anything along the lines of getting rid of the
> > mark_files_ro() nonse
On Fri, Oct 04, 2013 at 03:53:51AM +0100, Al Viro wrote:
> Speaking of those two - I really want to see file_table.c one killed.
> Christoph, do you have anything along the lines of getting rid of the
> mark_files_ro() nonsense? After all, a combination of r/w vfsmount
> and a superblock with MS_R
On Thu, Oct 03, 2013 at 11:15:03PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 03, 2013 at 11:03:05PM -0700, Josh Triplett wrote:
> > On Thu, Oct 03, 2013 at 10:29:59PM -0700, Paul E. McKenney wrote:
> > > On Thu, Oct 03, 2013 at 04:28:27PM -0700, Josh Triplett wrote:
> > > > On Thu, Oct 03, 2013
* Linus Torvalds wrote:
> On Thu, Oct 3, 2013 at 5:41 PM, Josh Triplett wrote:
> >
> > Read, yes, but I don't think that's enough to force your example above
> > to work in all cases. That requires semantics beyond what RCU's
> > primitives guarantee, and I don't think you can draw conclusio
On Thu, Oct 03, 2013 at 11:03:05PM -0700, Josh Triplett wrote:
> On Thu, Oct 03, 2013 at 10:29:59PM -0700, Paul E. McKenney wrote:
> > On Thu, Oct 03, 2013 at 04:28:27PM -0700, Josh Triplett wrote:
> > > On Thu, Oct 03, 2013 at 01:52:45PM -0700, Linus Torvalds wrote:
> > > > On Thu, Oct 3, 2013 at
On Thu, Oct 03, 2013 at 10:29:59PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 03, 2013 at 04:28:27PM -0700, Josh Triplett wrote:
> > On Thu, Oct 03, 2013 at 01:52:45PM -0700, Linus Torvalds wrote:
> > > On Thu, Oct 3, 2013 at 1:41 PM, Al Viro wrote:
> > > >
> > > > The problem is this:
> > > > A
On Thu, Oct 03, 2013 at 04:28:27PM -0700, Josh Triplett wrote:
> On Thu, Oct 03, 2013 at 01:52:45PM -0700, Linus Torvalds wrote:
> > On Thu, Oct 3, 2013 at 1:41 PM, Al Viro wrote:
> > >
> > > The problem is this:
> > > A = 1, B = 1
> > > CPU1:
> > > A = 0
> > >
> > > synchronize_rcu()
> > > read
On Thu, Oct 03, 2013 at 10:14:48PM +0100, Al Viro wrote:
> > So I don't see how they could possibly see ones. Modulo terminal bugs
> > in synchronize_barrier() (which can be very slow, but for umount I
> > wouldn't worry). Or modulo my brain being fried.
>
> There's one more place similar to that
On Thu, Oct 3, 2013 at 5:41 PM, Josh Triplett wrote:
>
> Read, yes, but I don't think that's enough to force your example above
> to work in all cases. That requires semantics beyond what RCU's
> primitives guarantee, and I don't think you can draw conclusions about
> those semantics without talk
On Thu, Oct 03, 2013 at 04:51:00PM -0700, Linus Torvalds wrote:
> On Thu, Oct 3, 2013 at 4:28 PM, Josh Triplett wrote:
> > On Thu, Oct 03, 2013 at 01:52:45PM -0700, Linus Torvalds wrote:
> >> On Thu, Oct 3, 2013 at 1:41 PM, Al Viro wrote:
> >> >
> >> > The problem is this:
> >> > A = 1, B = 1
> >
On Thu, Oct 3, 2013 at 4:28 PM, Josh Triplett wrote:
> On Thu, Oct 03, 2013 at 01:52:45PM -0700, Linus Torvalds wrote:
>> On Thu, Oct 3, 2013 at 1:41 PM, Al Viro wrote:
>> >
>> > The problem is this:
>> > A = 1, B = 1
>> > CPU1:
>> > A = 0
>> >
>> > synchronize_rcu()
>> > read B
>> >
>> > CPU2:
On Thu, Oct 03, 2013 at 01:52:45PM -0700, Linus Torvalds wrote:
> On Thu, Oct 3, 2013 at 1:41 PM, Al Viro wrote:
> >
> > The problem is this:
> > A = 1, B = 1
> > CPU1:
> > A = 0
> >
> > synchronize_rcu()
> > read B
> >
> > CPU2:
> > rcu_read_lock()
> > B = 0
> > read A
> >
> > Are we guaranteed
On Thu, Oct 03, 2013 at 01:52:45PM -0700, Linus Torvalds wrote:
> Yeah, I think we should be guaranteed that, because the
> synchronize_rcu() will guarantee that all other CPU's go through an
> idle period. So the "read A" on CPU2 cannot possibly see a 1 _unless_
> it happens so early that synchro
On Thu, Oct 3, 2013 at 1:41 PM, Al Viro wrote:
>
> The problem is this:
> A = 1, B = 1
> CPU1:
> A = 0
>
> synchronize_rcu()
> read B
>
> CPU2:
> rcu_read_lock()
> B = 0
> read A
>
> Are we guaranteed that we won't get both of them seeing ones, in situation
> when that rcu_read_lock() comes too l
On Thu, Oct 03, 2013 at 01:19:16PM -0700, Linus Torvalds wrote:
> Hmm. The CPU2 mntput can only happen under RCU readlock, right? After
> the RCU grace period _and_ if the umount is going ahead, nothing
> should have a mnt pointer, right?
umount -l doesn't care.
> So I'm wondering if you couldn'
On Thu, Oct 3, 2013 at 12:43 PM, Al Viro wrote:
>
> In the common case it's ->mnt_ns is *not* NULL; that's what we get if
> the damn thing is still mounted.
Yeah, I misread the profile assembly code. The point being that the
nice fast case now has the smp_mb() in it, and it accounts for about
60%
On Thu, Oct 03, 2013 at 12:06:04PM -0700, Linus Torvalds wrote:
> On Thu, Oct 3, 2013 at 10:44 AM, Al Viro wrote:
> >
> > Anyway, I've done nicer variants of that protection for everything except
> > fuse (hadn't gotten around to it yet); see vfs.git#experimental now:
>
> Ok, I did a quick test,
On Thu, Oct 3, 2013 at 10:44 AM, Al Viro wrote:
>
> Anyway, I've done nicer variants of that protection for everything except
> fuse (hadn't gotten around to it yet); see vfs.git#experimental now:
Ok, I did a quick test, and it looks ok here, so looking good for 3.13.
However, the new smp_mb() i
19 matches
Mail list logo
