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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <53A8ADEC.6070406@akamai.com>
Date:	Mon, 23 Jun 2014 17:45:00 -0500
From:	Josh Hunt <johunt@...mai.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Baron, Jason" <jbaron@...mai.com>
Subject: Re: [PATCH] panic: add TAINT_SOFTLOCKUP

On 06/23/2014 05:11 PM, Andrew Morton wrote:
> On Tue,  3 Jun 2014 22:12:35 -0400 Josh Hunt <johunt@...mai.com> wrote:
>
>> This taint flag will be set if the system has ever entered a softlockup
>> state. Similar to TAINT_WARN it is useful to know whether or not the system
>> has been in a softlockup state when debugging.
>>
>> ...
>>
>> @@ -329,6 +329,7 @@ static enum hrtimer_restart watchdog_timer_fn(struct hrtimer *hrtimer)
>>
>>   		if (softlockup_panic)
>>   			panic("softlockup: hung tasks");
>> +		add_taint(TAINT_SOFTLOCKUP, LOCKDEP_STILL_OK);
>>   		__this_cpu_write(soft_watchdog_warn, true);
>>   	} else
>>   		__this_cpu_write(soft_watchdog_warn, false);
>
> Would make more sense to have applied the taint *before* calling
> panic()?

Andrew

Yep, that's a good call. Thanks. Do you want me to send a v2 or did you 
take care of it?

In addition to adding the softlockup taint flag, do you think it'd be 
reasonable to add another flag for page allocation failures? I think 
it'd be nice to be able to account for these conditions somehow without 
having to parse dmesg, etc. As with the softlockup flag, it's helpful to 
know if your system had encountered a page allocation failure at some 
point before the crash or whatever you're debugging.

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/