From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2D045318EDC for ; Mon, 11 May 2026 05:45:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778478304; cv=none; b=RAbpc5EhpHlbn2mAr3YfEhhI6zWZRrKPcMANXW3Na9jZyGaFecininFyA2SezubvEf2lAXic5bbKoAYTXveN1x3vnNKKbp0erlWQWAye5M/aOP8KtISgcF3jSwhl9AOM+FIYGyNBM5YIg3tNRqe2C7oBIS+wIGCaQojaScrmV2Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778478304; c=relaxed/simple; bh=7yGxy1hSiTPiJ/R/loniiIx69AviSmIS7dZo6EijhcI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kVOE3N1TsXV1b0sp+JS/QxQnTJTV9ORWXp0HYlbeKbrCEbkasqH7WQIoSFwnqUeSaMjI+65KtX57ky59Yt8V7cM0MC+pgujZIgpe0TcLG/FhAQcWyOT3Ft9CJ4ZGA16kzZ8ww0Mnh10SxdxEt7G2zKgiA3yUXV8X4rXqkX0b2MU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=B35HU+Zy; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="B35HU+Zy" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A2AE41713; Sun, 10 May 2026 22:44:54 -0700 (PDT) Received: from [10.164.148.37] (MacBook-Pro.blr.arm.com [10.164.148.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2DD173F85F; Sun, 10 May 2026 22:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1778478299; bh=7yGxy1hSiTPiJ/R/loniiIx69AviSmIS7dZo6EijhcI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=B35HU+ZyrdKyuHrIW7B9PSu/JFFFgMqRt308Qf+b6/hNaIEvJl4FSohJWX2xNwojM mqbcbwkxnEEWeGJBGFMtXd1rSgN2OAgWKT3kdwxxxDw9+3e40z+Rm8UXr3HgidKkkv L4dTV5TRG1O04flCgcGCsJix7AydrZ2JDbxPeUtU= Message-ID: Date: Mon, 11 May 2026 11:14:45 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] mm/khugepaged: clear MMF_VM_HUGEPAGE on mm_slot_alloc() failure To: "David Hildenbrand (Arm)" , Lance Yang Cc: ye.liu@linux.dev, akpm@linux-foundation.org, ljs@kernel.org, xhao@linux.alibaba.com, liuye@kylinos.cn, ziy@nvidia.com, baolin.wang@linux.alibaba.com, liam@infradead.org, npache@redhat.com, ryan.roberts@arm.com, baohua@kernel.org, akpm@linux-foudation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <3fb8c00d-d60d-4fec-81b1-e7633384a52d@arm.com> <20260506105150.21504-1-lance.yang@linux.dev> <6b6b094b-8dcb-423b-bb86-ef1439887eed@kernel.org> <41676526-ff0f-4172-8871-0a825ab524d0@arm.com> <5db3ccc6-7184-4068-918f-72dbfc31a781@kernel.org> Content-Language: en-US From: Dev Jain In-Reply-To: <5db3ccc6-7184-4068-918f-72dbfc31a781@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/05/26 11:10 am, David Hildenbrand (Arm) wrote: > On 5/11/26 06:00, Dev Jain wrote: >> >> >> On 09/05/26 3:11 am, David Hildenbrand (Arm) wrote: >>> On 5/6/26 12:51, Lance Yang wrote: >>>> >>>> >>>> Right. A racing khugepaged_enter_vma() can see MMF_VM_HUGEPAGE is set >>>> and return, then !slot clears it again. If there is no later >>>> khugepaged_enter_vma(), the mm still wouldn't get registered :) >>> >>> So why not >>> >>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c >>> index 5f4e009593e0..78735f34250a 100644 >>> --- a/mm/khugepaged.c >>> +++ b/mm/khugepaged.c >>> @@ -437,13 +437,16 @@ void __khugepaged_enter(struct mm_struct *mm) >>> >>> /* __khugepaged_exit() must not run from under us */ >>> VM_BUG_ON_MM(collapse_test_exit(mm), mm); >>> - if (unlikely(mm_flags_test_and_set(MMF_VM_HUGEPAGE, mm))) >>> - return; >>> >>> slot = mm_slot_alloc(mm_slot_cache); >>> if (!slot) >>> return; >>> >>> + if (unlikely(mm_flags_test_and_set(MMF_VM_HUGEPAGE, mm))) { >>> + mm_slot_free(mm_slot_cache, slot); >>> + return; >>> + } >>> + >>> spin_lock(&khugepaged_mm_lock); >>> mm_slot_insert(mm_slots_hash, mm, slot); >>> /* >>> >>> >>> Arguably, on the race described above, likely the thread seeing the >>> MMF_VM_HUGEPAGE would likely similarly have failed the allocation. >>> >>> I'm fine with either, just wanted to raise the (cleaner looking?) alternative >>> where we just properly back off? >> >> Yes this is also fine - I am overthinking but I wasn't going this way because ... >> A process doing THP allocations will fail on the mm_flags_test_and_set everytime >> after the first time. > We should perform a mm_flags_test(MMF_VM_HUGEPAGE, vma->vm_mm) test before > calling the function when the flag might not be set yet: in khugepaged_enter_vma() Ah that slipped my mind, you are right. > > khugepaged_fork() should only get called once per process. > > Which makes sense, because mm_flags_test_and_set() is expensive. >