Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp2981539ybc; Thu, 21 Nov 2019 01:17:23 -0800 (PST) X-Google-Smtp-Source: APXvYqxy4xbdUAxPzBnwqarP5rYcDbkuW/nDkEamCtlqGT5qmBsoNtYudP15mvSZ9e/VxobuXBeM X-Received: by 2002:a17:906:4e94:: with SMTP id v20mr12747668eju.34.1574327843294; Thu, 21 Nov 2019 01:17:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574327843; cv=none; d=google.com; s=arc-20160816; b=DSmljNUGbgNZ0NgMVInN3p9dz/qJQb26Q5lnN91n9tWcyXCVZOBMZg/IHhrokI3DVf rrYaO8OOmhxz4fSupSZE5whhurt+hWHZugp4yKMdr14FAhksdtRnblfhmELsWWx8FfYw 5Yw53nKBCDmnkzDL99PIU/XLINyc31eSHkADdvrlfrbjkyuXVAChJlFgXu2F5dRjT8Re w415dPCc2lATf9fQuJFyMmNRRRQ9caX2nv81FYTHrSDXgHNx8qcmzLzdikZiGGvPqEl4 psLjShsKUmKwfRTsZ500QoUoeH1tTrAwEUAkZEDaufBBKAVKsliOEDIIJ6rAPCYFGWie fRjQ== 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=SVwz702z3wJTxoA1OPb+c+dl3c301ajnRyS31uljRGs=; b=kWl4UvNaI9gW6+4U0YuBKoZCZSDUJJEKIoEWw8lD+42Hnvsy+DO5n5boC6iyfWJ7CS gB7ycEElVQaGcrgE9x3p+NfUxGE/bjiMKeCuZ2g5gyXW4Sge/I2NqPdZRhZ3FRN2gkAA AriwUJA8ybEuHeCQr4i+BBqr2GD/EJuKpf/feSAL4XX6fLmg1F5Y2N1OuZl329cBATI8 ifQDxI+PG/NRsTCW0Gx62Zfp1K8ThJ5apFM6DY2+dRyJVqxcv3yoYSkp6nMff8FCjq83 T7Y8b4Jcv5bqSIUvfhQb8EeguaAWIjVo6Z30OGAkm8EnpRD2l0Ws6TvM6wg8KD24NsOf Mf3g== 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 ss14si1317548ejb.195.2019.11.21.01.16.58; Thu, 21 Nov 2019 01:17:23 -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 S1727289AbfKUJPX (ORCPT + 99 others); Thu, 21 Nov 2019 04:15:23 -0500 Received: from mx2.suse.de ([195.135.220.15]:44446 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726132AbfKUJPX (ORCPT ); Thu, 21 Nov 2019 04:15:23 -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 92B8CB11E; Thu, 21 Nov 2019 09:15:20 +0000 (UTC) Date: Thu, 21 Nov 2019 10:15:18 +0100 From: Petr Mladek To: Sergey Senozhatsky Cc: Sergey Senozhatsky , Qian Cai , Steven Rostedt , 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: <20191121091518.vcohlxzsri2gv4p3@pathway.suse.cz> References: <20190904144850.GA8296@tigerII.localdomain> <1567629737.5576.87.camel@lca.pw> <20190905113208.GA521@jagdpanzerIV> <1573751570.5937.122.camel@lca.pw> <20191118152738.az364dczadskgimc@pathway.suse.cz> <20191119004119.GC208047@google.com> <20191119094134.6hzbjc7l5ite6bpg@pathway.suse.cz> <20191120013005.GA3191@tigerII.localdomain> <20191120161334.p63723g4jyk6k7p3@pathway.suse.cz> <20191121010527.GB191121@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191121010527.GB191121@google.com> 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-21 10:05:27, Sergey Senozhatsky wrote: > On (19/11/20 17:13), Petr Mladek wrote: > [..] > > It is the first time that I hear about problem caused by the > > irq_work(). But we deal with deadlocks caused by wake_up() for years. > > It would be like replacing a lightly dripping tap with a heavily > > dripping one. > > > > I see reports with WARN() from scheduler code from time to time. > > I would get reports about silent death instead. > > Just curious, how many of those WARN() come under rq lock or pi_lock? > // this is real question I guess that all SCHED_WARN_ON() would stop working. I am not 100% sure but I think that all WARN_ON*() in set_task_cpu(), finish_task_switch(), migrate_tasks() are affected. I have seen many reports with the WARN() from native_smp_send_reschedule() about offline CPU. Best Regards, Petr