Re: [next-20130227] kernel NULL pointer dereference [ watchdog | perf related ? ]
On Thu, Feb 28, 2013 at 8:24 AM, Sedat Dilek wrote:
> On Wed, Feb 27, 2013 at 4:07 PM, Tejun Heo wrote:
>> Replying here too just in case.
>>
>> On Wed, Feb 27, 2013 at 02:08:40PM +0100, Sedat Dilek wrote:
>>> >> static inline void *idr_find(struct idr *idr, int id)
>>> >> {
>>> >> struct idr_layer *hint = rcu_dereference_raw(idr->hint);
>>> >> 86d7: 48 8b 05 00 00 00 00mov0x0(%rip),%rax#
>>> >> 86de
>>> >> 86da: R_X86_64_PC32 .bss+0xfc
>>> >>
>>> >> if ((id & ~IDR_MASK) == hint->prefix)
>>> >> 86de: 89 f2 mov%esi,%edx
>>> >> 86e0: 30 d2 xor%dl,%dl
>>> >> 86e2: 3b 10 cmp(%rax),%edx
>>> >> <--- trapping insn
>>> >> 86e4: 74 4a je 8730
>>> >>
>>> >> return rcu_dereference_raw(hint->ary[id & IDR_MASK]);
>>> >>
>>> >>
>>> >> So 'hint' is NULL as RAX above confirms and we're not supposed to deref
>>> >> NULL things.
>>> >>
>>> >> Looking at 29cf29e1fbb875019713eb55cf27ec35f1e5fa5e, Tejun should
>>> >> probably know. CCed.
>>
>> Fix was posted some days ago.
>>
>> http://thread.gmane.org/gmane.linux.kernel.next/26213
>>
>> I got Andrew's patch added to -mm message a week ago. Not sure why it
>> still hasn't showed up. Andrew, any ideas?
>>
>> Thanks.
>>
>> --
>> tejun
>
> AFAICS the updated (correct) patch "idr: implement lookup hint" is now
> in mainline.
>
...but not in next-20130228 yet (tomorrow's Linux-Next will have it).
- Sedat -
> - Sedat -
>
> [1]
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=0ffc2a9c8072969253a20821c2c733a2cbb4c7c7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [next-20130227] kernel NULL pointer dereference [ watchdog | perf related ? ]
On Wed, Feb 27, 2013 at 4:07 PM, Tejun Heo wrote:
> Replying here too just in case.
>
> On Wed, Feb 27, 2013 at 02:08:40PM +0100, Sedat Dilek wrote:
>> >> static inline void *idr_find(struct idr *idr, int id)
>> >> {
>> >> struct idr_layer *hint = rcu_dereference_raw(idr->hint);
>> >> 86d7: 48 8b 05 00 00 00 00mov0x0(%rip),%rax#
>> >> 86de
>> >> 86da: R_X86_64_PC32 .bss+0xfc
>> >>
>> >> if ((id & ~IDR_MASK) == hint->prefix)
>> >> 86de: 89 f2 mov%esi,%edx
>> >> 86e0: 30 d2 xor%dl,%dl
>> >> 86e2: 3b 10 cmp(%rax),%edx
>> >> <--- trapping insn
>> >> 86e4: 74 4a je 8730
>> >> return rcu_dereference_raw(hint->ary[id & IDR_MASK]);
>> >>
>> >>
>> >> So 'hint' is NULL as RAX above confirms and we're not supposed to deref
>> >> NULL things.
>> >>
>> >> Looking at 29cf29e1fbb875019713eb55cf27ec35f1e5fa5e, Tejun should
>> >> probably know. CCed.
>
> Fix was posted some days ago.
>
> http://thread.gmane.org/gmane.linux.kernel.next/26213
>
> I got Andrew's patch added to -mm message a week ago. Not sure why it
> still hasn't showed up. Andrew, any ideas?
>
> Thanks.
>
> --
> tejun
AFAICS the updated (correct) patch "idr: implement lookup hint" is now
in mainline.
- Sedat -
[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=0ffc2a9c8072969253a20821c2c733a2cbb4c7c7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [next-20130227] kernel NULL pointer dereference [ watchdog | perf related ? ]
On Wed, Feb 27, 2013 at 05:14:04PM +0100, Sedat Dilek wrote: > I am not screaming or whining... people should reflect a bit on the > patch workflow process? Also, I am sure a patchwork-service especially > for -next is helpful. Ok, now this formulation reads much nicer. So if you really think this is needed, simply talk to sfr and see what he has to say about it. But please do it in a nice way. I'd say, serious suggestions on how the workflow could be improved are always welcome. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [next-20130227] kernel NULL pointer dereference [ watchdog | perf related ? ]
On Wed, Feb 27, 2013 at 5:08 PM, Borislav Petkov wrote: > On Wed, Feb 27, 2013 at 04:56:27PM +0100, Sedat Dilek wrote: >> Hmm, I am not very amused to read all this, really. >> >> If such fixes are around why aren't they applied quickly? > > Sedat, you need to relax a little. You're testing a linux next tree > right during the merge window where patches are flying back and forth. > Things like that can happen and you, if you're really willing to test > such bleeding edge kernels, also would have to accept the fact that > fixes don't magically appear where they have to in no time. > > I debugged an issue which apparently got fixed already but I'm not > complaining. People are trying their best and screaming at them is not > constructive. At all. > I am not screaming or whining... people should reflect a bit on the patch workflow process? Also, I am sure a patchwork-service especially for -next is helpful. /me forgot to add a "call trace" to my 1st kernel checks. $ dmesg | egrep -i 'error|fail|warn|conflict|terminated|killed|call trace' That's why I have overseen it. > I'd suggest simply reporting the issue, maybe trying to debug it > yourself and patiently waiting. I'm sure you can find anything else to > do in the meantime :-) > Yupp, I had a coffee and two pieces of cake :-). > Thanks. > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [next-20130227] kernel NULL pointer dereference [ watchdog | perf related ? ]
On Wed, Feb 27, 2013 at 04:56:27PM +0100, Sedat Dilek wrote: > Hmm, I am not very amused to read all this, really. > > If such fixes are around why aren't they applied quickly? Sedat, you need to relax a little. You're testing a linux next tree right during the merge window where patches are flying back and forth. Things like that can happen and you, if you're really willing to test such bleeding edge kernels, also would have to accept the fact that fixes don't magically appear where they have to in no time. I debugged an issue which apparently got fixed already but I'm not complaining. People are trying their best and screaming at them is not constructive. At all. I'd suggest simply reporting the issue, maybe trying to debug it yourself and patiently waiting. I'm sure you can find anything else to do in the meantime :-) Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [next-20130227] kernel NULL pointer dereference [ watchdog | perf related ? ]
Replying here too just in case.
On Wed, Feb 27, 2013 at 02:08:40PM +0100, Sedat Dilek wrote:
> >> static inline void *idr_find(struct idr *idr, int id)
> >> {
> >> struct idr_layer *hint = rcu_dereference_raw(idr->hint);
> >> 86d7: 48 8b 05 00 00 00 00mov0x0(%rip),%rax#
> >> 86de
> >> 86da: R_X86_64_PC32 .bss+0xfc
> >>
> >> if ((id & ~IDR_MASK) == hint->prefix)
> >> 86de: 89 f2 mov%esi,%edx
> >> 86e0: 30 d2 xor%dl,%dl
> >> 86e2: 3b 10 cmp(%rax),%edx
> >> <--- trapping insn
> >> 86e4: 74 4a je 8730
> >> return rcu_dereference_raw(hint->ary[id & IDR_MASK]);
> >>
> >>
> >> So 'hint' is NULL as RAX above confirms and we're not supposed to deref
> >> NULL things.
> >>
> >> Looking at 29cf29e1fbb875019713eb55cf27ec35f1e5fa5e, Tejun should
> >> probably know. CCed.
Fix was posted some days ago.
http://thread.gmane.org/gmane.linux.kernel.next/26213
I got Andrew's patch added to -mm message a week ago. Not sure why it
still hasn't showed up. Andrew, any ideas?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [next-20130227] kernel NULL pointer dereference [ watchdog | perf related ? ]
Hi Sedat, > I have reported this issue several times (first for next-20130223) to > LKML and Linux-Next MLs but got no answer. > I am unsure which is the root cause for all this trouble. > > Can someone have a look at this, please? > > [0.065787] smpboot: CPU0: Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz > (fam: 06, model: 2a, stepping: 07) > [0.065799] TSC deadline timer enabled > [0.065811] Performance Events: PEBS fmt1+, 16-deep LBR, > SandyBridge events, Intel PMU driver. > [0.065822] ... version:3 > [0.065824] ... bit width: 48 > [0.065826] ... generic registers: 4 > [0.065829] ... value mask: > [0.065831] ... max period: 7fff > [0.065834] ... fixed-purpose events: 3 > [0.065836] ... event mask: 0007000f > [0.066888] BUG: unable to handle kernel NULL pointer dereference > at (null) > [0.066894] IP: [] perf_init_event+0x32/0x100 > [0.066900] PGD 0 > [0.066903] Oops: [#1] SMP > [0.066906] Modules linked in: > [0.066908] CPU 0 > [0.066912] Pid: 11, comm: watchdog/0 Not tainted > 3.8.0-next20130227-1-iniza-small #1 SAMSUNG ELECTRONICS CO., LTD. > 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH > [0.066918] RIP: 0010:[] [] > perf_init_event+0x32/0x100 > [0.066924] RSP: :880119b59d58 EFLAGS: 00010246 > [0.066927] RAX: RBX: 81c4d760 RCX: > 0002 > [0.066930] RDX: RSI: RDI: > 81f56dc0 > [0.066933] RBP: 880119b59d88 R08: 88011fa16fa0 R09: > 810ec0e0 > [0.066936] R10: 88011b012000 R11: R12: > 88011b012000 > [0.066939] R13: R14: R15: > 88011b012000 > [0.066942] FS: () GS:88011fa0() > knlGS: > [0.066946] CS: 0010 DS: ES: CR0: 80050033 > [0.066949] CR2: CR3: 01c0d000 CR4: > 000407f0 > [0.066952] DR0: DR1: DR2: > > [0.066955] DR3: DR6: 0ff0 DR7: > 0400 > [0.066959] Process watchdog/0 (pid: 11, threadinfo > 880119b58000, task 880119b5) > [0.066962] Stack: > [0.066964] 88011fa141b0 81c4d760 > 81c4d760 > [0.066970] 88011b012000 880119b59de8 > 8112a6b8 > [0.066975] 880119b00048 880119b00048 810ec0e0 > > [0.066980] Call Trace: > [0.066985] [] perf_event_alloc+0x358/0x490 > [0.066990] [] ? touch_nmi_watchdog+0x80/0x80 > [0.066995] [] > perf_event_create_kernel_counter+0x2e/0xe0 > [0.066999] [] watchdog_enable+0xfd/0x1e0 > [0.067004] [] smpboot_thread_fn+0x9c/0x170 > [0.067009] [] ? lg_global_lock+0x70/0x70 > [0.067013] [] kthread+0xc0/0xd0 > [0.067017] [] ? flush_kthread_worker+0xb0/0xb0 > [0.067021] [] ret_from_fork+0x7c/0xb0 > [0.067025] [] ? flush_kthread_worker+0xb0/0xb0 > [0.067027] Code: 54 49 89 fc 48 c7 c7 c0 6d f5 81 53 48 83 ec 18 > e8 e4 a5 f5 ff 41 8b b4 24 a0 00 00 00 41 89 c5 48 8b 05 f2 ca e2 00 > 89 f2 30 d2 <3b> 10 74 4a 48 c7 c7 80 6d f5 81 e8 ae ab 22 00 48 89 c3 > 48 85 > [0.067063] RIP [] perf_init_event+0x32/0x100 > [0.067067] RSP > [0.067069] CR2: > [0.067077] ---[ end trace 3cbbfd94f0f8f035 ]--- touch_nmi_watchdog is defined in kernel/watchdog.c (which is the kernels watchdog and has nothing to do with the watchdog device drivers). Kind regards, Wim. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
