Possible bug

Possible bug

[ml-raid]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

Hello,
I have a 2.6.27.29-4-grsec (from http://kernelsec.cr0.org) Linux box, on
x86, running debian lenny. On sunday, during the monthly rebuild of my
standard RAID1 setup (/proc/mdstat):

Personalities : [raid1]
md127 : active raid1 sda1[0] sdb1[1]
      488383936 blocks [2/2] [UU]

unused devices: <none>

The kernel started outputting thousands of backtraces (see attached log)
The IO throughput was drastically reduced but the resync finally
completed after about 38 hours.

This is the first time I have been bitten by this bug. The server has
been running on this kernel for 74 days and the previous resync didn't
exhibit any problem.

Unfortunately, the machine being used in production, I will probably not
be able to test possible fixes easily.

Regards,
Raphaël

[-- Attachment #2: logall --]
[-- Type: text/plain, Size: 4764 bytes --]

 kernel: [6275442.463023] PAX: refcount overflow detected in: md127_resync:28139, uid/euid: 0/0                                                            
 kernel: [6275442.463076] PAX: refcount overflow occured at: sync_request+0x63f/0x720 [raid1]                                                              
 kernel: [6275442.463108] Modules linked in: i2c_dev usbhid hid ip6table_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables ipv6 aes_i586 aes_generic cbc dm_crypt crypto_blkcipher loop evdev i2c_i801 i2c_core pcspkr button intel_agp agpgart shpchp pci_hotplug ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod raid1 md_mod sd_mod ata_generic ata_piix piix libata scsi_mod dock ide_pci_generic ehci_hcd floppy uhci_hcd e1000 usbcore thermal processor fan [last unloaded: scsi_wait_scan]                                                                                                                                                   
 kernel: [6275442.463383]                                                                                                                                  
 kernel: [6275442.463402] Pid: 28139, comm: md127_resync Not tainted (2.6.27.29-4-grsec #1)                                                                
 kernel: [6275442.463435] EIP: 0060:[<f893bfff>] EFLAGS: 00000a02 CPU: 0                                                                                   
 kernel: [6275442.463462] EIP is at sync_request+0x63f/0x720 [raid1]                                                                                       
 kernel: [6275442.463483] EAX: c3d61000 EBX: 00000000 ECX: 00000080 EDX: f7189100                                                                          
 kernel: [6275442.463505] ESI: 00000000 EDI: c16e9d40 EBP: f74c3480 ESP: c2403e70                                                                          
 kernel: [6275442.463528]  DS: 0068 ES: 0068 FS: 00d8 GS: 0000 SS: 0068                                                                                    
 kernel: [6275442.463550] Process md127_resync (pid: 28139, ti=c2402000 task=f77620b0 task.ti=c2402000)                                                    
 kernel: [6275442.463576] Stack: 00000000 00000000 11219a78 00000000 c3d6b800 f7000d80 3a384b80 00000000                                                   
 kernel: [6275442.463629]        00000080 00000000 00000000 ffffffff 00000001 00000002 00000000 00001000                                                   
 kernel: [6275442.463683]        00000380 11219a00 00000000 f893b9c0 00000408 f8986168 c2403f98 00000000                                                   
 kernel: [6275442.463738] Call Trace:                                                                                                                      
 kernel: [6275442.463769]  [<f893b9c0>] sync_request+0x0/0x720 [raid1]                                                                                     
 kernel: [6275442.463800]  [<f8986168>] md_do_sync+0x958/0xd80 [md_mod]                                                                                    
 kernel: [6275442.463836]  [<f8989837>] __param_str_start_ro+0x436/0x1ea7 [md_mod]                                                                         
 kernel: [6275442.463873]  [<f8985730>] md_thread+0x0/0xe0 [md_mod]                                                                                        
 kernel: [6275442.463908]  [<f8985752>] md_thread+0x22/0xe0 [md_mod]                                                                                       
 kernel: [6275442.463941]  [<f8985730>] md_thread+0x0/0xe0 [md_mod]                                                                                        
 kernel: [6275442.463973]  [<c0438572>] kthread+0x42/0x70                                                                                                  
 kernel: [6275442.463999]  [<c0438530>] kthread+0x0/0x70                                                                                                   
 kernel: [6275442.464020]  [<c0404fe7>] kernel_thread_helper+0x7/0x10                                                                                      
 kernel: [6275442.464046]  =======================                                                                                                         
 kernel: [6275442.464064] Code: 2b 5c 24 08 1b 74 24 0c e9 ca fc ff ff 8b 42 0c 8b 4c 24 20 8b 40 44 8b 40 58 f0 01 88 90 01 00 00 71 08 f0 29 88 90 01 00 00 ce <89> d0 e8 6a 78 bb c7 8b 54 24 14 8b 42 08 e9 8b fe ff ff 8b 40                                                                                                           

Re: Possible bug

[Neil Brown]

On Tue, 08 Dec 2009 14:18:24 +0100
ml-raid@syscall.eu wrote:

> Hello,
> I have a 2.6.27.29-4-grsec (from http://kernelsec.cr0.org) Linux box, on
> x86, running debian lenny. On sunday, during the monthly rebuild of my
> standard RAID1 setup (/proc/mdstat):
> 
> Personalities : [raid1]
> md127 : active raid1 sda1[0] sdb1[1]
>       488383936 blocks [2/2] [UU]
> 
> unused devices: <none>
> 
> The kernel started outputting thousands of backtraces (see attached log)
> The IO throughput was drastically reduced but the resync finally
> completed after about 38 hours.
> 
> This is the first time I have been bitten by this bug. The server has
> been running on this kernel for 74 days and the previous resync didn't
> exhibit any problem.

This is not a RAID problem - it was a problem with the grsec patches.
They assume that any atomic variable is used as a counter and should not
overflow.  That is not the case with bd_disk->sync_io.  It is expected to
overflow.  So the "PAX: ..." report is a false positive.

NeilBrown

Re: Possible bug

[ml-raid]

Neil Brown wrote:
> This is not a RAID problem - it was a problem with the grsec patches.
> They assume that any atomic variable is used as a counter and should not
> overflow.  That is not the case with bd_disk->sync_io.  It is expected to
> overflow.  So the "PAX: ..." report is a false positive.
> 
Thank you,
i've reported the bug to the grsec guys.

Regards,
Raphaël
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Possible bug

[David Kiarie]

Hello all,

There seems to a problem with the parsing of IVMD blocks in IVRS in
linux kernel AMD IOMMU driver.

The current code seems to assume that IVHD and IVMD blocks cannot
occur on the same IVRS table. From what I can see, ends up coming up
with IVMD blocks while none are specified in IVRS hence coming up with
fake unity mappings/exclusion regions. Here is the relevant code:

    ret = init_iommu_all(ivrs_base);
    if (ret)
        goto out;

    if (amd_iommu_irq_remap)
        amd_iommu_irq_remap = check_ioapic_information();

    if (amd_iommu_irq_remap) {
        /*
         * Interrupt remapping enabled, create kmem_cache for the
         * remapping tables.
         */
        ret = -ENOMEM;
        amd_iommu_irq_cache = kmem_cache_create("irq_remap_cache",
                MAX_IRQS_PER_TABLE * sizeof(u32),
                IRQ_TABLE_ALIGNMENT,
                0, NULL);
        if (!amd_iommu_irq_cache)
            goto out;

        irq_lookup_table = (void *)__get_free_pages(
                GFP_KERNEL | __GFP_ZERO,
                get_order(rlookup_table_size));
        if (!irq_lookup_table)
            goto out;
    }

    ret = init_memory_definitions(ivrs_base);
    if (ret)
        goto out;


And in 'init_memory_definitions', it's assumed there were no IVHD
entries in the IVRS by starting to parse for IVMD entries immediately
after the end of IVRS header.

   /* iterates over all memory definitions we find in the ACPI table */
static int __init init_memory_definitions(struct acpi_table_header *table)
{
    u8 *p = (u8 *)table, *end = (u8 *)table;
    struct ivmd_header *m;

    end += table->length;
    p += IVRS_HEADER_LENGTH;

    while (p < end) {
        m = (struct ivmd_header *)p;
        if (m->flags & IVMD_FLAG_EXCL_RANGE)
            init_exclusion_range(m);
        else if (m->flags & IVMD_FLAG_UNITY_MAP)
            init_unity_map_range(m);

        p += m->length;
    }

    return 0;
}

Re: Possible bug

[David Kiarie]

Meh, I just noted that myself, it defaults to not setting any
exclusion/unity-mapping regions since the IVHD/IVMD types do not
match.


On Sat, May 7, 2016 at 11:21 AM, Wan Zongshun <vw-6ukY98dZOFrYtjvyW6yDsg@public.gmane.org> wrote:
>
>
> -------- Original Message --------
>>
>> Hello all,
>>
>> There seems to a problem with the parsing of IVMD blocks in IVRS in
>> linux kernel AMD IOMMU driver.
>>
>> The current code seems to assume that IVHD and IVMD blocks cannot
>> occur on the same IVRS table. From what I can see, ends up coming up
>> with IVMD blocks while none are specified in IVRS hence coming up with
>> fake unity mappings/exclusion regions. Here is the relevant code:
>>
>>     ret = init_iommu_all(ivrs_base);
>>     if (ret)
>>         goto out;
>>
>>     if (amd_iommu_irq_remap)
>>         amd_iommu_irq_remap = check_ioapic_information();
>>
>>     if (amd_iommu_irq_remap) {
>>         /*
>>          * Interrupt remapping enabled, create kmem_cache for the
>>          * remapping tables.
>>          */
>>         ret = -ENOMEM;
>>         amd_iommu_irq_cache = kmem_cache_create("irq_remap_cache",
>>                 MAX_IRQS_PER_TABLE * sizeof(u32),
>>                 IRQ_TABLE_ALIGNMENT,
>>                 0, NULL);
>>         if (!amd_iommu_irq_cache)
>>             goto out;
>>
>>         irq_lookup_table = (void *)__get_free_pages(
>>                 GFP_KERNEL | __GFP_ZERO,
>>                 get_order(rlookup_table_size));
>>         if (!irq_lookup_table)
>>             goto out;
>>     }
>>
>>     ret = init_memory_definitions(ivrs_base);
>>     if (ret)
>>         goto out;
>>
>>
>> And in 'init_memory_definitions', it's assumed there were no IVHD
>> entries in the IVRS by starting to parse for IVMD entries immediately
>> after the end of IVRS header.
>>
>>    /* iterates over all memory definitions we find in the ACPI table */
>> static int __init init_memory_definitions(struct acpi_table_header *table)
>> {
>>     u8 *p = (u8 *)table, *end = (u8 *)table;
>>     struct ivmd_header *m;
>>
>>     end += table->length;
>>     p += IVRS_HEADER_LENGTH;
>>
>>     while (p < end) {
>>         m = (struct ivmd_header *)p;
>>         if (m->flags & IVMD_FLAG_EXCL_RANGE)
>>             init_exclusion_range(m);
>>         else if (m->flags & IVMD_FLAG_UNITY_MAP)
>>             init_unity_map_range(m);
>>
>>         p += m->length;
>>     }
>
>
>
> David,
>
> it maybe not a bug.
>
> This piece of code utilized a trick method to search the IVMD entry, if you
> check AMD IOMMU spec, you can find there are same offsets in type, flag and
> length fields of IVMD and IVHD header.
>
> Even we met one IVHD entry here, we also can do nothing and exit normally in
> 'init_exclusion_range' and 'init_unity_map_range', and then add a meaningful
> 'm->length'(here, it points IVHD entry length) to find the next entry until
> IVHD entry was found.
>
> Vincent Wan.
>
>>
>>     return 0;
>> }
>> _______________________________________________
>> iommu mailing list
>> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>>
>

Possible Bug

[Roger H Newell]

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 ]---

Possible Bug

[Valdis.Kletnieks at vt.edu]

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 

Possible Bug

[Valdis.Kletnieks at vt.edu]

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 

Possible Bug

[Roger H Newell]

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

Possible Bug

[Valdis.Kletnieks at vt.edu]

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 

Possible Bug

[Roger H Newell]

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

Possible Bug

[Roger H Newell]

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

Possible Bug

[Roger H Newell]

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

Possible Bug

[Roger H Newell]

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>

Possible Bug

[Valdis.Kletnieks at vt.edu]

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 

Possible Bug

[Carlo Caione]

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

Possible Bug

[Roger H Newell]

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.

Possible Bug

[Valdis.Kletnieks at vt.edu]

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 

Possible bug

[Ariel Norberto Bellino]

[-- Attachment #1: Type: text/plain, Size: 1608 bytes --]

Hi.

I'm not sure if this is a bug, but I couldn't find any useful information,
so here I write. Hope it's not a problem.

cpufreq-info shows this in my laptop:
hardware limits: 800 MHz - 2.53 GHz
available frequency steps: *2.53 GHz, 2.53 GHz*, 1.60 GHz, 800 MHz

As you can see, the maximum frequency is shown twice. I searched for that,
but only found non-related bug reports in which people notice the
duplicated frequency. So it is a relatively common issue. But I couldn't
find a bug report for this, specifically.

I also have a KDE widget that shows the processor frequency. It shows it
in green when at the lowest possible, in red when at the max frequency,
and in yellow when at an intermediate state. If I switch to conservative
governor and put the processor under load, I see the frequency raising
from 800 MHz (green) to 1.60 GHz (yellow), then 2.53 GHz (yellow again)
then 2.53 HGz (now red) so it seems to be effectively switching between
two different 
states with the same frequency. Although not serious, I think frequent
switching between the same frequencies may degrade performance.

I recently upgraded my processor from a T5800 to a T9400, and made no
software change. cpufreq-info didn't show twice the greatest frequency
with the former processor, this issue started as soon as I replaced it.

Attached: complete output of cpufreq-info, complete hardware info.
I'm running kubuntu 12.04, kernel 3.2.0-26-generic-pae


Thanks for your time (reading, and coding things like cpufreq). I really
appretiate your work.
And forgive my english, it's not my native language.

Regards,
Ariel

[-- Attachment #2: info.tar.gz --]
[-- Type: application/gzip, Size: 5096 bytes --]

Re: Possible bug

[Thomas Renninger]

On Saturday, July 21, 2012 09:09:08 AM Ariel Norberto Bellino wrote:
> Hi.
> 
> I'm not sure if this is a bug, but I couldn't find any useful information,
> so here I write. Hope it's not a problem.
> 
> cpufreq-info shows this in my laptop:
> hardware limits: 800 MHz - 2.53 GHz
> available frequency steps: *2.53 GHz, 2.53 GHz*, 1.60 GHz, 800 MHz
This should be a typical and well-known BIOS setup.
For some reason some BIOSes export the highest frequency twice (or with
one HZ difference or similar). Linux kernel should be able to handle this
gracefully. This is nothing to worry about.

  Thomas

Re: Possible bug

[Jukka Ruohonen]

On Tue, Jul 24, 2012 at 02:01:53PM +0200, Thomas Renninger wrote:
> On Saturday, July 21, 2012 09:09:08 AM Ariel Norberto Bellino wrote:
> > cpufreq-info shows this in my laptop:
> > hardware limits: 800 MHz - 2.53 GHz
> > available frequency steps: *2.53 GHz, 2.53 GHz*, 1.60 GHz, 800 MHz
> This should be a typical and well-known BIOS setup.
> For some reason some BIOSes export the highest frequency twice (or with
> one HZ difference or similar). Linux kernel should be able to handle this
> gracefully. This is nothing to worry about.

I think this is because of the so-called Turbo Boost. I recall at least
couple of Intel specifications or white papers in which it was adviced that
BIOS vendors should report the "turbo state" as the maximum + 1 MHz.

- Jukka.

Re: Possible bug

[Ariel Norberto Bellino]

-----Original Message-----
From: Jukka Ruohonen <jruohonen@iki.fi>
> On Tue, Jul 24, 2012 at 02:01:53PM +0200, Thomas Renninger wrote:
> > For some reason some BIOSes export the highest frequency twice (or
> with
> > one HZ difference or similar).
> 
> I think this is because of the so-called Turbo Boost. I recall at least
> couple of Intel specifications or white papers in which it was adviced
> that
> BIOS vendors should report the "turbo state" as the maximum + 1 MHz.
> 
> - Jukka.

I found that, effectively, the speeds are reported with a difference of 1 MHz:
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 
2534000 2533000 1600000 800000 

But Turbo Boost technology is not present in my new processor:
http://ark.intel.com/products/35562/Intel-Core2-Duo-Processor-T9400-%286M-Cache-2_53-GHz-1066-MHz-FSB

In fact, as far as I know, no processor supported by this motherboard has it:
http://www.intel.com/es_la/assets/PDF/datasheet/320122.pdf

BIOS issue? The laptop is a Sony Vaio VGN-SR210J, BIOS R1130Y1 (latest to
this day).

Possible bug

[Reuben Thomas]

Observe the following exchange with git 1.7.4.1, which I found rather
perplexing:

$ cat ~/reportbug-git
$ git rm -f ../INSTALL
rm 'INSTALL'
$ git ci -m "INSTALL is now provided by gnulib." ../INSTALL
error: pathspec 'ALL' did not match any file(s) known to git.
$ cd ..
$ git ci -m "INSTALL is now provided by gnulib." INSTALL
[master 0895314] INSTALL is now provided by gnulib.
 1 files changed, 0 insertions(+), 1 deletions(-)
 delete mode 120000 INSTALL

Is this a bug, or merely some magic I don't know about?

-- 
http://rrt.sc3d.org

Possible Bug

[Angelo]

>From Miele angelo, mac.angelo@vallecalore.it



Menuconfig has encountered a possible error in one of the kernel's

configuration files and is unable to continue. Here is the error

report:


Q> scripts/Menuconfig: line 832: MCmenu71: command not found


Please report this to the maintainer <mec@shout.net>. You may also

send a problem report to <linux-kernel@vger.kernel.org>.


Kernel version: linux-2.4.21-0.13mdk


make: *** [menuconfig] Error 1

possible bug

[undertow]

Im spannish user of linux, I have detected an error on my distro and I
ask to local average users and told me that prob. is a kernel bug.
Sometimes when I do a kill -9 pid the command dont tells any error but
no pid die, the task still freeze but the os works perfect and I can
continue using my linux box with any problem, but I read that a kill -)
command MUST finnish the running task, Im quite newbie with linux but I
hope is a real bug and dont make you losing time.Normaly the freeze task
is edonkey or overnet.
My system specs:
amd k7-900 448 ram
hd ide ibm 40 gb 7200 rpm
voodoo3
mainboard msi ms-6330
distro: MDK 9.0 kernel: 2.4.19-16 mdk

I can make an ssh account on my machine when the problem appear to let
you enter on my linux and watch the problem or I can send you whatever
you want.

see you
Eduardo Galan de Andres
Spain, Madrid
01-10-2002

Re: possible bug

[DervishD]

    Hi Eduardo :)

> Im spannish user of linux, I have detected an error on my distro
> and I ask to local average users and told me that prob. is a kernel
> bug.

    I'm spanish, too ;)) But let's go to the matter: probably the PID
you're trying to 'kill -9' is stuck in 'D' state (or any other
uninterruptible state), so it's not a kernel bug ;) If this is not
the case, you may have hit a kernel bug.

> but I read that a kill -)
> command MUST finnish the running task

    AFAIK this is not exact ;) The 'SIGKILL' signal (that is, 9),
cannot be trapped and so its action cannot be changed. Moreover, it
is unblockable, so it's always 'fatal' ;))) it is always *sent*. This
doesn't mean that the process will die. If the process is in any
uninterruptible state, it won't be interrupted!. You will have to
wait until the process is woken up and then it will die.

    The more probable state, in my experience, is the 'D' state,
which if I remember well, is something like 'disk sleep', waiting for
disk i/o, etc...

> Normaly the freeze task
> is edonkey or overnet.

    Oh... The eDonkey client... AFAIK, this is closed source, so any
problem related to this client is difficult (if not impossible) to
catch...

    Raúl

Re: possible bug

[Denis Vlasenko]

On 1 October 2002 14:37, DervishD wrote:
>     I'm spanish, too ;)) But let's go to the matter: probably the PID
> you're trying to 'kill -9' is stuck in 'D' state (or any other
> uninterruptible state), so it's not a kernel bug ;) If this is not

How come? Process stuck in 'D' state *is* a kernel bug
(well, the only legitimate reason for it is a hard,nointr NFS mount
and remote server down but I still think that this mount option for NFS
should be never used).
--
vda

Re: possible bug

[DervishD]

    Hi Denis :)

> > you're trying to 'kill -9' is stuck in 'D' state (or any other
> > uninterruptible state), so it's not a kernel bug ;) If this is not
> How come? Process stuck in 'D' state *is* a kernel bug

    Yes if it is stuck in that state forever, but I've suffered
processes stuck in 'D' state due to, for example, my CD recorder
frozen... It can last more than 600 seconds, and it's not a kernel
bug, just a 'long-lasting' transient state ;)

    Anyway, last time I had a process stuck in 'D' state was back in
2.2 kernel, more than a year ago.

    Raúl