Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp2966231ybc; Mon, 18 Nov 2019 07:29:38 -0800 (PST) X-Google-Smtp-Source: APXvYqzNOIRErsR614Hu8Cikk+LAxyGtQDtieiuB8JxyZJeWDB3qHTquREYEl95O/AsClRrSu6LU X-Received: by 2002:a17:906:c45:: with SMTP id t5mr26630369ejf.296.1574090978518; Mon, 18 Nov 2019 07:29:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574090978; cv=none; d=google.com; s=arc-20160816; b=vX4/0LuCdTDFwqqQ1oMs1az/71fp1bVMT9F99XiTNsJdbaUc2LIFKeYB750tpWNIbM DFlcORtOYnhV893crE8gxMty/0SiE0U7/1YO8bVaO0/LGOVSucUa+WsS5LgQ5CV46aFQ VEUYurtOHLuhZGCqh8JXHXDBAi1syWgFZHyiWbfbClA4FUVkuMeRdaJPtFLYvdzPvG4Z sVHRQQ0oJqHcfxF2bbyx/FIJ5E23/XuoyW9urog/92hOT9UCmvwt2v8rXMdn9Me9aBlZ 52E3DZUmUTBeG3dwQ2ut3nR3VhisC26s4680fzsMAzFy7xsCVEUhaWcxechiB2Xcn9Lv YnEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=iOMHwhsp2ObzledAnpVEDvy4iAt96bzZ7a69cXSRUwA=; b=QOBwsAMcXmmr39Vl2qvkkOFJW4F2FsreAWgLbHo760rXlvtKFUr6t2TGjF1XzDRqA5 sPVrumY1SJBxOmppinbZDUhgz7uJl23aD3+B9tlrmJeOPJ3L+8GlGaBE71usXuO2IbcJ wf1PJCgt1SkFWCMjjplinHw5lqakwfJMcCBke5ZkIixScOy9WCu0foHpHtNjpFcXfcBQ +yIPsjyC6u3IEGIrIhKYIbB8cdVuS+/b4vYWhUwOaZYhZL48kUBog3Qq+7e8+kpdj9yj qyVM/pEXfAiCC2oAMTkQTZ1EvH2YahQHzDcuO6/k7TgT7NOchQI2FYs/N21Sjx+6aK8W mDqA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id pj27si11429436ejb.241.2019.11.18.07.29.14; Mon, 18 Nov 2019 07:29:38 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727190AbfKRP1m (ORCPT + 99 others); Mon, 18 Nov 2019 10:27:42 -0500 Received: from mx2.suse.de ([195.135.220.15]:37566 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726578AbfKRP1l (ORCPT ); Mon, 18 Nov 2019 10:27:41 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 22DD6AE55; Mon, 18 Nov 2019 15:27:39 +0000 (UTC) Date: Mon, 18 Nov 2019 16:27:38 +0100 From: Petr Mladek To: Qian Cai Cc: Sergey Senozhatsky , Steven Rostedt , Sergey Senozhatsky , Michal Hocko , Eric Dumazet , davem@davemloft.net, netdev@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] net/skbuff: silence warnings under memory pressure Message-ID: <20191118152738.az364dczadskgimc@pathway.suse.cz> References: <20190904061501.GB3838@dhcp22.suse.cz> <20190904064144.GA5487@jagdpanzerIV> <20190904065455.GE3838@dhcp22.suse.cz> <20190904071911.GB11968@jagdpanzerIV> <20190904074312.GA25744@jagdpanzerIV> <1567599263.5576.72.camel@lca.pw> <20190904144850.GA8296@tigerII.localdomain> <1567629737.5576.87.camel@lca.pw> <20190905113208.GA521@jagdpanzerIV> <1573751570.5937.122.camel@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1573751570.5937.122.camel@lca.pw> User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 2019-11-14 12:12:50, Qian Cai wrote: > On Thu, 2019-09-05 at 20:32 +0900, Sergey Senozhatsky wrote: > > On (09/04/19 16:42), Qian Cai wrote: > > > > Let me think more. > > > > > > To summary, those look to me are all good long-term improvement that would > > > reduce the likelihood of this kind of livelock in general especially for other > > > unknown allocations that happen while processing softirqs, but it is still up to > > > the air if it fixes it 100% in all situations as printk() is going to take more > > > time > > > > Well. So. I guess that we don't need irq_work most of the time. > > > > We need to queue irq_work for "safe" wake_up_interruptible(), when we > > know that we can deadlock in scheduler. IOW, only when we are invoked > > from the scheduler. Scheduler has printk_deferred(), which tells printk() > > that it cannot do wake_up_interruptible(). Otherwise we can just use > > normal wake_up_process() and don't need that irq_work->wake_up_interruptible() > > indirection. The parts of the scheduler, which by mistake call plain printk() > > from under pi_lock or rq_lock have chances to deadlock anyway and should > > be switched to printk_deferred(). > > > > I think we can queue significantly much less irq_work-s from printk(). > > > > Petr, Steven, what do you think? > > Sergey, do you still plan to get this patch merged? > > > > > Something like this. Call wake_up_interruptible(), switch to > > wake_up_klogd() only when called from sched code. > > > > --- > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > > index cd51aa7d08a9..89cb47882254 100644 > > --- a/kernel/printk/printk.c > > +++ b/kernel/printk/printk.c > > @@ -2027,8 +2027,11 @@ asmlinkage int vprintk_emit(int facility, int level, > > pending_output = (curr_log_seq != log_next_seq); > > logbuf_unlock_irqrestore(flags); > > > > + if (!pending_output) > > + return printed_len; > > + > > /* If called from the scheduler, we can not call up(). */ > > - if (!in_sched && pending_output) { > > + if (!in_sched) { > > /* > > * Disable preemption to avoid being preempted while holding > > * console_sem which would prevent anyone from printing to > > @@ -2043,10 +2046,11 @@ asmlinkage int vprintk_emit(int facility, int level, > > if (console_trylock_spinning()) > > console_unlock(); > > preempt_enable(); > > - } > > > > - if (pending_output) > > + wake_up_interruptible(&log_wait); I do not like this. As a result, normal printk() will always deadlock in the scheduler code, including WARN() calls. The chance of the deadlock is small now. It happens only when there is another process waiting for console_sem. We want to remove locks from printk() and not add them. Best Regards, Petr