linux-kernel - Re: [Linux 2.6.29-rc2] BUG: using smp_processor

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: <200901271628.54037.rjw@sisk.pl>
Date:	Tue, 27 Jan 2009 16:28:53 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Frédéric Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Maciej Rutecki <maciej.rutecki@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [Linux 2.6.29-rc2] BUG: using smp_processor_id() in preemptible

On Monday 26 January 2009, Ingo Molnar wrote:
> 
> * Rafael J. Wysocki <rjw@...k.pl> wrote:
> 
> > On Monday 26 January 2009, Ingo Molnar wrote:
> [...]
> > > It would work like this, you could mark IRQs as disabled 'permanently':
> > > 
> > >    force_irqs_off_start();
> > >    ...
> > >    force_irqs_off_end();
> > > 
> > > you could mark an arbitrarily complex code sequence that way, and ftrace 
> > > would emit a WARN_ONCE() if irqs are enable anytime during that sequence - 
> > > by using the irq-tracking facilities we have for the irqsoff tracer (and 
> > > which we also have for lockdep).
> > > 
> > > Would that be useful?
> > 
> > Not sure, I only know a little about ftrace, I really can't judge.
> 
> The instrumentation is really simple, see kernel/tracing/trace_irqsoff.c:
> 
> we call this function if hardirqs are disabled anywhere in the kernel:
> 
>  static inline void
>  start_critical_timing(unsigned long ip, unsigned long parent_ip)
> 
> and we call this function if hardirqs are enabled anywhere in the kernel:
> 
>  static inline void
>  stop_critical_timing(unsigned long ip, unsigned long parent_ip)
> 
> that's all. You need a single line check in stop_critical_timing(), 
> something like this:
> 
>    WARN_ON_ONCE(per_cpu(hardirqs_forced_off, this_cpu));
>
> > Anyway, I think that putting the checks directly into the code path in 
> > question would be more reliable and would still work without ftrace.
> 
> More reliable than a WARN() triggering right at the buggy place that 
> erroneously enables IRQs? Regardless of how obscurely it's done - whether 
> it's a side effect of something, etc. etc.?

Actually, yes.
 
> With such a generic facility you'd not have to put in any explicit checks 
> anywhere _at all_.

That's under the assumption that the traces we get are always useful.

> In fact whatever check you put in it's _always_ going to be fundamentally 
> more fragile than direct instrumentation: you cannot possibly check all 
> possible places that enable interrupts. (they could be disabling 
> interrupts as a _restore_irqs() sequence for example)

In this particular case, I'm not really interested in that.  What I'm
interested in is which driver's ->suspend_late() or ->resume_early() (or the
equivalents for sysdevs) has enabled interrupts, which is quite easy to
check directly.

Thanks,
Rafael
--
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/