Received: by 10.213.65.68 with SMTP id h4csp143573imn; Wed, 21 Mar 2018 14:39:09 -0700 (PDT) X-Google-Smtp-Source: AG47ELs9CWy0vTGeYqXyLt0/hATgWvHdnfvS62tF5qhbw+i5ylPTy2ZMej4n0qnXnCMKvNY0DVtq X-Received: by 10.101.72.198 with SMTP id o6mr15838174pgs.279.1521668349573; Wed, 21 Mar 2018 14:39:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521668349; cv=none; d=google.com; s=arc-20160816; b=YfJiZk18kJZc9BcpMkxITXrpq6xoHvLKOvrIBGqIvc/1eW9K+fhx+JzQG+vFCPChT+ p8iIdtPtfC+Yw+I7usXgNTjfVgS0XuH9ZEupCwx4cauFSxGar9b+XfcdlVNvyshumEw0 AeThfkq//q5q5oAJCQCH6G7w6Uj4Pc643Cg1XpTtBB3J5QbpmlLeq+U/AfkJfKHABWJA /a8CQHMTQuzm8QyVHcLpiIh6srVFeqZo6G5Fddfa/1mInidtssl/nvcTHp3hrxThYX1d EctkgeNBh4BzbUkcxWXg++wsn2JD982W2b0XVXz1zwdtyV2fAtNmUoxZGdr9U0h8NnZ7 9ClA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=rnPxHWXgHoLlIsxJwM1jOXuJ/8lcPThbj1M9bQVyJ2k=; b=Kyy5IG+vCRF2Z1PLCzbD2u1VBO2CGfRmfyr9MeFez9maceKW6l9r3zCOILM9r+UAp4 7S2iTzPWvwj1LauDJH1R2u84QZDOa5tDIvEG86TUFMSvALGoGZWTLm1ln0mZGj+l/CeS 34cGrL1rsHs2h9JetzjIMJbkQhBVvqQjmZwjsYAdGTOp6G4CY0XCwweeBvLVw+MKHOj6 9vvcWk3Y2uJNRHRvQ0NKzqNDmXJAm7/858kVy2GddICVYRRTfcTHjMpWCYm8t0pTxdJM w0Ij/4+rdF5E1TxtV4EPbji1V5WQVhUJFjkk+l8qaS9akiWnKAcbfSsHbRBBbGDMBOR+ m7wg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=bt6ltGKC; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l20si3374074pgc.748.2018.03.21.14.38.43; Wed, 21 Mar 2018 14:39:09 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=bt6ltGKC; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753757AbeCUVhK (ORCPT + 99 others); Wed, 21 Mar 2018 17:37:10 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:45231 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753720AbeCUVhG (ORCPT ); Wed, 21 Mar 2018 17:37:06 -0400 Received: by mail-oi0-f66.google.com with SMTP id 71-v6so5601128oie.12 for ; Wed, 21 Mar 2018 14:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rnPxHWXgHoLlIsxJwM1jOXuJ/8lcPThbj1M9bQVyJ2k=; b=bt6ltGKCoFjaQIViUrUZp2ekaBY+3rYudLnTVj+p1h7I4STNhzI2tC1ERLdc7zc2Ly QISP1S3WDEL2DpdHQgQTt/a0VWkOSjImFa4PadVAlU7JtAhusWGSKMODal7NoJwRuUnb YM7G50M/qaXEJdnpAb3y0zLmoaDfqUoImNMfuZ+3/Vn5i9gaTXvum8qkvlZ3IJi9yKJP KfKK7nMX3uGLIF/H9X6FtA8M+zmDS+qzFoxhZbG0KVbmM48komkhOtIgZKuLDgzpW0Ts s6G+YLA/Sal7+JA64VuaBGDW4Mr8khK6TmWmErODCnr0hAjinNl9etcW96lZWFbbCwTN zf7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rnPxHWXgHoLlIsxJwM1jOXuJ/8lcPThbj1M9bQVyJ2k=; b=qhpGUHsi/Ie7lxpQi7DBXmqP9z0c40AAyaJhvkNyHRMi8uuCDI0z5twvopI6cTuZgv dpLBQc7mQRak4GY9ykK7cF66lmBpsYfp8TaFbFQXIqYsNnleKBt9pHBpNelrGDRYf2Oj brTQ02EDPa3TVBy94g78tq+PDWwLz2TM7PBigDle0HZxlV+/f5srH7Y+G8Gdy3e3+D3C lGupg7wZ7Fksfyyz3+fHVToWSlgiGURIIZUIPAdbZrrKPSuz/ikrSpnLZi556nzYsgDu K7CK/8F+5nExUNfKDfbKY7VN5liLfSv9jjpN96TBaKHSE/xs/dorf2meVDJjhol3zeuy fVsg== X-Gm-Message-State: AElRT7GvjNKNdkimHrtVNtUXMEJWRsasKaG0TqZ9rsUoPnu9iAXIG3eC EHtO+pLejCBvwOoOJmf4vMGLZFvhqFVKZ2PDSeM= X-Received: by 10.202.76.73 with SMTP id z70mr12181621oia.59.1521668225136; Wed, 21 Mar 2018 14:37:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:4294:0:0:0:0:0 with HTTP; Wed, 21 Mar 2018 14:37:04 -0700 (PDT) In-Reply-To: <20170510071511.GA31466@dhcp22.suse.cz> References: <20170510065328.9215-1-nick.desaulniers@gmail.com> <20170510071511.GA31466@dhcp22.suse.cz> From: Nick Desaulniers Date: Wed, 21 Mar 2018 14:37:04 -0700 Message-ID: Subject: Re: [PATCH] mm/vmscan: fix unsequenced modification and access warning To: Michal Hocko Cc: Andrew Morton , Johannes Weiner , mgorman@techsingularity.net, vbabka@suse.cz, Minchan Kim , linux-mm , Linux Kernel Mailing List , paullawrence@google.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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()? 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()? On Wed, May 10, 2017 at 12:15 AM, Michal Hocko wrote: > On Tue 09-05-17 23:53:28, Nick Desaulniers wrote: >> Clang flags this file with the -Wunsequenced error that GCC does not >> have. >> >> unsequenced modification and access to 'gfp_mask' >> >> It seems that gfp_mask is both read and written without a sequence point >> in between, which is undefined behavior. > > Hmm. This is rather news to me. I thought that a = foo(a) is perfectly > valid. Same as a = b = c where c = foo(b) or is the problem in the > following .reclaim_idx = gfp_zone(gfp_mask) initialization? If that is > the case then the current code is OKish because gfp_zone doesn't depend > on the gfp_mask modification. It is messy, right, but works as expected. > > Anyway, we have a similar construct __node_reclaim > > If you really want to change this code, and I would agree it would be > slightly less tricky, then I would suggest doing something like the > following instead > --- > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 5ebf468c5429..ba4b695e810e 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -2965,7 +2965,7 @@ unsigned long try_to_free_pages(struct zonelist *zonelist, int order, > unsigned long nr_reclaimed; > struct scan_control sc = { > .nr_to_reclaim = SWAP_CLUSTER_MAX, > - .gfp_mask = (gfp_mask = current_gfp_context(gfp_mask)), > + .gfp_mask = current_gfp_context(gfp_mask), > .reclaim_idx = gfp_zone(gfp_mask), > .order = order, > .nodemask = nodemask, > @@ -2980,12 +2980,12 @@ unsigned long try_to_free_pages(struct zonelist *zonelist, int order, > * 1 is returned so that the page allocator does not OOM kill at this > * point. > */ > - if (throttle_direct_reclaim(gfp_mask, zonelist, nodemask)) > + if (throttle_direct_reclaim(sc.gfp_mask, zonelist, nodemask)) > return 1; > > trace_mm_vmscan_direct_reclaim_begin(order, > sc.may_writepage, > - gfp_mask, > + sc.gfp_mask, > sc.reclaim_idx); > > nr_reclaimed = do_try_to_free_pages(zonelist, &sc); > @@ -3772,17 +3772,16 @@ static int __node_reclaim(struct pglist_data *pgdat, gfp_t gfp_mask, unsigned in > const unsigned long nr_pages = 1 << order; > struct task_struct *p = current; > struct reclaim_state reclaim_state; > - int classzone_idx = gfp_zone(gfp_mask); > unsigned int noreclaim_flag; > struct scan_control sc = { > .nr_to_reclaim = max(nr_pages, SWAP_CLUSTER_MAX), > - .gfp_mask = (gfp_mask = current_gfp_context(gfp_mask)), > + .gfp_mask = current_gfp_context(gfp_mask), > .order = order, > .priority = NODE_RECLAIM_PRIORITY, > .may_writepage = !!(node_reclaim_mode & RECLAIM_WRITE), > .may_unmap = !!(node_reclaim_mode & RECLAIM_UNMAP), > .may_swap = 1, > - .reclaim_idx = classzone_idx, > + .reclaim_idx = gfp_znoe(gfp_mask), > }; > > cond_resched(); > @@ -3793,7 +3792,7 @@ static int __node_reclaim(struct pglist_data *pgdat, gfp_t gfp_mask, unsigned in > */ > noreclaim_flag = memalloc_noreclaim_save(); > p->flags |= PF_SWAPWRITE; > - lockdep_set_current_reclaim_state(gfp_mask); > + lockdep_set_current_reclaim_state(sc.gfp_mask); > reclaim_state.reclaimed_slab = 0; > p->reclaim_state = &reclaim_state; > > -- > Michal Hocko > SUSE Labs