From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 0986D27F19F for ; Wed, 11 Mar 2026 16:54:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773248085; cv=none; b=J5Pv4fXHLnM4JBI0gV0CiaS2ixVqFlD3hELvBkOf26E+KqMzi1URf/7QSOUoIMvYyNDzTPl3rtTYOlkaKpqLy0VDDYAdD2rlgEZ6BZq5oyK8q3wTIH5lRTAKBYkhYY2tdOmU/wgBEngtANvFkFv/1EvwOz3BjhmL4tASc+fR4CA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773248085; c=relaxed/simple; bh=91qlieLRgYOSO9XaMOoUeKdKgp5MSyhzDjaJY4o2/5s=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=LZWUzmUXXzEVay2XDNs52aH/fT9CCK6kBBI8Fju2ZZdx1KXTIRzC7sEcDHcYrdfgnWFv9UTV/muojKTrYL9+sBZANPCCXcj80BehUCnABa3q844GgiG8YcuMTmbo5h2cBIaxsRR/NPWuQGaPTqSErN790lfVMajaSMzWVJceuWs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BaiyyMN3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BaiyyMN3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9A9CC19425; Wed, 11 Mar 2026 16:54:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773248084; bh=91qlieLRgYOSO9XaMOoUeKdKgp5MSyhzDjaJY4o2/5s=; h=Date:From:Subject:To:Cc:References:In-Reply-To:From; b=BaiyyMN38qaU8eVJpkSJb+UwLI0Hhj1dt3L+OUCHNHOI2B/jmnlEbqApjU1uA900O SUzuUoh7VLARxP3yJgifBHMAStBHPRIuzxHlW+MJwYRc7lkQu+doCU/T9lbLvd2Ckq BdZ9CLenSLwr7DqwIzuwVIi1wOt28LooVRxbprzYhmBfCe+eFoiSjGGqpmXElrloGO LhBEn5UMLjyrQC0bBtV/BpRmdZhVk2xzH2uekf75l821lJVNIhQ7B526tN/TpoMREJ iX8J7YXM162DAc4Z04Uae5SLguC6hYe2uxDhKZ3h9T0D0GsdoLgJZhinhp9kJkwywf 6r2oDDLPUFWNw== Message-ID: <272f1848-e2c8-471c-9b0d-e6706b464d11@kernel.org> Date: Wed, 11 Mar 2026 17:54:40 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Vlastimil Babka Subject: Re: [PATCH] slab: fix memory leak when refill_sheaf() fails Content-Language: en-US To: Hao Li , Qing Wang , Harry Yoo Cc: Andrew Morton , Christoph Lameter , David Rientjes , Roman Gushchin , Suren Baghdasaryan , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260311093617.4155965-1-wangqing7171@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/11/26 17:30, Hao Li wrote: >> >> I also want to bring up another point here, although it may be outside the >> scope of the current fix. >> >> When I looked into the refill_sheaf() path, I found a refill failure does not >> guarantee that the sheaf remains intact: refill_sheaf() can partially fill the >> sheaf before failing. This non-intact behavior propagates to its caller, >> __prefill_sheaf_pfmemalloc(), which therefore also cannot assume that the sheaf >> is still intact after a refill failure. >> >> However, the comment for kmem_cache_refill_sheaf() says that "if the refill >> fails (returning -ENOMEM), the existing sheaf is left intact." That means the >> behavior of __prefill_sheaf_pfmemalloc() - where the sheaf may be left >> partially filled on refill failure - contradicts the API contract of >> kmem_cache_refill_sheaf(). >> >> Maybe we can add rollback logic to __prefill_sheaf_pfmemalloc() so that it >> provides intact semantics, preventing the non-intact behavior of refill_sheaf() >> from propagating up to kmem_cache_refill_sheaf(). > > Looking at this a bit more, after checking the current callers, it seems that > the existing callers of kmem_cache_refill_sheaf() are not relying on the sheaf > remaining intact on refill failure. > > If so, then another possible option might be to update the comment for > kmem_cache_refill_sheaf() to match the current behavior, rather than adding > rollback logic. I agree with this option. Having possibly more objects than before the call shouldn't be an issue for the callers. > So it may just come down to whether we want to preserve the documented > semantics in the implementation, or adjust the comment to reflect what the code > already does. > > I may be missing some intended dependency here, though. >