linux-kernel - Re: [PATCH] panic: add TAINT

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAPDOMVienF9gj8fAeqdXQRM9+v3jpFRygA1aL4DqiEU2dbH5tA@mail.gmail.com>
Date:	Tue, 24 Jun 2014 23:39:12 -0400
From:	Nick Krause <xerofoify@...il.com>
To:	Josh Hunt <johunt@...mai.com>
Cc:	David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Baron, Jason" <jbaron@...mai.com>
Subject: Re: [PATCH] panic: add TAINT_SOFTLOCKUP

If you want to flush the ram issues back to disk,
that may be a good idea otherwise I would just
close this discussion.
Cheers Nick

On Tue, Jun 24, 2014 at 11:24 PM, Josh Hunt <johunt@...mai.com> wrote:
> On 06/24/2014 07:45 PM, David Rientjes wrote:
>>
>> On Tue, 24 Jun 2014, Josh Hunt wrote:
>>
>>> Anyone you'd suggest adding to this thread to get other feedback about
>>> tracking page allocation failures? I could also spin up a patch and cc
>>> them.
>>>
>>
>> Page allocation failures happen all the time, mostly because of
>> large-order allocations (more than PAGE_ALLOC_COSTLY_ORDER) or allocations
>> done with GFP_ATOMIC where it's impossible to reclaim or compact memory to
>> allocate.  Because of this, they are fairly easy to trigger from userspace
>> without having to do much.
>>
>> Why would this qualify for a taint?  I have never debugged a kernel crash
>> that I traced back to an earlier page allocation failure and said "oh, if
>> I had only known about that page allocation failure earlier!".  If one of
>> them is going to cause an issue, it probably is at the point of the crash
>> and you shouldn't have to "investigate" much.
>>
>
> I guess I was thinking more of the case where all you have is the trace/dump
> and for whatever reason the last bits which may contain the page allocation
> failure info didn't get flushed to disk. In that case it'd be nice to know
> what lead up to the crash. However, I do agree with your point and Andrew's
> about the frequency and ease of triggering them which would make taint the
> wrong place to account for them.
>
> Thanks
> Josh
>
>
>
> --
> 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/
--
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/