From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2AAA434E74F for ; Thu, 12 Mar 2026 16:02:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773331326; cv=none; b=CfzslDZ9QsdqnrFIrYKF0FrL9YvMCiFdjRrRj2O8oh7KwVDHuXemppTiEDTy8VNd8XLscCi7sgX6t/ibKSKjiP676qZKGuB7z8kgEMGUpDC+AscUwj/czTsSsSdcbAVNbcLWIpyS6uABpWjcO/8TPA+JkDujRoWCFHTszL4pvp4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773331326; c=relaxed/simple; bh=Pk6i8yoSLmvjbHvV1MTtVmz1qPYslpyIivwjKzVBn8Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YVfN8hTnge9l0FAddl/t9vAtjT+Ee/UQXz/hRyytXAK4kzOlSp6Y2RQy6AWGgEd/XowmqcBke31RBZD2/wMVgon+fOLiY2t+mZZjpFQyzRipUxqlLVjMuRhIVpAxtwC0sOm79e36Gw8P/uL6amJMJyFzoEx8uwIYcQYh7yPY4o4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=rbLc8vZ/; arc=none smtp.client-ip=209.85.128.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="rbLc8vZ/" Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-79863ab8478so12262967b3.3 for ; Thu, 12 Mar 2026 09:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1773331323; x=1773936123; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Qy73+iGNGeECV0rQjpRLn6tiSFKzdH9itGL02lldZDY=; b=rbLc8vZ/FcDkhvwgG62p7BH84BmsDhlouJqv20KeeVZXwAdbkr/BR4+NMeooweOoZn TMHrT+ReYzyZB6sqN+Re28uCz+O0R8VqZLVFDQflZdcniwQkJoM9S3oxXsTN1y4Naeeh Ky2lxze5YixfoJIlJUyCz3JOfH5lJeTDpRh+eLD92jhJULina3EpzBhpS+eYiPLq/xvw d3hOoZiIVGZg1pLCunZQPDWQTej/UiTWIvLUni8TpQn7pqWDX7xr5jskr36FR+fkmJz/ PRWvItN7ZPaOrgJC5JQd9s3wXET+13MrJLPVN218S+mjcrfoJ9YuW5abbphmVmPhWhbe P3Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773331323; x=1773936123; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Qy73+iGNGeECV0rQjpRLn6tiSFKzdH9itGL02lldZDY=; b=kYJgqJEL9uy1IdCyt5+bjx6OSPjl15NcM7SRRMIGgxtdc4MZo9IfMoZgy8g7z+ljVR GADZ6r9djv6iYf7flPdAmrbq/eZm9x/4zejYwHGiPe97kp3bIRIn1TG6Zd1Wau0mMB7h DDNc+9TMz9sgvlvZbqply7KDDDbC95AHfhEH24SEau3V6gujmp+tF391KBtRKfMdVM9a qbO8/ToDcwOL/NlrpKsR3CRSquNE04rNB5pHtzYgS0BET7FF7Hgxk6Ro21uCZtf4RhOt TFyeTvBSgrFQo6q8eGZN88AKHWW447geCN/E5g1nyWuPzJH8fRIIkpHGlh+viTiXtg7j 3Tcg== X-Forwarded-Encrypted: i=1; AJvYcCXiJ4sIZA9KVaqtz9LdCwRTYx8Ln6sGy2zCTM4yiwYucswdRxNwRovEDFsgRoeE0vUYEiENiENvIICUP4s=@vger.kernel.org X-Gm-Message-State: AOJu0YzF//Rmp7JfKMQUfWOYpVEH1FXUH/ELku5W0wBdnEo08T6crinU nQKLDxrnzUwBQ872lEzt3yH5yttYnOFpIDmQUWdln2lhWTETtHgGC2IWmpVO4Lua5+g= X-Gm-Gg: ATEYQzwguJwKCbCofppBdAaTOieEc3OR2oRE5r3Fz/nKvkqYJEKRIFNylE1yPSqH/6M iGJy/HUL/FjLjt7BjM0pDq5pFskIo2p3iQnVcdxRku4XHFu7t9VOFns0DfnZSue1Na7fSZJyBkO r6i1aYdEblTP66r/Sr+lXD2WtXKCBAYBxTZkQlDWTaAMb+y16Uw60MOEc8QI1EYDiEjEvdQOwSy 60xRw1gkIG4K8P532Qv/U5rULT6eDzF5Sp4MFIYJQsZFpJAWaTywuKupJ71bGY4QmDCQccyWczi LAW0N6PWgyRI7mlz6WuT1fxWgv4VHWqQBDcNzPbNTr3/EUUeoouCaNuMsHQ67enlJ9nmZqeT/p9 DAQGTwbSM91kqg7bk4IhkYWhqSXfKsWhkwnE4TOCTZcszBBRTrmzwkL/VEcsEwRwUDuOfFB+eGy w4q3m7fLkUS3wy7+Uy6Aa10UK5UZJSrFm5Rj/7VLBLUAAzNQ6Tn+cgnCDdf05Oplz2bLSOIz4Nf n0etdJrFw== X-Received: by 2002:a05:690c:6389:b0:796:45d4:9e2d with SMTP id 00721157ae682-79a1c1dce28mr556267b3.53.1773331321722; Thu, 12 Mar 2026 09:02:01 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-96-255-20-138.washdc.ftas.verizon.net. [96.255.20.138]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-89a65d2160asm37260386d6.52.2026.03.12.09.02.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Mar 2026 09:02:01 -0700 (PDT) Date: Thu, 12 Mar 2026 12:01:57 -0400 From: Gregory Price To: Johannes Weiner Cc: Alexandre Ghiti , akpm@linux-foundation.org, alexghiti@kernel.org, kernel-team@meta.com, akinobu.mita@gmail.com, david@kernel.org, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, zhengqi.arch@bytedance.com, shakeel.butt@linux.dev, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, apopple@nvidia.com, byungchul@sk.com, joshua.hahnjy@gmail.com, matthew.brost@intel.com, rakie.kim@sk.com, ying.huang@linux.alibaba.com, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Bing Jiao , stable@vger.kernel.org Subject: Re: [PATCH 3/4] mm: Fix demotion gfp by clearing GFP_RECLAIM after setting GFP_TRANSHUGE Message-ID: References: <20260311110314.237315-1-alex@ghiti.fr> <20260311110314.237315-4-alex@ghiti.fr> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Mar 11, 2026 at 01:54:50PM -0400, Johannes Weiner wrote: > On Wed, Mar 11, 2026 at 12:02:42PM +0100, Alexandre Ghiti wrote: > > GFP_TRANSHUGE sets __GFP_DIRECT_RECLAIM so we must clear GFP_RECLAIM > > after, not before. > > > > Reported-by: Bing Jiao > > Closes: https://lore.kernel.org/linux-mm/aXlKOxGGI9zne8sl@google.com/ > > Fixes: 9933a0c8a539 ("mm/migrate: clear __GFP_RECLAIM to make the migration callback consistent with regular THP allocations") > > Cc: stable@vger.kernel.org > > Signed-off-by: Alexandre Ghiti > > --- > > mm/migrate.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/migrate.c b/mm/migrate.c > > index 2c3d489ecf51..ee533a4d38db 100644 > > --- a/mm/migrate.c > > +++ b/mm/migrate.c > > @@ -2190,12 +2190,12 @@ struct folio *alloc_migration_target(struct folio *src, unsigned long private) > > } > > > > if (folio_test_large(src)) { > > + gfp_mask |= GFP_TRANSHUGE; > > /* > > * clear __GFP_RECLAIM to make the migration callback > > * consistent with regular THP allocations. > > */ > > gfp_mask &= ~__GFP_RECLAIM; > > - gfp_mask |= GFP_TRANSHUGE; > > I don't think this is right. > > The Fixes: did it this way to disable kswapd for THP allocations, > while still allowing the customary direct reclaim. Maybe a better > comment would have been: /* GFP_TRANSHUGE has its own reclaim policy */ > The bigger issue how many times we see this particular flag getting masked and apparently added back in at multiple layers. We saw two or three paths (some unreachable) that can twiddle RECLAIM flags in the stack for demotion (which is in reclaim already, so do the flags matter?). It makes it difficult to reason about what the GFP flags actually are at any given point. But yeah I wasn't sure to make of this code, it could be as you suggested just a bad comment. ~Gregory