Received: by 2002:ac0:950e:0:0:0:0:0 with SMTP id f14csp306858imc; Sat, 16 Mar 2019 01:35:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqw2TbQ6bY/maqgwCbK0trJS71C2S0c4xledsrq6qm5zZHpSQdTy/aeTvu7T2/Ab1vZb0yOg X-Received: by 2002:a62:f201:: with SMTP id m1mr8379385pfh.97.1552725327069; Sat, 16 Mar 2019 01:35:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552725327; cv=none; d=google.com; s=arc-20160816; b=MfFGz50gxLVUFE07ShG3gKDDLSQRP+2ozL0sMFcQ0ZjM2xDg9VEOczkgvG1KJI/WPl t2K/ja6JCpsyELMOh0oKGbsqcGKOUrUmGFt9rPXo2hHyB9i4iPJI2fX8Fn4sRMYqBqwH i4tR55dqFKpcbNIo76PgujmsxJ5z0mqWeJAvtYcHBjpmUPjAojPWLl3icD53lgkNofXo RDnuRY+P4XTDyKB9lbzrWvsmrsiwOwBEMY8YG4dQJriBlvEngypN3nqvZGoY/O20kn7R c/sAwdm/KmKqArUeqTwBsAvBLjVAYw6osmxJcMj803NCdHVzs/EzE1BXLFGZb/HfZy6R fERg== 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=ITA6CL5hCZRyW7s8fFzIfwI8ElWa95Hy9WtyMFBGPMo=; b=QjHzEDul/EDyF+WarCzpy5MRyUF2fuYVVnMk7/w1/xIJTGMivIo+8cJVtQ7M53J1ed 0sy5LbGUNOxIYYfiB/tLJfn3izPGTscEOT1+BE253Hl2gKuYMh7Zt/3ec91tb1bCC+TG jvNeKv3/oTv6NV2a+FG6VxBa98Nd5WEdDhjz240vyaZtQCNCSmhgpmmbs4ekcersS6lR o5bK40lCswU/jsS/3IlfdTeDh6qvstCyCYm62r+mIuA4gv0Q8F9yecW5xkC5oIw80YUq aX2gJvorkjnHf+sak5v5SNa9+XOuRNYJ166BFmgcDQzwnNSvHb4Zh3oD1CGRjHxz0paq 3XdQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b2si3745009pls.31.2019.03.16.01.35.11; Sat, 16 Mar 2019 01:35:27 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726310AbfCPIeh (ORCPT + 99 others); Sat, 16 Mar 2019 04:34:37 -0400 Received: from mx2.suse.de ([195.135.220.15]:34920 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725970AbfCPIeg (ORCPT ); Sat, 16 Mar 2019 04:34:36 -0400 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 B8205ACD7; Sat, 16 Mar 2019 08:34:35 +0000 (UTC) Date: Sat, 16 Mar 2019 09:34:34 +0100 From: Michal Hocko To: Hugh Dickins Cc: Oscar Salvador , akpm@linux-foundation.org, anshuman.khandual@arm.com, william.kucharski@oracle.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jan Kara Subject: Re: [PATCH] mm: Fix __dump_page when mapping->host is not set Message-ID: <20190316083434.GI15672@dhcp22.suse.cz> References: <20190315121826.23609-1-osalvador@suse.de> <20190315124733.GE15672@dhcp22.suse.cz> <20190315143304.pkuvj4qwtlzgm7iq@d104.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [my mbox didn't get synced completely so our emails "crossed"] On Fri 15-03-19 10:21:18, Hugh Dickins wrote: > On Fri, 15 Mar 2019, Oscar Salvador wrote: > > On Fri, Mar 15, 2019 at 01:47:33PM +0100, Michal Hocko wrote: > > > diff --git a/mm/debug.c b/mm/debug.c > > > index 1611cf00a137..499c26d5ebe5 100644 > > > --- a/mm/debug.c > > > +++ b/mm/debug.c > > > @@ -78,6 +78,9 @@ void __dump_page(struct page *page, const char *reason) > > > else if (PageKsm(page)) > > > pr_warn("ksm "); > > > else if (mapping) { > > > + if (PageSwapCache(page)) > > > + mapping = page_swap_info(page)->swap_file->f_mapping; > > > + > > > pr_warn("%ps ", mapping->a_ops); > > > if (mapping->host->i_dentry.first) { > > > struct dentry *dentry; > > > > This looks like a much nicer fix, indeed. > > I gave it a spin and it works. > > > > Since the mapping is set during the swapon, I would assume that this should > > always work for swap. > > Although I am not sure if once you start playing with e.g zswap the picture can > > change. > > > > Let us wait for Hugh and Jan. > > > > Thanks Michal > > Sorry, I don't agree that Michal's more sophisticated patch is nicer: > the appropriate patch was your original, just checking for NULL. > > Though, would I be too snarky to suggest that your patch description > would be better at 2 lines than 90? Swap mapping->host is NULL, > so of course __dump_page() needs to be careful about that. > > I was a little disturbed to see __dump_page() now getting into dentries, > but admit that it can sometimes be very helpful to see the name of the > file involved; so if that is not in danger of breaking anything, okay. > > It is very often useful to see if a page is PageSwapCache (typically > because that should account for 1 of its refcount); I cannot think of > a time when it's been useful to know the name of the underlying swap > device (if that's indeed what f_mapping leads to: it's new to me). > And if you need swp_type and swp_offset, they're in the raw output. > > The cleverer __dump_page() tries to get, the more likely that it will > itself crash just when you need it most. Please just keep it simple. OK, fair enough. If we ever have anybody suggesting to follow the swap lead then we can add it. I do not have a good use case for that right now. Let's go with Oscar's original patch. Thanks! Acked-by: Michal Hocko -- Michal Hocko SUSE Labs