Re: [PATCH] panic: add TAINT_SOFTLOCKUP

Nick Krause
2014-06-25T03:39:14Z

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@akamai.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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/