linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Florian Weimer <fw@deneb.enyo.de>,
	Dave Chinner <david@fromorbit.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] mm, compaction: fix wrong pfn handling in __reset_isolation_pfn()
Date: Tue, 8 Oct 2019 16:51:56 +0100	[thread overview]
Message-ID: <20191008155156.GD3321@techsingularity.net> (raw)
In-Reply-To: <20191008152915.24704-1-vbabka@suse.cz>

On Tue, Oct 08, 2019 at 05:29:15PM +0200, Vlastimil Babka wrote:
> Florian and Dave reported [1] a NULL pointer dereference in
> __reset_isolation_pfn(). While the exact cause is unclear, staring at the code
> revealed two bugs, which might be related.
> 

I think the fix is a good fit. Even if the problem still occurs, it
eliminates an important possibility.

> One bug is that if zone starts in the middle of pageblock, block_page might
> correspond to different pfn than block_pfn, and then the pfn_valid_within()
> checks will check different pfn's than those accessed via struct page. This
> might result in acessing an unitialized page in CONFIG_HOLES_IN_ZONE configs.
> 

s/acessing/accessing/

Aside from HOLES_IN_ZONE, the patch addresses an issue if the start
of the zone is not pageblock-aligned. While this is common, it's not
guaranteed. I don't think this needs to be clarified in the changelog as
your example is valid. I'm commenting in case someone decides not to try
the patch because they feel HOLES_IN_ZONE is required.

> The other bug is that end_page refers to the first page of next pageblock and
> not last page of current pageblock. The online and valid check is then wrong
> and with sections, the while (page < end_page) loop might wander off actual
> struct page arrays.
> 
> [1] https://lore.kernel.org/linux-xfs/87o8z1fvqu.fsf@mid.deneb.enyo.de/
> 
> Reported-by: Florian Weimer <fw@deneb.enyo.de>
> Reported-by: Dave Chinner <david@fromorbit.com>
> Fixes: 6b0868c820ff ("mm/compaction.c: correct zone boundary handling when resetting pageblock skip hints")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>

Acked-by: Mel Gorman <mgorman@techsingularity.net>

Just one minor irrelevant note below.

> ---
>  mm/compaction.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index ce08b39d85d4..672d3c78c6ab 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -270,14 +270,15 @@ __reset_isolation_pfn(struct zone *zone, unsigned long pfn, bool check_source,
>  
>  	/* Ensure the start of the pageblock or zone is online and valid */
>  	block_pfn = pageblock_start_pfn(pfn);
> -	block_page = pfn_to_online_page(max(block_pfn, zone->zone_start_pfn));
> +	block_pfn = max(block_pfn, zone->zone_start_pfn);
> +	block_page = pfn_to_online_page(block_pfn);
>  	if (block_page) {
>  		page = block_page;
>  		pfn = block_pfn;
>  	}
>  
>  	/* Ensure the end of the pageblock or zone is online and valid */
> -	block_pfn += pageblock_nr_pages;
> +	block_pfn = pageblock_end_pfn(pfn) - 1;
>  	block_pfn = min(block_pfn, zone_end_pfn(zone) - 1);
>  	end_page = pfn_to_online_page(block_pfn);
>  	if (!end_page)

This is fine and is definetly fixing a potential issue.

> @@ -303,7 +304,7 @@ __reset_isolation_pfn(struct zone *zone, unsigned long pfn, bool check_source,
>  
>  		page += (1 << PAGE_ALLOC_COSTLY_ORDER);
>  		pfn += (1 << PAGE_ALLOC_COSTLY_ORDER);
> -	} while (page < end_page);
> +	} while (page <= end_page);
>  
>  	return false;
>  }

I think this is also ok as it's appropriate for PFN walkers in general of
this style. However, I think it's unlikely to fix anything given that we
are walking in steps of (1 << PAGE_ALLOC_COSTLY_ORDER) and the final page
is not necessarily aligned on that boundary. Still, it's an improvement.

Thanks

-- 
Mel Gorman
SUSE Labs


      reply	other threads:[~2019-10-08 15:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-08 15:29 [PATCH] mm, compaction: fix wrong pfn handling in __reset_isolation_pfn() Vlastimil Babka
2019-10-08 15:51 ` Mel Gorman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191008155156.GD3321@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=fw@deneb.enyo.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).