linux-kernel - Re: [PATCH v2] printk: Avoid softlockups in console

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] [day] [month] [year] [list]

Date:	Wed, 6 Feb 2013 22:29:49 +0100
From:	Jan Kara <jack@...e.cz>
To:	Hugh Dickins <hughd@...gle.com>
Cc:	Jan Kara <jack@...e.cz>, David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, jslaby@...e.cz,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v2] printk: Avoid softlockups in console_unlock()

On Wed 06-02-13 12:19:19, Hugh Dickins wrote:
> On Wed, 6 Feb 2013, Jan Kara wrote:
> > On Wed 06-02-13 09:58:48, David Rientjes wrote:
> > > On Wed, 6 Feb 2013, Jan Kara wrote:
> > > 
> > > >   Yes, I noticed that thread just yesterday and also though that using
> > > > similar trick might be viable. I'll experiment if we could use the same
> > > > method for handling lockup problems I hit. Steven seems to have already
> > > > tweaked PRINTK_PENDING stuff to be usable more easily...
> > > > 
> > > 
> > > Are these new build failures in linux-next coming from this patch?
> > > 
> > > kernel/printk.c: In function 'console_unlock':
> > > kernel/printk.c:2156:18: error: 'printk_work' undeclared (first use in this function)
> > > kernel/printk.c:2156:18: note: each undeclared identifier is reported only once for each function it appears in
> > > kernel/printk.c: At top level:
> > > kernel/printk.c:2167:13: warning: 'printk_worker' defined but not used [-Wunused-function]
> >   Yes, I already sent a patch to fix these (attached if you need it).
> > Thanks for notice.
> 
> Is the console_unlock patch actually intended to be a console load test?
> Could we just revert it until it's baked?
  Yeah, agreed. I'll probably go sligthly different route anyway.

> This little hunk from __console_unlock():
> 
>  	console_may_schedule = 0;
> +	cur_cpu = smp_processor_id();
> 
> I have CONFIG_PREEMPT=y CONFIG_DEBUG_PREEMPT=y,
> so that fills the console with messages:
  Thanks for report, I'll take this in consideration when working on the next
version of the patch. Somehow console_unlock() was never called from the
context you show below in my testing.

> BUG: using smp_processor_id() in preemptible [00000000] code: systemd/1
> caller is __console_unlock+0x3c/0x39c
> Pid: 1, comm: systemd Tainted: G        W    3.8.0-rc6-mm1 #1
> Call Trace:
>  [<ffffffff81223ee2>] debug_smp_processor_id+0xbe/0xd8
>  [<ffffffff810615d8>] __console_unlock+0x3c/0x39c
>  [<ffffffff810a6a38>] ? trace_hardirqs_on+0xd/0xf
>  [<ffffffff8154a997>] ? _raw_spin_unlock_irqrestore+0x46/0x64
>  [<ffffffff81061941>] console_unlock+0x9/0x1b
>  [<ffffffff812955ab>] con_shutdown+0x29/0x2d
>  [<ffffffff81295582>] ? visual_init+0x10d/0x10d
>  [<ffffffff812857ed>] release_tty+0x4d/0x91
>  [<ffffffff8128644f>] tty_release+0x421/0x460
>  [<ffffffff81120c57>] __fput+0x104/0x1e9
>  [<ffffffff81120d45>] ____fput+0x9/0xb
>  [<ffffffff8107a6c3>] task_work_run+0x79/0xa6
>  [<ffffffff8102f4a6>] do_notify_resume+0x55/0x66
>  [<ffffffff8121e29e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
>  [<ffffffff8154b898>] int_signal+0x12/0x17

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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/