[Bug 1964487] Re: __asan_default_options not working with -shared-libasan

2022-04-26 Thread Jonas Hahnfeld
** Description changed:

  When using the shared libclang_rt.asan-x86_64.so, __asan_default_options
  aren't working. Consider the following example:
  
-  $ cat test_asan.c
+  $ cat test_asan.c
  const char *__asan_default_options() {
-   return "help=1";
+   return "help=1";
  }
  
  int main() { return 0; }
-  $ clang -fsanitize=address -shared-libasan test_asan.c -o 
test_asan.clang.shared.x
-  $ 
LD_PRELOAD=/usr/lib/llvm-10/lib/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.so
 ./test_asan.clang.shared.x 
+  $ clang -fsanitize=address -shared-libasan test_asan.c -o 
test_asan.clang.shared.x
+  $ 
LD_PRELOAD=/usr/lib/llvm-10/lib/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.so
 ./test_asan.clang.shared.x
  [no output]
  
- The expected behavior would be:
-  $ clang -fsanitize=address -static-libsan test_asan.c -o 
test_asan.clang.static.x
-  $ ./test_asan.clang.static.x |& head
+ The expected behavior would be the same as you get with:
+  $ clang -fsanitize=address -static-libsan test_asan.c -o 
test_asan.clang.static.x
+  $ ./test_asan.clang.static.x |& head
  Available flags for AddressSanitizer:
-   quarantine_size
-   - Deprecated, please use quarantine_size_mb. (Current Value: -1)
-   quarantine_size_mb
-   - Size (in Mb) of quarantine used to detect use-after-free 
errors. Lower value may reduce memory usage but increase the chance of false 
negatives. (Current Value: -1)
-   thread_local_quarantine_size_kb
-   - Size (in Kb) of thread local quarantine used to detect 
use-after-free errors. Lower value may reduce memory usage but increase the 
chance of false negatives. It is not advised to go lower than 64Kb, otherwise 
frequent transfers to global quarantine might affect performance. (Current 
Value: -1)
-   redzone
-   - Minimal size (in bytes) of redzones around heap objects. 
Requirement: redzone >= 16, is a power of two. (Current Value: 16)
-   max_redzone
+  quarantine_size
+   - Deprecated, please use quarantine_size_mb. (Current Value: -1)
+  quarantine_size_mb
+   - Size (in Mb) of quarantine used to detect use-after-free errors. Lower 
value may reduce memory usage but increase the chance of false negatives. 
(Current Value: -1)
+  thread_local_quarantine_size_kb
+   - Size (in Kb) of thread local quarantine used to detect use-after-free 
errors. Lower value may reduce memory usage but increase the chance of false 
negatives. It is not advised to go lower than 64Kb, otherwise frequent 
transfers to global quarantine might affect performance. (Current Value: -1)
+  redzone
+   - Minimal size (in bytes) of redzones around heap objects. Requirement: 
redzone >= 16, is a power of two. (Current Value: 16)
+  max_redzone
  
  With GCC everything works fine:
-  $ gcc -fsanitize=address test_asan.c -o test_asan.gcc.shared.x
-  $ ldd test_asan.gcc.shared.x
-   linux-vdso.so.1 (0x7ffd4938e000)
-   libasan.so.5 => /usr/lib/x86_64-linux-gnu/libasan.so.5 
(0x7f704ffd6000)
-   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f704fde4000)
-   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f704fdde000)
-   librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f704fdd4000)
-   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f704fdb1000)
-   libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f704fc62000)
-   libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f704fc45000)
-   /lib64/ld-linux-x86-64.so.2 (0x7f7050a1a000)
-  $ ./test_asan.gcc.shared.x |& head
+  $ gcc -fsanitize=address test_asan.c -o test_asan.gcc.shared.x
+  $ ldd test_asan.gcc.shared.x
+  linux-vdso.so.1 (0x7ffd4938e000)
+  libasan.so.5 => /usr/lib/x86_64-linux-gnu/libasan.so.5 (0x7f704ffd6000)
+  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f704fde4000)
+  libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f704fdde000)
+  librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f704fdd4000)
+  libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f704fdb1000)
+  libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f704fc62000)
+  libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f704fc45000)
+  /lib64/ld-linux-x86-64.so.2 (0x7f7050a1a000)
+  $ ./test_asan.gcc.shared.x |& head
  Available flags for AddressSanitizer:
-   quarantine_size
-   - Deprecated, please use quarantine_size_mb.
-   quarantine_size_mb
-   - Size (in Mb) of quarantine used to detect use-after-free 
errors. Lower value may reduce memory usage but increase the chance of false 
negatives.
-   thread_local_quarantine_size_kb
-   - Size (in Kb) of thread local quarantine used to detect 
use-after-free errors. Lower value may reduce memory usage but increase the 
chance of false negatives. It is not advised to go lower than 64Kb, otherwise 
frequent transfers to global quarantine might affect performance.
-   redzone
- 

[Bug 1899199] Re: [libomp.so.5] OMPT with LD_PRELOAD not working

2022-03-10 Thread Jonas Hahnfeld
I can confirm this. I was actually involved in implementing OMPT support in the 
LLVM OpenMP runtime and the startup works by overwriting the weak symbol 
ompt_start_tool via LD_PRELOAD. The symbol is there, as seen with
 $ objdump -T /usr/lib/x86_64-linux-gnu/libomp.so.5 | grep ompt
000aa4b0  w   DF .text  0036  VERSION ompt_start_tool

but there is no relocation:
 $ readelf --relocs /usr/lib/x86_64-linux-gnu/libomp.so.5 | grep ompt
[no output]

This might actually be the same problem as
https://bugs.launchpad.net/ubuntu/+source/llvm-defaults/+bug/1964487
that I just reported.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1899199

Title:
  [libomp.so.5] OMPT with LD_PRELOAD not working

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/llvm-defaults/+bug/1899199/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1964487] [NEW] __asan_default_options not working with -shared-libasan

2022-03-10 Thread Jonas Hahnfeld
Public bug reported:

When using the shared libclang_rt.asan-x86_64.so, __asan_default_options
aren't working. Consider the following example:

 $ cat test_asan.c
const char *__asan_default_options() {
  return "help=1";
}

int main() { return 0; }
 $ clang -fsanitize=address -shared-libasan test_asan.c -o 
test_asan.clang.shared.x
 $ 
LD_PRELOAD=/usr/lib/llvm-10/lib/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.so
 ./test_asan.clang.shared.x 
[no output]

The expected behavior would be:
 $ clang -fsanitize=address -static-libsan test_asan.c -o 
test_asan.clang.static.x
 $ ./test_asan.clang.static.x |& head
Available flags for AddressSanitizer:
quarantine_size
- Deprecated, please use quarantine_size_mb. (Current Value: -1)
quarantine_size_mb
- Size (in Mb) of quarantine used to detect use-after-free 
errors. Lower value may reduce memory usage but increase the chance of false 
negatives. (Current Value: -1)
thread_local_quarantine_size_kb
- Size (in Kb) of thread local quarantine used to detect 
use-after-free errors. Lower value may reduce memory usage but increase the 
chance of false negatives. It is not advised to go lower than 64Kb, otherwise 
frequent transfers to global quarantine might affect performance. (Current 
Value: -1)
redzone
- Minimal size (in bytes) of redzones around heap objects. 
Requirement: redzone >= 16, is a power of two. (Current Value: 16)
max_redzone

With GCC everything works fine:
 $ gcc -fsanitize=address test_asan.c -o test_asan.gcc.shared.x
 $ ldd test_asan.gcc.shared.x
linux-vdso.so.1 (0x7ffd4938e000)
libasan.so.5 => /usr/lib/x86_64-linux-gnu/libasan.so.5 
(0x7f704ffd6000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f704fde4000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f704fdde000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f704fdd4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f704fdb1000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f704fc62000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f704fc45000)
/lib64/ld-linux-x86-64.so.2 (0x7f7050a1a000)
 $ ./test_asan.gcc.shared.x |& head
Available flags for AddressSanitizer:
quarantine_size
- Deprecated, please use quarantine_size_mb.
quarantine_size_mb
- Size (in Mb) of quarantine used to detect use-after-free 
errors. Lower value may reduce memory usage but increase the chance of false 
negatives.
thread_local_quarantine_size_kb
- Size (in Kb) of thread local quarantine used to detect 
use-after-free errors. Lower value may reduce memory usage but increase the 
chance of false negatives. It is not advised to go lower than 64Kb, otherwise 
frequent transfers to global quarantine might affect performance.
redzone
- Minimal size (in bytes) of redzones around heap objects. 
Requirement: redzone >= 16, is a power of two.
max_redzone

The reason seems to be that there is no relocation for the 
__asan_default_options symbol:
 $ readelf --relocs 
/usr/lib/llvm-10/lib/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.so | grep 
__asan_default_options
[no output]

The shared libasan.so used by GCC is fine:
 $ readelf --relocs /usr/lib/x86_64-linux-gnu/libasan.so.5.0.0 | grep 
__asan_default_options
00188358  03fc0007 R_X86_64_JUMP_SLO 000365d0 
__asan_default_options + 0

Note that some other symbols are not affected by this. For example,
__lsan_default_options works fine even with Clang's shared
libclang_rt.asan-x86_64.so.

** Affects: llvm-defaults (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1964487

Title:
  __asan_default_options not working with -shared-libasan

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/llvm-defaults/+bug/1964487/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1745608] Re: [x86_64] Kernel panic when building on NFS in VM

2018-02-18 Thread Jonas Hahnfeld
Any updates on this?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1745608

Title:
  [x86_64] Kernel panic when building on NFS in VM

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745608/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1745608] Re: [x86_64] Kernel panic when building on NFS in VM

2018-01-29 Thread Jonas Hahnfeld
That's weird:
[ 2691.471972] PANIC: double fault, error_code: 0x0
[ 2691.477488] Kernel panic - not syncing: Machine halted.
[ 2691.478724] CPU: 1 PID: 31425 Comm: cc1 Not tainted 4.4.0-98-generic 
#121-Ubuntu
[ 2691.479962] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.11.0-20171110_100015-anatol 04/01/2014
[ 2691.481621]  0086 dbc9cc8a876ccdc2 88013fc84e80 
813fb2c3
[ 2691.483041]  81cb9bfd 88013fc84f18 88013fc84f08 
8118df77
[ 2691.484325]  0008 88013fc84f18 88013fc84eb0 
dbc9cc8a876ccdc2
[ 2691.485654] Call Trace:
[ 2691.486077]  <#DF>  [] dump_stack+0x63/0x90
[ 2691.487057]  [] panic+0xd3/0x215
[ 2691.487880]  [] df_debug+0x2d/0x30
[ 2691.488677]  [] do_double_fault+0x7c/0xf0
[ 2691.489620]  [] double_fault+0x28/0x30
[ 2691.490537]  [] ? clear_page_c_e+0x7/0x10
[ 2691.491487]  <>  [] ? 
get_page_from_freelist+0x454/0xa50
[ 2691.492736]  [] ? pagevec_lookup_tag+0x21/0x30
[ 2691.493743]  [] ? write_cache_pages+0x123/0x510
[ 2691.494756]  [] __alloc_pages_nodemask+0x159/0x2a0
[ 2691.495826]  [] alloc_pages_vma+0xad/0x250
[ 2691.496775]  [] wp_page_copy.isra.56+0x38f/0x550
[ 2691.497802]  [] ? __alloc_pages_nodemask+0x159/0x2a0
[ 2691.498890]  [] do_wp_page+0xd8/0x6c0
[ 2691.499881]  [] ? update_curr+0xe3/0x160
[ 2691.501148]  [] handle_mm_fault+0xcf4/0x1820
[ 2691.502373]  [] ? set_next_entity+0x9c/0xb0
[ 2691.503540]  [] __do_page_fault+0x197/0x400
[ 2691.504769]  [] trace_do_page_fault+0x37/0xe0
[ 2691.505859]  [] do_async_page_fault+0x19/0x70
[ 2691.507364]  [] async_page_fault+0x28/0x30
[ 2691.508921] Kernel Offset: disabled
[ 2691.518757] ---[ end Kernel panic - not syncing: Machine halted.

Any ideas?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1745608

Title:
  [x86_64] Kernel panic when building on NFS in VM

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745608/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1745608] Re: [x86_64] Kernel panic when building on NFS in VM

2018-01-29 Thread Jonas Hahnfeld
Trying linux-image-4.4.0-98-generic next which should be the last known-
good kernel according to the cached packages in /var/cache/apt/archives
- assuming that it's only related to a kernel upgrade...

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1745608

Title:
  [x86_64] Kernel panic when building on NFS in VM

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745608/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1745608] Re: [x86_64] Kernel panic when building on NFS in VM

2018-01-29 Thread Jonas Hahnfeld
Got something similar:
[ 2570.763287] PANIC: double fault, error_code: 0x0
[ 2570.764564] Kernel panic - not syncing: Machine halted.
[ 2570.765428] CPU: 0 PID: 22272 Comm: as Not tainted 4.15.0-041500-generic 
#201801282230
[ 2570.767059] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.11.0-20171110_100015-anatol 04/01/2014
[ 2570.768815] Call Trace:
[ 2570.769263]  <#DF>
[ 2570.769643]  dump_stack+0x63/0x8b
[ 2570.770251]  panic+0xe4/0x234
[ 2570.770787]  df_debug+0x2d/0x30
[ 2570.771342]  do_double_fault+0xa1/0x130
[ 2570.772031]  double_fault+0x22/0x30
[ 2570.772583] RIP: 0010:clear_page_erms+0x7/0x10
[ 2570.773303] RSP: 0018:b98e428d78a0 EFLAGS: 00010246
[ 2570.774242] RAX:  RBX: 0004 RCX: 1000
[ 2570.775515] RDX: 90327df4c500 RSI: db5084a10fc0 RDI: 90332843f000
[ 2570.776837] RBP: b98e428d79b8 R08:  R09: db5084a11000
[ 2570.778144] R10:  R11: b98e428d7cc0 R12: 90333ffd2d00
[ 2570.779437] R13: b98e428d79c8 R14: 014280ca R15: db5084a10fc0
[ 2570.780712]  
[ 2570.781098]  ? get_page_from_freelist+0xf0d/0x1400
[ 2570.781958]  ? try_to_wake_up+0x59/0x480
[ 2570.782709]  __alloc_pages_nodemask+0xfb/0x280
[ 2570.783652]  alloc_pages_vma+0x88/0x1f0
[ 2570.784354]  __handle_mm_fault+0x938/0x11e0
[ 2570.785128]  handle_mm_fault+0xb1/0x200
[ 2570.785814]  __do_page_fault+0x257/0x4d0
[ 2570.786528]  do_page_fault+0x2e/0xd0
[ 2570.787171]  do_async_page_fault+0x51/0x80
[ 2570.787902]  async_page_fault+0x2c/0x60
[ 2570.788589] RIP: 0010:copy_user_enhanced_fast_string+0xe/0x20
[ 2570.789624] RSP: 0018:b98e428d7cd8 EFLAGS: 00050206
[ 2570.790584] RAX: 7f5c60aff010 RBX: 04a26f00 RCX: 0010
[ 2570.791858] RDX: 1000 RSI: 9033289bcff0 RDI: 7f5c60aff000
[ 2570.793076] RBP: b98e428d7ce0 R08: b98e428d7e50 R09: db5084a26f00
[ 2570.794161] R10: 0040 R11: b98e428d7cc0 R12: 1000
[ 2570.795252] R13: b98e428d7e88 R14: 9033289bc000 R15: 1000
[ 2570.796339]  ? copyout+0x26/0x30
[ 2570.796867]  copy_page_to_iter+0x10c/0x2f0
[ 2570.797521]  generic_file_read_iter+0x44b/0xbe0
[ 2570.798239]  ? page_cache_tree_insert+0xe0/0xe0
[ 2570.798969]  nfs_file_read+0x6e/0xc0 [nfs]
[ 2570.799667]  __vfs_read+0xee/0x160
[ 2570.800262]  vfs_read+0x8e/0x130
[ 2570.800817]  SyS_read+0x55/0xc0
[ 2570.801358]  entry_SYSCALL_64_fastpath+0x24/0x87
[ 2570.802156] RIP: 0033:0x7f5c614b4260
[ 2570.802768] RSP: 002b:7ffc41b1b638 EFLAGS: 0246 ORIG_RAX: 

[ 2570.804043] RAX: ffda RBX: 7f5c61781b20 RCX: 7f5c614b4260
[ 2570.805242] RDX: 0010 RSI: 7f5c60ada010 RDI: 0003
[ 2570.806445] RBP: 00100010 R08: 016bf380 R09: 0054
[ 2570.807645] R10: 7f5c61db8700 R11: 0246 R12: 00101000
[ 2570.808845] R13: 7f5c61781b78 R14: 1000 R15: 0040
[ 2570.810251] Kernel Offset: 0x2d40 from 0x8100 (relocation 
range: 0x8000-0xbfff)
[ 2570.812045] ---[ end Kernel panic - not syncing: Machine halted.

** Tags added: kernel-bug-exists-upstream

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1745608

Title:
  [x86_64] Kernel panic when building on NFS in VM

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745608/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1745608] Re: [x86_64] Kernel panic when building on NFS in VM

2018-01-26 Thread Jonas Hahnfeld
It's a kernel panic rendering the system unusable, so I can't run any
diagnostic commands.

** Changed in: linux (Ubuntu)
   Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1745608

Title:
  [x86_64] Kernel panic when building on NFS in VM

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745608/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1745608] [NEW] [x86_64] Kernel panic when building on NFS in VM

2018-01-26 Thread Jonas Hahnfeld
Public bug reported:

Since around begin of December (definitely before any KPTI was merged),
I'm having problems building AOSP on an NFS share that is mounted in a
VM with Ubuntu 16.04.3. After some minutes the system freezes
completely, the SSH session becomes unresponsive and I can't open a new
one. Logging in via virt-manager's UI isn't possible either.

When connecting to serial port, I got the following kernel panic stack trace:
[ 2531.058622] PANIC: double fault, error_code: 0x0
[ 2531.073231] Kernel panic - not syncing: Machine halted.
[ 2531.074309] CPU: 2 PID: 16421 Comm: kworker/2:0H Not tainted 
4.4.0-112-generic #135-Ubuntu
[ 2531.076122] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.11.0-20171110_100015-anatol 04/01/2014
[ 2531.080374] Workqueue: rpciod rpc_async_schedule [sunrpc]
[ 2531.081818]  0086 3c797ca978191564 88013fd07e80 
813fc233
[ 2531.083022]  81cba603 88013fd07f18 88013fd07f08 
8118f1c7
[ 2531.084382]  0008 88013fd07f18 88013fd07eb0 
3c797ca978191564
[ 2531.086127] Call Trace:
[ 2531.086928]  <#DF>  [] dump_stack+0x63/0x90
[ 2531.088606]  [] panic+0xd3/0x215
[ 2531.091309]  [] df_debug+0x2d/0x30
[ 2531.092424]  [] do_double_fault+0x7c/0xf0
[ 2531.093294]  [] double_fault+0x28/0x30
[ 2531.094170]  [] ? __build_skb+0x9d/0xe0
[ 2531.095017]  <>[] 
__netdev_alloc_skb+0xc0/0x100
[ 2531.096281]  [] page_to_skb+0x65/0x340
[ 2531.097120]  [] virtnet_receive+0x2a5/0x8f0
[ 2531.098055]  [] ? virtnet_receive+0x5d3/0x8f0
[ 2531.099023]  [] virtnet_poll+0x1d/0x80
[ 2531.100100]  [] net_rx_action+0x21e/0x360
[ 2531.100894]  [] ? skb_recv_done+0x43/0x50
[ 2531.101765]  [] __do_softirq+0x101/0x290
[ 2531.102619]  [] irq_exit+0xa3/0xb0
[ 2531.103511]  [] do_IRQ+0x54/0xd0
[ 2531.104453]  [] common_interrupt+0x1a6/0x1a6
[ 2531.105459][] ? new_slab+0x29f/0x490
[ 2531.106516]  [] ? new_slab+0x385/0x490
[ 2531.107428]  [] ___slab_alloc+0x22b/0x470
[ 2531.108372]  [] ? rpc_malloc+0x34/0xa0 [sunrpc]
[ 2531.109389]  [] ? xs_sendpages+0x61/0x1d0 [sunrpc]
[ 2531.110693]  [] ? rpcauth_lookup_credcache+0xbe/0x2a0 
[sunrpc]
[ 2531.112050]  [] ? rpc_malloc+0x34/0xa0 [sunrpc]
[ 2531.113174]  [] __slab_alloc+0x20/0x40
[ 2531.113906]  [] __kmalloc+0x1d5/0x250
[ 2531.114649]  [] rpc_malloc+0x34/0xa0 [sunrpc]
[ 2531.115483]  [] call_allocate+0xc2/0x1b0 [sunrpc]
[ 2531.116353]  [] ? call_reserveresult+0x120/0x120 [sunrpc]
[ 2531.117298]  [] ? call_reserveresult+0x120/0x120 [sunrpc]
[ 2531.118236]  [] __rpc_execute+0x91/0x470 [sunrpc]
[ 2531.119085]  [] rpc_async_schedule+0x15/0x20 [sunrpc]
[ 2531.120327]  [] process_one_work+0x165/0x480
[ 2531.121364]  [] worker_thread+0x4b/0x4d0
[ 2531.122340]  [] ? process_one_work+0x480/0x480
[ 2531.123696]  [] kthread+0xe5/0x100
[ 2531.124717]  [] ? kthread_create_on_node+0x1e0/0x1e0
[ 2531.126057]  [] ret_from_fork+0x3f/0x70
[ 2531.127192]  [] ? kthread_create_on_node+0x1e0/0x1e0
[ 2531.129000] Kernel Offset: disabled
[ 2531.160053] ---[ end Kernel panic - not syncing: Machine halted.

I decided to try the HWE kernel - with the same result, but a different stack 
trace:
[ 3643.637138] PANIC: double fault, error_code: 0x0
[ 3643.650655] Kernel panic - not syncing: Machine halted.
[ 3643.651474] CPU: 0 PID: 47 Comm: kswapd0 Not tainted 4.13.0-32-generic 
#35~16.04.1-Ubuntu
[ 3643.653108] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.11.0-20171110_100015-anatol 04/01/2014
[ 3643.654974] Call Trace:
[ 3643.655384]  <#DF>
[ 3643.655740]  dump_stack+0x63/0x8b
[ 3643.656337]  panic+0xe4/0x23d
[ 3643.656870]  df_debug+0x2d/0x30
[ 3643.657421]  do_double_fault+0x9a/0x130
[ 3643.658119]  double_fault+0x22/0x30
[ 3643.658722] RIP: 0010:_raw_spin_trylock+0x9/0x30
[ 3643.659518] RSP: :a3ec408a3bf8 EFLAGS: 00010292
[ 3643.660404] RAX: 0040008c RBX: 8c31683d1f00 RCX: a3ec408a3c50
[ 3643.661664] RDX: 0001 RSI: 8c31683d19b0 RDI: 8c3166d1e720
[ 3643.662927] RBP: a3ec408a3bf8 R08: a3ec408a3c50 R09: a3ec408a3d50
[ 3643.664166] R10: 0004dde0 R11: 0040 R12: 8c3166cb7f58
[ 3643.665359] R13: a3ec408a3c50 R14: 8c3166cb7f00 R15: 8c3166cb7f80
[ 3643.666573]  
[ 3643.666948]  shrink_dentry_list+0x101/0x2e0
[ 3643.667679]  prune_dcache_sb+0x5a/0x80
[ 3643.668330]  super_cache_scan+0x119/0x1a0
[ 3643.669025]  shrink_slab.part.48+0x1fa/0x420
[ 3643.669760]  shrink_slab+0x29/0x30
[ 3643.670357]  shrink_node+0x108/0x310
[ 3643.670995]  kswapd+0x32a/0x770
[ 3643.671547]  kthread+0x109/0x140
[ 3643.672115]  ? mem_cgroup_shrink_node+0x180/0x180
[ 3643.672924]  ? kthread_create_on_node+0x70/0x70
[ 3643.673707]  ret_from_fork+0x1f/0x30
[ 3643.674451] Kernel Offset: 0x9c0 from 0x8100 (relocation 
range: 0x8000-0xbfff)
[ 3643.676229] ---[ end Kernel panic - not syncing: Machine halted.

Please let me know if you need further information, I can reproduce this
pretty reliably...