Re: Possible Bug
On Thu, Mar 31, 2016 at 11:41 PM, nick wrote: > > > On 2016-03-31 04:22 PM, Roger H Newell wrote: >> On Thu, Mar 31, 2016 at 4:53 PM, 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 0805 >> [961778.809728] IP: [] kmem_cache_alloc_trace+0x7b/0x1e0 >> [961778.815943] PGD cea04067 PUD abb59067 PMD 0 >> [961778.822149] Oops: [#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 040209/20/2011 >> [961778.863557] task: 88003dbdc100 ti: 88009ae3c000 task.ti: >> 88009ae3c000 >> [961778.870811] RIP: 0010:[] [] >> kmem_cache_alloc_trace+0x7b/0x1e0 >> [961778.878175] RSP: 0018:88009ae3fc70 EFLAGS: 00010206 >> [961778.885522] RAX: RBX: 024080c0 RCX: >> 0bd44541 >> [961778.892949] RDX: 0bd44540 RSI: 024080c0 RDI: >> 00019b20 >> [961778.900361] RBP: 88009ae3fcb0 R08: 88012fc99b20 R09: >> 88012b003cc0 >> [961778.907810] R10: 0805 R11: fefefefefefefeff R12: >> 024080c0 >> [961778.915294] R13: 813736d3 R14: 7f9b2ac8c040 R15: >> 88012b003cc0 >> [961778.922812] FS: 7f8546f0a700() GS:88012fc8() >> knlGS: >> [961778.930405] CS: 0010 DS: ES: CR0: 80050033 >> [961778.937994] CR2: 0805 CR3: b9cdc000 CR4: >> 06e0 >> [961778.945445] Stack: >> [961778.952673] 81214fef 88009ae3fccc 0002 >> 880002c28700 >> [961778.960013] 880002c28700 88009ae3fef4 7f9b2ac8c040 >> 88009ae3fde0 >> [961778.967372] 88009ae3fcc8 813736d3 81c9fe80 >> 88009ae3fce8 >> [961778.974682] Call Trace: >> [961778.981902] [] ? lookup_fast+0x16f/0x320 >> [961778.989161] [] apparmor_file_alloc_security+0x23/0x40 >> [961778.996452] [] security_file_alloc+0x33/0x50 >> [961779.003495] [] get_empty_filp+0x9a/0x1c0 >> [961779.010284] [] path_openat+0x2e/0x1400 >> [961779.016817] [] ? walk_component+0x3a/0x470 >> [961779.023241] [] ? alloc_pages_vma+0xbe/0x240 >> [961779.029590] [] do_filp_open+0x7e/0xe0 >> [961779.035858] [] ? >> lru_cache_add_active_or_unevictable+0x36/0xb0 >> [961779.042118] [] ? handle_mm_fault+0x1253/0x19e0 >> [961779.048323] [] ? kmem_cache_alloc+0x17a/0x1d0 >> [961779.054493] [] ? __alloc_fd+0x46/0x190 >> [961779.060674] [] do_sys_open+0x124/0x210 >> [961779.066821] [] SyS_open+0x1e/0x20 >> [961779.072981] [] 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
Re: Possible Bug
On Thu, Mar 31, 2016 at 4:53 PM, 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 0805 [961778.809728] IP: [] kmem_cache_alloc_trace+0x7b/0x1e0 [961778.815943] PGD cea04067 PUD abb59067 PMD 0 [961778.822149] Oops: [#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 040209/20/2011 [961778.863557] task: 88003dbdc100 ti: 88009ae3c000 task.ti: 88009ae3c000 [961778.870811] RIP: 0010:[] [] kmem_cache_alloc_trace+0x7b/0x1e0 [961778.878175] RSP: 0018:88009ae3fc70 EFLAGS: 00010206 [961778.885522] RAX: RBX: 024080c0 RCX: 0bd44541 [961778.892949] RDX: 0bd44540 RSI: 024080c0 RDI: 00019b20 [961778.900361] RBP: 88009ae3fcb0 R08: 88012fc99b20 R09: 88012b003cc0 [961778.907810] R10: 0805 R11: fefefefefefefeff R12: 024080c0 [961778.915294] R13: 813736d3 R14: 7f9b2ac8c040 R15: 88012b003cc0 [961778.922812] FS: 7f8546f0a700() GS:88012fc8() knlGS: [961778.930405] CS: 0010 DS: ES: CR0: 80050033 [961778.937994] CR2: 0805 CR3: b9cdc000 CR4: 06e0 [961778.945445] Stack: [961778.952673] 81214fef 88009ae3fccc 0002 880002c28700 [961778.960013] 880002c28700 88009ae3fef4 7f9b2ac8c040 88009ae3fde0 [961778.967372] 88009ae3fcc8 813736d3 81c9fe80 88009ae3fce8 [961778.974682] Call Trace: [961778.981902] [] ? lookup_fast+0x16f/0x320 [961778.989161] [] apparmor_file_alloc_security+0x23/0x40 [961778.996452] [] security_file_alloc+0x33/0x50 [961779.003495] [] get_empty_filp+0x9a/0x1c0 [961779.010284] [] path_openat+0x2e/0x1400 [961779.016817] [] ? walk_component+0x3a/0x470 [961779.023241] [] ? alloc_pages_vma+0xbe/0x240 [961779.029590] [] do_filp_open+0x7e/0xe0 [961779.035858] [] ? lru_cache_add_active_or_unevictable+0x36/0xb0 [961779.042118] [] ? handle_mm_fault+0x1253/0x19e0 [961779.048323] [] ? kmem_cache_alloc+0x17a/0x1d0 [961779.054493] [] ? __alloc_fd+0x46/0x190 [961779.060674] [] do_sys_open+0x124/0x210 [961779.066821] [] SyS_open+0x1e/0x20 [961779.072981] [] 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 [] kmem_cache_alloc_trace+0x7b/0x1e0 [961779.092359] RSP [961779.098773] CR2: 0805 [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 Kernel
Re: Possible Bug
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. pgpNvJVw7RCqG.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Possible Bug
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. pgpO9c7A3KHyz.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Possible Bug
On Thu, Mar 31, 2016 at 3:22 PM, 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: [] 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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Possible Bug
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: [] 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) pgphJuVx5TEcc.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Possible Bug
On Thu, Mar 31, 2016 at 2:12 PM, nick wrote: > > > On 2016-03-31 12:30 PM, Carlo Caione wrote: >> On Thu, Mar 31, 2016 at 5:08 PM, Roger H Newell >> wrote: >>> On Thu, Mar 31, 2016 at 12:18 PM, nick 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. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Possible Bug
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. pgpdF1QME74wj.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Possible Bug
On Thu, Mar 31, 2016 at 5:08 PM, Roger H Newell wrote: > On Thu, Mar 31, 2016 at 12:18 PM, nick 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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Possible Bug
On Thu, Mar 31, 2016 at 1:41 PM, nick wrote: > > > On 2016-03-31 11:08 AM, Roger H Newell wrote: >> On Thu, Mar 31, 2016 at 12:18 PM, nick 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 0805 [952620.397309] IP: [] kmem_cache_alloc_trace+0x7b/0x1e0 [952620.397427] PGD 3db56067 PUD cb6cd067 PMD 0 [952620.397511] Oops: [#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 040209/20/2011 [952620.398884] task: 88009bf68d00 ti: 8800499f task.ti: 8800499f [952620.399006] RIP: 0010:[] [] kmem_cache_alloc_trace+0x7b/0x1e0 [952620.399158] RSP: 0018:8800499f3c70 EFLAGS: 00010206 [952620.399246] RAX: RBX: 024080c0 RCX: 0ae98088 [952620.399362] RDX: 0ae98087 RSI: 024080c0 RDI: 00019b20 [952620.399477] RBP: 8800499f3cb0 R08: 88012fc59b20 R09: 88012b003cc0 [952620.399593] R10: 0805 R11: fefefefefefefeff R12: 024080c0 [952620.399709] R13: 813736d3 R14: 7f9bfa435040 R15: 88012b003cc0 [952620.399826] FS: 7f550c9a48c0() GS:88012fc4() knlGS: [952620.399956] CS: 0010 DS: ES: CR0: 80050033 [952620.400050] CR2: 0805 CR3: ce839000 CR4: 06e0 [952620.400165] Stack: [952620.400201] 024080c0 8120bb2c 0002 88000227d500 [952620.400335] 88000227d500 8800499f3ef4 7f9bfa435040 8800499f3de0 [952620.400467] 8800499f3cc8 813736d3 81c9fe80 8800499f3ce8 [952620.400599] Call Trace: [952620.400649] [] ? get_empty_filp+0x5c/0x1c0 [952620.400748] [] apparmor_file_alloc_security+0x23/0x40 [952620.400861] [] security_file_alloc+0x33/0x50 [952620.400961] [] get_empty_filp+0x9a/0x1c0 [952620.401057] [] path_openat+0x2e/0x1400 [952620.401149] [] ? walk_component+0x3a/0x470 [952620.401246] [] ? path_init+0x1d9/0x330 [952620.401339] [] ? __inc_zone_page_state+0x35/0x40 [952620.401444] [] ? putname+0x54/0x60 [952620.401530] [] do_filp_open+0x7e/0xe0 [952620.401620] [] ? kmem_cache_alloc_trace+0x1c5/0x1e0 [952620.401728] [] ? kmem_cache_alloc+0x17a/0x1d0 [952620.401829] [] ? getname_flags+0x56/0x1f0 [952620.401924] [] ? __alloc_fd+0x46/0x190 [952620.402016] [] do_sys_open+0x124/0x210 [952620.402107] [] ? SyS_access+0x1e8/0x230 [952620.402200] [] SyS_open+0x1e/0x20 [952620.402286] [] 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 [] kmem_cache_alloc_trace+0x7b/0x1e0 [952620.403047] RSP [952620.403106] CR2: 0805 [952620.445606] ---[ end trace e7adb7015192b3a3 ]--- ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org
Re: Possible Bug
On Thu, Mar 31, 2016 at 12:18 PM, nick 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 0805 >> [952620.397309] IP: [] kmem_cache_alloc_trace+0x7b/0x1e0 >> [952620.397427] PGD 3db56067 PUD cb6cd067 PMD 0 >> [952620.397511] Oops: [#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 040209/20/2011 >> [952620.398884] task: 88009bf68d00 ti: 8800499f task.ti: >> 8800499f >> [952620.399006] RIP: 0010:[] [] >> kmem_cache_alloc_trace+0x7b/0x1e0 >> [952620.399158] RSP: 0018:8800499f3c70 EFLAGS: 00010206 >> [952620.399246] RAX: RBX: 024080c0 RCX: >> 0ae98088 >> [952620.399362] RDX: 0ae98087 RSI: 024080c0 RDI: >> 00019b20 >> [952620.399477] RBP: 8800499f3cb0 R08: 88012fc59b20 R09: >> 88012b003cc0 >> [952620.399593] R10: 0805 R11: fefefefefefefeff R12: >> 024080c0 >> [952620.399709] R13: 813736d3 R14: 7f9bfa435040 R15: >> 88012b003cc0 >> [952620.399826] FS: 7f550c9a48c0() GS:88012fc4() >> knlGS: >> [952620.399956] CS: 0010 DS: ES: CR0: 80050033 >> [952620.400050] CR2: 0805 CR3: ce839000 CR4: >> 06e0 >> [952620.400165] Stack: >> [952620.400201] 024080c0 8120bb2c 0002 >> 88000227d500 >> [952620.400335] 88000227d500 8800499f3ef4 7f9bfa435040 >> 8800499f3de0 >> [952620.400467] 8800499f3cc8 813736d3 81c9fe80 >> 8800499f3ce8 >> [952620.400599] Call Trace: >> [952620.400649] [] ? get_empty_filp+0x5c/0x1c0 >> [952620.400748] [] apparmor_file_alloc_security+0x23/0x40 >> [952620.400861] [] security_file_alloc+0x33/0x50 >> [952620.400961] [] get_empty_filp+0x9a/0x1c0 >> [952620.401057] [] path_openat+0x2e/0x1400 >> [952620.401149] [] ? walk_component+0x3a/0x470 >> [952620.401246] [] ? path_init+0x1d9/0x330 >> [952620.401339] [] ? __inc_zone_page_state+0x35/0x40 >> [952620.401444] [] ? putname+0x54/0x60 >> [952620.401530] [] do_filp_open+0x7e/0xe0 >> [952620.401620] [] ? kmem_cache_alloc_trace+0x1c5/0x1e0 >> [952620.401728] [] ? kmem_cache_alloc+0x17a/0x1d0 >> [952620.401829] [] ? getname_flags+0x56/0x1f0 >> [952620.401924] [] ? __alloc_fd+0x46/0x190 >> [952620.402016] [] do_sys_open+0x124/0x210 >> [952620.402107] [] ? SyS_access+0x1e8/0x230 >> [952620.402200] [] SyS_open+0x1e/0x20 >> [952620.402286] [] 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 [] kmem_cache_alloc_trace+0x7b/0x1e0 >> [952620.403047] RSP >> [952620.403106] CR2: 0805 >> [952620.445606] ---[ end trace e7adb7015192b3a3 ]--- >> >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@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(
Re: Possible Bug
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 > 0805 > [952620.397309] IP: [] kmem_cache_alloc_trace+0x7b/0x1e0 > [952620.397427] PGD 3db56067 PUD cb6cd067 PMD 0 > [952620.397511] Oops: [#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 040209/20/2011 > [952620.398884] task: 88009bf68d00 ti: 8800499f task.ti: > 8800499f > [952620.399006] RIP: 0010:[] [] > kmem_cache_alloc_trace+0x7b/0x1e0 > [952620.399158] RSP: 0018:8800499f3c70 EFLAGS: 00010206 > [952620.399246] RAX: RBX: 024080c0 RCX: > 0ae98088 > [952620.399362] RDX: 0ae98087 RSI: 024080c0 RDI: > 00019b20 > [952620.399477] RBP: 8800499f3cb0 R08: 88012fc59b20 R09: > 88012b003cc0 > [952620.399593] R10: 0805 R11: fefefefefefefeff R12: > 024080c0 > [952620.399709] R13: 813736d3 R14: 7f9bfa435040 R15: > 88012b003cc0 > [952620.399826] FS: 7f550c9a48c0() GS:88012fc4() > knlGS: > [952620.399956] CS: 0010 DS: ES: CR0: 80050033 > [952620.400050] CR2: 0805 CR3: ce839000 CR4: > 06e0 > [952620.400165] Stack: > [952620.400201] 024080c0 8120bb2c 0002 > 88000227d500 > [952620.400335] 88000227d500 8800499f3ef4 7f9bfa435040 > 8800499f3de0 > [952620.400467] 8800499f3cc8 813736d3 81c9fe80 > 8800499f3ce8 > [952620.400599] Call Trace: > [952620.400649] [] ? get_empty_filp+0x5c/0x1c0 > [952620.400748] [] apparmor_file_alloc_security+0x23/0x40 > [952620.400861] [] security_file_alloc+0x33/0x50 > [952620.400961] [] get_empty_filp+0x9a/0x1c0 > [952620.401057] [] path_openat+0x2e/0x1400 > [952620.401149] [] ? walk_component+0x3a/0x470 > [952620.401246] [] ? path_init+0x1d9/0x330 > [952620.401339] [] ? __inc_zone_page_state+0x35/0x40 > [952620.401444] [] ? putname+0x54/0x60 > [952620.401530] [] do_filp_open+0x7e/0xe0 > [952620.401620] [] ? kmem_cache_alloc_trace+0x1c5/0x1e0 > [952620.401728] [] ? kmem_cache_alloc+0x17a/0x1d0 > [952620.401829] [] ? getname_flags+0x56/0x1f0 > [952620.401924] [] ? __alloc_fd+0x46/0x190 > [952620.402016] [] do_sys_open+0x124/0x210 > [952620.402107] [] ? SyS_access+0x1e8/0x230 > [952620.402200] [] SyS_open+0x1e/0x20 > [952620.402286] [] 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 [] kmem_cache_alloc_trace+0x7b/0x1e0 > [952620.403047] RSP > [952620.403106] CR2: 0805 > [952620.445606] ---[ end trace e7adb7015192b3a3 ]--- pgpbVCsq_vX0I.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelne
Possible Bug
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 0805 [952620.397309] IP: [] kmem_cache_alloc_trace+0x7b/0x1e0 [952620.397427] PGD 3db56067 PUD cb6cd067 PMD 0 [952620.397511] Oops: [#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 040209/20/2011 [952620.398884] task: 88009bf68d00 ti: 8800499f task.ti: 8800499f [952620.399006] RIP: 0010:[] [] kmem_cache_alloc_trace+0x7b/0x1e0 [952620.399158] RSP: 0018:8800499f3c70 EFLAGS: 00010206 [952620.399246] RAX: RBX: 024080c0 RCX: 0ae98088 [952620.399362] RDX: 0ae98087 RSI: 024080c0 RDI: 00019b20 [952620.399477] RBP: 8800499f3cb0 R08: 88012fc59b20 R09: 88012b003cc0 [952620.399593] R10: 0805 R11: fefefefefefefeff R12: 024080c0 [952620.399709] R13: 813736d3 R14: 7f9bfa435040 R15: 88012b003cc0 [952620.399826] FS: 7f550c9a48c0() GS:88012fc4() knlGS: [952620.399956] CS: 0010 DS: ES: CR0: 80050033 [952620.400050] CR2: 0805 CR3: ce839000 CR4: 06e0 [952620.400165] Stack: [952620.400201] 024080c0 8120bb2c 0002 88000227d500 [952620.400335] 88000227d500 8800499f3ef4 7f9bfa435040 8800499f3de0 [952620.400467] 8800499f3cc8 813736d3 81c9fe80 8800499f3ce8 [952620.400599] Call Trace: [952620.400649] [] ? get_empty_filp+0x5c/0x1c0 [952620.400748] [] apparmor_file_alloc_security+0x23/0x40 [952620.400861] [] security_file_alloc+0x33/0x50 [952620.400961] [] get_empty_filp+0x9a/0x1c0 [952620.401057] [] path_openat+0x2e/0x1400 [952620.401149] [] ? walk_component+0x3a/0x470 [952620.401246] [] ? path_init+0x1d9/0x330 [952620.401339] [] ? __inc_zone_page_state+0x35/0x40 [952620.401444] [] ? putname+0x54/0x60 [952620.401530] [] do_filp_open+0x7e/0xe0 [952620.401620] [] ? kmem_cache_alloc_trace+0x1c5/0x1e0 [952620.401728] [] ? kmem_cache_alloc+0x17a/0x1d0 [952620.401829] [] ? getname_flags+0x56/0x1f0 [952620.401924] [] ? __alloc_fd+0x46/0x190 [952620.402016] [] do_sys_open+0x124/0x210 [952620.402107] [] ? SyS_access+0x1e8/0x230 [952620.402200] [] SyS_open+0x1e/0x20 [952620.402286] [] 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 [] kmem_cache_alloc_trace+0x7b/0x1e0 [952620.403047] RSP [952620.403106] CR2: 0805 [952620.445606] ---[ end trace e7adb7015192b3a3 ]--- ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies