From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751574AbdARH3l (ORCPT ); Wed, 18 Jan 2017 02:29:41 -0500 Received: from mail-pg0-f65.google.com ([74.125.83.65]:33957 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751090AbdARH3i (ORCPT ); Wed, 18 Jan 2017 02:29:38 -0500 Date: Wed, 18 Jan 2017 16:21:41 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Steven Rostedt , Sergey Senozhatsky , Tetsuo Handa , Peter Zijlstra , Andrew Morton , Greg Kroah-Hartman , Jiri Slaby , linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, ergey Senozhatsky Subject: Re: [PATCH] printk: Correctly handle preemption in console_unlock() Message-ID: <20170118072141.GB881@jagdpanzerIV.localdomain> References: <1484313321-17196-1-git-send-email-pmladek@suse.com> <20170113110542.2c3e42c5@gandalf.local.home> <20170116110012.GE20462@pathway.suse.cz> <20170118054551.GA881@jagdpanzerIV.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170118054551.GA881@jagdpanzerIV.localdomain> User-Agent: Mutt/1.7.2 (2016-11-26) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (01/18/17 14:45), Sergey Senozhatsky wrote: [..] > > there is a function that clears @console_may_schedule out of > console_sem scope - console_flush_on_panic(). > so I *may be* can think about a worst case scenario of race > condition between > console_flush_on_panic()->console_may_schedule = 0 on panic CPU > and > console_unlock()->console_may_schedule = 1 from CPU that panic CPU > failed to stop (smp_send_stop() can return with secondary CPUs still being > online). what I mean, is that we can have, let's say, 2 CPUs spinning in console_unlock(), both with @console_may_schedule == 1 (because secondary CPU restores global @console_may_schedule value). now, suppose, we have misbehaving scheduler (well, we are in panic after all). secondary CPU will cond_resched() and may be lockup somewhere in the scheduler. which is fine, we don't care about that secondary CPU anyway. but the same can happen to panic CPU as well. what do you think? -ss From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergey Senozhatsky Date: Wed, 18 Jan 2017 07:21:41 +0000 Subject: Re: [PATCH] printk: Correctly handle preemption in console_unlock() Message-Id: <20170118072141.GB881@jagdpanzerIV.localdomain> List-Id: References: <1484313321-17196-1-git-send-email-pmladek@suse.com> <20170113110542.2c3e42c5@gandalf.local.home> <20170116110012.GE20462@pathway.suse.cz> <20170118054551.GA881@jagdpanzerIV.localdomain> In-Reply-To: <20170118054551.GA881@jagdpanzerIV.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Petr Mladek Cc: Steven Rostedt , Sergey Senozhatsky , Tetsuo Handa , Peter Zijlstra , Andrew Morton , Greg Kroah-Hartman , Jiri Slaby , linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, ergey Senozhatsky On (01/18/17 14:45), Sergey Senozhatsky wrote: [..] > > there is a function that clears @console_may_schedule out of > console_sem scope - console_flush_on_panic(). > so I *may be* can think about a worst case scenario of race > condition between > console_flush_on_panic()->console_may_schedule = 0 on panic CPU > and > console_unlock()->console_may_schedule = 1 from CPU that panic CPU > failed to stop (smp_send_stop() can return with secondary CPUs still being > online). what I mean, is that we can have, let's say, 2 CPUs spinning in console_unlock(), both with @console_may_schedule = 1 (because secondary CPU restores global @console_may_schedule value). now, suppose, we have misbehaving scheduler (well, we are in panic after all). secondary CPU will cond_resched() and may be lockup somewhere in the scheduler. which is fine, we don't care about that secondary CPU anyway. but the same can happen to panic CPU as well. what do you think? -ss