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 1865E3D9026 for ; Wed, 18 Mar 2026 14:31:00 +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=1773844261; cv=none; b=ruT6EWb3+P1oIuCQ3yQQwHh0cYw9wWW2Y517RWwVycB204itL6vxkunhvp8/oDBodJy7GsRuJdpeRqj/uqnFWj5qzV7zTIk+bQbLSES1sVTwFc04SHgpyb/mcwOsEK4CBaUqTOKNdmqLFanj56lYAK9h3h8M6nXb3jSmDdPDHL0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773844261; c=relaxed/simple; bh=vDmi4D9iGjVbOJZ7zVFCLFrvInUmkCXAJtsumdbDJsE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RwVJjPPGLwacMrMEcB6pwWLAghPEPup+VzEKtOVcKpWIR+LXGongq5ahETf1ZFf9bkXrgp8tgtEdfVIK2pzLAiVVck2kig+ZIervm4tF7I8f90BL9vjQlzTLs5gqghYtisTjDB7893u07MvjqAN+i2t0TyIdy7UBWKdADutYpcI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GKoq9NcN; 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="GKoq9NcN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93713C19421; Wed, 18 Mar 2026 14:30:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773844260; bh=vDmi4D9iGjVbOJZ7zVFCLFrvInUmkCXAJtsumdbDJsE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GKoq9NcN0VzvpFAjtGIslmMleSCRgUwLPdAR4RiGMuwe+gDcnSuO6cnG/CWbbqB8I 7iwLZq6N35puxGe7fUhTqSOVvR8RkcgHQA2YvgQKxk6Kf+Qd5smx6zQ+PwKSk8kY43 eARrDdfRVkb+qiBckbqTiThWNkRWLfsiTD9ScZbHmPZqn64WymnL+Pfsj9B7GTAuae +qM+R3qvqG8YzPK/ErDQwHRdSQ7q11w5RAstRdh1mEGZ32T3/AN52CvE5AH0gJKhjr jATH0TP0W/QJs1sYdyus4fgivwmRbam5BDfIAO2Qy1+2hiDmTF7wgaQLq49y+3LQF5 0rGH/qXdOlFdQ== Date: Wed, 18 Mar 2026 16:30:53 +0200 From: Mike Rapoport To: Hubert Mazur Cc: Andrew Morton , Greg Kroah-Hartman , Stanislaw Kardach , Michal Krawczyk , Slawomir Rosek , Lukasz Majczak , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/1] Encapsulate the populate and alloc as one atomic Message-ID: References: <20260317125020.1293472-1-hmazur@google.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: <20260317125020.1293472-1-hmazur@google.com> Hi Hubert, On Tue, Mar 17, 2026 at 12:50:19PM +0000, Hubert Mazur wrote: > Hello, > thanks for the review of the v1 patchset. I tried to make v2 diff as > small as possible and without a modification of the core logic. > > When a block of memory is requested from the execmem manager the > free_areas tree is traversed to find area of given size. If it is not > found then a new fragment, aligned to a PAGE_SIZE, is allocated and > added to free_areas. Afterwards, the free_areas tree is being traversed > again to fullfil the request. > > The above operations of allocation and tree traversal are not atomic > hence another request may consume this newly allocated memory > block dedicated to the original request. As a result - the first > request fails to get the memory. Such occurence can be spotted on > evices running the 6.18 kernel during the paralell modules loading. typo: devices In general, a single patch does not require cover letter, but the details about why the patch is needed should be a part of the commit message. > Regards > Hubert > > Changes in v2: > The __execmem_cache_alloc_locked function (lockless version of > __execmem_cache_alloc) is introduced and called after > execmem_cache_add_locked from the __execmem_cache_populate_alloc > function (renamed from execmem_cache_populate). Both calls are > guarded now with a single mutex. > > Changes in v1: > Allocate new memory fragment and assign it directly to the busy_areas > inside execmem_cache_populate function. > > Link to v1: > https://lore.kernel.org/all/20260312131438.361746-1-hmazur@google.com/T/#t > > Hubert Mazur (1): > mm/execmem: Make the populate and alloc atomic > > mm/execmem.c | 61 +++++++++++++++++++++++++++++----------------------- > 1 file changed, 34 insertions(+), 27 deletions(-) > > -- > 2.53.0.851.ga537e3e6e9-goog > -- Sincerely yours, Mike.