From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751899AbdBAJGd (ORCPT ); Wed, 1 Feb 2017 04:06:33 -0500 Received: from mx2.suse.de ([195.135.220.15]:34760 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751519AbdBAJGb (ORCPT ); Wed, 1 Feb 2017 04:06:31 -0500 Date: Wed, 1 Feb 2017 10:06:25 +0100 From: Jan Kara To: Ross Zwisler Cc: Sergey Senozhatsky , Ross Zwisler , Andrew Morton , Petr Mladek , Linus Torvalds , Jan Kara , Tejun Heo , Calvin Owens , Steven Rostedt , Ingo Molnar , Peter Zijlstra , Andy Lutomirski , Peter Hurley , LKML , Sergey Senozhatsky Subject: Re: [PATCHv7 6/8] printk: use printk_safe buffers in printk Message-ID: <20170201090625.GC11567@quack2.suse.cz> References: <20161227141611.940-1-sergey.senozhatsky@gmail.com> <20161227141611.940-7-sergey.senozhatsky@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 31-01-17 10:27:53, Ross Zwisler wrote: > On Tue, Dec 27, 2016 at 7:16 AM, Sergey Senozhatsky > wrote: > > Use printk_safe per-CPU buffers in printk recursion-prone blocks: > > -- around logbuf_lock protected sections in vprintk_emit() and > > console_unlock() > > -- around down_trylock_console_sem() and up_console_sem() > > > > Note that this solution addresses deadlocks caused by printk() > > recursive calls only. That is vprintk_emit() and console_unlock(). > > The rest will be converted in a followup patch. > > > > Another thing to note is that we now keep lockdep enabled in printk, > > because we are protected against the printk recursion caused by > > lockdep in vprintk_emit() by the printk-safe mechanism - we first > > switch to per-CPU buffers and only then access the deadlock-prone > > locks. > > When booting v4.10-rc5-mmots-2017-01-26-15-49 from the mmots tree, I > sometimes see the following lockdep splat which I think may be related > to this commit? I don't think it is really related. Look at the backtrace: > [ 13.090684] printk+0x52/0x6e > [ 13.090685] ? update_load_avg+0x85b/0xb80 > [ 13.090685] __warn+0x39/0xf0 > [ 13.090685] warn_slowpath_fmt+0x5f/0x80 > [ 13.090686] update_load_avg+0x85b/0xb80 > [ 13.090686] ? debug_smp_processor_id+0x17/0x20 > [ 13.090686] detach_task_cfs_rq+0x3f/0x210 > [ 13.090687] task_change_group_fair+0x24/0x100 > [ 13.090687] sched_change_group+0x5f/0x110 > [ 13.090687] sched_move_task+0x53/0x160 > [ 13.090687] cpu_cgroup_attach+0x36/0x70 > [ 13.090688] cgroup_migrate_execute+0x230/0x3f0 > [ 13.090688] cgroup_migrate+0xce/0x140 > [ 13.090688] ? cgroup_migrate+0x5/0x140 > [ 13.090689] cgroup_attach_task+0x27f/0x3e0 > [ 13.090689] ? cgroup_attach_task+0x9b/0x3e0 > [ 13.090689] __cgroup_procs_write+0x30e/0x510 > [ 13.090690] ? __cgroup_procs_write+0x70/0x510 > [ 13.090690] cgroup_procs_write+0x14/0x20 > [ 13.090690] cgroup_file_write+0x44/0x1e0 > [ 13.090690] kernfs_fop_write+0x13c/0x1c0 > [ 13.090691] __vfs_write+0x37/0x160 > [ 13.090691] ? rcu_read_lock_sched_held+0x4a/0x80 > [ 13.090691] ? rcu_sync_lockdep_assert+0x2f/0x60 > [ 13.090692] ? __sb_start_write+0x10d/0x220 > [ 13.090692] ? vfs_write+0x19b/0x1f0 > [ 13.090692] ? security_file_permission+0x3b/0xc0 > [ 13.090693] vfs_write+0xcb/0x1f0 > [ 13.090693] SyS_write+0x58/0xc0 Clearly scheduler code (update_load_avg) calls WARN_ON from scheduler while holding rq_lock which has been always forbidden. Sergey and Petr were doing some work to prevent similar deadlocks but I'm not sure how far they went... Honza -- Jan Kara SUSE Labs, CR