On Tue, Jan 28, 2014 at 12:40:17AM +0100, Jan Kara wrote:
> On Fri 24-01-14 08:26:45, Jiri Kosina wrote:
> > On Fri, 24 Jan 2014, Jan Kara wrote:
> >
> > > Strange. I've installed systemd system (openSUSE 13.1) and it boots
> > > with the latest Linus' kernel just fine (and I have at least FANOTIFY
> > > and SLAB debugging set the same way as you). But it was only a KVM
> > > guest. I'll try tomorrow with a physical machine I guess.
> >
> > FWIW the system I am reliably able to reproduce this on is opensuse 12.3
> > with this systemd version:
> >
> > Version : 195
> > Release : 13.18.1
> Hum, still no luck with reproduction (either on physical machine or with
> KVM). Anyway, I've looked at the code again and the previous patch had a
> stupid bug (passing different pointer to fsnotify_destroy_event() than we
> should have), plus also the merging function in fanotify was too
> aggressive. Can you try the attached patch? It boots for me but that means
> nothing since I cannot reproduce the issue... Thanks!
still not good I'm afraid. I still see corruption very early on in boot
and now it panics and locks up too.
Again, this happens so early that I can't grab it over usb-serial.
I stuck an mdelay(10000) in the slub corruption detector, and managed
to grab a photo of the first trace.
Trace:
? preempt_schedule
lock_acquire
? lockref_put_or_lock
_raw_spin_lock
? lockref_put_or_lock
dput
path_put
fanotify_free_event
fsnotify_destroy_event
fanotify_handle_event
? mntput
? path_openat
? handle_mm_fault
send_to_group
? fsnotify
fsnotify
do_sys_open
sys_open
RIP: lock_acquire
2b:* 4d 8b 64 c6 08 mov 0x8(%r14,%rax,8),%r12 <-- trapping
instruction
R14 is 0x6b6b6b6b6b6b6c03, which looks like a use-after-free.
I also notice you mention SLAB above, but I've been using SLUB. I don't
know if the choice of allocator makes a difference in reproducability.
It's also worth noting that I have lockdep enabled, which may be perturbing
things
to some degree.
Dave
--
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-info.html
Please read the FAQ at http://www.tux.org/lkml/
