From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758104Ab3BFUTU (ORCPT ); Wed, 6 Feb 2013 15:19:20 -0500 Received: from mail-ie0-f182.google.com ([209.85.223.182]:41282 "EHLO mail-ie0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755294Ab3BFUTR (ORCPT ); Wed, 6 Feb 2013 15:19:17 -0500 Date: Wed, 6 Feb 2013 12:19:19 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Jan Kara cc: David Rientjes , Andrew Morton , LKML , jslaby@suse.cz, Greg Kroah-Hartman , Frederic Weisbecker , Steven Rostedt Subject: Re: [PATCH v2] printk: Avoid softlockups in console_unlock() In-Reply-To: <20130206185205.GA11254@quack.suse.cz> Message-ID: References: <1360016230-26696-1-git-send-email-jack@suse.cz> <20130205123838.146a5371.akpm@linux-foundation.org> <20130206142346.GF6330@quack.suse.cz> <20130206185205.GA11254@quack.suse.cz> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? 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: 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: [] debug_smp_processor_id+0xbe/0xd8 [] __console_unlock+0x3c/0x39c [] ? trace_hardirqs_on+0xd/0xf [] ? _raw_spin_unlock_irqrestore+0x46/0x64 [] console_unlock+0x9/0x1b [] con_shutdown+0x29/0x2d [] ? visual_init+0x10d/0x10d [] release_tty+0x4d/0x91 [] tty_release+0x421/0x460 [] __fput+0x104/0x1e9 [] ____fput+0x9/0xb [] task_work_run+0x79/0xa6 [] do_notify_resume+0x55/0x66 [] ? trace_hardirqs_on_thunk+0x3a/0x3f [] int_signal+0x12/0x17 As a quick and obviously wrong hack, I replace the call to smp_processor_id() by call to raw_smp_processor_id() and then: + /* + * We give us some headroom because we check the time only after + * printing the whole message + */ + end_time = sched_clock_cpu(cur_cpu) + + max_interrupt_disabled_duration() / 2; Oh, sched_clock_cpu() is also giving me such BUGs, but also (phew, it's a WARN_ON_ONCE): 00000] WARNING: at kernel/sched/clock.c:219 sched_clock_cpu+0x2e/0xcf() 00000] Hardware name: 4174AY9 00000] Modules linked in: 00000] Pid: 0, comm: swapper/0 Not tainted 3.8.0-rc6-mm1 #2 00000] Call Trace: 00000] [] warn_slowpath_common+0x7e/0x99 00000] [] warn_slowpath_null+0x15/0x17 00000] [] sched_clock_cpu+0x2e/0xcf 00000] [] __console_unlock+0x48/0x39e 00000] [] ? printk+0x48/0x4a 00000] [] console_unlock+0x9/0x1b 00000] [] con_init+0x252/0x27d 00000] [] console_init+0x16/0x27 00000] [] start_kernel+0x243/0x322 00000] [] ? repair_env_string+0x5a/0x5a 00000] [] x86_64_start_reservations+0x2a/0x2c 00000] [] x86_64_start_kernel+0xc8/0xcc Please fix or revert; though whether yesterday's mmotm then becomes usable, I'm not so sure (iwlwifi broken? characters dropped from i915 screen? oops in find_pid_ns? I'd better move on to something else). Hugh