From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755303AbcBIQl3 (ORCPT ); Tue, 9 Feb 2016 11:41:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55460 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751197AbcBIQl2 (ORCPT ); Tue, 9 Feb 2016 11:41:28 -0500 Message-ID: <56BA16B5.60805@redhat.com> Date: Tue, 09 Feb 2016 17:41:25 +0100 From: Denys Vlasenko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Steven Rostedt CC: linux-kernel@vger.kernel.org, srostedt@redhat.com, Tejun Heo , Peter Hurley Subject: Re: [PATCH] printk: avoid livelock if another CPU printks continuously References: <1454963703-20433-1-git-send-email-dvlasenk@redhat.com> <20160208161123.2ceb601d@gandalf.local.home> <56B9FEE4.3010502@redhat.com> <20160209101707.540641fb@gandalf.local.home> <56BA04AD.7090903@redhat.com> <20160209105024.3606f233@gandalf.local.home> In-Reply-To: <20160209105024.3606f233@gandalf.local.home> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/09/2016 04:50 PM, Steven Rostedt wrote: > On Tue, 09 Feb 2016 16:24:29 +0100 >>>>>> + /* Good, other CPU entered "for(;;)" loop */ >>>>>> + goto out; >>>>>> + } >>>>>> + } >>>>>> + /* No one seems to be willing to take it... */ >>>>>> + if (console_trylock()) >>>>>> + goto again; /* we took it */ >>>>> >>>>> Perhaps add a few loops to the taking of the console sem. >>>> >>>> Why? >>>> >>>> If we fail to take the lock, another CPU took it. >>>> There is no need to try harder, as soon as we know that any >>>> other CPU took that lock, we can safely exit this function. >>> >>> Because if this CPU is the one spamming the other CPU, it will widen >>> the window to be the one that takes the lock. >> >> If we reached this code, we aren't the spamming CPU. We are the CPU >> which is being spammed (we are in the loop which services the backlog). > > No, I mentioned the taking of console sem. The spamming task will be > trying that a bit, failing and then letting this CPU continue doing its > bidding. That's exactly what we *don't* want to happen. We want that other CPU to get the lock. How do you plan to achieve that, if not by giving it a grace period when it can grab a lock?