Re: Possible Bug

[Roger H Newell]

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 

Re: Possible Bug

[Roger H Newell]

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

___

Re: Possible Bug

[Valdis . Kletnieks]

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

[Valdis . Kletnieks]

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

[Roger H Newell]

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

[Valdis . Kletnieks]

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

[Roger H Newell]

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(_files);
>  if (f)
> call_rcu(>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

[Valdis . Kletnieks]

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

[Carlo Caione]

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

[Roger H Newell]

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

Re: Possible Bug

[Roger H Newell]

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);
>

Re: Possible Bug

[Valdis . Kletnieks]

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