From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751406AbeAWPVi (ORCPT ); Tue, 23 Jan 2018 10:21:38 -0500 Received: from mail-pg0-f65.google.com ([74.125.83.65]:38285 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751209AbeAWPVf (ORCPT ); Tue, 23 Jan 2018 10:21:35 -0500 X-Google-Smtp-Source: AH8x227L6Ddj+g6Y5lTJ39kziE6BljcGifdcrbFe99yMUoMgSvf0yiDm0mSwp1TKFqVzloWjFXk8ig== Date: Wed, 24 Jan 2018 00:21:30 +0900 From: Sergey Senozhatsky To: Steven Rostedt Cc: Sergey Senozhatsky , Petr Mladek , Tejun Heo , akpm@linux-foundation.org, linux-mm@kvack.org, Cong Wang , Dave Hansen , Johannes Weiner , Mel Gorman , Michal Hocko , Vlastimil Babka , Peter Zijlstra , Linus Torvalds , Jan Kara , Mathieu Desnoyers , Tetsuo Handa , rostedt@rostedt.homelinux.com, Byungchul Park , Pavel Machek , linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup Message-ID: <20180123152130.GB429@tigerII.localdomain> References: <20180117091208.ezvuhumnsarz5thh@pathway.suse.cz> <20180117151509.GT3460072@devbig577.frc2.facebook.com> <20180117121251.7283a56e@gandalf.local.home> <20180117134201.0a9cbbbf@gandalf.local.home> <20180119132052.02b89626@gandalf.local.home> <20180120071402.GB8371@jagdpanzerIV> <20180120104931.1942483e@gandalf.local.home> <20180121141521.GA429@tigerII.localdomain> <20180123064023.GA492@jagdpanzerIV> <20180123095652.5e14da85@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180123095652.5e14da85@gandalf.local.home> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (01/23/18 09:56), Steven Rostedt wrote: [..] > > Why do we even use irq_work for printk_safe? > > Why not? > > Really, I think you are trying to solve a symptom and not the problem. > If we are having issues with irq_work, we are going to have issues with > a work queue. It's just spreading out the problem instead of fixing it. I don't want to have heuristics in print_safe, I don't want to have a magic number controlled by a user-space visible knob, I don't want to have the first 3 lines of a lockdep splat. The problem is - we flush printk_safe too soon and printing CPU ends up in a lockup - it log_store()-s new messages while it's printing the pending ones. It's fine to do so when CPU is in preemptible context. Really, we should not care in printk_safe as long as we don't lockup the kernel. The misbehaving console must be fixed. If CPU is not in preemptible context then we do lockup the kernel. Because we flush printk_safe regardless of the current CPU context. If we will flush printk_safe via WQ then we automatically add this "OK! The CPU is preemptible, we can log_store(), it's totally OK, we will not lockup it up." thing. Yes, we fill up the logbuf with probably needed and appreciated or unneeded messages. But we should not care in printk_safe. We don't lockup the kernel... And the misbehaving console must be fixed. I disagree with "If we are having issues with irq_work, we are going to have issues with a work queue". There is a tremendous difference between irq_work on that CPU and queue_work_on(smp_proessor_id()). One does not care about CPU context, the other one does. -ss