From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (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 4F65035581D for ; Mon, 12 Jan 2026 11:09:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768216199; cv=none; b=TWDksPksqJunleWje+042UNC3aENAtOmgMUcKuaNM16lXiot9LPRmQC1tr5yL2NelHP716Ba/1It1S5RtgNzn7tu3YKoc2WV743fTcN5k4CbieS5zXo4vUUBibTeh8XxvL4X+G5yOCz39fjazXSl6DGo2ybo3kenbCto+uj/xdc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768216199; c=relaxed/simple; bh=CAhjXFVV6eQ8wGDDtxt7TZXKzjOsRmfHq2cvatCMwZ4=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lrclBC5TOsqsbk++xhOCuMdyoSCW9Jgr6GJJEKhlR2XBPShQxvzdhBQwghQKdbEswqrH1WjgVJ86m+HFLTBLiX4UxzUFFwdKteTBkr3TIxRqKoB2bQjrd+842dpj7RKjF8fQ6wJQGq6kzUgNN9f/KMV7nPFr2bM5Vfb/oJO1LjU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=deTdagAK; arc=none smtp.client-ip=209.85.167.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="deTdagAK" Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-59b7bb3b913so4288730e87.1 for ; Mon, 12 Jan 2026 03:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768216193; x=1768820993; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=hJnK/ei48zDVB0dQO8DBPDRFjRo4ADnGxtGvkG0ch+E=; b=deTdagAKHOGX3AWhVmz/O6w5bwFbhVgl12nkQY0RLq67pSdTvjqPbSc5Z9hZXgyvAN q5f44y/arTRnOS9vBq/UGrHtv092Y13caOzIJs7h/dW4o4s2ArGHAAsBXtI6x0+1bh8k wuCtlY5g99+uHj00VMm/MqyWgGbh6CdEXjaTH5Ng1YTzbUPQ0N4vJV/KOCQop9OL3QT5 c4r3iQQSaFfxfJvvcS0HjjstgvdgD6TmKtzS3+VIpEZXZXhYtuFhbV4qAxDeLIRuOLl4 bfwYfi/CLzYYaL7JcaGf2dQuBdMAdGQZ10999KJrzG7nDnbFwO32Gvs9AkbQd4Sm821/ cxgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768216193; x=1768820993; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hJnK/ei48zDVB0dQO8DBPDRFjRo4ADnGxtGvkG0ch+E=; b=l3IGSd/N/KNGVPGP/dZpirazBPRz5qg/+EvXvluYyC2zj1IBGpR1NoyoMObtO6ZubJ mwxC8mYidTjb1R+bl3dQdDdBUrCHFpIAZpsITrKZoZ0L4vBe8d2DFvGsmsJolZBPLJZG 8dKse3yNtC8aM4+D0wiqKfBuHTi8hbHOVw8ns8wjpVfr+zKDLqK/LMyVwIRbTFPkd95M D7J3eP2kPjY/KlikF+0/Tr+l10or737sJNh7q4azNBdvhQe3fmsbMFFwW16ZLuSF2+Kk FAZVDh4GDKR1n96Sksi3jmvpt3tzlN25hhYlq3rcXQN/mqv9ZFgCUYklx287ac9ZWQ8E 7oGw== X-Forwarded-Encrypted: i=1; AJvYcCUMKhTb0mkmmLLvtikOUe9Z0bn9GPanDiOqhFHyMvvXgSPoPqkj6uPYIYkB5akyxuIFq6t7RG6tslgNQG4=@vger.kernel.org X-Gm-Message-State: AOJu0YyAM1MUY/APy81ynh4QR3A6kQgRyRkebDKFxWNv6ZNCjjvqUVOj bYCAzdNtxruSc7RfxxetzrH36bqLZAINeLjLKOiovvhMYWAPFkaSP9pk X-Gm-Gg: AY/fxX5NRueUzBkAPOjRQcOvGe1kDZXPBGbbt1u8D3B1LB80rlTKfOBybXj0dLdm01t IvXlSq9C13wDWZduvciJJpEotU0ROfjdJ1nqsI2TDdtzEMb29CDzJJRrtRj4/vj4pD09S7AUAjH CS3rtdmYVsQjwSImltqO82W5WsTg759aGdtKn6GDE7a+Vhnk0CEIi18Co2nP2NN2m5b9oi5QYd+ JF4pZWc2WURsxU9AseMlJFuxbeDz5LkehdCkBIzU20ihRhvtzk9PR+oq+AgiQVXlmq2CG00r+Gj wPZW70QurJ+67FraumrDLUPHNJ3tqxOsWY5lgyfzr7gq6ZDKaDvYNso8krVaceU32emqyHphtjX l2BJ/GnIXKprn2FwtW6JADuHatae17pnTldLYC/fj3LKCpbzCke5oNFj/nfxU33K9ZSC02Q5Ksd gMGiUbDjEicVIz3vgiTgC8x76vGmbtFPysmjcLGQ== X-Google-Smtp-Source: AGHT+IEp/se7xsBn5Zy5m6ezN/he+DrJVk9vJFsoad8vBJwhFX14R+WJyNjzHktCAH5Re/onvRS+Mw== X-Received: by 2002:a05:6512:3b06:b0:598:e985:21ef with SMTP id 2adb3069b0e04-59b6eb6b363mr5513280e87.24.1768216193127; Mon, 12 Jan 2026 03:09:53 -0800 (PST) Received: from pc636 (host-95-203-18-139.mobileonline.telia.com. [95.203.18.139]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-59b732da1e7sm3696067e87.18.2026.01.12.03.09.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 03:09:52 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Mon, 12 Jan 2026 12:09:50 +0100 To: Deepanshu Kartikey Cc: akpm@linux-foundation.org, urezki@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, syzbot+d8d4c31d40f868eaea30@syzkaller.appspotmail.com Subject: Re: [PATCH v2] mm/vmalloc: prevent RCU stalls in kasan_release_vmalloc_node Message-ID: References: <20260112103612.627247-1-kartikey406@gmail.com> 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: <20260112103612.627247-1-kartikey406@gmail.com> On Mon, Jan 12, 2026 at 04:06:12PM +0530, Deepanshu Kartikey wrote: > When CONFIG_PAGE_OWNER is enabled, freeing KASAN shadow pages during > vmalloc cleanup triggers expensive stack unwinding that acquires RCU > read locks. Processing a large purge_list without rescheduling can > cause the task to hold CPU for extended periods (10+ seconds), leading > to RCU stalls and potential OOM conditions. > > The issue manifests in purge_vmap_node() -> kasan_release_vmalloc_node() > where iterating through hundreds or thousands of vmap_area entries and > freeing their associated shadow pages causes: > > rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: > rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P6229/1:b..l > ... > task:kworker/0:17 state:R running task stack:28840 pid:6229 > ... > kasan_release_vmalloc_node+0x1ba/0xad0 mm/vmalloc.c:2299 > purge_vmap_node+0x1ba/0xad0 mm/vmalloc.c:2299 > > Each call to kasan_release_vmalloc() can free many pages, and with > page_owner tracking, each free triggers save_stack() which performs > stack unwinding under RCU read lock. Without yielding, this creates > an unbounded RCU critical section. > > Add periodic cond_resched() calls within the loop to allow: > - RCU grace periods to complete > - Other tasks to run > - Scheduler to preempt when needed > > The fix uses need_resched() for immediate response under load, with > a batch count of 32 as a guaranteed upper bound to prevent worst-case > stalls even under light load. > > Reported-by: syzbot+d8d4c31d40f868eaea30@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=d8d4c31d40f868eaea30 > Link: https://lore.kernel.org/all/20260112084723.622910-1-kartikey406@gmail.com/T/ [v1] > Suggested-by: Uladzislau Rezki > Signed-off-by: Deepanshu Kartikey > --- > v2: Use a macro for batch size (suggested by Uladzislau Rezki) > --- > mm/vmalloc.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 41dd01e8430c..51e58701565d 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2268,11 +2268,14 @@ decay_va_pool_node(struct vmap_node *vn, bool full_decay) > reclaim_list_global(&decay_list); > } > > +#define KASAN_RELEASE_BATCH_SIZE 32 > + > static void > kasan_release_vmalloc_node(struct vmap_node *vn) > { > struct vmap_area *va; > unsigned long start, end; > + unsigned int batch_count = 0; > > start = list_first_entry(&vn->purge_list, struct vmap_area, list)->va_start; > end = list_last_entry(&vn->purge_list, struct vmap_area, list)->va_end; > @@ -2282,6 +2285,11 @@ kasan_release_vmalloc_node(struct vmap_node *vn) > kasan_release_vmalloc(va->va_start, va->va_end, > va->va_start, va->va_end, > KASAN_VMALLOC_PAGE_RANGE); > + > + if (need_resched() || (++batch_count >= KASAN_RELEASE_BATCH_SIZE)) { > + cond_resched(); > + batch_count = 0; > + } > } > > kasan_release_vmalloc(start, end, start, end, KASAN_VMALLOC_TLB_FLUSH); > -- > 2.43.0 > Reviewed-by: Uladzislau Rezki (Sony) -- Uladzislau Rezki