From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 43BD9310777 for ; Wed, 17 Jun 2026 06:02:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781676142; cv=none; b=SXpK88yDRTUgd79y1h5dLmSjoiNLsYGZdUI6l9kFM4+SKI7sPdJ760mxLkzJIekBhg+nFAJnJWv/0BZB5h3QphaHrEc4q8VZWbQMIkksDk5ftuRzrGL1JbV8awiEhP60ogO95emKBECblOZMhdLl1v7IMgzc5bt+ac8bj1HYWm8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781676142; c=relaxed/simple; bh=WZ2tcMt/VXGR51Z7THmm91dyiFJHy8Q6EppDU8I/NvA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=B7XjSpjm35CSeM9Wvd5o6+mk2+73ompc6hKlBRW6LwkWm9ss/eWYNo6UVgcL0Zjg+eThnrhjRR6plKsYzZm55H+s7LiJnO5nzE7QD5CokyrMOTOre4z2SdIQMI+uIV485VQApWyyfSqFP29cOPWm0kn5RSBo4BNaaxkcyEi3vcM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=d1qEgAUA; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="d1qEgAUA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97B2B1F000E9; Wed, 17 Jun 2026 06:02:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781676141; bh=Tdg+qxsERN6xrjUnxPGS2XNaJdEod0AKmfxv6p5DAjE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=d1qEgAUAo6blDAhN91UNiZow7zQ464yVflIh9uH8SnlNEterfQJsfiUwxOWvNfU1S WtERR+Hb2aOl+EQ+3PLnHJGjOOeev5luXk98tx/A1znZ2jguGLacUX37MBFlDK6zDp FTLNL4zrANsVYKUmoQxNZijPnHjV9oPA4TOCEDTaV53FLw7iDHFP3yWKWCOTLedpkc VWwPuSJPp4BlXilsYd1YU2kUB+5y+UAKVNx7swEj1qimxwoKP+csf6le0/wIYrF6/m /O/ejAsblbG6z2mHY4Y9SQbL+qTQFcVtEbVb2j/mDZtplx4AlaqwpDX0/YGmcFkDOP aihEFDXrBYoYg== Date: Tue, 16 Jun 2026 23:02:19 -0700 From: Dennis Zhou To: Kaitao Cheng Cc: Andrew Morton , Uladzislau Rezki , Dennis Zhou , Tejun Heo , Christoph Lameter , Vlastimil Babka , Michal Hocko , muchun.song@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Kaitao Cheng Subject: Re: [PATCH v3 1/3] mm/vmalloc: honor GFP constraints in pcpu_get_vm_areas() Message-ID: References: <20260612022648.13008-1-kaitao.cheng@linux.dev> <20260612022648.13008-2-kaitao.cheng@linux.dev> 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: <20260612022648.13008-2-kaitao.cheng@linux.dev> Hello, On Fri, Jun 12, 2026 at 10:26:46AM +0800, Kaitao Cheng wrote: > From: Kaitao Cheng > > pcpu_alloc_noprof() derives pcpu_gfp from the caller supplied GFP mask > and passes it down to the backing percpu allocator. However, when the > percpu vmalloc allocator has to create a new chunk, pcpu_create_chunk() > calls pcpu_get_vm_areas() to allocate the corresponding vmalloc areas. > > pcpu_get_vm_areas() currently performs its internal allocations with > GFP_KERNEL, including vmap area metadata, vm_struct metadata and KASAN > vmalloc shadow population. This means that a caller which deliberately > uses GFP_NOFS or GFP_NOIO can still enter FS or IO reclaim while creating > the vmalloc areas for a new percpu chunk. > > One possible case is blk-cgroup after commit 5d726c4dbeed > ("blk-cgroup: fix possible deadlock while configuring policy"). > blkg_conf_prep() now serializes against blkcg_deactivate_policy() with > q->blkcg_mutex, and blkg_alloc() was changed to GFP_NOIO for that reason: > > CPU0: blkg_conf_prep() > mutex_lock(q->blkcg_mutex) > blkg_alloc(..., GFP_NOIO) > alloc_percpu_gfp(..., GFP_NOIO) > pcpu_alloc_noprof(..., GFP_NOIO) > pcpu_create_chunk(GFP_NOIO) > pcpu_get_vm_areas() > -> if percpu chunks are exhausted, chunk create may do > internal GFP_KERNEL allocations > -> direct reclaim / writeback can issue IO to this queue > -> IO waits because the queue is frozen > > CPU1: blkcg_deactivate_policy() > blk_mq_freeze_queue(q) > mutex_lock(q->blkcg_mutex) > -> waits for CPU0 > ... unfreeze only happens after q->blkcg_mutex is acquired/released > > So the concern is that the caller deliberately uses GFP_NOIO because it > may hold a lock which can be acquired after queue freeze, but the percpu > slow path can temporarily lose that allocation context. > > Pass the caller supplied GFP mask from pcpu_create_chunk() to > pcpu_get_vm_areas(), and use it for the internal vmalloc metadata and > KASAN shadow allocations. > > Fixes: 9a5b183941b5 ("mm, percpu: do not consider sleepable allocations atomic") > Signed-off-by: Kaitao Cheng > Reviewed-by: Uladzislau Rezki (Sony) > --- Acked-by: Dennis Zhou Thanks, Dennis