Re: [Kernel-packages] [Bug 1505948] Re: Memory arena corruption with FUSE (was Memory allocation failure crashes kernel hard, presumably related to FUSE)

2016-03-11 Thread Robert Doebbelin 
Great, thanks!

Robert
Am 11.03.2016 15:01 schrieb "Seth Forshee" :

> On Fri, Mar 11, 2016 at 01:03:32PM -, Robert Doebbelin wrote:
> > Thank you Seth for taking a close look at the problem and my proposed
> > fix. As mentioned on the mailing list my test runs fine now with the two
> > fixes.
> >
> > However, I prefer your fix as it prevents us from running into this
> > issue again. Our test system is happily installing VMs for two hours now
> > using your build. Please propose your patch.
>
> I'm not subscribed to fuse-devel and hadn't refreshed the mailing list
> thread so I didn't realize that you had discovered that the hang was
> unrelated. That's good.
>
> I'm happy to send the patches, I'll go ahead and send both my patch and
> your iocb patch after I make sure it all applies/builds okay on 4.5.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1505948
>
> Title:
>   Memory arena corruption with FUSE (was Memory allocation failure
>   crashes kernel hard, presumably related to FUSE)
>
> Status in linux package in Ubuntu:
>   Confirmed
> Status in linux source package in Wily:
>   Confirmed
> Status in linux package in Fedora:
>   Unknown
>
> Bug description:
>   Hello everybody,
>
>   Linux 4.1, 4.2 or 4.3-rc leads to an immediate kernel panic in our
>   setup when trying to start a Qemu process on top of a fuse-based
>   mount. Here is an example stacktrace:
>
>   [  739.807817] BUG: unable to handle kernel paging request at
> 8800a4104ea0
>   [  739.840201] IP: [] kmem_cache_alloc_trace+0x7a/0x1f0
>   [  739.870309] PGD 2fee067 PUD 2fbf4dd063 PMD 0
>   [  739.890418] Oops:  [#1] SMP
>   [  739.905265] Modules linked in: nbd vport_vxlan vport_gre gre
> ebtable_filter ebtables openvswitch ib_iser rdma_cm iw_cm ib_cm ib_sa
> ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
> ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter
> xt_CT iptable_raw ip_tables xt_tcpudp ip6t_REJECT nf_reject_ipv6 xt_limit
> nf_conntrack_ipv6 nf_defrag_ipv6 xt_multiport xt_conntrack nf_conntrack
> ip6table_filter ip6_tables x_tables dm_crypt ipmi_ssif intel_rapl iosf_mbi
> x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul
> crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul
> glue_helper ablk_helper cryptd kvm_intel kvm ipmi_devintf vhost_net vhost
> macvtap macvlan joydev input_leds dm_multipath scsi_dh bonding sb_edac
> 8021q garp hpilo mrp stp ipmi_si llc edac_core lpc_ich ioatdma 8250_fintek
> ipmi_msghandler lp shpchp acpi_power_meter mac_hid parport nls_iso8859_1
> sch_fq_codel xfs libcrc32c btrfs xor raid6_pq ixgbe ses enclosure
> hid_generic dca vxlan usbhid ip6_udp_tunnel tg3 udp_tunnel ptp hid pps_core
> hpsa mdio wmi
>   [  740.345300] CPU: 8 PID: 10550 Comm: qemu-system-x86 Not tainted
> 4.2.0-040200-generic #201508301530
>   [  740.386879] Hardware name: HP ProLiant DL380 Gen9, BIOS P89 05/06/2015
>   [  740.416827] task: 882f8e958dc0 ti: 882f28c2 task.ti:
> 882f28c2
>   [  740.451672] RIP: 0010:[]  []
> kmem_cache_alloc_trace+0x7a/0x1f0
>   [  740.494047] RSP: 0018:882f28c23c68  EFLAGS: 00010286
>   [  740.518425] RAX:  RBX: 00d0 RCX:
> 26b3
>   [  740.551611] RDX: 26b2 RSI: 00d0 RDI:
> 882fbf407840
>   [  740.584846] RBP: 882f28c23ca8 R08: 00019920 R09:
> e8d000200ab0
>   [  740.618287] R10: 812e8dcd R11: ea00bca0ac00 R12:
> 00d0
>   [  740.651320] R13: 882fbf407840 R14: 8800a4104ea0 R15:
> 882fbf407840
>   [  740.684195] FS:  7f2642ffd700() GS:882fbfa0()
> knlGS:
>   [  740.722030] CS:  0010 DS:  ES:  CR0: 80050033
>   [  740.749469] CR2: 8800a4104ea0 CR3: 002f26f83000 CR4:
> 001426e0
>   [  740.783390] Stack:
>   [  740.792577]  812e8dcd 0048 0002
> 882f908c8468
>   [  740.827003]  01bef000 882f928e4600 882f28c23e48
> 882f28c23d70
>   [  740.860971]  882f28c23d38 812e8dcd 0001
> 882f908c8300
>   [  740.894994] Call Trace:
>   [  740.906211]  [] ? fuse_direct_IO+0xdd/0x280
>   [  740.932940]  [] fuse_direct_IO+0xdd/0x280
>   [  740.958866]  [] generic_file_direct_write+0x9e/0x150
>   [  740.989318]  [] fuse_file_write_iter+0x15c/0x2e0
>   [  741.017725]  [] __vfs_write+0xa7/0xf0
>   [  741.041787]  [] vfs_write+0xa9/0x190
>   [  741.065307]  [] SyS_pwrite64+0x69/0xa0
>   [  741.090141]  [] ? SyS_rt_sigprocmask+0x67/0xb0
>   [  741.135924]  [] entry_SYSCALL_64_fastpath+0x16/0x75
>   [  741.183478] Code: 4c 03 05 32 d8 e3 7e 4d 8b 30 49 8b 40 10 4d 85 f6
> 0f 84 22 01 00 00 48 85 c0 0f 84 19 01 00 00 49 63 47 20 48 8d 4a 01 4d 8b
> 07 <49> 8b 1c 06 4c 89 f0 65 49 0f c7 08 0f 94 c0 84 c0 74 b9 49 63
>   [  741.306817]

Re: [Kernel-packages] [Bug 1505948] Re: Memory arena corruption with FUSE (was Memory allocation failure crashes kernel hard, presumably related to FUSE)

2016-03-11 Thread Seth Forshee 
On Fri, Mar 11, 2016 at 01:03:32PM -, Robert Doebbelin wrote:
> Thank you Seth for taking a close look at the problem and my proposed
> fix. As mentioned on the mailing list my test runs fine now with the two
> fixes.
> 
> However, I prefer your fix as it prevents us from running into this
> issue again. Our test system is happily installing VMs for two hours now
> using your build. Please propose your patch.

I'm not subscribed to fuse-devel and hadn't refreshed the mailing list
thread so I didn't realize that you had discovered that the hang was
unrelated. That's good.

I'm happy to send the patches, I'll go ahead and send both my patch and
your iocb patch after I make sure it all applies/builds okay on 4.5.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1505948

Title:
  Memory arena corruption with FUSE (was Memory allocation failure
  crashes kernel hard, presumably related to FUSE)

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Wily:
  Confirmed
Status in linux package in Fedora:
  Unknown

Bug description:
  Hello everybody,

  Linux 4.1, 4.2 or 4.3-rc leads to an immediate kernel panic in our
  setup when trying to start a Qemu process on top of a fuse-based
  mount. Here is an example stacktrace:

  [  739.807817] BUG: unable to handle kernel paging request at 8800a4104ea0
  [  739.840201] IP: [] kmem_cache_alloc_trace+0x7a/0x1f0
  [  739.870309] PGD 2fee067 PUD 2fbf4dd063 PMD 0
  [  739.890418] Oops:  [#1] SMP
  [  739.905265] Modules linked in: nbd vport_vxlan vport_gre gre 
ebtable_filter ebtables openvswitch ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad 
ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipt_REJECT 
nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter xt_CT 
iptable_raw ip_tables xt_tcpudp ip6t_REJECT nf_reject_ipv6 xt_limit 
nf_conntrack_ipv6 nf_defrag_ipv6 xt_multiport xt_conntrack nf_conntrack 
ip6table_filter ip6_tables x_tables dm_crypt ipmi_ssif intel_rapl iosf_mbi 
x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul 
ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper 
cryptd kvm_intel kvm ipmi_devintf vhost_net vhost macvtap macvlan joydev 
input_leds dm_multipath scsi_dh bonding sb_edac 8021q garp hpilo mrp stp 
ipmi_si llc edac_core lpc_ich ioatdma 8250_fintek ipmi_msghandler lp shpchp 
acpi_power_meter mac_hid parport nls_iso8859_1 sch_fq_codel xfs libcrc32c btrfs 
xor raid6_pq ixgbe ses enclosure
  hid_generic dca vxlan usbhid ip6_udp_tunnel tg3 udp_tunnel ptp hid pps_core 
hpsa mdio wmi
  [  740.345300] CPU: 8 PID: 10550 Comm: qemu-system-x86 Not tainted 
4.2.0-040200-generic #201508301530
  [  740.386879] Hardware name: HP ProLiant DL380 Gen9, BIOS P89 05/06/2015
  [  740.416827] task: 882f8e958dc0 ti: 882f28c2 task.ti: 
882f28c2
  [  740.451672] RIP: 0010:[]  [] 
kmem_cache_alloc_trace+0x7a/0x1f0
  [  740.494047] RSP: 0018:882f28c23c68  EFLAGS: 00010286
  [  740.518425] RAX:  RBX: 00d0 RCX: 
26b3
  [  740.551611] RDX: 26b2 RSI: 00d0 RDI: 
882fbf407840
  [  740.584846] RBP: 882f28c23ca8 R08: 00019920 R09: 
e8d000200ab0
  [  740.618287] R10: 812e8dcd R11: ea00bca0ac00 R12: 
00d0
  [  740.651320] R13: 882fbf407840 R14: 8800a4104ea0 R15: 
882fbf407840
  [  740.684195] FS:  7f2642ffd700() GS:882fbfa0() 
knlGS:
  [  740.722030] CS:  0010 DS:  ES:  CR0: 80050033
  [  740.749469] CR2: 8800a4104ea0 CR3: 002f26f83000 CR4: 
001426e0
  [  740.783390] Stack:
  [  740.792577]  812e8dcd 0048 0002 
882f908c8468
  [  740.827003]  01bef000 882f928e4600 882f28c23e48 
882f28c23d70
  [  740.860971]  882f28c23d38 812e8dcd 0001 
882f908c8300
  [  740.894994] Call Trace:
  [  740.906211]  [] ? fuse_direct_IO+0xdd/0x280
  [  740.932940]  [] fuse_direct_IO+0xdd/0x280
  [  740.958866]  [] generic_file_direct_write+0x9e/0x150
  [  740.989318]  [] fuse_file_write_iter+0x15c/0x2e0
  [  741.017725]  [] __vfs_write+0xa7/0xf0
  [  741.041787]  [] vfs_write+0xa9/0x190
  [  741.065307]  [] SyS_pwrite64+0x69/0xa0
  [  741.090141]  [] ? SyS_rt_sigprocmask+0x67/0xb0
  [  741.135924]  [] entry_SYSCALL_64_fastpath+0x16/0x75
  [  741.183478] Code: 4c 03 05 32 d8 e3 7e 4d 8b 30 49 8b 40 10 4d 85 f6 0f 84 
22 01 00 00 48 85 c0 0f 84 19 01 00 00 49 63 47 20 48 8d 4a 01 4d 8b 07 <49> 8b 
1c 06 4c 89 f0 65 49 0f c7 08 0f 94 c0 84 c0 74 b9 49 63
  [  741.306817] RIP  [] kmem_cache_alloc_trace+0x7a/0x1f0

  The problem has also been documented by somebody else in the Fedora
  bug tracker at https://bugzilla.redhat.com/show_bug.cgi?id=1254310

  This behaviour is 100% reproducible. I have