From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (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 5ACA53ACA49 for ; Fri, 6 Mar 2026 14:29:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.176.79.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772807367; cv=none; b=H4xL+orB9JQoZM54PEeHkR91HT6S6J3rIFk43wtySAdHAzSSi2vRW4U1WgULxQqUUH1A8tnQxy3WQgkWHijbJW75T/KNbbR+EXYnRT0Yb6RziUu14yVEBaS/neC85i8Xl9CBPeTagucublDZPGbDsPTafCPfNf5axfyRA/Yq9bU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772807367; c=relaxed/simple; bh=Fp1fASYwi007ghNDHOLBmdDv0+AaoXeBmw4fAa0XeHA=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=hFGH+hssVz6QiNYM1gXyscOpluQ9mLqDCgsO+LdeT1SMVi1o4Og41IGHKO/5TWoyZYdyziixPaHIc78TffXdSP+MPvLq815Cz0VEzcuaEHHZEsKOZAFMNBUt70ZixRSewak/MvFJmm1DIbXR90Fjozg8liAeUPHOeiFLzGkhuUg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=h-partners.com; spf=pass smtp.mailfrom=h-partners.com; arc=none smtp.client-ip=185.176.79.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=h-partners.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=h-partners.com Received: from mail.maildlp.com (unknown [172.18.224.83]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4fS8060CqPzHnH5f; Fri, 6 Mar 2026 22:28:22 +0800 (CST) Received: from mscpeml500003.china.huawei.com (unknown [7.188.49.51]) by mail.maildlp.com (Postfix) with ESMTPS id CEF4740086; Fri, 6 Mar 2026 22:29:21 +0800 (CST) Received: from [10.123.123.67] (10.123.123.67) by mscpeml500003.china.huawei.com (7.188.49.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Mar 2026 17:29:18 +0300 Message-ID: <75aa8f34-4d91-4758-847d-248a5be3db62@h-partners.com> Date: Fri, 6 Mar 2026 17:29:15 +0300 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 1/1] mm: implement page refcount locking via dedicated bit To: "David Hildenbrand (Arm)" CC: Andrew Morton , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Zi Yan , Harry Yoo , Matthew Wilcox , Yu Zhao , Baolin Wang , Alistair Popple , Gorbunov Ivan , Muchun Song , , , Kiryl Shutsemau , Linus Torvalds References: <6bf6eba6e2e6a74e2045a3bd08d58fd91bece7be.1772120327.git.gladyshev.ilya1@h-partners.com> <902d821b-e903-4bf5-89db-070851c95a1a@h-partners.com> <54cc6e6d-bda7-4c5b-a998-df854ead1985@kernel.org> Content-Language: en-US From: Gladyshev Ilya In-Reply-To: <54cc6e6d-bda7-4c5b-a998-df854ead1985@kernel.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: lhrpeml500012.china.huawei.com (7.191.174.4) To mscpeml500003.china.huawei.com (7.188.49.51) >>> For example, all pages we add to the page allocator through >>> __free_pages_core(). >> >> You are right that refcount = 0 is tricky. However, for a bad outcome >> you will need: >> 1. Some external reference to this page, through which you try to >> increment the refcount; >> 2. set_page_count(0) somewhere between freeing and "it is safe to alloc" >> state. > > That is way, way, way too dodgy. > > What you should likely do is > > (a) Make set_page_count(0) set it to PAGEREF_LOCKED_BIT > (b) Make any places that might skip set_page_count(0) to use it > (c) Document this all extremely thoroughly. Okay, I agree. My reasoning was more about "it's not _that_ bad if we miss something outside the allocator" than "everything is fine as it is", but maybe it is really that bad... > Alternatively, disallow set_page_count(0) ccompletely and add something > like "initialize_page_as_frozen()" or sth. like that. (Below are my thoughts, not active proposal) Actually, we can keep "zero is locked" property if we change scheme a little: If we invert locked bit so that 0 means locked, then we don't care about memset() / GFP_ZERO / set_page(0). But then there is extra bit on each active refcount, and (un)masking will be required on each refcount read/set/etc operation. We can place locked bit in the highest bit like now, or move it to the lowest. This doesn't make any difference except for how masking is performed (and or shift). I can't really tell which approach is faster (and more optimizable after inline). This approach doesn't look appealing to me, mostly because of redundant masking. So for now I will try to add proper initialization / documentation in all risky places. >> So adding new pages with zeroed refcount to allocator is safe, because >> there are no external references. Zeroing tail page's refcount is safe, >> unless someone actually tries to increment its refcount (and this is bug). >> >> Generally, the only unsafe set_page_count() (or any other zeroing) will >> be in allocator itself between freeing and allocating. Or maybe I missed >> something, and this approach is indeed incorrect >> >> Probably we can think of some debug checks to prevent bugs in "safe" >> scenarious > > Just take a look at do_migrate_range(), where we do a > > page = pfn_to_page(pfn); > folio = page_folio(page); > > if (!folio_try_get(folio)) > continue; > > If that is a page that was added to the buddy (set_page_count(0)) but > either (a) not allocated yet or (b) allocated as frozen that's a problem. > > We really rely on > > (1) Frozen pages > (2) Buddy pages > (3) Tail pages (compound or non-compoud) > > To have a refcount of 0 that *reliably* makes folio_try_get() etc. fail. > > Anything else is just playing with fire. >