From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (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 45E463D412D for ; Fri, 3 Apr 2026 17:22:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775236973; cv=none; b=ECsl+5kjBtoJJYj5dHcwf5TXJ/ZMy3hZoTY8Tp0HKmz+4zrfe/PBngbMdsyfrdpPs5GbYAA5gL+Mu7fjjXjSHdGrJYVChdgHxMYf5Nke5z25DvudCUwge6whTS1FUODgO2Y5dJ1v/U86BtpC6lMNnRzFoF59p8Hx5FBYDtqWw90= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775236973; c=relaxed/simple; bh=3fhyzIJizn7kSws392yDPF0poaSi/eZGCmd7o3EdrpQ=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=koXEe28GHjnLZe96TLmFl+9sbdIy6W3UtlZkHk5t9SRx2GRQWRq7K62Z09XpqrOhrNvB1zL7aPnNATjdKgTr9LWdm1J1VgsZn1ij1oO08WGOhWdPqLPYeg6CBUEGXSddJsBVg25DtFGS+JKpZsUAIyiueE/m4wFTsy55sdCzj5o= 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=WbMMgF/8; arc=none smtp.client-ip=209.85.167.54 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="WbMMgF/8" Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-5a3cd6f0447so722355e87.2 for ; Fri, 03 Apr 2026 10:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775236970; x=1775841770; 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=dJED12d87e2OFGfOFcvX5QJpnewt2iLfQSg/1M48KSc=; b=WbMMgF/8oULhfcQwawRrEebCS7cyCagXZuzOrUVOKsBLVaifv73T+FMFG6Wyno2h54 GIGii78FT3rUT9hPpCP76X822JW/hzHYslj/WT7pmuKtm3ogOhddMdKT/u3tBM2AM5dV Lonp+clZm+usWmDLWsN5+1kEbBPOymugd9b3uOWZF1hJPzmCZa3H+SGwWTdPtjeIFjo0 mw5SjFaBpn8JKZFJ/9zhAXIL1IfUl5eOpG82G0WinM+srRSf6BWl3b6jVe8y2mQMHSKW zRz+kvOZk7pNg4umqEyw/EdA+k3bCHBpAKvejddxYcF5i40Efp8TwO1Lx3MvnKtZJwPX nPlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775236970; x=1775841770; 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=dJED12d87e2OFGfOFcvX5QJpnewt2iLfQSg/1M48KSc=; b=D8TyObeVREj49crigdrGteYlCDGhWdPJ4lOuIUuz1HbdUcjMrhkBlJhAVTyWe0Js8L AGeu49vERe98Tsma+rQn+PVzRByHRe3czdZzwPCutSMeQsyhwF2Ry0deifCaAzRvgycV AU96Sjv4myjaMF4p2lNaI/zKF0/xqx+bu6YU0ZqXJ+OOMpskWyoQzEt6h6jjQS0fj0PQ 0buYIiBtofecSKafhtS/55yY0c1DC5+d6Lz9h3komJNhSUlEFL2zXt+P32t7tnRl0L5O ryHmR0NzipWDm/MqbK/gnBDpVLsY4xWPOd++hN/7/x1TNd1VdnMtqus4/j/aA+EIQnJp Rr3w== X-Forwarded-Encrypted: i=1; AJvYcCXzv0kXIgRmUxv0YTeJ8trqphcjuydMijjLV0rSZV+N7PIMHES9oOgydPCH+9NIDFFFcd1/6I/eVG/Dw0c=@vger.kernel.org X-Gm-Message-State: AOJu0YxSDP/08gn0oJeTGz4lTUG5RRUMZdpChDGhGwhc67jlxE8y1bF5 AtYnic8x7A+SL1KeqyZUZKbqPn+CUUGebAXFAf4QcWTbUHUVdC/B6fc4d6GIRbS+ X-Gm-Gg: AeBDietGW3kogttRLBHCiPl39jkPntgM1eEak4w74FnUaXg3CsHWtkmeRasGGorV8HV dStbde/984WwAOlld5lgc52Dg+TW/8mwnTskhKC0VEDCjxL6UAiTLNFXhlYNSebZEYfoWo1LHW9 uzSV9BDjB7S4I8l4Z2lk6448XN1NZjt/RGIvoCKkLiJFjIlfRiVhxEiiQ6ii3OgORbrT0Daccyl u2MUVUHMHvezZAhiQWl+lhfipgCGtJmdCF6fyJCvxoh36MnWPJnVyZbDlGYh4x2MPUyOTgaAtzZ /677Ezm+rjoldJqheTE3W2yoc2fiBFcuAIdZjv74WXCJRqAM/YFiRCK1RGoYjDDoB2o0U25umza uCZlzAumgRTqRvBRxvGtufHntP0LulOpRA85dLoLB+Jxo1aLk3Yy7S0taOeWkLCxE X-Received: by 2002:ac2:4c47:0:b0:5a2:8495:965f with SMTP id 2adb3069b0e04-5a33756436dmr1253371e87.15.1775236970034; Fri, 03 Apr 2026 10:22:50 -0700 (PDT) Received: from milan ([2001:9b1:d5a0:a500::24b]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a2c6c95263sm1567678e87.11.2026.04.03.10.22.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Apr 2026 10:22:49 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Fri, 3 Apr 2026 19:22:48 +0200 To: chenyichong Cc: chenyichong , wangqing7171@gmail.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzbot+37b7f6cd519f7fb8d32a@syzkaller.appspotmail.com Subject: Re: [PATCH] mm/vmalloc: fix KMSAN uninit in decay_va_pool_node list handling Message-ID: References: <20260402081413.1896640-1-wangqing7171@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: On Fri, Apr 03, 2026 at 12:55:31PM +0200, Uladzislau Rezki wrote: > On Fri, Apr 03, 2026 at 03:52:03PM +0800, chenyichong wrote: > > Prevent decay_va_pool_node from overwriting concurrent repopulation of > > vmap_node pool[i].head while purging. Read/reset pool[i].len under > > pool_lock and splice leftover vmap_area nodes back into the pool > > instead of replacing the list. > > > > Reported-by: syzbot+37b7f6cd519f7fb8d32a@syzkaller.appspotmail.com > > Closes: https://syzkaller.appspot.com/bug?extid=37b7f6cd519f7fb8d32a > > Fixes: 7679ba6b36db ("mm: vmalloc: add a shrinker to drain vmap pools") > > Signed-off-by: chenyichong > > --- > > mm/vmalloc.c | 13 +++++++++---- > > 1 file changed, 9 insertions(+), 4 deletions(-) > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index ecbac900c35f..72fb60553a71 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -2233,10 +2233,9 @@ decay_va_pool_node(struct vmap_node *vn, bool full_decay) > > /* Detach the pool, so no-one can access it. */ > > spin_lock(&vn->pool_lock); > > list_replace_init(&vn->pool[i].head, &tmp_list); > > - spin_unlock(&vn->pool_lock); > > - > > pool_len = n_decay = vn->pool[i].len; > > WRITE_ONCE(vn->pool[i].len, 0); > > + spin_unlock(&vn->pool_lock); > > > > /* Decay a pool by ~25% out of left objects. */ > > if (!full_decay) > > @@ -2259,8 +2258,14 @@ decay_va_pool_node(struct vmap_node *vn, bool full_decay) > > */ > > if (!list_empty(&tmp_list)) { > > spin_lock(&vn->pool_lock); > > - list_replace_init(&tmp_list, &vn->pool[i].head); > > - WRITE_ONCE(vn->pool[i].len, pool_len); > > + /* > > + * Merge leftover areas back into the pool rather than > > + * replacing the whole list. A concurrent allocator can > > + * repopulate vn->pool[i].head while we are decaying > > + * tmp_list, and replacing would drop those nodes. > > + */ > > + list_splice_tail_init(&tmp_list, &vn->pool[i].head); > > + WRITE_ONCE(vn->pool[i].len, vn->pool[i].len + pool_len); > > > "A concurrent allocator can repopulate..." - Where is it done? Probably > you meant something different. > Actually decay_va_pool_node() is not designed to be called concurrently. See the comment: /* * Attach the pool back if it has been partly decayed. * Please note, it is supposed that nobody(other contexts) * can populate the pool therefore a simple list replace * operation takes place here. */ but after adding the shrinker it may be called concurrently to free some memory, if high memory pressure occurs. This is not good because we can lose added VAs by the __purge_vmap_area_lazy() helper. So it might leak memory. That problem has been introduced by the "mm: vmalloc: add a shrinker to drain vmap pools" patch. IMO, the best what we should do is to follow the design reflected by the comment. It implies that shrinker has to decay holding the vmap_purge_lock mutex. -- Uladzislau Rezki