linux-kernel - Re: [PATCH 3/3] Stop tracing on a schedule bug

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: <i2z40ec3ea41004152101gd55713f2w9eadd8d5ea721688@mail.gmail.com>
Date:	Thu, 15 Apr 2010 21:01:46 -0700
From:	Chase Douglas <chase.douglas@...onical.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...e.hu>,
	Randy Dunlap <randy.dunlap@...cle.com>
Subject: Re: [PATCH 3/3] Stop tracing on a schedule bug

On Thu, Apr 15, 2010 at 5:21 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Fri, 16 Apr 2010, Thomas Gleixner wrote:
>> BTW, if interacting with grub is that hard: how does an user start the
>> tracer at all ?
>
> Just looked through the other patches and noticed that the patch which
> provides the tracing_off(level) stuff is incomplete as it provides
> only a command line option to change that tracing off level.
>
> The command line option is merily for tracing which happens to be
> started on the command line i.e. _BEFORE_ we have usable user space.
>
> So your grub argument is just crap. If the user cannot change this
> setting w/o fiddling with the obscured grub then he can not start the
> tracer on the command line either.
>
> But somehow he can start the tracer later when user space is up and
> running, but there is no way to change that setting anymore. Therefor
> you go through the kernel and impose settings at will.
>
> 1) Your patch simply lacks an interface to change that setting via
>   debugfs/tracing/wtf
>
>   WTF should I reboot my machine to change that setting from the
>   default BUG to WARN or NONE ? There is no reason at all.

You're right, this should be something that may be changed at run
time. I spoke with Steven at LCS and he agrees that there should be an
option in (debugfs)/tracing/options/ for this. I will fix up the first
patch to include this.

> 2) tracing off can be done via filters on functions and/or events
>   already - so I doubt that the tracing_off_event(level) is necessary
>   at all.
>
>   schedule_bug() definitely deserves a separate trace_schedule_bug()
>   event which can be used to stop the tracer by already existing
>   functionality.

Steven said he would be fine with a separate TRACE_EVENT_<blah> macro
for the schedule bug if needed, but I'm not sure we need to go that
far. If it's configurable through debugfs at run time then it serves
my purpose. Unless you feel we should have finer grained control
specifically for scheduling while atomic bugs, I'll just leave it as
TRACE_EVENT_WARN.

-- Chase
--
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/