Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp5138751ybl; Mon, 26 Aug 2019 23:27:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqzI5CFZ3oOrg4l0fw97lae4F+9WH+Sz/VnP4kHEA6GQ58/tKqw/6IG3pGh46q9mL1Z6SMmW X-Received: by 2002:a63:9245:: with SMTP id s5mr20224427pgn.123.1566887241546; Mon, 26 Aug 2019 23:27:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566887241; cv=none; d=google.com; s=arc-20160816; b=EyvXUIAAxJ/HklWsA929IWGJVGCvI5mbL8n8hJZRRXIqKG2YC/XUO4Hzxe5XmnSVtj ggAqDWOWDvUG58i5BpRfZj53mDVpFzhVH7gy7ZBlw6Kgk2xnabNHIkng5SW0kZiB7deo +ACbEaAOTHunFZIW4L9ikQw7b0q4SMQ94Qv47NIN7vPlMlJWoIzaHffgsthlrNySq2ar gDd6yiY2GCy1lyMIphyMvMnpnJF63V/AyBostTiT2NiIWs97fEiSZS8b+ZslYp3SSE/d QxiB2w1a4tqtNC+m8FrfIb/Mc9G4s2svN3bnOb0qmVm4sv2XMVf1RPNWKmHDGztIQa8Y IlgA== 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=G4ZDiSFwgCz7yvt6D2ZuftsnYdpv0yKp/SsacyGy3g8=; b=vRzjMX38ry1fOX4HZu5A4JayaBK2mPHvskaPwrQ5Epayg8Bg1Wa2Ivzam8rqpkJ6wc NZdJpEx1ZOtotkofDNbrO/ALgU/wCMyRTDdaUhZttz2ssrDswtLnKPqxCDY0NF5uQnGQ FVqGvPyRqnEJu2W60k20JmlMVtLdvnwuEJcmq63B1b8n6++b+7DPmNCf7dMBe2hNWLdI 3zL+lvMlzjHJF1pUoqIs2PD/EctJtHbcYhRqk1nxHKmDiJ+09KcWZaJBsqQwuIqTcDz0 Tc77UaN/Vwf7uFyl6fUilc4LE97ChaD9SsXbq100BnZqz9qK/I7qZTJG4YoFfN+L/aOI XKjQ== 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 r4si11157405pgi.304.2019.08.26.23.27.05; Mon, 26 Aug 2019 23:27:21 -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 S1726278AbfH0GYs (ORCPT + 99 others); Tue, 27 Aug 2019 02:24:48 -0400 Received: from mx2.suse.de ([195.135.220.15]:55320 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725825AbfH0GYs (ORCPT ); Tue, 27 Aug 2019 02:24:48 -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 491DDADB3; Tue, 27 Aug 2019 06:24:47 +0000 (UTC) Date: Tue, 27 Aug 2019 08:24:45 +0200 From: Michal Hocko To: Alastair D'Silva Cc: alastair@d-silva.org, Andrew Morton , Oscar Salvador , Mike Rapoport , Dan Williams , Wei Yang , David Hildenbrand , Qian Cai , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] mm: don't hide potentially null memmap pointer in sparse_remove_section Message-ID: <20190827062445.GO7538@dhcp22.suse.cz> References: <20190827053656.32191-1-alastair@au1.ibm.com> <20190827053656.32191-3-alastair@au1.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190827053656.32191-3-alastair@au1.ibm.com> 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 On Tue 27-08-19 15:36:55, Alastair D'Silva wrote: > From: Alastair D'Silva > > By adding offset to memmap before passing it in to clear_hwpoisoned_pages, > we hide a theoretically null memmap from the null check inside > clear_hwpoisoned_pages. Isn't that other way around? Calculating the offset struct page pointer will actually make the null check effective. Besides that I cannot really see how pfn_to_page would return NULL. I have to confess that I cannot really see how offset could lead to a NULL struct page either and I strongly suspect that the NULL check is not really needed. Maybe it used to be in the past. > This patch passes the offset to clear_hwpoisoned_pages instead, allowing > memmap to successfully perform it's null check. I do not see any improvement in this patch. It just adds a new argument unnecessarily. > Signed-off-by: Alastair D'Silva > --- > mm/sparse.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/mm/sparse.c b/mm/sparse.c > index e41917a7e844..3ff84e627e58 100644 > --- a/mm/sparse.c > +++ b/mm/sparse.c > @@ -882,7 +882,7 @@ int __meminit sparse_add_section(int nid, unsigned long start_pfn, > } > > #ifdef CONFIG_MEMORY_FAILURE > -static void clear_hwpoisoned_pages(struct page *memmap, int nr_pages) > +static void clear_hwpoisoned_pages(struct page *memmap, int start, int count) > { > int i; > > @@ -898,7 +898,7 @@ static void clear_hwpoisoned_pages(struct page *memmap, int nr_pages) > if (atomic_long_read(&num_poisoned_pages) == 0) > return; > > - for (i = 0; i < nr_pages; i++) { > + for (i = start; i < start + count; i++) { > if (PageHWPoison(&memmap[i])) { > num_poisoned_pages_dec(); > ClearPageHWPoison(&memmap[i]); > @@ -906,7 +906,8 @@ static void clear_hwpoisoned_pages(struct page *memmap, int nr_pages) > } > } > #else > -static inline void clear_hwpoisoned_pages(struct page *memmap, int nr_pages) > +static inline void clear_hwpoisoned_pages(struct page *memmap, int start, > + int count) > { > } > #endif > @@ -915,7 +916,7 @@ void sparse_remove_section(struct mem_section *ms, unsigned long pfn, > unsigned long nr_pages, unsigned long map_offset, > struct vmem_altmap *altmap) > { > - clear_hwpoisoned_pages(pfn_to_page(pfn) + map_offset, > + clear_hwpoisoned_pages(pfn_to_page(pfn), map_offset, > nr_pages - map_offset); > section_deactivate(pfn, nr_pages, altmap); > } > -- > 2.21.0 > -- Michal Hocko SUSE Labs