linux-kernel - Re: [PATCH 0/2] [RFC] RT: Optionally allow IRQF

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]

Date:	Fri, 05 Oct 2007 12:54:13 -0400
From:	Gregory Haskins <ghaskins@...ell.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	mingo@...e.hu, rostedt@...dmis.org, linux-rt-users@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] [RFC] RT: Optionally allow IRQF_NODELAY on serial
	console

On Fri, 2007-10-05 at 18:41 +0200, Thomas Gleixner wrote:
> On Fri, 5 Oct 2007, Gregory Haskins wrote:
> > This series may help debugging certain circumstances where the serial
> > console is unreponsive (e.g. RT51+ spinner, or scheduler problem).  It changes
> > the serial8250 driver to use IRQF_NODELAY so that interrupts execute in irq
> > context instead of a kthread.
> > 
> > It works pretty well on this end, though it is admitted not fully baked  For
> > instance, a few paths in sysrq can still call into non-raw spinlocks
> > (sched_debug_show, for instance) which will cause subsequent errors.  Also,
> > if you use KDB, be sure to convert the kdb_printf_lock to raw as well.  I may
> > send a KDB related patch seperately.
> > 
> > I am sending this out now in case it is helpful to someone.
> 
> The simple non-patch solution is to up the priority of the serial 
> console irq to maximum. That's usually sufficient to catch runnaway tasks 
> etc. It does not interfere with the system in normal operation as long as 
> you do not hit keys in your minicom.
> 
> I doubt that your patch has a chance to survive lockdep and anything which 
> is not a sysrq.

Your point is valid, and I thought of this too.  The one problem with it
is that it is not immune to problems in the scheduler itself (which at
the time, I thought I was chasing..turned out to be lockdep), but that
is probably a rarity.  In any case, we have been using it on a number of
debug systems here for a few weeks and the console continues to work
well in all functions besides sysrq, believe it or not (*).  But I don't
see this as being anything used for real.  Just thought I would throw it
out there in case it was useful or inspired someone to give it some
love.

Regards,
-Greg

(*) The trick is that once it figures out its not for sysrq, it
schedules a (kthread based) tasklet to do the actual tty() callbacks.

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)