Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem

[Sedat Dilek]

On Wed, Jan 16, 2013 at 10:52 AM, Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote:
> On Wed, Jan 16, 2013 at 10:35 AM, Takashi Iwai <tiwai@xxxxxxx> wrote:
>> At Wed, 16 Jan 2013 10:21:46 +0100,
>> Sedat Dilek wrote:
>>>
>>> On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai <tiwai@xxxxxxx> wrote:
>>> > At Sat, 5 Jan 2013 13:13:27 +0100,
>>> > Sedat Dilek wrote:
>>> >>
>>> >> Hi Jiri,
>>> >>
>>> >> ...known issue (see thread in [1]), please feel free to test patches
>>> >> from Alan and Andrew (see [1], [2] and [3]) and report.
>>> >>
>>> >> Regards,
>>> >> - Sedat -
>>> >>
>>> >> [1] http://marc.info/?t=135309396400003&r=1&w=2
>>> >> [2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
>>> >> [3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
>>> >> [4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
>>> >
>>> > I've hit this bug and tried the patch [2] ([3] and [4] are gone).
>>> > Unfortunately the deadlock is still reported, as seen below.
>>> >
>>> > A similar fix for fbcon_unbind(), splitting an unlocked version of
>>> > unbind_con_driver() and call it?
>>> >
>>> > (BTW, the patch [2] contains strange characters in the comments, and
>>> >  has a few coding issues easily detected by checkpatch.pl.)
>>> >
>>>
>>> [ CCing Rafael as he asked in another thread if I had sent a patch ]
>>>
>>> I noticed also some these "strange" chars in the patch from Andrew and
>>> a patch of mine was sent as
>>> "fb-Rework-locking-to-fix-lock-ordering-on-takeover-fix-comments.patch"
>>> to the lists.
>>>
>>> It is strange to me that Andrew or other maintainers himself did not
>>> check with "checkpatch.pl".
>>> This should be a common testcase!
>>> Hey, noone is perfect :-).
>>> ( /me has also not checked with that script - I just saw it. )
>>>
>>> Just as a note to the issue in general:
>>> Andrew took over the patch from Alan which is very honest - he is not
>>> the active TTY maintainer!
>>> Didn't Greg takeover maintenance from Alan (after a dispute and blaming Alan)?
>>> If this is true, why the hell is Greg not CCed?
>>
>> Let's do it :)
>>
>> Greg, Jiri, this bug hits already quite a few people.
>>
>> I can reproduce the bug easily on a machine with a radeon graphics.
>> It appears always at boot when lockdep is enabled.
>>
>>
>>> Thanks for the real patch in the followup of this thread!
>>> Who will take care of it :-)?
>>
>> Either tty maintainer, or fb maintainer, or Andrew?
>>
>> FWIW, Andrew took my patch in mm:
>>   http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
>>   http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
>>
>
> [ CCing linux-next ML ]
>
> Thanks for all your efforts to get this fb-issue nailed down for mainline!
>
> Just as a note being a Linux-Next customer:
>
> "fb-yet-another-band-aid-for-fixing-lockdep-mess.patch" did not hit
> next-20130116!
> Thanks for the link!
>
> Normally Andrew sents out a mmotm release marking patches from his
> tree destinated for Linux-Next with a "*".
>
> To quote from the latest mmotm release-notes:
>
> "This mmotm tree contains the following patches against 3.8-rc3:
> (patches marked "*" will be included in linux-next)"
>
> But anyway this stuff is Linux-3.8 material as well.
>

JYI: [1] now does NOT have anymore those "strange" chars, Thanks Takashi san.

I will test next-20130116 with both fb-fixes as -2 kernel.
( Running LTP-lite on my "naked" -1 kernel only with my kbuild/deb-pkg-fixes. )

Thanks to everyone involved.

- Sedat -

[1] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
[2] http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
> - Sedat -
>
>>
>> thanks,
>>
>> Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/