On Sat, Feb 27, 2016 at 11:27 PM, Al Viro [off-list ref] wrote:

On Fri, Feb 26, 2016 at 10:07:59PM +0000, Al Viro wrote:

quoted

On Fri, Feb 26, 2016 at 10:25:21PM +0100, Dmitry Vyukov wrote:

quoted

On Fri, Feb 26, 2016 at 10:21 PM, Al Viro [off-list ref] wrote:

quoted

On Thu, Feb 25, 2016 at 04:39:27PM +0000, Al Viro wrote:

quoted

Hrm...  OK, seeing that you still seem to trigger those within an hour or
two (and *any* of remaining WARN_ON() are serious bugs - none of the
"mitigation had been triggered" remained, sorry for not making it clear),
let's try this.  Again, any WARN_ON triggered means that we'd caught something,
whether it progresses into oops or not.

Any news on that one?  I'm going to carve fixes for understood bugs out of
that one and put those into tonight push, but it would be nice to sort out
all remaining crap lurking in that area...

Another question: what about the very first trace you'd posted, with apparent
GPF at 00000050?  Have you seen anything like that afterwards?

No, I did not have time to retest.

GPF at 00000050 was not mine, it was Mickaël's.

Ah, OK - his is basically a forced nd->stack[] underrun, with passing a
never-assigned nd->link_inode to atime_needs_update(), so we are just
passing a contents of uninitialized stack word there and while it ends
up possible to dereference, it's not an address of struct inode and the
first attempt to follow a pointer in what would've been a struct inode
at that address (accessing inode->i_sb->s_flags) did blow up with GPF at
offsetof(struct super_block, s_flags).

All right, so we basically have several understood ones with fixes plus
something unknown that leads to lookup_fast() returning 0 with NULL in
*inode in about an hour or two on your setup...

BTW, what kind of userland are you using?  The thing is, shared-subtree
setups differ, and if the crap is anywhere near vfsmount handling, that
could have some impact...  So far I hadn't been able to trigger any of
these WARN_ON(); setup here is debian/testing on 4-way KVM guest with 4Gb
memory given to it running on a 6-way host (Phenom II X6 1100T, 3.3GHz, 16Gb
RAM total); 4.2 with debian/stable userland on host.  What's the setup on
your reproducer?

Restarted fuzzer with the latest patch on top of
0fcbf996d848d03573113d83f4e3fb3bcfa5ab5e.

All that stops these warnings from triggering atime_... oopsen is that dentry
involved isn't a symlink one.

What worries me is that I am running the same program in the same
setup. The program does operate on symlinks and previous it triggered
oopses. But now it does not. I've also rebased onto latest Linus tree,
maybe that made difference...

My userspace is a Debian Wheezy built using this script:
https://github.com/google/syzkaller/blob/master/tools/create-image.sh

I run it in qemu as:
$ qemu-system-x86_64 -hda wheezy.img -net
user,host=10.0.2.10,hostfwd=tcp::10022-:22 -net nic -nographic -kernel
arch/x86/boot/bzImage -append "console=ttyS0 root=/dev/sda debug
earlyprintk=serial slub_debug=UZ" -enable-kvm -pidfile vm_pid -m 2G
-numa node,nodeid=0,cpus=0-1 -numa node,nodeid=1,cpus=2-3 -smp
sockets=2,cores=2,threads=1 -usb -usbdevice mouse -usbdevice tablet
-soundhw all

I also use a pretty beefy config (attached) which includes KASAN and
KCOV both of which introduce significant slowdown and can affect
thread interleavings.