Messages in this thread | | | Date | Sat, 13 Dec 2014 23:47:30 +0000 | From | Al Viro <> | Subject | Re: frequent lockups in 3.18rc4 |
| |
On Sat, Dec 13, 2014 at 03:38:57PM -0800, Linus Torvalds wrote: > On Sat, Dec 13, 2014 at 3:35 PM, Al Viro <viro@zeniv.linux.org.uk> wrote: > > > > Er... There's much more direct reason - suppose we get a timer interrupt > > right in the middle of mnt_drop_write(). And lost the timeslice. > > So? > > You didn't have preemption disabled in *between* the mnt_want_write() > and mnt_drop_write(), there's absolutely no reason to have it inside > of them. > > Nobody cares if you get preempted and go away for a while. It's > exactly equivalent to sleeping while doing the write that the pair was > protecting. > > Seriously, the preemption disable looks like just voodoo code. It > doesn't protect anything, it doesn't fix anything, it doesn't change > anything. All it does is disable preemption over a random sequence of > code.
Huh? Sure, we can enable it after mnt_inc_writers() and disable just prior to mnt_dec_writers(), but we absolutely *do* need it disabled during either. Is that what you are talking about? If so, yes, we can do that.
But that applies only to __mnt_want_write() - __mnt_drop_write() is pure mnt_dec_writers() and we can't call that one with preemption enabled. Seriously, look at the mnt_dec_writers(): static inline void mnt_dec_writers(struct mount *mnt) { #ifdef CONFIG_SMP this_cpu_dec(mnt->mnt_pcp->mnt_writers); #else mnt->mnt_writers--; #endif } It's load/modify/store, without any kind of atomicity; get preempted in the middle of that sequence by another caller of mnt_dec_writers() and obvious bad things will happen...
Al, really confused by now...
| |