linux-kernel - Re: Linux 4.2-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CACVXFVMboxPrWXQh+sYdfFVXYRwxw10qJghytCGL=8Be+GcorA@mail.gmail.com>
Date:	Sat, 11 Jul 2015 06:36:24 +0800
From:	Ming Lei <ming.lei@...onical.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Shuah Khan <shuahkh@....samsung.com>, vz@...ia.com,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Tejun Heo <tj@...nel.org>, Shuah Khan <shuahkhan@...il.com>
Subject: Re: Linux 4.2-rc1

On Sat, Jul 11, 2015 at 5:47 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> But my patch (which is committed now) solves it all for you?
>
> I'm going to just assume it's timing, and there is no major real reason why
> it started triggering just now...

Now I see it, the issue is triggered when firmware request is
timed out, and Shuah's reported should be caused by the following
commit 0cb64249(firmware_loader: abort request if wait_for_completion
is interrupted).

But your patch is correct for this issue too.

Thanks,
Ming

>
>      Linus
>
> On Jul 10, 2015 2:33 PM, "Shuah Khan" <shuahkh@....samsung.com> wrote:
>>
>> On 07/10/2015 11:11 AM, Linus Torvalds wrote:
>> > On Fri, Jul 10, 2015 at 9:58 AM, Shuah Khan <shuahkh@....samsung.com>
>> > wrote:
>> >>
>> >> I am not sure why this patch would cause the problem I am seeing.
>> >> This patch itself looks like a cleanup type patch and doesn't
>> >> really fix a bug. I am building with this patch reverted at the
>> >> moment to confirm.
>> >
>> > Smells to me like it's just a timing issue, and that mayeb the bisect
>> > failed because it's not 100% repeatable. Or maybe it *was* 100%
>> > repeatable, but simply because that commit changed the timing of the
>> > bootup scripts etc.
>> >
>> > But yes, trying it with the revert in place is a good idea just to
>> > make sure. And perhaps checking that kernel more than a few times to
>> > verify just how repeatable it is.
>> >
>>
>> Quick update. Reverting didn't help. I think I mentioned I am seeing
>> hangs during poweroff and reboot. I am seeing hangs during boot as well.
>> I think there is a timing problem that manifests into the following
>> 3 variations:
>>
>> 1. NULL pointer dereference alert, boots fine and runs fine - hangs
>>    during poweroff and reboot
>> 2. Hangs during boot. When booted in recovery, it runs into repeated
>>    errors which looks very much like the same call trace I see in the
>>    alert.
>>
>> Please see attached images. These two are rolling failures repeated
>> during udev initialization. It is related to firmware loading it looks
>> like.
>>
>> thanks,
>> -- Shuah
>>
>> --
>> Shuah Khan
>> Sr. Linux Kernel Developer
>> Open Source Innovation Group
>> Samsung Research America (Silicon Valley)
>> shuahkh@....samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/