From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753055AbdKBLqy (ORCPT ); Thu, 2 Nov 2017 07:46:54 -0400 Received: from mx2.suse.de ([195.135.220.15]:41103 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751122AbdKBLqw (ORCPT ); Thu, 2 Nov 2017 07:46:52 -0400 Date: Thu, 2 Nov 2017 12:46:50 +0100 From: Petr Mladek To: Steven Rostedt Cc: Vlastimil Babka , Tetsuo Handa , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Cong Wang , Dave Hansen , Johannes Weiner , Mel Gorman , Michal Hocko , Sergey Senozhatsky , "yuwang.yuwang" Subject: Re: [PATCH] mm: don't warn about allocations which stall for too long Message-ID: <20171102114650.GB31148@pathway.suse.cz> References: <1509017339-4802-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> <20171031153225.218234b4@gandalf.local.home> <187a38c6-f964-ed60-932d-b7e0bee03316@suse.cz> <20171101133845.GF20040@pathway.suse.cz> <20171101113647.243eecf8@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171101113647.243eecf8@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 2017-11-01 11:36:47, Steven Rostedt wrote: > On Wed, 1 Nov 2017 14:38:45 +0100 > Petr Mladek wrote: > > My current main worry with Steven's approach is a risk of deadlocks > > that Jan Kara saw when he played with similar solution. > > And if there exists such a deadlock, then the deadlock exists today. The patch is going to effectively change console_trylock() to console_lock() and this might add problems. The most simple example is: console_lock() printk() console_trylock() was SAFE. console_lock() printk() console_lock() cause DEADLOCK! Sure, we could detect this and avoid waiting when console_owner == current. But does this cover all situations? What about? CPU0 CPU1 console_lock() func() console->write() take_lockA() func() printk() busy wait for console_lock() take_lockA() By other words, it used to be safe to call printk() from console->write() functions because printk() used console_trylock(). Your patch is going to change this. It is even worse because you probably will not use console_lock() directly and therefore this might be hidden for lockdep. BTW: I am still not sure how to make the busy waiter preferred over console_lock() callers. I mean that the busy waiter has to get console_sem even if there are some tasks in the workqueue. > > But let's wait for the patch. It might look and work nicely > > in the end. > > Oh, I need to write a patch? Bah, I guess I should. Where's all those > developers dying to do kernel programing where I can pass this off to? Yes, where are these days when my primary task was to learn kernel hacking? This would have been a great training material. I still have to invest time into fixing printk. But I personally think that the lazy offloading to kthreads is more promising way to go. It is pretty straightforward. The only problem is the guaranty of the takeover. But there must be a reasonable way how to detect that the system heart is still beating and we are not the only working CPU. Best Regards, Petr From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f71.google.com (mail-wm0-f71.google.com [74.125.82.71]) by kanga.kvack.org (Postfix) with ESMTP id D80726B0260 for ; Thu, 2 Nov 2017 07:46:52 -0400 (EDT) Received: by mail-wm0-f71.google.com with SMTP id 198so2805656wmg.6 for ; Thu, 02 Nov 2017 04:46:52 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id q20si11890edc.14.2017.11.02.04.46.51 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 02 Nov 2017 04:46:51 -0700 (PDT) Date: Thu, 2 Nov 2017 12:46:50 +0100 From: Petr Mladek Subject: Re: [PATCH] mm: don't warn about allocations which stall for too long Message-ID: <20171102114650.GB31148@pathway.suse.cz> References: <1509017339-4802-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> <20171031153225.218234b4@gandalf.local.home> <187a38c6-f964-ed60-932d-b7e0bee03316@suse.cz> <20171101133845.GF20040@pathway.suse.cz> <20171101113647.243eecf8@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171101113647.243eecf8@gandalf.local.home> Sender: owner-linux-mm@kvack.org List-ID: To: Steven Rostedt Cc: Vlastimil Babka , Tetsuo Handa , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Cong Wang , Dave Hansen , Johannes Weiner , Mel Gorman , Michal Hocko , Sergey Senozhatsky , "yuwang.yuwang" On Wed 2017-11-01 11:36:47, Steven Rostedt wrote: > On Wed, 1 Nov 2017 14:38:45 +0100 > Petr Mladek wrote: > > My current main worry with Steven's approach is a risk of deadlocks > > that Jan Kara saw when he played with similar solution. > > And if there exists such a deadlock, then the deadlock exists today. The patch is going to effectively change console_trylock() to console_lock() and this might add problems. The most simple example is: console_lock() printk() console_trylock() was SAFE. console_lock() printk() console_lock() cause DEADLOCK! Sure, we could detect this and avoid waiting when console_owner == current. But does this cover all situations? What about? CPU0 CPU1 console_lock() func() console->write() take_lockA() func() printk() busy wait for console_lock() take_lockA() By other words, it used to be safe to call printk() from console->write() functions because printk() used console_trylock(). Your patch is going to change this. It is even worse because you probably will not use console_lock() directly and therefore this might be hidden for lockdep. BTW: I am still not sure how to make the busy waiter preferred over console_lock() callers. I mean that the busy waiter has to get console_sem even if there are some tasks in the workqueue. > > But let's wait for the patch. It might look and work nicely > > in the end. > > Oh, I need to write a patch? Bah, I guess I should. Where's all those > developers dying to do kernel programing where I can pass this off to? Yes, where are these days when my primary task was to learn kernel hacking? This would have been a great training material. I still have to invest time into fixing printk. But I personally think that the lazy offloading to kthreads is more promising way to go. It is pretty straightforward. The only problem is the guaranty of the takeover. But there must be a reasonable way how to detect that the system heart is still beating and we are not the only working CPU. Best Regards, Petr -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org