GPF in __d_lookup_rcu after hibernate

GPF in __d_lookup_rcu after hibernate

[Johan Hovold]

Hi,

After updating to 4.4.5 I keep hitting a GPF in __d_lookup_rcu after
resuming from suspend-to-disk:

[36023.005198] general protection fault: 0000 [#1] PREEMPT SMP 
[36023.005304] Modules linked in: intel_rapl iosf_mbi [last unloaded: videobuf2_memops]
[36023.005440] CPU: 1 PID: 2726 Comm: rsync Not tainted 4.4.6 #130
[36023.005535] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 940X3G/NP940X3G-K03SE, BIOS P02ACJ.101.130926.dg 09/26/2013
[36023.005702] task: ffff88020cf39780 ti: ffff8800c6088000 task.ti: ffff8800c6088000
[36023.005820] RIP: 0010:[<ffffffff811539b2>]  [<ffffffff811539b2>] __d_lookup_rcu+0x72/0x150
[36023.005960] RSP: 0018:ffff8800c608bc88  EFLAGS: 00010206
[36023.006045] RAX: 0000000000090000 RBX: 000b0000000a0000 RCX: 000000000000000c
[36023.006164] RDX: ffff880216c00000 RSI: ffff8800c608bdb0 RDI: ffff8801f2be4d80
[36023.006271] RBP: ffff8801f2be4d80 R08: 0000000000000040 R09: ffff8800da9f6025
[36023.006378] R10: 0000000000000005 R11: ffffffffffffffff R12: 000b00000009fff8
[36023.006485] R13: 0000000519aa5aaf R14: ffff8800c608bdb0 R15: ffff8800c608bcec
[36023.006592] FS:  00007f1457ad7700(0000) GS:ffff88021fa80000(0000) knlGS:0000000000000000
[36023.006714] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[36023.006800] CR2: 0000000002f98ff0 CR3: 00000001ce66e000 CR4: 00000000001406e0
[36023.006907] Stack:
[36023.006937]  00000002b9c5bf00 ffff8800c608bda0 0000000000000000 ffff8800c608bda0
[36023.007059]  0000000000000000 ffff8800c608bd38 ffff8801f2be4d80 ffff8800c608bd30
[36023.007179]  ffff8800d4e00da0 ffffffff8114973d ffff8800c608bd2c ffff8801f2be4d80
[36023.007300] Call Trace:
[36023.007339]  [<ffffffff8114973d>] ? lookup_fast+0x3d/0x2d0
[36023.007423]  [<ffffffff81149a71>] ? walk_component+0x31/0x2b0
[36023.007511]  [<ffffffff811483db>] ? path_init+0x17b/0x3c0
[36023.007593]  [<ffffffff8114a2db>] ? path_lookupat+0x5b/0x110
[36023.007678]  [<ffffffff8114bce3>] ? filename_lookup+0x93/0x110
[36023.007769]  [<ffffffff8112b46e>] ? page_add_new_anon_rmap+0x3e/0x80
[36023.007865]  [<ffffffff8114b9e4>] ? getname_flags+0x44/0x180
[36023.007952]  [<ffffffff81142fd4>] ? vfs_fstatat+0x44/0x90
[36023.008035]  [<ffffffff81143560>] ? SyS_newlstat+0x10/0x30
[36023.008118]  [<ffffffff81001039>] ? syscall_trace_enter_phase1+0xb9/0x110
[36023.008222]  [<ffffffff810a4ae3>] ? vtime_user_enter+0x23/0x40
[36023.008312]  [<ffffffff81102345>] ? __context_tracking_enter+0x45/0x90
[36023.008413]  [<ffffffff817a0b57>] ? entry_SYSCALL_64_fastpath+0x12/0x6a
[36023.008512] Code: 8b 18 48 83 e3 fe 0f 84 96 00 00 00 4c 89 e8 49 c7 c3 ff ff ff ff 48 c1 e8 20 49 89 c2 eb 08 48 8b 1b 48 85 db 74 7b 4c 8d 63 f8 <8b> 43 fc 48 39 6b 10 75 eb 48 83 7b 08 00 74 e4 83 e0 fe f6 45 
[36023.008940] RIP  [<ffffffff811539b2>] __d_lookup_rcu+0x72/0x150
[36023.009034]  RSP <ffff8800c608bc88>
[36023.036540] ---[ end trace 0f7289662a99e06b ]---

4.4.6 has the same problem as can be seen above, and I just discovered I
had saved a log from 4.3.4 which also appears to suffer from this:

[154467.785854] general protection fault: 0000 [#1] PREEMPT SMP 
[154467.785962] Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core intel_rapl iosf_mbi [last unloaded: videobuf2_memops]
[154467.786191] CPU: 0 PID: 3944 Comm: rsync Not tainted 4.3.4 #126
[154467.786287] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 940X3G/NP940X3G-K03SE, BIOS P02ACJ.101.130926.dg 09/26/2013
[154467.786456] task: ffff88018a5d8c00 ti: ffff8801f959c000 task.ti: ffff8801f959c000
[154467.786583] RIP: 0010:[<ffffffff8114f7d2>]  [<ffffffff8114f7d2>] __d_lookup_rcu+0x72/0x150
[154467.786709] RSP: 0018:ffff8801f959fc88  EFLAGS: 00010206
[154467.786786] RAX: 0000000000990000 RBX: 009b0000009a0000 RCX: 000000000000000c
[154467.786890] RDX: ffff880216c00000 RSI: ffff8801f959fdb0 RDI: ffff8801fa214480
[154467.786993] RBP: ffff8801fa214480 R08: ffff880192cee033 R09: ffff880192cee039
[154467.787096] R10: 0000000000000021 R11: ffffffffffffffff R12: 009b00000099fff8
q[154467.787200] R13: 00000021d9ccb96d R14: ffff8801f959fdb0 R15: ffff8801f959fcec
[154467.787303] FS:  00007f444fd82700(0000) GS:ffff88021fa00000(0000) knlGS:0000000000000000
[154467.787420] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[154467.787503] CR2: 0000000002c00ff8 CR3: 000000006b262000 CR4: 00000000001406f0
[154467.787605] Stack:
[154467.787631]  00000002fa2149c0 ffff8801f959fda0 0000000000000000 ffff8801f959fda0
[154467.787727]  0000000000000000 ffff8801f959fd38 ffff8801fa214480 ffff8801f959fd30
[154467.787824]  ffff88021400fe20 ffffffff8114550d ffff8801f959fd2c ffff8801fa214480
[154467.787920] Call Trace:
[154467.787953]  [<ffffffff8114550d>] ? lookup_fast+0x3d/0x2d0
[154467.788022]  [<ffffffff81145841>] ? walk_component+0x31/0x280
[154467.788093]  [<ffffffff81144152>] ? path_init+0x182/0x3c0
[154467.788159]  [<ffffffff8114605b>] ? path_lookupat+0x5b/0x110
[154467.788229]  [<ffffffff81147a53>] ? filename_lookup+0x93/0x110
[154467.788301]  [<ffffffff8119fa3f>] ? call_filldir+0x7f/0x120
[154467.788370]  [<ffffffff81147754>] ? getname_flags+0x44/0x180
[154467.788439]  [<ffffffff8113ed04>] ? vfs_fstatat+0x44/0x90
[154467.788506]  [<ffffffff8113f290>] ? SyS_newlstat+0x10/0x30
[154467.788581]  [<ffffffff8100105f>] ? syscall_trace_enter_phase1+0xdf/0x130
[154467.788650]  [<ffffffff81789817>] ? entry_SYSCALL_64_fastpath+0x12/0x6a
[154467.788716] Code: 8b 18 48 83 e3 fe 0f 84 96 00 00 00 4c 89 e8 49 c7 c3 ff ff ff ff 48 c1 e8 20 49 89 c2 eb 08 48 8b 1b 48 85 db 74 7b 4c 8d 63 f8 <8b> 43 fc 48 39 6b 10 75 eb 48 83 7b 08 00 74 e4 83 e0 fe f6 45 
[154467.788998] RIP  [<ffffffff8114f7d2>] __d_lookup_rcu+0x72/0x150
[154467.789060]  RSP <ffff8801f959fc88>
[154467.807471] ---[ end trace 1f6c02a6b2bb76b1 ]---

When this happens only a forced cold boot appears to make the machine
usable again (further look-ups keep failing).

Looking at these logs now I realised I had reloaded the uvcvideo module so
to be sure I just suspended without touching that module and hit another
GFP when relaunching firefox after resume:

[ 2741.976850] general protection fault: 0000 [#1] PREEMPT SMP 
[ 2741.976957] Modules linked in: intel_rapl iosf_mbi uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core
[ 2741.977159] CPU: 3 PID: 8199 Comm: firefox Not tainted 4.4.6 #130
[ 2741.977256] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 940X3G/NP940X3G-K03SE, BIOS P02ACJ.101.130926.dg 09/26/2013
[ 2741.977425] task: ffff8801edcdaf00 ti: ffff8800d41b0000 task.ti: ffff8800d41b0000
[ 2741.977544] RIP: 0010:[<ffffffff8119d840>]  [<ffffffff8119d840>] kernfs_iop_follow_link+0x70/0x1a0
[ 2741.977696] RSP: 0018:ffff8800d41b3e98  EFLAGS: 00010286
[ 2741.977780] RAX: ffff8801edcdaf00 RBX: ffff88021687e4b0 RCX: 0000000000000000
[ 2741.977893] RDX: 008f0000008e0000 RSI: 0000000000000000 RDI: ffffffff81c324e0
[ 2741.978007] RBP: ffff8800d53b6000 R08: ffffffff81ab6c29 R09: ffffea000354edc0
[ 2741.978120] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800d53b6000
[ 2741.978233] R13: 00007ffd3ccaed80 R14: ffff8800da802870 R15: 008f0000008e0000
[ 2741.978347] FS:  00007ff343d65780(0000) GS:ffff88021fb80000(0000) knlGS:0000000000000000
[ 2741.978475] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2741.978573] CR2: 00007ff343d3f070 CR3: 00000000da8be000 CR4: 00000000001406e0
[ 2741.978665] Stack:
[ 2741.978698]  ffff8800d41b3ed8 ffff8802148f98c0 00007ff3429314d0 0000000000000063
[ 2741.978804]  00007ffd3ccaed80 ffff8802148f98c0 00007ff3429314d0 ffffffff81147926
[ 2741.978908]  00000000ffffff9c 00000000ffffffea 0000000000004000 00000000ffffff9c
[ 2741.979012] Call Trace:
[ 2741.979047]  [<ffffffff81147926>] ? generic_readlink+0x56/0x70
[ 2741.979126]  [<ffffffff8114366d>] ? SyS_readlinkat+0x8d/0x100
[ 2741.979203]  [<ffffffff817a0b57>] ? entry_SYSCALL_64_fastpath+0x12/0x6a
[ 2741.979289] Code: 24 c3 81 4c 89 e5 48 8b 58 08 4c 8b 70 40 e8 38 17 60 00 48 83 7b 08 00 74 35 4d 8b 7e 08 4c 89 fa eb 08 48 39 da 74 2b 48 89 ca <48> 8b 4a 08 48 85 c9 75 ef 48 39 d3 74 1a c7 45 00 2e 2e 2f 00 
[ 2741.979650] RIP  [<ffffffff8119d840>] kernfs_iop_follow_link+0x70/0x1a0
[ 2741.979723]  RSP <ffff8800d41b3e98>
[ 2742.000022] ---[ end trace 264065d347b49d9e ]---

I found the "fs: NULL deref in atime_needs_update" thread

	https://lkml.kernel.org/r/20160228170133.GM17997@ZenIV.linux.org.uk

after a quick search but can't say if its related. 

Any ideas of what might be going on here?

Thanks,
Johan

Re: GPF in __d_lookup_rcu after hibernate

[Al Viro]

On Sat, Mar 19, 2016 at 12:46:04PM -0400, Johan Hovold wrote:
> Hi,
> 
> After updating to 4.4.5 I keep hitting a GPF in __d_lookup_rcu after
> resuming from suspend-to-disk:

[snip]

Hash chain leading into 0x000b0000000a0000, which is not a valid pointer.

> 4.4.6 has the same problem as can be seen above, and I just discovered I
> had saved a log from 4.3.4 which also appears to suffer from this:

Hash chain leading into 0x009b0000009a0000, which is not a valid pointer.

> When this happens only a forced cold boot appears to make the machine
> usable again (further look-ups keep failing).
> 
> Looking at these logs now I realised I had reloaded the uvcvideo module so
> to be sure I just suspended without touching that module and hit another
> GFP when relaunching firefox after resume:

> [ 2741.976850] general protection fault: 0000 [#1] PREEMPT SMP 
> [ 2741.976957] Modules linked in: intel_rapl iosf_mbi uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core
> [ 2741.977159] CPU: 3 PID: 8199 Comm: firefox Not tainted 4.4.6 #130
> [ 2741.977256] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 940X3G/NP940X3G-K03SE, BIOS P02ACJ.101.130926.dg 09/26/2013
> [ 2741.977425] task: ffff8801edcdaf00 ti: ffff8800d41b0000 task.ti: ffff8800d41b0000
> [ 2741.977544] RIP: 0010:[<ffffffff8119d840>]  [<ffffffff8119d840>] kernfs_iop_follow_link+0x70/0x1a0
> [ 2741.977696] RSP: 0018:ffff8800d41b3e98  EFLAGS: 00010286
> [ 2741.977780] RAX: ffff8801edcdaf00 RBX: ffff88021687e4b0 RCX: 0000000000000000
> [ 2741.977893] RDX: 008f0000008e0000 RSI: 0000000000000000 RDI: ffffffff81c324e0
> [ 2741.978007] RBP: ffff8800d53b6000 R08: ffffffff81ab6c29 R09: ffffea000354edc0
> [ 2741.978120] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800d53b6000
> [ 2741.978233] R13: 00007ffd3ccaed80 R14: ffff8800da802870 R15: 008f0000008e0000
> [ 2741.978347] FS:  00007ff343d65780(0000) GS:ffff88021fb80000(0000) knlGS:0000000000000000
> [ 2741.978475] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 2741.978573] CR2: 00007ff343d3f070 CR3: 00000000da8be000 CR4: 00000000001406e0
> [ 2741.978665] Stack:
> [ 2741.978698]  ffff8800d41b3ed8 ffff8802148f98c0 00007ff3429314d0 0000000000000063
> [ 2741.978804]  00007ffd3ccaed80 ffff8802148f98c0 00007ff3429314d0 ffffffff81147926
> [ 2741.978908]  00000000ffffff9c 00000000ffffffea 0000000000004000 00000000ffffff9c
> [ 2741.979012] Call Trace:
> [ 2741.979047]  [<ffffffff81147926>] ? generic_readlink+0x56/0x70
> [ 2741.979126]  [<ffffffff8114366d>] ? SyS_readlinkat+0x8d/0x100
> [ 2741.979203]  [<ffffffff817a0b57>] ? entry_SYSCALL_64_fastpath+0x12/0x6a
> [ 2741.979289] Code: 24 c3 81 4c 89 e5 48 8b 58 08 4c 8b 70 40 e8 38 17 60 00 48 83 7b 08 00 74 35 4d 8b 7e 08 4c 89 fa eb 08 48 39 da 74 2b 48 89 ca <48> 8b 4a 08 48 85 c9 75 ef 48 39 d3 74 1a c7 45 00 2e 2e 2f 00 
> [ 2741.979650] RIP  [<ffffffff8119d840>] kernfs_iop_follow_link+0x70/0x1a0
> [ 2741.979723]  RSP <ffff8800d41b3e98>
> [ 2742.000022] ---[ end trace 264065d347b49d9e ]---
> 
> I found the "fs: NULL deref in atime_needs_update" thread
> 
> 	https://lkml.kernel.org/r/20160228170133.GM17997@ZenIV.linux.org.uk
> 
> after a quick search but can't say if its related. 

Shouldn't be.  It's already past the pathname resolution; by the time
we hit generic_readlink(), we are through with pathname handling.

Hard to tell without your .config, but at a guess that's
                while (kn->parent && base != kn)
                        kn = kn->parent;
in kernfs_get_target_path() running into kn equal to 0x008f0000008e0000,
which is not a valid pointer.

Note that all of those are of the same pattern:
	00 00 N 00 00 00 N+1 00
where a pointer should've been.  In these traces we'd seen N equal to 0xa,
0x9a and 0x8e.  Hell knows what it is, but the patterns are too similar to
be a coincidence; it's the same kind of memory corruption.  Have it hit
a dentry and you've got yourself a persistent oops in dcache hash chain
traversals.

FWIW, it might be a single table of that form, with the previous pointer
in the chain corrupted so it points into it.  Hell knows...  AFAICS,
by that point the previous addresses are already lost, both in __d_lookup_rcu()
and kernfs_get_target_path() cases.

Might make sense to trawl for such values in the suspended images.  Or,
if you really can reproduce it quickly enough, try to add
	u64 v = (u64) node->next;

	if (unlikely((v >> 32) == (u32)v + 0x10000)) {
		int i;
		printk(KERN_ERR "buggered at %p", dentry);
		for (i = 0; i < sizeof(struct dentry)/4; i++)
			printk(" %08x", ((int *)dentry)[i]);
		printk("\n");
	}
just before seqretry: label in __d_lookup_rcu() and try to trigger that thing.
Might give a better idea of what's going on...

Re: GPF in __d_lookup_rcu after hibernate

[Al Viro]

On Sat, Mar 19, 2016 at 07:24:30PM +0000, Al Viro wrote:
> Hard to tell without your .config, but at a guess that's
>                 while (kn->parent && base != kn)
>                         kn = kn->parent;
> in kernfs_get_target_path() running into kn equal to 0x008f0000008e0000,
> which is not a valid pointer.
> 
> Note that all of those are of the same pattern:
> 	00 00 N 00 00 00 N+1 00
> where a pointer should've been.  In these traces we'd seen N equal to 0xa,
> 0x9a and 0x8e.  Hell knows what it is, but the patterns are too similar to
> be a coincidence; it's the same kind of memory corruption.  Have it hit
> a dentry and you've got yourself a persistent oops in dcache hash chain
> traversals.
> 
> FWIW, it might be a single table of that form, with the previous pointer
> in the chain corrupted so it points into it.  Hell knows...  AFAICS,
> by that point the previous addresses are already lost, both in __d_lookup_rcu()
> and kernfs_get_target_path() cases.

As the matter of fact, it looks like similar values pop up in traces posted
at least a couple of years ago - http://pastebin.com/Nhewn8xP, for example,
is full of such stuff, also on resume from suspend-on-disk.  With 3.13
kernel, including the things like pte equal to 0x0095000000940000, etc.

So it smells like a repeated pattern of memory corruption on resume from
disk, going back at least that far.  What gets corrupted varies, so I suspect
that dcache is simply something that contains lists long enough and traversed
frequently enough to be likely to catch that.  Page tables are another
place where it's likely to show up...

Re: GPF in __d_lookup_rcu after hibernate

[Johan Hovold]

On Sat, Mar 19, 2016 at 08:17:59PM +0000, Al Viro wrote:
> On Sat, Mar 19, 2016 at 07:24:30PM +0000, Al Viro wrote:
> > Hard to tell without your .config, but at a guess that's
> >                 while (kn->parent && base != kn)
> >                         kn = kn->parent;
> > in kernfs_get_target_path() running into kn equal to 0x008f0000008e0000,
> > which is not a valid pointer.
> > 
> > Note that all of those are of the same pattern:
> > 	00 00 N 00 00 00 N+1 00
> > where a pointer should've been.  In these traces we'd seen N equal to 0xa,
> > 0x9a and 0x8e.  Hell knows what it is, but the patterns are too similar to
> > be a coincidence; it's the same kind of memory corruption.  Have it hit
> > a dentry and you've got yourself a persistent oops in dcache hash chain
> > traversals.
> > 
> > FWIW, it might be a single table of that form, with the previous pointer
> > in the chain corrupted so it points into it.  Hell knows...  AFAICS,
> > by that point the previous addresses are already lost, both in __d_lookup_rcu()
> > and kernfs_get_target_path() cases.
> 
> As the matter of fact, it looks like similar values pop up in traces posted
> at least a couple of years ago - http://pastebin.com/Nhewn8xP, for example,
> is full of such stuff, also on resume from suspend-on-disk.  With 3.13
> kernel, including the things like pte equal to 0x0095000000940000, etc.
> 
> So it smells like a repeated pattern of memory corruption on resume from
> disk, going back at least that far.  What gets corrupted varies, so I suspect
> that dcache is simply something that contains lists long enough and traversed
> frequently enough to be likely to catch that.  Page tables are another
> place where it's likely to show up...

Ouch. Thanks for looking into this.

I followed your advice and dumped the swap partition. The pattern is
definitely there; at least 250+ times in my 8GB partition, possibly left
overs from earlier suspends.

The pattern itself appears to be repeat from at least 0x4400 to 0x7ff00 
with a similar series before it (with some values overwritten):

75024120 2a00290028002700 2d002c0182002b00
75024140 310030002f002e00 3500340033003200
75024160 3900380037003600 3d003c003b003a00
75024200 410040003f003e00 4500440043004200
75024220 4900480047004600 4d004c004b004a00
...
75025200 0000003200000031 0000003400000033
75025220 0000003600000035 0000003800000037
75025240 0000003a00000039 0000003c0000003b
75025260 0000003e0000003d a02400400000003f
75025300 0000000028042277 0000000000000000
75025320 0000000000000000 0000000000000000
75025340 0000432600000000 0000450000004400
75025360 0000470000004600 0000490000004800
75025400 00004b0000004a00 00004d0000004c00
...
75044620 0007ef000007ee00 0007f1000007f000
75044640 0007f3000007f200 0007f5000007f400
75044660 0007f7000007f600 0007f9000007f800
75044700 0007fb000007fa00 0007fd000007fc00
75044720 0007ff000007fe00 00000007140e2000

It appeared harder to trigger the GPF with your debugging code added but
that was probably just coincidence:

[ 2660.062886] buggered at ffff8800da802780 00500000 00510000 00520000 00530000 00540000 00550000 00560000 00570000 00580000 00590000 005a0000 005b0000 005c0000 005d0000 005e0000 005f0000 00600000 00610000 00620000 00630000 00640000 00650000 00660000 00670000 00680000 00690000 006a0000 006b0000 006c0000 006d0000 006e0000 006f0000 00700000 00710000 00720000 00730000 00740000 00750000 00760000 00770000 00780000 00790000 007a0000 007b0000 007c0000 007d0000 007e0000 007f0000
[ 2660.062912] general protection fault: 0000 [#1] PREEMPT SMP 
[ 2660.063016] Modules linked in: intel_rapl iosf_mbi uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core
[ 2660.063218] CPU: 1 PID: 8036 Comm: rsync Not tainted 4.4.6 #131
[ 2660.063313] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 940X3G/NP940X3G-K03SE, BIOS P02ACJ.101.130926.dg 09/26/2013
[ 2660.063480] task: ffff8800d53a8000 ti: ffff8800d46ec000 task.ti: ffff8800d46ec000
[ 2660.063599] RIP: 0010:[<ffffffff811539b2>]  [<ffffffff811539b2>] __d_lookup_rcu+0x72/0x210
[ 2660.063739] RSP: 0018:ffff8800d46efc80  EFLAGS: 00010206
[ 2660.063823] RAX: 0000000000510000 RBX: 0053000000520000 RCX: 0000000000000000
[ 2660.063942] RDX: ffff88021fa8e040 RSI: ffff88021fa8c9b8 RDI: ffff88021fa8c9b8
[ 2660.064010] RBP: ffff8800bee21600 R08: ffffffff81dcf4a8 R09: ffff88002a035038
[ 2660.064078] R10: 0000000000000019 R11: ffffffffffffffff R12: ffff8800da802780
[ 2660.064146] R13: 00000019d2947805 R14: ffff8800d46efdb0 R15: ffff8800d46efcec
[ 2660.064214] FS:  00007fb0608ac700(0000) GS:ffff88021fa80000(0000) knlGS:0000000000000000
[ 2660.064291] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2660.064345] CR2: 0000000001fcf000 CR3: 000000013045d000 CR4: 00000000001406e0
[ 2660.064413] Stack:
[ 2660.064433]  ffff88002a035038 ffff880000000019 ffffffffffffffff ffffffffffffffff
[ 2660.064509]  ffff8800d46efda0 0000000000000000 ffff8800d46efd38 ffff8800bee21600
[ 2660.064585]  ffff8800d46efd30 ffff880215df4f20 ffffffff8114973d ffff8800d46efd2c
[ 2660.064662] Call Trace:
[ 2660.064708]  [<ffffffff8114973d>] ? lookup_fast+0x3d/0x2d0
[ 2660.064767]  [<ffffffff81149a71>] ? walk_component+0x31/0x2b0
[ 2660.064829]  [<ffffffff811483db>] ? path_init+0x17b/0x3c0
[ 2660.064887]  [<ffffffff8114a2db>] ? path_lookupat+0x5b/0x110
[ 2660.064947]  [<ffffffff8114bce3>] ? filename_lookup+0x93/0x110
[ 2660.065009]  [<ffffffff8114b9e4>] ? getname_flags+0x44/0x180
[ 2660.065071]  [<ffffffff81142fd4>] ? vfs_fstatat+0x44/0x90
[ 2660.065130]  [<ffffffff81143560>] ? SyS_newlstat+0x10/0x30
[ 2660.065189]  [<ffffffff81001039>] ? syscall_trace_enter_phase1+0xb9/0x110
[ 2660.065262]  [<ffffffff810a4ae3>] ? vtime_user_enter+0x23/0x40
[ 2660.065325]  [<ffffffff81102345>] ? __context_tracking_enter+0x45/0x90
[ 2660.065396]  [<ffffffff817a0c17>] ? entry_SYSCALL_64_fastpath+0x12/0x6a
[ 2660.065466] Code: 8b 18 48 83 e3 fe 0f 84 bc 00 00 00 4c 89 e8 49 c7 c3 ff ff ff ff 48 c1 e8 20 49 89 c2 eb 0c 48 8b 1b 48 85 db 0f 84 9d 00 00 00 <4c> 8b 03 4c 8d 63 f8 4c 89 c2 41 8d 80 00 00 01 00 48 c1 ea 20 
[ 2660.065768] RIP  [<ffffffff811539b2>] __d_lookup_rcu+0x72/0x210
[ 2660.065827]  RSP <ffff8800d46efc80>
[ 2660.084547] ---[ end trace 2546bba214fdadef ]---

Thanks,
Johan