* Possible Bug
@ 2016-03-31 12:34 Roger H Newell
2016-03-31 14:37 ` Valdis.Kletnieks at vt.edu
[not found] ` <56FD38C4.8030201@gmail.com>
0 siblings, 2 replies; 13+ messages in thread
From: Roger H Newell @ 2016-03-31 12:34 UTC (permalink / raw)
To: kernelnewbies
Hi:
I think I may have stumbled upon a USB bug. Before I send it off to
one of the larger lists I thought I should run it through here to be
sure its a bug and I have all the information. Could someone have a
look and advise ?
I was having a problem mounting up a USB drive, so I had a look at
dmesg. The output is as follows. I'm running 4.5.0+ from gregs
staging-testing tree.
[952620.256859] usb 1-6: new high-speed USB device number 4 using ehci-pci
[952620.389797] usb 1-6: New USB device found, idVendor=0781, idProduct=5530
[952620.389807] usb 1-6: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[952620.389813] usb 1-6: Product: Cruzer
[952620.389818] usb 1-6: Manufacturer: SanDisk
[952620.389823] usb 1-6: SerialNumber: 20060876510A09733592
[952620.397158] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000805
[952620.397309] IP: [<ffffffff811e636b>] kmem_cache_alloc_trace+0x7b/0x1e0
[952620.397427] PGD 3db56067 PUD cb6cd067 PMD 0
[952620.397511] Oops: 0000 [#1] SMP
[952620.397573] Modules linked in: binfmt_misc snd_hda_codec_realtek
snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec
snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event
snd_rawmidi snd_seq snd_seq_device snd_timer edac_mce_amd snd joydev
kvm_amd input_leds edac_core kvm soundcore serio_raw k10temp i2c_piix4
8250_fintek asus_atk0110 mac_hid irqbypass parport_pc ppdev lp parport
autofs4 pata_acpi hid_generic usbhid hid amdkfd amd_iommu_v2 radeon
i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt
fb_sys_fops drm psmouse ahci pata_atiixp libahci r8169 mii wmi
[952620.398620] CPU: 1 PID: 18445 Comm: mtp-probe Not tainted 4.5.0+ #28
[952620.398726] Hardware name: System manufacturer System Product
Name/M5A78L-M LX PLUS, BIOS 0402 09/20/2011
[952620.398884] task: ffff88009bf68d00 ti: ffff8800499f0000 task.ti:
ffff8800499f0000
[952620.399006] RIP: 0010:[<ffffffff811e636b>] [<ffffffff811e636b>]
kmem_cache_alloc_trace+0x7b/0x1e0
[952620.399158] RSP: 0018:ffff8800499f3c70 EFLAGS: 00010206
[952620.399246] RAX: 0000000000000000 RBX: 00000000024080c0 RCX:
000000000ae98088
[952620.399362] RDX: 000000000ae98087 RSI: 00000000024080c0 RDI:
0000000000019b20
[952620.399477] RBP: ffff8800499f3cb0 R08: ffff88012fc59b20 R09:
ffff88012b003cc0
[952620.399593] R10: 0000000000000805 R11: fefefefefefefeff R12:
00000000024080c0
[952620.399709] R13: ffffffff813736d3 R14: 00007f9bfa435040 R15:
ffff88012b003cc0
[952620.399826] FS: 00007f550c9a48c0(0000) GS:ffff88012fc40000(0000)
knlGS:0000000000000000
[952620.399956] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[952620.400050] CR2: 0000000000000805 CR3: 00000000ce839000 CR4:
00000000000006e0
[952620.400165] Stack:
[952620.400201] 00000000024080c0 ffffffff8120bb2c 0000000000000002
ffff88000227d500
[952620.400335] ffff88000227d500 ffff8800499f3ef4 00007f9bfa435040
ffff8800499f3de0
[952620.400467] ffff8800499f3cc8 ffffffff813736d3 ffffffff81c9fe80
ffff8800499f3ce8
[952620.400599] Call Trace:
[952620.400649] [<ffffffff8120bb2c>] ? get_empty_filp+0x5c/0x1c0
[952620.400748] [<ffffffff813736d3>] apparmor_file_alloc_security+0x23/0x40
[952620.400861] [<ffffffff81335b53>] security_file_alloc+0x33/0x50
[952620.400961] [<ffffffff8120bb6a>] get_empty_filp+0x9a/0x1c0
[952620.401057] [<ffffffff812176ce>] path_openat+0x2e/0x1400
[952620.401149] [<ffffffff8121661a>] ? walk_component+0x3a/0x470
[952620.401246] [<ffffffff812146c9>] ? path_init+0x1d9/0x330
[952620.401339] [<ffffffff811a6e85>] ? __inc_zone_page_state+0x35/0x40
[952620.401444] [<ffffffff81219454>] ? putname+0x54/0x60
[952620.401530] [<ffffffff8121a38e>] do_filp_open+0x7e/0xe0
[952620.401620] [<ffffffff811e64b5>] ? kmem_cache_alloc_trace+0x1c5/0x1e0
[952620.401728] [<ffffffff811e629a>] ? kmem_cache_alloc+0x17a/0x1d0
[952620.401829] [<ffffffff812194b6>] ? getname_flags+0x56/0x1f0
[952620.401924] [<ffffffff81227606>] ? __alloc_fd+0x46/0x190
[952620.402016] [<ffffffff81208984>] do_sys_open+0x124/0x210
[952620.402107] [<ffffffff81207d48>] ? SyS_access+0x1e8/0x230
[952620.402200] [<ffffffff81208a8e>] SyS_open+0x1e/0x20
[952620.402286] [<ffffffff817ec736>] entry_SYSCALL_64_fastpath+0x1e/0xa8
[952620.402391] Code: 08 65 4c 03 05 3f 3e e2 7e 49 83 78 10 00 4d 8b
10 0f 84 14 01 00 00 4d 85 d2 0f 84 0b 01 00 00 49 63 41 20 48 8d 4a
01 49 8b 39 <49> 8b 1c 02 4c 89 d0 65 48 0f c7 0f 0f 94 c0 84 c0 74 bb
49 63
[952620.402934] RIP [<ffffffff811e636b>] kmem_cache_alloc_trace+0x7b/0x1e0
[952620.403047] RSP <ffff8800499f3c70>
[952620.403106] CR2: 0000000000000805
[952620.445606] ---[ end trace e7adb7015192b3a3 ]---
^ permalink raw reply [flat|nested] 13+ messages in thread
* Possible Bug
2016-03-31 12:34 Possible Bug Roger H Newell
@ 2016-03-31 14:37 ` Valdis.Kletnieks at vt.edu
[not found] ` <56FD5089.5070302@canonical.com>
[not found] ` <56FD38C4.8030201@gmail.com>
1 sibling, 1 reply; 13+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2016-03-31 14:37 UTC (permalink / raw)
To: kernelnewbies
On Thu, 31 Mar 2016 10:04:47 -0230, Roger H Newell said:
> I think I may have stumbled upon a USB bug. Before I send it off to
Looks like an apparmor bug, not USB. Quite likely the same problem as these
guys hit, as the traceback is the same:
http://askubuntu.com/questions/748119/ubuntu-15-10-hangs-after-suspend-resume-inspiron-7559
https://github.com/IRATI/stack/issues/470
(And other hits)
Seems to be a long-standing issue, that second link is from Feb 2015. On
the other hand, all the hits appear to be in mailing lists *other* than
ones where apparmor guys were likely to see it.
I'm adding a cc: to the apparmor guys.
> I was having a problem mounting up a USB drive, so I had a look at
> dmesg. The output is as follows. I'm running 4.5.0+ from gregs
> staging-testing tree.
>
> [952620.256859] usb 1-6: new high-speed USB device number 4 using ehci-pci
> [952620.389797] usb 1-6: New USB device found, idVendor=0781, idProduct=5530
> [952620.389807] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [952620.389813] usb 1-6: Product: Cruzer
> [952620.389818] usb 1-6: Manufacturer: SanDisk
> [952620.389823] usb 1-6: SerialNumber: 20060876510A09733592
> [952620.397158] BUG: unable to handle kernel NULL pointer dereference at 0000000000000805
> [952620.397309] IP: [<ffffffff811e636b>] kmem_cache_alloc_trace+0x7b/0x1e0
> [952620.397427] PGD 3db56067 PUD cb6cd067 PMD 0
> [952620.397511] Oops: 0000 [#1] SMP
> [952620.397573] Modules linked in: binfmt_misc snd_hda_codec_realtek
> snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec
> snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event
> snd_rawmidi snd_seq snd_seq_device snd_timer edac_mce_amd snd joydev
> kvm_amd input_leds edac_core kvm soundcore serio_raw k10temp i2c_piix4
> 8250_fintek asus_atk0110 mac_hid irqbypass parport_pc ppdev lp parport
> autofs4 pata_acpi hid_generic usbhid hid amdkfd amd_iommu_v2 radeon
> i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt
> fb_sys_fops drm psmouse ahci pata_atiixp libahci r8169 mii wmi
> [952620.398620] CPU: 1 PID: 18445 Comm: mtp-probe Not tainted 4.5.0+ #28
> [952620.398726] Hardware name: System manufacturer System Product Name/M5A78L-M LX PLUS, BIOS 0402 09/20/2011
> [952620.398884] task: ffff88009bf68d00 ti: ffff8800499f0000 task.ti: ffff8800499f0000
> [952620.399006] RIP: 0010:[<ffffffff811e636b>] [<ffffffff811e636b>] kmem_cache_alloc_trace+0x7b/0x1e0
> [952620.399158] RSP: 0018:ffff8800499f3c70 EFLAGS: 00010206
> [952620.399246] RAX: 0000000000000000 RBX: 00000000024080c0 RCX: 000000000ae98088
> [952620.399362] RDX: 000000000ae98087 RSI: 00000000024080c0 RDI: 0000000000019b20
> [952620.399477] RBP: ffff8800499f3cb0 R08: ffff88012fc59b20 R09: ffff88012b003cc0
> [952620.399593] R10: 0000000000000805 R11: fefefefefefefeff R12: 00000000024080c0
> [952620.399709] R13: ffffffff813736d3 R14: 00007f9bfa435040 R15: ffff88012b003cc0
> [952620.399826] FS: 00007f550c9a48c0(0000) GS:ffff88012fc40000(0000) knlGS:0000000000000000
> [952620.399956] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [952620.400050] CR2: 0000000000000805 CR3: 00000000ce839000 CR4: 00000000000006e0
> [952620.400165] Stack:
> [952620.400201] 00000000024080c0 ffffffff8120bb2c 0000000000000002 ffff88000227d500
> [952620.400335] ffff88000227d500 ffff8800499f3ef4 00007f9bfa435040 ffff8800499f3de0
> [952620.400467] ffff8800499f3cc8 ffffffff813736d3 ffffffff81c9fe80 ffff8800499f3ce8
> [952620.400599] Call Trace:
> [952620.400649] [<ffffffff8120bb2c>] ? get_empty_filp+0x5c/0x1c0
> [952620.400748] [<ffffffff813736d3>] apparmor_file_alloc_security+0x23/0x40
> [952620.400861] [<ffffffff81335b53>] security_file_alloc+0x33/0x50
> [952620.400961] [<ffffffff8120bb6a>] get_empty_filp+0x9a/0x1c0
> [952620.401057] [<ffffffff812176ce>] path_openat+0x2e/0x1400
> [952620.401149] [<ffffffff8121661a>] ? walk_component+0x3a/0x470
> [952620.401246] [<ffffffff812146c9>] ? path_init+0x1d9/0x330
> [952620.401339] [<ffffffff811a6e85>] ? __inc_zone_page_state+0x35/0x40
> [952620.401444] [<ffffffff81219454>] ? putname+0x54/0x60
> [952620.401530] [<ffffffff8121a38e>] do_filp_open+0x7e/0xe0
> [952620.401620] [<ffffffff811e64b5>] ? kmem_cache_alloc_trace+0x1c5/0x1e0
> [952620.401728] [<ffffffff811e629a>] ? kmem_cache_alloc+0x17a/0x1d0
> [952620.401829] [<ffffffff812194b6>] ? getname_flags+0x56/0x1f0
> [952620.401924] [<ffffffff81227606>] ? __alloc_fd+0x46/0x190
> [952620.402016] [<ffffffff81208984>] do_sys_open+0x124/0x210
> [952620.402107] [<ffffffff81207d48>] ? SyS_access+0x1e8/0x230
> [952620.402200] [<ffffffff81208a8e>] SyS_open+0x1e/0x20
> [952620.402286] [<ffffffff817ec736>] entry_SYSCALL_64_fastpath+0x1e/0xa8
> [952620.402391] Code: 08 65 4c 03 05 3f 3e e2 7e 49 83 78 10 00 4d 8b 10 0f 84 14 01 00 00 4d 85 d2 0f 84 0b 01 00 00 49 63 41 20 48 8d 4a 01 49 8b 39 <49> 8b 1c 02 4c 89 d0 65 48 0f c7 0f 0f 94 c0 84 c0 74 bb 49 63
> [952620.402934] RIP [<ffffffff811e636b>] kmem_cache_alloc_trace+0x7b/0x1e0
> [952620.403047] RSP <ffff8800499f3c70>
> [952620.403106] CR2: 0000000000000805
> [952620.445606] ---[ end trace e7adb7015192b3a3 ]---
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160331/b966d726/attachment-0001.bin
^ permalink raw reply [flat|nested] 13+ messages in thread
* Possible Bug
[not found] ` <56FD38C4.8030201@gmail.com>
@ 2016-03-31 15:08 ` Roger H Newell
[not found] ` <56FD4C35.5040301@gmail.com>
2016-03-31 16:30 ` Carlo Caione
0 siblings, 2 replies; 13+ messages in thread
From: Roger H Newell @ 2016-03-31 15:08 UTC (permalink / raw)
To: kernelnewbies
On Thu, Mar 31, 2016 at 12:18 PM, nick <xerofoify@gmail.com> wrote:
>
>
> On 2016-03-31 08:34 AM, Roger H Newell wrote:
>> Hi:
>>
>> I think I may have stumbled upon a USB bug. Before I send it off to
>> one of the larger lists I thought I should run it through here to be
>> sure its a bug and I have all the information. Could someone have a
>> look and advise ?
>>
>> I was having a problem mounting up a USB drive, so I had a look at
>> dmesg. The output is as follows. I'm running 4.5.0+ from gregs
>> staging-testing tree.
>>
>> [952620.256859] usb 1-6: new high-speed USB device number 4 using ehci-pci
>> [952620.389797] usb 1-6: New USB device found, idVendor=0781, idProduct=5530
>> [952620.389807] usb 1-6: New USB device strings: Mfr=1, Product=2,
>> SerialNumber=3
>> [952620.389813] usb 1-6: Product: Cruzer
>> [952620.389818] usb 1-6: Manufacturer: SanDisk
>> [952620.389823] usb 1-6: SerialNumber: 20060876510A09733592
>> [952620.397158] BUG: unable to handle kernel NULL pointer dereference
>> at 0000000000000805
>> [952620.397309] IP: [<ffffffff811e636b>] kmem_cache_alloc_trace+0x7b/0x1e0
>> [952620.397427] PGD 3db56067 PUD cb6cd067 PMD 0
>> [952620.397511] Oops: 0000 [#1] SMP
>> [952620.397573] Modules linked in: binfmt_misc snd_hda_codec_realtek
>> snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec
>> snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event
>> snd_rawmidi snd_seq snd_seq_device snd_timer edac_mce_amd snd joydev
>> kvm_amd input_leds edac_core kvm soundcore serio_raw k10temp i2c_piix4
>> 8250_fintek asus_atk0110 mac_hid irqbypass parport_pc ppdev lp parport
>> autofs4 pata_acpi hid_generic usbhid hid amdkfd amd_iommu_v2 radeon
>> i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt
>> fb_sys_fops drm psmouse ahci pata_atiixp libahci r8169 mii wmi
>> [952620.398620] CPU: 1 PID: 18445 Comm: mtp-probe Not tainted 4.5.0+ #28
>> [952620.398726] Hardware name: System manufacturer System Product
>> Name/M5A78L-M LX PLUS, BIOS 0402 09/20/2011
>> [952620.398884] task: ffff88009bf68d00 ti: ffff8800499f0000 task.ti:
>> ffff8800499f0000
>> [952620.399006] RIP: 0010:[<ffffffff811e636b>] [<ffffffff811e636b>]
>> kmem_cache_alloc_trace+0x7b/0x1e0
>> [952620.399158] RSP: 0018:ffff8800499f3c70 EFLAGS: 00010206
>> [952620.399246] RAX: 0000000000000000 RBX: 00000000024080c0 RCX:
>> 000000000ae98088
>> [952620.399362] RDX: 000000000ae98087 RSI: 00000000024080c0 RDI:
>> 0000000000019b20
>> [952620.399477] RBP: ffff8800499f3cb0 R08: ffff88012fc59b20 R09:
>> ffff88012b003cc0
>> [952620.399593] R10: 0000000000000805 R11: fefefefefefefeff R12:
>> 00000000024080c0
>> [952620.399709] R13: ffffffff813736d3 R14: 00007f9bfa435040 R15:
>> ffff88012b003cc0
>> [952620.399826] FS: 00007f550c9a48c0(0000) GS:ffff88012fc40000(0000)
>> knlGS:0000000000000000
>> [952620.399956] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [952620.400050] CR2: 0000000000000805 CR3: 00000000ce839000 CR4:
>> 00000000000006e0
>> [952620.400165] Stack:
>> [952620.400201] 00000000024080c0 ffffffff8120bb2c 0000000000000002
>> ffff88000227d500
>> [952620.400335] ffff88000227d500 ffff8800499f3ef4 00007f9bfa435040
>> ffff8800499f3de0
>> [952620.400467] ffff8800499f3cc8 ffffffff813736d3 ffffffff81c9fe80
>> ffff8800499f3ce8
>> [952620.400599] Call Trace:
>> [952620.400649] [<ffffffff8120bb2c>] ? get_empty_filp+0x5c/0x1c0
>> [952620.400748] [<ffffffff813736d3>] apparmor_file_alloc_security+0x23/0x40
>> [952620.400861] [<ffffffff81335b53>] security_file_alloc+0x33/0x50
>> [952620.400961] [<ffffffff8120bb6a>] get_empty_filp+0x9a/0x1c0
>> [952620.401057] [<ffffffff812176ce>] path_openat+0x2e/0x1400
>> [952620.401149] [<ffffffff8121661a>] ? walk_component+0x3a/0x470
>> [952620.401246] [<ffffffff812146c9>] ? path_init+0x1d9/0x330
>> [952620.401339] [<ffffffff811a6e85>] ? __inc_zone_page_state+0x35/0x40
>> [952620.401444] [<ffffffff81219454>] ? putname+0x54/0x60
>> [952620.401530] [<ffffffff8121a38e>] do_filp_open+0x7e/0xe0
>> [952620.401620] [<ffffffff811e64b5>] ? kmem_cache_alloc_trace+0x1c5/0x1e0
>> [952620.401728] [<ffffffff811e629a>] ? kmem_cache_alloc+0x17a/0x1d0
>> [952620.401829] [<ffffffff812194b6>] ? getname_flags+0x56/0x1f0
>> [952620.401924] [<ffffffff81227606>] ? __alloc_fd+0x46/0x190
>> [952620.402016] [<ffffffff81208984>] do_sys_open+0x124/0x210
>> [952620.402107] [<ffffffff81207d48>] ? SyS_access+0x1e8/0x230
>> [952620.402200] [<ffffffff81208a8e>] SyS_open+0x1e/0x20
>> [952620.402286] [<ffffffff817ec736>] entry_SYSCALL_64_fastpath+0x1e/0xa8
>> [952620.402391] Code: 08 65 4c 03 05 3f 3e e2 7e 49 83 78 10 00 4d 8b
>> 10 0f 84 14 01 00 00 4d 85 d2 0f 84 0b 01 00 00 49 63 41 20 48 8d 4a
>> 01 49 8b 39 <49> 8b 1c 02 4c 89 d0 65 48 0f c7 0f 0f 94 c0 84 c0 74 bb
>> 49 63
>> [952620.402934] RIP [<ffffffff811e636b>] kmem_cache_alloc_trace+0x7b/0x1e0
>> [952620.403047] RSP <ffff8800499f3c70>
>> [952620.403106] CR2: 0000000000000805
>> [952620.445606] ---[ end trace e7adb7015192b3a3 ]---
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
> In the fs/file_table.c file as from the root directory of your kernel tree change in the function,
> get_empty_flip change these lines:
> if (unlikely(error)) {
> file_free(f);
> return ERR_PTR(error);
> }
> to:
> if (unlikely(error))
> return ERR_PTR(error);
> and tell me if that fixes your issue.
> Nick
Seems to have worked, the error is is gone and I can mount the USB device.
dmesg output as follows
[ 32.538288] usb 1-5: new high-speed USB device number 2 using ehci-pci
[ 32.671122] usb 1-5: New USB device found, idVendor=0781, idProduct=5530
[ 32.671125] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 32.671126] usb 1-5: Product: Cruzer
[ 32.671128] usb 1-5: Manufacturer: SanDisk
[ 32.671129] usb 1-5: SerialNumber: 20060876510A09733592
[ 32.697487] usb-storage 1-5:1.0: USB Mass Storage device detected
[ 32.697691] scsi host6: usb-storage 1-5:1.0
[ 32.697757] usbcore: registered new interface driver usb-storage
[ 32.702641] usbcore: registered new interface driver uas
[ 33.695126] scsi 6:0:0:0: Direct-Access SanDisk Cruzer
1.02 PQ: 0 ANSI: 2
[ 33.695382] sd 6:0:0:0: Attached scsi generic sg2 type 0
[ 33.696114] sd 6:0:0:0: [sdc] 7813120 512-byte logical blocks:
(4.00 GB/3.73 GiB)
[ 33.697739] sd 6:0:0:0: [sdc] Write Protect is off
[ 33.697742] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00
[ 33.698740] sd 6:0:0:0: [sdc] No Caching mode page found
[ 33.698744] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[ 33.707370] sdc: sdc1 sdc2
[ 33.710732] sd 6:0:0:0: [sdc] Attached SCSI removable disk
^ permalink raw reply [flat|nested] 13+ messages in thread
* Possible Bug
[not found] ` <56FD4C35.5040301@gmail.com>
@ 2016-03-31 16:25 ` Roger H Newell
2016-03-31 17:22 ` Valdis.Kletnieks at vt.edu
0 siblings, 1 reply; 13+ messages in thread
From: Roger H Newell @ 2016-03-31 16:25 UTC (permalink / raw)
To: kernelnewbies
On Thu, Mar 31, 2016 at 1:41 PM, nick <xerofoify@gmail.com> wrote:
>
>
> On 2016-03-31 11:08 AM, Roger H Newell wrote:
>> On Thu, Mar 31, 2016 at 12:18 PM, nick <xerofoify@gmail.com> wrote:
>>>
>>>
>>> On 2016-03-31 08:34 AM, Roger H Newell wrote:
>>>> Hi:
>>>>
>>>> I think I may have stumbled upon a USB bug. Before I send it off to
>>>> one of the larger lists I thought I should run it through here to be
>>>> sure its a bug and I have all the information. Could someone have a
>>>> look and advise ?
>>>>
>>>> I was having a problem mounting up a USB drive, so I had a look at
>>>> dmesg. The output is as follows. I'm running 4.5.0+ from gregs
>>>> staging-testing tree.
>>>>
>>>> [952620.256859] usb 1-6: new high-speed USB device number 4 using ehci-pci
>>>> [952620.389797] usb 1-6: New USB device found, idVendor=0781, idProduct=5530
>>>> [952620.389807] usb 1-6: New USB device strings: Mfr=1, Product=2,
>>>> SerialNumber=3
>>>> [952620.389813] usb 1-6: Product: Cruzer
>>>> [952620.389818] usb 1-6: Manufacturer: SanDisk
>>>> [952620.389823] usb 1-6: SerialNumber: 20060876510A09733592
>>>> [952620.397158] BUG: unable to handle kernel NULL pointer dereference
>>>> at 0000000000000805
>>>> [952620.397309] IP: [<ffffffff811e636b>] kmem_cache_alloc_trace+0x7b/0x1e0
>>>> [952620.397427] PGD 3db56067 PUD cb6cd067 PMD 0
>>>> [952620.397511] Oops: 0000 [#1] SMP
>>>> [952620.397573] Modules linked in: binfmt_misc snd_hda_codec_realtek
>>>> snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec
>>>> snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event
>>>> snd_rawmidi snd_seq snd_seq_device snd_timer edac_mce_amd snd joydev
>>>> kvm_amd input_leds edac_core kvm soundcore serio_raw k10temp i2c_piix4
>>>> 8250_fintek asus_atk0110 mac_hid irqbypass parport_pc ppdev lp parport
>>>> autofs4 pata_acpi hid_generic usbhid hid amdkfd amd_iommu_v2 radeon
>>>> i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt
>>>> fb_sys_fops drm psmouse ahci pata_atiixp libahci r8169 mii wmi
>>>> [952620.398620] CPU: 1 PID: 18445 Comm: mtp-probe Not tainted 4.5.0+ #28
>>>> [952620.398726] Hardware name: System manufacturer System Product
>>>> Name/M5A78L-M LX PLUS, BIOS 0402 09/20/2011
>>>> [952620.398884] task: ffff88009bf68d00 ti: ffff8800499f0000 task.ti:
>>>> ffff8800499f0000
>>>> [952620.399006] RIP: 0010:[<ffffffff811e636b>] [<ffffffff811e636b>]
>>>> kmem_cache_alloc_trace+0x7b/0x1e0
>>>> [952620.399158] RSP: 0018:ffff8800499f3c70 EFLAGS: 00010206
>>>> [952620.399246] RAX: 0000000000000000 RBX: 00000000024080c0 RCX:
>>>> 000000000ae98088
>>>> [952620.399362] RDX: 000000000ae98087 RSI: 00000000024080c0 RDI:
>>>> 0000000000019b20
>>>> [952620.399477] RBP: ffff8800499f3cb0 R08: ffff88012fc59b20 R09:
>>>> ffff88012b003cc0
>>>> [952620.399593] R10: 0000000000000805 R11: fefefefefefefeff R12:
>>>> 00000000024080c0
>>>> [952620.399709] R13: ffffffff813736d3 R14: 00007f9bfa435040 R15:
>>>> ffff88012b003cc0
>>>> [952620.399826] FS: 00007f550c9a48c0(0000) GS:ffff88012fc40000(0000)
>>>> knlGS:0000000000000000
>>>> [952620.399956] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>> [952620.400050] CR2: 0000000000000805 CR3: 00000000ce839000 CR4:
>>>> 00000000000006e0
>>>> [952620.400165] Stack:
>>>> [952620.400201] 00000000024080c0 ffffffff8120bb2c 0000000000000002
>>>> ffff88000227d500
>>>> [952620.400335] ffff88000227d500 ffff8800499f3ef4 00007f9bfa435040
>>>> ffff8800499f3de0
>>>> [952620.400467] ffff8800499f3cc8 ffffffff813736d3 ffffffff81c9fe80
>>>> ffff8800499f3ce8
>>>> [952620.400599] Call Trace:
>>>> [952620.400649] [<ffffffff8120bb2c>] ? get_empty_filp+0x5c/0x1c0
>>>> [952620.400748] [<ffffffff813736d3>] apparmor_file_alloc_security+0x23/0x40
>>>> [952620.400861] [<ffffffff81335b53>] security_file_alloc+0x33/0x50
>>>> [952620.400961] [<ffffffff8120bb6a>] get_empty_filp+0x9a/0x1c0
>>>> [952620.401057] [<ffffffff812176ce>] path_openat+0x2e/0x1400
>>>> [952620.401149] [<ffffffff8121661a>] ? walk_component+0x3a/0x470
>>>> [952620.401246] [<ffffffff812146c9>] ? path_init+0x1d9/0x330
>>>> [952620.401339] [<ffffffff811a6e85>] ? __inc_zone_page_state+0x35/0x40
>>>> [952620.401444] [<ffffffff81219454>] ? putname+0x54/0x60
>>>> [952620.401530] [<ffffffff8121a38e>] do_filp_open+0x7e/0xe0
>>>> [952620.401620] [<ffffffff811e64b5>] ? kmem_cache_alloc_trace+0x1c5/0x1e0
>>>> [952620.401728] [<ffffffff811e629a>] ? kmem_cache_alloc+0x17a/0x1d0
>>>> [952620.401829] [<ffffffff812194b6>] ? getname_flags+0x56/0x1f0
>>>> [952620.401924] [<ffffffff81227606>] ? __alloc_fd+0x46/0x190
>>>> [952620.402016] [<ffffffff81208984>] do_sys_open+0x124/0x210
>>>> [952620.402107] [<ffffffff81207d48>] ? SyS_access+0x1e8/0x230
>>>> [952620.402200] [<ffffffff81208a8e>] SyS_open+0x1e/0x20
>>>> [952620.402286] [<ffffffff817ec736>] entry_SYSCALL_64_fastpath+0x1e/0xa8
>>>> [952620.402391] Code: 08 65 4c 03 05 3f 3e e2 7e 49 83 78 10 00 4d 8b
>>>> 10 0f 84 14 01 00 00 4d 85 d2 0f 84 0b 01 00 00 49 63 41 20 48 8d 4a
>>>> 01 49 8b 39 <49> 8b 1c 02 4c 89 d0 65 48 0f c7 0f 0f 94 c0 84 c0 74 bb
>>>> 49 63
>>>> [952620.402934] RIP [<ffffffff811e636b>] kmem_cache_alloc_trace+0x7b/0x1e0
>>>> [952620.403047] RSP <ffff8800499f3c70>
>>>> [952620.403106] CR2: 0000000000000805
>>>> [952620.445606] ---[ end trace e7adb7015192b3a3 ]---
>>>>
>>>> _______________________________________________
>>>> Kernelnewbies mailing list
>>>> Kernelnewbies at kernelnewbies.org
>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>>
>>> In the fs/file_table.c file as from the root directory of your kernel tree change in the function,
>>> get_empty_flip change these lines:
>>> if (unlikely(error)) {
>>> file_free(f);
>>> return ERR_PTR(error);
>>> }
>>> to:
>>> if (unlikely(error))
>>> return ERR_PTR(error);
>>> and tell me if that fixes your issue.
>>> Nick
>>
> Ok this seems fixed to me. I just need you to send me a email with your added
> Tested By: your email address so I can it to a patch I am sending to fix this bug.
> Cheers Nick
>>
>> Seems to have worked, the error is is gone and I can mount the USB device.
>>
>> dmesg output as follows
>>
>> [ 32.538288] usb 1-5: new high-speed USB device number 2 using ehci-pci
>> [ 32.671122] usb 1-5: New USB device found, idVendor=0781, idProduct=5530
>> [ 32.671125] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
>> [ 32.671126] usb 1-5: Product: Cruzer
>> [ 32.671128] usb 1-5: Manufacturer: SanDisk
>> [ 32.671129] usb 1-5: SerialNumber: 20060876510A09733592
>> [ 32.697487] usb-storage 1-5:1.0: USB Mass Storage device detected
>> [ 32.697691] scsi host6: usb-storage 1-5:1.0
>> [ 32.697757] usbcore: registered new interface driver usb-storage
>> [ 32.702641] usbcore: registered new interface driver uas
>> [ 33.695126] scsi 6:0:0:0: Direct-Access SanDisk Cruzer
>> 1.02 PQ: 0 ANSI: 2
>> [ 33.695382] sd 6:0:0:0: Attached scsi generic sg2 type 0
>> [ 33.696114] sd 6:0:0:0: [sdc] 7813120 512-byte logical blocks:
>> (4.00 GB/3.73 GiB)
>> [ 33.697739] sd 6:0:0:0: [sdc] Write Protect is off
>> [ 33.697742] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00
>> [ 33.698740] sd 6:0:0:0: [sdc] No Caching mode page found
>> [ 33.698744] sd 6:0:0:0: [sdc] Assuming drive cache: write through
>> [ 33.707370] sdc: sdc1 sdc2
>> [ 33.710732] sd 6:0:0:0: [sdc] Attached SCSI removable disk
>>
Tested-By: Roger H. Newell <newell.roger@gmail.com>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Possible Bug
2016-03-31 15:08 ` Roger H Newell
[not found] ` <56FD4C35.5040301@gmail.com>
@ 2016-03-31 16:30 ` Carlo Caione
[not found] ` <56FD5358.5010101@gmail.com>
1 sibling, 1 reply; 13+ messages in thread
From: Carlo Caione @ 2016-03-31 16:30 UTC (permalink / raw)
To: kernelnewbies
On Thu, Mar 31, 2016 at 5:08 PM, Roger H Newell <newell.roger@gmail.com> wrote:
> On Thu, Mar 31, 2016 at 12:18 PM, nick <xerofoify@gmail.com> wrote:
>>
>>
>> On 2016-03-31 08:34 AM, Roger H Newell wrote:
>> In the fs/file_table.c file as from the root directory of your kernel tree change in the function,
>> get_empty_flip change these lines:
>> if (unlikely(error)) {
>> file_free(f);
>> return ERR_PTR(error);
>> }
>> to:
>> if (unlikely(error))
>> return ERR_PTR(error);
>> and tell me if that fixes your issue.
>> Nick
>
>
> Seems to have worked, the error is is gone and I can mount the USB device.
That's not a fix, you are leaking f.
--
Carlo Caione
^ permalink raw reply [flat|nested] 13+ messages in thread
* Possible Bug
2016-03-31 16:25 ` Roger H Newell
@ 2016-03-31 17:22 ` Valdis.Kletnieks at vt.edu
0 siblings, 0 replies; 13+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2016-03-31 17:22 UTC (permalink / raw)
To: kernelnewbies
On Thu, 31 Mar 2016 13:55:57 -0230, nick said:
> >>> In the fs/file_table.c file as from the root directory of your kernel tree change in the function,
> >>> get_empty_flip change these lines:
> >>> if (unlikely(error)) {
> >>> file_free(f);
> >>> return ERR_PTR(error);
> >>> }
> >>> to:
> >>> if (unlikely(error))
> >>> return ERR_PTR(error);
> >>> and tell me if that fixes your issue.
> >>> Nick
This is an incorrect fix, as the crash happens in security_file_alloc() -
before it ever even *reaches* the if statement.
In addition, you just leaked a reference on f->f_cred by
bypassing the put_cred() that file_free() calls.
If this happens to work, it's by accident, and is merely papering over
a more serious problem.
Spotting the reference leak is (or should have been) a 3 or 5 minute task -
look at the code, see there's a get_FOO() call, and ask where the matching
put_FOO() is. There's a get_cred() you need to have hit to get here - so
*somebody* needs to do a put_cred(). And then looking at the body of
file_free() *should* have shown you that your proposed fix is incredibly
incorrect.
Seriously Nick - please stop this. You're detracting from valuable developer
resources by submitting these incorrect fixes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160331/86f8dcff/attachment.bin
^ permalink raw reply [flat|nested] 13+ messages in thread
* Possible Bug
[not found] ` <56FD5358.5010101@gmail.com>
@ 2016-03-31 17:29 ` Roger H Newell
2016-03-31 18:42 ` Valdis.Kletnieks at vt.edu
0 siblings, 1 reply; 13+ messages in thread
From: Roger H Newell @ 2016-03-31 17:29 UTC (permalink / raw)
To: kernelnewbies
On Thu, Mar 31, 2016 at 2:12 PM, nick <xerofoify@gmail.com> wrote:
>
>
> On 2016-03-31 12:30 PM, Carlo Caione wrote:
>> On Thu, Mar 31, 2016 at 5:08 PM, Roger H Newell <newell.roger@gmail.com> wrote:
>>> On Thu, Mar 31, 2016 at 12:18 PM, nick <xerofoify@gmail.com> wrote:
>>>>
>>>>
>>>> On 2016-03-31 08:34 AM, Roger H Newell wrote:
>>>> In the fs/file_table.c file as from the root directory of your kernel tree change in the function,
>>>> get_empty_flip change these lines:
>>>> if (unlikely(error)) {
>>>> file_free(f);
>>>> return ERR_PTR(error);
>>>> }
>>>> to:
>>>> if (unlikely(error))
>>>> return ERR_PTR(error);
>>>> and tell me if that fixes your issue.
>>>> Nick
>>>
>>>
>>> Seems to have worked, the error is is gone and I can mount the USB device.
>>
>> That's not a fix, you are leaking f.
>>
> Good catch seems:
> static inline void file_free(struct file *f)
> {
> percpu_counter_dec(&nr_files);
> if (f)
> call_rcu(&f->f_u.fu_rcuhead, file_free_rcu);
> }
> Roger can you tell this and see if it fixes your issue. The file
> is fs/file_table.c from the root of the kernel directory.
> Thanks,
> Nick
I reverted the previous change, and applied the if(f) test in
file_free. There are no error messages in dmseg and I can mount the
USB device.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Possible Bug
[not found] ` <56FD5089.5070302@canonical.com>
@ 2016-03-31 17:52 ` Valdis.Kletnieks at vt.edu
2016-03-31 18:16 ` Roger H Newell
0 siblings, 1 reply; 13+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2016-03-31 17:52 UTC (permalink / raw)
To: kernelnewbies
On Thu, 31 Mar 2016 09:30:01 -0700, John Johansen said:
> hrmm, the only thing apparmor is doing in this kernel here is a kzalloc and
> assigning it to f_security, expanding out the aa_alloc_file_context
> abstraction (which should probably just be dropped) we get.
>
> file->f_security = kzalloc(sizeof(struct aa_file_cxt), GFP_KERNEL);
> if (!file->f_security)
> return -ENOMEM;
> return 0;
>
> So unless we are getting a NULL for the file I don't see how apparmor can be
> causing the NULL pointer dereference
Now here's the odd part - just before that, we have:
f->f_cred = get_cred(cred);
error = security_file_alloc(f);
so if f-> was NULL, we should have exploded just *before* the security_file_alloc()
call.
>> [952620.397309] IP: [<ffffffff811e636b>] kmem_cache_alloc_trace+0x7b/0x1e0
Aha. Smoking gun - I should have spotted this before. f-> isn't the null
pointer - it's exploding trying to alloc a slab. You're right, John - it looks
like somebody did the fandango all over the memory allocator.
Roger - can you find out if this kernel was using SLAB, SLOB, or SLUB as
the allocator? And is KASAN enabled or not? (I see a kasan_kmalloc() lurking
in slab.h)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160331/6d61410e/attachment-0001.bin
^ permalink raw reply [flat|nested] 13+ messages in thread
* Possible Bug
2016-03-31 17:52 ` Valdis.Kletnieks at vt.edu
@ 2016-03-31 18:16 ` Roger H Newell
2016-03-31 19:23 ` Valdis.Kletnieks at vt.edu
0 siblings, 1 reply; 13+ messages in thread
From: Roger H Newell @ 2016-03-31 18:16 UTC (permalink / raw)
To: kernelnewbies
On Thu, Mar 31, 2016 at 3:22 PM, <Valdis.Kletnieks@vt.edu> wrote:
> On Thu, 31 Mar 2016 09:30:01 -0700, John Johansen said:
>
>> hrmm, the only thing apparmor is doing in this kernel here is a kzalloc and
>> assigning it to f_security, expanding out the aa_alloc_file_context
>> abstraction (which should probably just be dropped) we get.
>>
>> file->f_security = kzalloc(sizeof(struct aa_file_cxt), GFP_KERNEL);
>> if (!file->f_security)
>> return -ENOMEM;
>> return 0;
>>
>> So unless we are getting a NULL for the file I don't see how apparmor can be
>> causing the NULL pointer dereference
>
> Now here's the odd part - just before that, we have:
>
> f->f_cred = get_cred(cred);
> error = security_file_alloc(f);
>
> so if f-> was NULL, we should have exploded just *before* the security_file_alloc()
> call.
>
>>> [952620.397309] IP: [<ffffffff811e636b>] kmem_cache_alloc_trace+0x7b/0x1e0
>
> Aha. Smoking gun - I should have spotted this before. f-> isn't the null
> pointer - it's exploding trying to alloc a slab. You're right, John - it looks
> like somebody did the fandango all over the memory allocator.
>
> Roger - can you find out if this kernel was using SLAB, SLOB, or SLUB as
> the allocator? And is KASAN enabled or not? (I see a kasan_kmalloc() lurking
> in slab.h)
>
I had a look inside the .config I used to compile this kernel.
I think I found the information you're looking for.
# CONFIG_KASAN is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
^ permalink raw reply [flat|nested] 13+ messages in thread
* Possible Bug
2016-03-31 17:29 ` Roger H Newell
@ 2016-03-31 18:42 ` Valdis.Kletnieks at vt.edu
0 siblings, 0 replies; 13+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2016-03-31 18:42 UTC (permalink / raw)
To: kernelnewbies
On Thu, 31 Mar 2016 14:59:51 -0230, Roger H Newell said:
> I reverted the previous change, and applied the if(f) test in
> file_free. There are no error messages in dmseg and I can mount the
> USB device.
That's because Nick's patch is *still* wrong, as the *real* problem
appears to be a memory corruption issue elsewhere. You don't see it
every mount because it only explodes if a new slab needs to be allocated
after the memory corruption has happened.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160331/de3ff823/attachment.bin
^ permalink raw reply [flat|nested] 13+ messages in thread
* Possible Bug
2016-03-31 18:16 ` Roger H Newell
@ 2016-03-31 19:23 ` Valdis.Kletnieks at vt.edu
2016-03-31 20:22 ` Roger H Newell
0 siblings, 1 reply; 13+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2016-03-31 19:23 UTC (permalink / raw)
To: kernelnewbies
On Thu, 31 Mar 2016 15:46:51 -0230, Roger H Newell said:
> I had a look inside the .config I used to compile this kernel.
> I think I found the information you're looking for.
>
> # CONFIG_KASAN is not set
> # CONFIG_SLAB is not set
> CONFIG_SLUB=y
> # CONFIG_SLOB is not set
Well, that cuts down on the amount of code that needs to be stared at.
I don't suppose we get extra-ordinarily lucky and the system was set up to
do crash dumps, was it?
I've spent a few more minutes looking at the relevant code, and the more I
stare at it, the more I understand why we see the same stack trace in varied
forums going back over a year - it looks like it only craps out if something
during resume or hotplug or similar processing stomps on memory, and the next
call to apparmor_file_alloc_security() has to allocate a new slab.
Or more correctly, it only dies with *this* traceback under those conditions.
If something else is next up to allocate a slab, it gets a different traceback.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160331/eb62ce61/attachment.bin
^ permalink raw reply [flat|nested] 13+ messages in thread
* Possible Bug
2016-03-31 19:23 ` Valdis.Kletnieks at vt.edu
@ 2016-03-31 20:22 ` Roger H Newell
[not found] ` <56FDD8D9.9010408@gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: Roger H Newell @ 2016-03-31 20:22 UTC (permalink / raw)
To: kernelnewbies
On Thu, Mar 31, 2016 at 4:53 PM, <Valdis.Kletnieks@vt.edu> wrote:
> On Thu, 31 Mar 2016 15:46:51 -0230, Roger H Newell said:
>
>> I had a look inside the .config I used to compile this kernel.
>> I think I found the information you're looking for.
>>
>> # CONFIG_KASAN is not set
>> # CONFIG_SLAB is not set
>> CONFIG_SLUB=y
>> # CONFIG_SLOB is not set
>
> Well, that cuts down on the amount of code that needs to be stared at.
>
> I don't suppose we get extra-ordinarily lucky and the system was set up to
> do crash dumps, was it?
>
> I've spent a few more minutes looking at the relevant code, and the more I
> stare at it, the more I understand why we see the same stack trace in varied
> forums going back over a year - it looks like it only craps out if something
> during resume or hotplug or similar processing stomps on memory, and the next
> call to apparmor_file_alloc_security() has to allocate a new slab.
>
> Or more correctly, it only dies with *this* traceback under those conditions.
> If something else is next up to allocate a slab, it gets a different traceback.
>
>
No it wasn't. There is a file
/var/crash/linux-image-4.5.0+.267545.crash. However, its basically the
same output that I pasted from dmesg. I've included it anyway in case
there are some hints in it.
ProblemType: KernelOops
Annotation: Your system might become unstable now and might need to be
restarted.
Date: Thu Mar 31 12:29:19 2016
Failure: oops
OopsText:
[961778.803501] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000805
[961778.809728] IP: [<ffffffff811e636b>] kmem_cache_alloc_trace+0x7b/0x1e0
[961778.815943] PGD cea04067 PUD abb59067 PMD 0
[961778.822149] Oops: 0000 [#3] SMP
[961778.828328] Modules linked in: binfmt_misc snd_hda_codec_realtek
snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec
snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event
snd_rawmidi snd_seq snd_seq_device snd_timer edac_mce_amd snd joydev
kvm_amd input_leds edac_core kvm soundcore serio_raw k10temp i2c_piix4
8250_fintek asus_atk0110 mac_hid irqbypass parport_pc ppdev lp parport
autofs4 pata_acpi hid_generic usbhid hid amdkfd amd_iommu_v2 radeon
i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt
fb_sys_fops drm psmouse ahci pata_atiixp libahci r8169 mii wmi
[961778.849223] CPU: 2 PID: 23118 Comm: sign-file Tainted: G D
4.5.0+ #28
[961778.856339] Hardware name: System manufacturer System Product
Name/M5A78L-M LX PLUS, BIOS 0402 09/20/2011
[961778.863557] task: ffff88003dbdc100 ti: ffff88009ae3c000 task.ti:
ffff88009ae3c000
[961778.870811] RIP: 0010:[<ffffffff811e636b>] [<ffffffff811e636b>]
kmem_cache_alloc_trace+0x7b/0x1e0
[961778.878175] RSP: 0018:ffff88009ae3fc70 EFLAGS: 00010206
[961778.885522] RAX: 0000000000000000 RBX: 00000000024080c0 RCX:
000000000bd44541
[961778.892949] RDX: 000000000bd44540 RSI: 00000000024080c0 RDI:
0000000000019b20
[961778.900361] RBP: ffff88009ae3fcb0 R08: ffff88012fc99b20 R09:
ffff88012b003cc0
[961778.907810] R10: 0000000000000805 R11: fefefefefefefeff R12:
00000000024080c0
[961778.915294] R13: ffffffff813736d3 R14: 00007f9b2ac8c040 R15:
ffff88012b003cc0
[961778.922812] FS: 00007f8546f0a700(0000) GS:ffff88012fc80000(0000)
knlGS:0000000000000000
[961778.930405] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[961778.937994] CR2: 0000000000000805 CR3: 00000000b9cdc000 CR4:
00000000000006e0
[961778.945445] Stack:
[961778.952673] ffffffff81214fef ffff88009ae3fccc 0000000000000002
ffff880002c28700
[961778.960013] ffff880002c28700 ffff88009ae3fef4 00007f9b2ac8c040
ffff88009ae3fde0
[961778.967372] ffff88009ae3fcc8 ffffffff813736d3 ffffffff81c9fe80
ffff88009ae3fce8
[961778.974682] Call Trace:
[961778.981902] [<ffffffff81214fef>] ? lookup_fast+0x16f/0x320
[961778.989161] [<ffffffff813736d3>] apparmor_file_alloc_security+0x23/0x40
[961778.996452] [<ffffffff81335b53>] security_file_alloc+0x33/0x50
[961779.003495] [<ffffffff8120bb6a>] get_empty_filp+0x9a/0x1c0
[961779.010284] [<ffffffff812176ce>] path_openat+0x2e/0x1400
[961779.016817] [<ffffffff8121661a>] ? walk_component+0x3a/0x470
[961779.023241] [<ffffffff811dd0ee>] ? alloc_pages_vma+0xbe/0x240
[961779.029590] [<ffffffff8121a38e>] do_filp_open+0x7e/0xe0
[961779.035858] [<ffffffff81196d36>] ?
lru_cache_add_active_or_unevictable+0x36/0xb0
[961779.042118] [<ffffffff811b9163>] ? handle_mm_fault+0x1253/0x19e0
[961779.048323] [<ffffffff811e629a>] ? kmem_cache_alloc+0x17a/0x1d0
[961779.054493] [<ffffffff81227606>] ? __alloc_fd+0x46/0x190
[961779.060674] [<ffffffff81208984>] do_sys_open+0x124/0x210
[961779.066821] [<ffffffff81208a8e>] SyS_open+0x1e/0x20
[961779.072981] [<ffffffff817ec736>] entry_SYSCALL_64_fastpath+0x1e/0xa8
[961779.079150] Code: 08 65 4c 03 05 3f 3e e2 7e 49 83 78 10 00 4d 8b
10 0f 84 14 01 00 00 4d 85 d2 0f 84 0b 01 00 00 49 63 41 20 48 8d 4a
01 49 8b 39 <49> 8b 1c 02 4c 89 d0 65 48 0f c7 0f 0f 94 c0 84 c0 74 bb
49 63
[961779.085893] RIP [<ffffffff811e636b>] kmem_cache_alloc_trace+0x7b/0x1e0
[961779.092359] RSP <ffff88009ae3fc70>
[961779.098773] CR2: 0000000000000805
[961779.105231] ---[ end trace e7adb7015192b3a5 ]---
Package: linux-image-4.5.0+ (not installed)
SourcePackage: linux
Tags: kernel-oops
Uname: Linux 4.5.0+ x86_64
^ permalink raw reply [flat|nested] 13+ messages in thread
* Possible Bug
[not found] ` <56FDD8D9.9010408@gmail.com>
@ 2016-04-01 13:00 ` Roger H Newell
0 siblings, 0 replies; 13+ messages in thread
From: Roger H Newell @ 2016-04-01 13:00 UTC (permalink / raw)
To: kernelnewbies
On Thu, Mar 31, 2016 at 11:41 PM, nick <xerofoify@gmail.com> wrote:
>
>
> On 2016-03-31 04:22 PM, Roger H Newell wrote:
>> On Thu, Mar 31, 2016 at 4:53 PM, <Valdis.Kletnieks@vt.edu> wrote:
>>> On Thu, 31 Mar 2016 15:46:51 -0230, Roger H Newell said:
>>>
>>>> I had a look inside the .config I used to compile this kernel.
>>>> I think I found the information you're looking for.
>>>>
>>>> # CONFIG_KASAN is not set
>>>> # CONFIG_SLAB is not set
>>>> CONFIG_SLUB=y
>>>> # CONFIG_SLOB is not set
>>>
>>> Well, that cuts down on the amount of code that needs to be stared at.
>>>
>>> I don't suppose we get extra-ordinarily lucky and the system was set up to
>>> do crash dumps, was it?
>>>
>>> I've spent a few more minutes looking at the relevant code, and the more I
>>> stare at it, the more I understand why we see the same stack trace in varied
>>> forums going back over a year - it looks like it only craps out if something
>>> during resume or hotplug or similar processing stomps on memory, and the next
>>> call to apparmor_file_alloc_security() has to allocate a new slab.
>>>
>>> Or more correctly, it only dies with *this* traceback under those conditions.
>>> If something else is next up to allocate a slab, it gets a different traceback.
>>>
>>>
>>
>> No it wasn't. There is a file
>> /var/crash/linux-image-4.5.0+.267545.crash. However, its basically the
>> same output that I pasted from dmesg. I've included it anyway in case
>> there are some hints in it.
>>
>> ProblemType: KernelOops
>> Annotation: Your system might become unstable now and might need to be
>> restarted.
>> Date: Thu Mar 31 12:29:19 2016
>> Failure: oops
>> OopsText:
>> [961778.803501] BUG: unable to handle kernel NULL pointer dereference
>> at 0000000000000805
>> [961778.809728] IP: [<ffffffff811e636b>] kmem_cache_alloc_trace+0x7b/0x1e0
>> [961778.815943] PGD cea04067 PUD abb59067 PMD 0
>> [961778.822149] Oops: 0000 [#3] SMP
>> [961778.828328] Modules linked in: binfmt_misc snd_hda_codec_realtek
>> snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec
>> snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event
>> snd_rawmidi snd_seq snd_seq_device snd_timer edac_mce_amd snd joydev
>> kvm_amd input_leds edac_core kvm soundcore serio_raw k10temp i2c_piix4
>> 8250_fintek asus_atk0110 mac_hid irqbypass parport_pc ppdev lp parport
>> autofs4 pata_acpi hid_generic usbhid hid amdkfd amd_iommu_v2 radeon
>> i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt
>> fb_sys_fops drm psmouse ahci pata_atiixp libahci r8169 mii wmi
>> [961778.849223] CPU: 2 PID: 23118 Comm: sign-file Tainted: G D
>> 4.5.0+ #28
>> [961778.856339] Hardware name: System manufacturer System Product
>> Name/M5A78L-M LX PLUS, BIOS 0402 09/20/2011
>> [961778.863557] task: ffff88003dbdc100 ti: ffff88009ae3c000 task.ti:
>> ffff88009ae3c000
>> [961778.870811] RIP: 0010:[<ffffffff811e636b>] [<ffffffff811e636b>]
>> kmem_cache_alloc_trace+0x7b/0x1e0
>> [961778.878175] RSP: 0018:ffff88009ae3fc70 EFLAGS: 00010206
>> [961778.885522] RAX: 0000000000000000 RBX: 00000000024080c0 RCX:
>> 000000000bd44541
>> [961778.892949] RDX: 000000000bd44540 RSI: 00000000024080c0 RDI:
>> 0000000000019b20
>> [961778.900361] RBP: ffff88009ae3fcb0 R08: ffff88012fc99b20 R09:
>> ffff88012b003cc0
>> [961778.907810] R10: 0000000000000805 R11: fefefefefefefeff R12:
>> 00000000024080c0
>> [961778.915294] R13: ffffffff813736d3 R14: 00007f9b2ac8c040 R15:
>> ffff88012b003cc0
>> [961778.922812] FS: 00007f8546f0a700(0000) GS:ffff88012fc80000(0000)
>> knlGS:0000000000000000
>> [961778.930405] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [961778.937994] CR2: 0000000000000805 CR3: 00000000b9cdc000 CR4:
>> 00000000000006e0
>> [961778.945445] Stack:
>> [961778.952673] ffffffff81214fef ffff88009ae3fccc 0000000000000002
>> ffff880002c28700
>> [961778.960013] ffff880002c28700 ffff88009ae3fef4 00007f9b2ac8c040
>> ffff88009ae3fde0
>> [961778.967372] ffff88009ae3fcc8 ffffffff813736d3 ffffffff81c9fe80
>> ffff88009ae3fce8
>> [961778.974682] Call Trace:
>> [961778.981902] [<ffffffff81214fef>] ? lookup_fast+0x16f/0x320
>> [961778.989161] [<ffffffff813736d3>] apparmor_file_alloc_security+0x23/0x40
>> [961778.996452] [<ffffffff81335b53>] security_file_alloc+0x33/0x50
>> [961779.003495] [<ffffffff8120bb6a>] get_empty_filp+0x9a/0x1c0
>> [961779.010284] [<ffffffff812176ce>] path_openat+0x2e/0x1400
>> [961779.016817] [<ffffffff8121661a>] ? walk_component+0x3a/0x470
>> [961779.023241] [<ffffffff811dd0ee>] ? alloc_pages_vma+0xbe/0x240
>> [961779.029590] [<ffffffff8121a38e>] do_filp_open+0x7e/0xe0
>> [961779.035858] [<ffffffff81196d36>] ?
>> lru_cache_add_active_or_unevictable+0x36/0xb0
>> [961779.042118] [<ffffffff811b9163>] ? handle_mm_fault+0x1253/0x19e0
>> [961779.048323] [<ffffffff811e629a>] ? kmem_cache_alloc+0x17a/0x1d0
>> [961779.054493] [<ffffffff81227606>] ? __alloc_fd+0x46/0x190
>> [961779.060674] [<ffffffff81208984>] do_sys_open+0x124/0x210
>> [961779.066821] [<ffffffff81208a8e>] SyS_open+0x1e/0x20
>> [961779.072981] [<ffffffff817ec736>] entry_SYSCALL_64_fastpath+0x1e/0xa8
>> [961779.079150] Code: 08 65 4c 03 05 3f 3e e2 7e 49 83 78 10 00 4d 8b
>> 10 0f 84 14 01 00 00 4d 85 d2 0f 84 0b 01 00 00 49 63 41 20 48 8d 4a
>> 01 49 8b 39 <49> 8b 1c 02 4c 89 d0 65 48 0f c7 0f 0f 94 c0 84 c0 74 bb
>> 49 63
>> [961779.085893] RIP [<ffffffff811e636b>] kmem_cache_alloc_trace+0x7b/0x1e0
>> [961779.092359] RSP <ffff88009ae3fc70>
>> [961779.098773] CR2: 0000000000000805
>> [961779.105231] ---[ end trace e7adb7015192b3a5 ]---
>>
>> Package: linux-image-4.5.0+ (not installed)
>> SourcePackage: linux
>> Tags: kernel-oops
>> Uname: Linux 4.5.0+ x86_64
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
> Roger,
> Are you able to accurately reproduce this error? If so I would very much like
> to see the output with KASAN enabled to see the actual memory regions being
> freed/allocated before the NULL deference.
> Nick
Nick:
No, I can't accurately reproduce the error. It doesn't happen every
time I plug in the USB stick, and it hasn't happened since the first
instance.
In terms of any further testing, you've had two shots at it already.
Frankly unless someone else can confirm you are on the right track, I
don't feel its a good use of my time to recompile and boot into my
kernel over and over. It was a fun ride at the time, but all rides
come to an end and this one ends here.
Best of luck:
Roger
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-04-01 13:00 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-31 12:34 Possible Bug Roger H Newell
2016-03-31 14:37 ` Valdis.Kletnieks at vt.edu
[not found] ` <56FD5089.5070302@canonical.com>
2016-03-31 17:52 ` Valdis.Kletnieks at vt.edu
2016-03-31 18:16 ` Roger H Newell
2016-03-31 19:23 ` Valdis.Kletnieks at vt.edu
2016-03-31 20:22 ` Roger H Newell
[not found] ` <56FDD8D9.9010408@gmail.com>
2016-04-01 13:00 ` Roger H Newell
[not found] ` <56FD38C4.8030201@gmail.com>
2016-03-31 15:08 ` Roger H Newell
[not found] ` <56FD4C35.5040301@gmail.com>
2016-03-31 16:25 ` Roger H Newell
2016-03-31 17:22 ` Valdis.Kletnieks at vt.edu
2016-03-31 16:30 ` Carlo Caione
[not found] ` <56FD5358.5010101@gmail.com>
2016-03-31 17:29 ` Roger H Newell
2016-03-31 18:42 ` Valdis.Kletnieks at vt.edu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).