lkml.org 
[lkml]   [2013]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp | rcu related? ]
From
On Sat, Apr 20, 2013 at 10:00 PM, Davidlohr Bueso
<davidlohr.bueso@hp.com> wrote:
> On Sat, 2013-04-20 at 02:19 +0200, Sedat Dilek wrote:
>> On Sat, Apr 20, 2013 at 2:06 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>> > On Sat, Apr 20, 2013 at 1:02 AM, Linus Torvalds
>> > <torvalds@linux-foundation.org> wrote:
>> >> On Fri, Apr 19, 2013 at 3:55 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>> >>>
>> >>> Davidlohr pointed to this patch (tested the triplet):
>> >>>
>> >>> ipc, sem: do not call sem_lock when bogus sma:
>> >>> https://lkml.org/lkml/2013/3/31/12
>> >>>
>> >>> Is that what you mean?
>> >>
>> >> Yup.
>> >>
>> >
>> > Davidlohr Bueso (1):
>> > ipc, sem: do not call sem_lock when bogus sma
>> >
>> > Linus Torvalds (1):
>> > crazy rcu double free debug hack
>> >
>> > With ***both*** patches applied I am able to build a Linux-kernel with
>> > 4 parallel-make-jobs again.
>> > David's or your patch alone are not sufficient!
>> >
>>
>> [ Still both patches applied ]
>>
>> To correct myself... The 1st run was OK.
>>
>> The 2nd run shows a NULL-pointer-deref (excerpt):
>>
>> [ 178.490583] BUG: spinlock bad magic on CPU#1, sh/8066
>> [ 178.490595] lock: 0xffff88008b53ea18, .magic: 6b6b6b6b, .owner:
>> make/8068, .owner_cpu: 3
>> [ 178.490599] BUG: unable to handle kernel NULL pointer dereference
>> at (null)
>> [ 178.490608] IP: [<ffffffff812bacd0>] update_queue+0x70/0x210
>> [ 178.490610] PGD 0
>> [ 178.490612] Oops: 0000 [#1] SMP
>> ...
>
> The exit_sem() >> do_smart_update() >> update_queue() calls seem pretty
> well protected. Furthermore we're asserting that sma->sem_perm.lock is
> taken. This could just be a consequence of another issue. Earlier this
> week Andrew pointed out a potential race in semctl_main() where
> sma->sem_perm.deleted could be changed when cmd == GETALL.
>
> Sedat, could you try the attached patch to keep the ipc lock acquired
> (on top of the three patches you're already using) and let us know how
> it goes? We could also just have the RCU read lock instead of
> ->sem.perm.lock for GETALL, but lets play it safe for now.
>

I had to refresh your patch and it contain strange ^M charachters as well.

NOPE, the machine gets FROZEN (cold reboot).

- Sedat -

P.S.: I have attached all 4 patches against next-20130419 in case
someone wants to follow.

> Thanks,
> Davidlohr
>
[unhandled content-type:application/octet-stream][unhandled content-type:application/octet-stream][unhandled content-type:application/octet-stream][unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2013-04-20 23:41    [W:0.117 / U:0.784 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site