From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.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 EF8F52264C7 for ; Sun, 23 Aug 2026 23:01:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787526103; cv=none; b=CYwozHzxqzCgDoKqzna0V2DPEu0u90/0duJEerSo6RbbyVm9oH9tspygk1HBacKoNMmWCzXL73FBW/Oew/8L6/xQET1Tt6ICnCxe9BS4ApAyDPFj5llylOEKtT48ORrb3K/PWOcr0mp0XGGBhvv3Asa52rvXI8VOHnIigKPj/lU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787526103; c=relaxed/simple; bh=X4vU0jrIDDnDBJ+yCuscV6b5ynMxLzlodmmIiDrAeFU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lLJwJp3mBXLJleZLAHQwNsjeY/4Aln60bkQ9qP7T2p6+4+slmvvqybIJTTUgecZb17BaDLFcJ6UOEZpE9q/0z20lfc9O4CbQLBzKAF5dZcU7GWPDgzZPDy6AsGJkCXQlf2OQ4CzqYA8kXYAQPDDumohLoz9x1BxG6ylH9FEO2EM= 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=i8d95cWG; arc=none smtp.client-ip=209.85.160.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="i8d95cWG" Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-527e352a167so17905401cf.1 for ; Sun, 23 Aug 2026 16:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1787526101; x=1788130901; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=OBBDznrj/QvBtLL3STRylJUtnIkvdfK3qqt1IzYGCsg=; b=i8d95cWGpuLW+1BssWAyBcXUL5bwcFpeFF94eUWWJ4QBRumUG4+BKYBWUIvBTxoltQ oll7GvclCnjf2vhoq85BKlOXsBrUIifIw8VLFeCIKIXejAGNptYFc/Itj0spXYOLpqDd 9QR4i/iiTcfoLqzUSaQTeSIjnMe/AGKCWleK4xXSdWoUWhCYCux92ST8g5UspzB25tWJ q4hvGXtQeYlzk13BWd22g+i+/EfqGSkaQMLmkesov2eT01+iYEhzdk45IB88Q+jAMK/T NylKf5o/1/2HhrB3wBrpv35BRTKn701dqQaaFxScWL9mjkCYP+W8n5IQIq+1Wg4GosRQ 3pJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787526101; x=1788130901; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=OBBDznrj/QvBtLL3STRylJUtnIkvdfK3qqt1IzYGCsg=; b=F8VunbJdlkjOBxlubP4X768ol9kS8pGYrAZObf6fziiorMiCsUC+oesDzjHdBNzgxv c7ph/IIUD2/B0WV1ceCAcJQYCFYC58RUmjMjsiliwQJ2GTb78TPsNsDypVbuKllWXHJd HI1AI5P2Xsllx6gxgyeheD38zNesH4Nabglot9FcmPjkpvQGnenKGbSWgpZZYGoZtmWW 0tPu7nE7PgqGN37e4du4joFL3fRN+4eLAkp9KyCMKz0P5btHer56Gg6r+A8mUFRFhNtp 3Npt5vrCLPwQGPof84uCAe2/pA4Tms3qwLjojMh0nRKbamyF01o3Tqg00aUKOjBBsx5Z VHJw== X-Forwarded-Encrypted: i=1; AHgh+Rr8bzHxkD4gowREv35/83CQn2KSbRqnIa5AKNQ7EioD4ETkzY7MlNwqJ/XSN+70U1BEFm3G8pE5noC6uZE=@vger.kernel.org X-Gm-Message-State: AFuF++kkL/gCthTxARwqW1CGEZelyP7uaJCRMSAtI2iey7gaLs4pjOEV v1BUar1lEobBPlMITB1mi9qt9E9fT2j5hFXsRNwdcBDlkdeADtRCyN6GMvCU2+7Eiac= X-Gm-Gg: AR+sD13BRkTq9jRrydxVt1XWmqf15pQ1035O7b8okxc9zika6d/maqoj7vzJf2mrQ1L cXdwXd4RmiipkGsVlmDXJkBdte481pRBwHuHeG7WEBwc13346CL/yR6I27nfD9yJf3+wCyz00wE J0gARYNErnpBgMkVUX6eO0JH16M2d7TLL53wjNXlW6FXUta8Yn9tsZvOgCoNlMyO7NWiHzyHwk0 uvxEmdyqbwti8Q7rex3lG3jvN1bXfdGaxgi8xj2zzkn0u2UCYaQYP3qPitcOdArjzs9GTVtUhum avSQ+yhqNIwu39qAuHcPLjn6RH1Kr3lGKAADkiVREhJEKqvVE8X42OAiJ+a13GBQuyQVF5kykSm 5remI8eK4cb3Ir5N8JaD1r5CSNfoOi6CrgBZ9aLo7PllR485YE5AONx3swy+oSHkBNJPu+Whyro AVhp6DgcHzY30SqB3aInCDor+bDndx6tW8scKV9iLufUMf2K1bAOFGPAF+KxdoESIjL4yDaWTay k1grMiV/3dFmWZ/veZEqxmtNjRNzf8DjyM+FAwdo+6jmN4CZQhnE60= X-Received: by 2002:ac8:6f14:0:b0:51c:b98a:2448 with SMTP id d75a77b69052e-52df56f9741mr225201801cf.9.1787526100658; Sun, 23 Aug 2026 16:01:40 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-173-79-60-52.washdc.fios.verizon.net. [173.79.60.52]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-52e09aca49dsm36057701cf.23.2026.08.23.16.01.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Aug 2026 16:01:39 -0700 (PDT) Date: Sun, 23 Aug 2026 19:01:37 -0400 From: Gregory Price To: Andrew Morton Cc: Eric Dumazet , linux-kernel , syzbot+0dbf6d295b3350944f0b@syzkaller.appspotmail.com, David Hildenbrand , Zi Yan , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Ying Huang , Alistair Popple , linux-mm@kvack.org Subject: Re: [PATCH] mm/mempolicy: Fix sleeping allocation in alloc_pages_bulk_weighted_interleave() Message-ID: References: <20260821170407.3721004-1-edumazet@google.com> <20260821104043.f692421fec915c0c5bc1fbe6@linux-foundation.org> 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: <20260821104043.f692421fec915c0c5bc1fbe6@linux-foundation.org> On Fri, Aug 21, 2026 at 10:40:43AM -0700, Andrew Morton wrote: > > --- a/mm/mempolicy.c > > +++ b/mm/mempolicy.c > > @@ -2688,7 +2688,7 @@ static unsigned long alloc_pages_bulk_weighted_interleave(gfp_t gfp, > > prev_node = node; > > > > /* create a local copy of node weights to operate on outside rcu */ > > - weights = kzalloc(nr_node_ids, GFP_KERNEL); > > + weights = kmalloc(nr_node_ids, gfp & GFP_RECLAIM_MASK); > > I wonder if we *really* need the local copy of state->iw_table. > Perhaps with appropriate care we can directly use state->iw_table in > here. > > How much would it hurt to expand the rcu_read_lock() coverage? > Ah, the current space we'd expand rcu read lock into is the actual allocation - which we can't do. Same with the spinlock. We can clean this up with a refcount + rcu_free and kill the allocation in the hot path. Will get something out this week. ~Gregory