From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 89425C33CB1 for ; Wed, 15 Jan 2020 09:22:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 53FCE207E0 for ; Wed, 15 Jan 2020 09:22:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 53FCE207E0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DF1098E0009; Wed, 15 Jan 2020 04:22:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DA0E48E0003; Wed, 15 Jan 2020 04:22:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C8FD18E0009; Wed, 15 Jan 2020 04:22:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0210.hostedemail.com [216.40.44.210]) by kanga.kvack.org (Postfix) with ESMTP id B10F98E0003 for ; Wed, 15 Jan 2020 04:22:25 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 7A59C1F1A for ; Wed, 15 Jan 2020 09:22:25 +0000 (UTC) X-FDA: 76379327850.04.bear58_151ce5734bc13 X-HE-Tag: bear58_151ce5734bc13 X-Filterd-Recvd-Size: 4843 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Wed, 15 Jan 2020 09:22:24 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id w15so14994587wru.4 for ; Wed, 15 Jan 2020 01:22:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=O6Fx5eqaqV4mFfMkhI1kCNNjaUd3xOj+I29Cn8Tuc+M=; b=ZglflVx46fSD/0C+BYwUHrH8S+f8aHRF/6l9XvxWQI2hgxnjwVNTUvtsli88okRB6u 8FU8ETu4+LZFpsEKKscv7EoDPsIgwYgC7ZwS4oc9rFyiitfwWhOgNuU3Yq5NJFeOkvtA WwCQ1c1ieNGlqQGEubExippGhIdo3++c5yNdAvTC69jTXtaNHmWQrV0kmNEc4CKUh6UK vBXoGVLU4HjmtWqgtaPu50NczMfseD17QHTTEm6YSzQk7rhwz7TWQgtYM1tSUouUpeGg Fn/PEi3+xccgQdQ6gjq4phAm4JNzR2frDrM1MiS3x54/fFur1kYZ6MKbFpUSZamE7wxX 4PNw== X-Gm-Message-State: APjAAAW/E8fqwKZzXUq6o2FEjWMDKbHYjS3qBW59fE22dJlYoci4ov8q /Kdyi47jR+GBvwWNCDgjJI4= X-Google-Smtp-Source: APXvYqzYN49FR1sFPCG2CULBNTV+pZPhfE+hHQPbGDilOx7rpmYmeEIFPuI8mZw0xSGw9fbalnTwyw== X-Received: by 2002:adf:fc4b:: with SMTP id e11mr29777612wrs.326.1579080143950; Wed, 15 Jan 2020 01:22:23 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id a5sm22343325wmb.37.2020.01.15.01.22.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jan 2020 01:22:22 -0800 (PST) Date: Wed, 15 Jan 2020 10:22:21 +0100 From: Michal Hocko To: Qian Cai Cc: akpm@linux-foundation.org, sergey.senozhatsky.work@gmail.com, pmladek@suse.com, rostedt@goodmis.org, peterz@infradead.org, david@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH -next v2] mm/hotplug: silence a lockdep splat with printk() Message-ID: <20200115092221.GX19428@dhcp22.suse.cz> References: <20200115053130.15490-1-cai@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200115053130.15490-1-cai@lca.pw> User-Agent: Mutt/1.12.2 (2019-09-21) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed 15-01-20 00:31:30, Qian Cai wrote: > It is guaranteed to trigger a lockdep splat if calling printk() with > zone->lock held because there are many places (tty, console drivers, > debugobjects etc) would allocate some memory with another lock > held which is proved to be difficult to fix them all. This really should mention that most of them are false positives due to early code intialization which cannot really cause a real lockup. AFAIR you have also found some that really do allocate (GFP_ATOMIC) from the console callback and those should be really fixed IMHO. > A common workaround until the onging effort to make all printk() as > deferred happens is to use printk_deferred() in those places similar to > the recent commit [1] merged into the random and -next trees, but memory > offline will call dump_page() which needs to be deferred after the lock. > > So change has_unmovable_pages() so that it no longer calls dump_page() > itself - instead it returns a "struct page *" of the unmovable page back > to the caller so that in the case of a has_unmovable_pages() failure, > the caller can call dump_page() after releasing zone->lock. Also, make > dump_page() is able to report a CMA page as well, so the reason string > from has_unmovable_pages() can be removed. OK, this is slightly better than your previous attempts. Returing the page without holding a reference is a quite subtle though. It should be safe here because the page cannot go away because it is unmovable but please add a comment that explains that the page _must not_ be used for anything else than dumping its state. > While at it, remove a similar but unnecessary debug-only printk() as > well. Because it doesn't really provide any useful information from the practice. [...] > @@ -74,9 +75,9 @@ void __dump_page(struct page *page, const char *reason) > page->mapping, page_to_pgoff(page), > compound_mapcount(page)); > else > - pr_warn("page:%px refcount:%d mapcount:%d mapping:%px index:%#lx\n", > + pr_warn("page:%px refcount:%d mapcount:%d mapping:%px index:%#lx cma:%d\n", > page, page_ref_count(page), mapcount, > - page->mapping, page_to_pgoff(page)); > + page->mapping, page_to_pgoff(page), page_cma); Is this correct? CMA pages cannot be comound? Btw. I would simply do pr_warn("page:%px refcount:%d mapcount:%d mapping:%px index:%#lx%s\n", ...., page_cmap ? "CMA": ""); -- Michal Hocko SUSE Labs