From: Michal Hocko <mhocko@kernel.org>
To: Nick Desaulniers <nick.desaulniers@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
mgorman@techsingularity.net, vbabka@suse.cz,
Minchan Kim <minchan@kernel.org>, linux-mm <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
paullawrence@google.com
Subject: Re: [PATCH] mm/vmscan: fix unsequenced modification and access warning
Date: Thu, 22 Mar 2018 10:50:44 +0100 [thread overview]
Message-ID: <20180322095044.GA23100@dhcp22.suse.cz> (raw)
In-Reply-To: <CAH7mPvh0qG2R30ToKV=dX3YNc+0BQtnCH3cQUANJWmVdbn6sXw@mail.gmail.com>
On Wed 21-03-18 14:37:04, Nick Desaulniers wrote:
> Sorry to dig up an old thread but a coworker was asking about this
> patch. This is essentially the code that landed in commit
> f2f43e566a02a3bdde0a65e6a2e88d707c212a29 "mm/vmscan.c: fix unsequenced
> modification and access warning".
>
> Is .reclaim_idx still correct in the case of try_to_free_pages()?
Yes, it gets initialized from the given gfp_mask. sc.gfp_mask might be
sllightly different but that doesn't change the reclaim_idx because we
only drop __GFP_{FS,IO} which do not have any zone modification effects.
> It
> looks like reclaim_idx is based on the original gfp_mask in
> __node_reclaim(), but in try_to_free_pages() it looks like it may have
> been based on current_gfp_context()? (The sequencing is kind of
> ambiguous, thus fixed in my patch)
>
> Was there a bug in the original try_to_free_pages() pre commit
> f2f43e566a0, or is .reclaim_idx supposed to be different between
> try_to_free_pages() and __node_reclaim()?
I do not think there was any real bug.
--
Michal Hocko
SUSE Labs
prev parent reply other threads:[~2018-03-22 9:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-10 6:53 [PATCH] mm/vmscan: fix unsequenced modification and access warning Nick Desaulniers
2017-05-10 7:15 ` Michal Hocko
2017-05-10 8:27 ` [Patch v2] " Nick Desaulniers
2017-05-10 8:38 ` Michal Hocko
2017-05-16 8:27 ` Michal Hocko
2017-05-17 3:01 ` Nick Desaulniers
2017-05-26 4:43 ` Nick Desaulniers
2017-05-31 15:21 ` Michal Hocko
2017-05-10 8:46 ` [PATCH] " Nick Desaulniers
2017-05-10 9:25 ` Michal Hocko
2017-05-10 15:40 ` [Patch v3] " Nick Desaulniers
2018-03-21 21:37 ` [PATCH] " Nick Desaulniers
2018-03-22 9:50 ` Michal Hocko [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=20180322095044.GA23100@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=minchan@kernel.org \
--cc=nick.desaulniers@gmail.com \
--cc=paullawrence@google.com \
--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).