Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp569503pxu; Wed, 25 Nov 2020 10:03:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJy8TZ+ekx/EJmQ7aRJ0p21sm2bm6czylvyfFoXVL7KJX65OJlfmvP0M+xpNq2/g5s3drwt9 X-Received: by 2002:aa7:c249:: with SMTP id y9mr4473272edo.67.1606327392819; Wed, 25 Nov 2020 10:03:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606327392; cv=none; d=google.com; s=arc-20160816; b=DOGysADv84PXYJSdzkHQB9kLfYi5RyJdF6KAd3eizwrh8kHc5TLD2ZomXRbEXXeYOV sfqvaV07wsyRaBhVC9UrwxRXBiT+vzdEdXZ1NAfZkjE51WrcYt4hbITM4bvkac+X9cO7 2hXReJtmnLgKHhiYQA6Ra30M8xUHGDLBT79XSSW4ZVytcGTJ1PY6I4p8vG8H5svDQy7R yjnUCuwvDfhGr4v0Az05nNFOQx1en0EKK4Kr0nQUJOtnT6x9SuirkHqr4izp0PBJmrls wM134y8oN9NvBhQjGYGEZCbmWr7zCKoz7Z07tXlOAphF50acaQzk+lbBN8W0pmXkscVc r97A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=f2TfpgLBbqTLgJ/HITwubrW+9Ir09rOmpEtYtMzPxVI=; b=saFJfS3owdpb7hMqPf+BWz3TKsqXz1LLdRJkbPfZcUWy5hfKSdDC5BkeLSnXovEJX2 MIso1mLJHE8z7j5qQxFMCoNOQHuyqrPh833FAcMATnqD1/Iddn8enXlnl+ht1WefNV0G zJqSQ2GKmxceXwsLmStrxS+IYcd/+BRwe97veYkYxb3HvPN+XiJRjb8EH/5n07iT5kKH ARkKnPp4kI6m/TR8Wh3vA0NJAUB7Xdffga73KjSlmMIss2PfoiyQnU2yVTRCv21mIrot P5S2imOlNHRfDdVGnlqKyOBhqhJUJekpun/onrIBu6acNaBRKVSIPaPLYggR3BnEkN5L F+vQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fO67HqHC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g20si1632150edh.74.2020.11.25.10.02.48; Wed, 25 Nov 2020 10:03:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fO67HqHC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731621AbgKYSAK (ORCPT + 99 others); Wed, 25 Nov 2020 13:00:10 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:37786 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730420AbgKYSAK (ORCPT ); Wed, 25 Nov 2020 13:00:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606327209; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=f2TfpgLBbqTLgJ/HITwubrW+9Ir09rOmpEtYtMzPxVI=; b=fO67HqHCbQs28MFcfeaNq44Hi9X9aH8vZxiDCRTFY8yQTqBjN/N4OGoCIdRHBunis2ZyF3 n5hpvxQ2xMSprnbimzRzzWH3uQTf754FYq3clCURf8mE1sWrZ1bKdynhONLY7hU8kQ7wwr 9iWYQhtCCkH8MfvW3CH+MCQvaVsXBSw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-447-LYalrKdJM3iCrbc3A1jHRg-1; Wed, 25 Nov 2020 13:00:04 -0500 X-MC-Unique: LYalrKdJM3iCrbc3A1jHRg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3245C1074640; Wed, 25 Nov 2020 18:00:03 +0000 (UTC) Received: from mail (ovpn-112-118.rdu2.redhat.com [10.10.112.118]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 836E260855; Wed, 25 Nov 2020 17:59:59 +0000 (UTC) Date: Wed, 25 Nov 2020 12:59:58 -0500 From: Andrea Arcangeli To: Mel Gorman Cc: Vlastimil Babka , Andrew Morton , linux-mm@kvack.org, Qian Cai , Michal Hocko , David Hildenbrand , linux-kernel@vger.kernel.org, Mike Rapoport , Baoquan He Subject: Re: [PATCH 1/1] mm: compaction: avoid fast_isolate_around() to set pageblock_skip on reserved pages Message-ID: References: <8C537EB7-85EE-4DCF-943E-3CC0ED0DF56D@lca.pw> <20201121194506.13464-1-aarcange@redhat.com> <20201121194506.13464-2-aarcange@redhat.com> <20201124133205.GK3306@suse.de> <20201125103053.GL3306@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201125103053.GL3306@suse.de> User-Agent: Mutt/2.0.2 (2020-11-20) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 25, 2020 at 10:30:53AM +0000, Mel Gorman wrote: > On Tue, Nov 24, 2020 at 03:56:22PM -0500, Andrea Arcangeli wrote: > > Hello, > > > > On Tue, Nov 24, 2020 at 01:32:05PM +0000, Mel Gorman wrote: > > > I would hope that is not the case because they are not meant to overlap. > > > However, if the beginning of the pageblock was not the start of a zone > > > then the pages would be valid but the pfn would still be outside the > > > zone boundary. If it was reserved, the struct page is valid but not > > > suitable for set_pfnblock_flags_mask. However, it is a concern in > > > general because the potential is there that pages are isolated from the > > > wrong zone. > > > > I guess we have more than one issue to correct in that function > > because the same BUG_ON reproduced again even with the tentative patch > > I posted earlier. > > > > So my guess is that the problematic reserved page isn't pointed by the > > min_pfn, but it must have been pointed by the "highest" variable > > calculated below? > > > > if (pfn >= highest) > > highest = pageblock_start_pfn(pfn); > > > > When I looked at where "highest" comes from, it lacks > > pageblock_pfn_to_page check (which was added around v5.7 to min_pfn). > > > > Is that the real bug, which may be fixed by something like this? (untested) > > > > It's plausible as it is a potential source of leaking but as you note > in another mail, it's surprising to me that valid struct pages, even if > within memory holes and reserved would have broken node/zone information > in the page flags. I think the patch to add pageblock_pfn_to_page is still needed to cope with !pfn_valid or a pageblock in between zones, but pfn_valid or pageblock in between zones is not what happens here. So the patch adding pageblock_pfn_to_page would have had the undesired side effect of hiding the bug so it's best to deal with the other bug first.