lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHbLzkpTgJkzCNCmPwmtnOwGEf0-pxT=_bhPw-gawgiuH21OBw@mail.gmail.com>
Date: Mon, 28 Oct 2024 11:36:48 -0700
From: Yang Shi <shy828301@...il.com>
To: Hugh Dickins <hughd@...gle.com>
Cc: Zi Yan <ziy@...dia.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Usama Arif <usamaarif642@...il.com>, Wei Yang <richard.weiyang@...il.com>, 
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, Matthew Wilcox <willy@...radead.org>, 
	David Hildenbrand <david@...hat.com>, Johannes Weiner <hannes@...xchg.org>, 
	Baolin Wang <baolin.wang@...ux.alibaba.com>, Barry Song <baohua@...nel.org>, 
	Kefeng Wang <wangkefeng.wang@...wei.com>, Ryan Roberts <ryan.roberts@....com>, 
	Nhat Pham <nphamcs@...il.com>, Chris Li <chrisl@...nel.org>, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org
Subject: Re: [PATCH hotfix 1/2] mm/thp: fix deferred split queue not partially_mapped

On Sat, Oct 26, 2024 at 10:08 PM Hugh Dickins <hughd@...gle.com> wrote:
>
> On Fri, 25 Oct 2024, Yang Shi wrote:
> >
> > The other subtle thing is folio->_deferred_list is reused when the
> > folio is moved to the local on-stack list. And some
>
> Yes.
>
> > list_empty(deferred_list) checks return true even though the folio is
> > actually on the local on-stack list. Some code may depend on or
>
> The code definitely depends on that behaviour: that's how folios get
> unqueued when refcount reaches 0, whether they are on the public list
> or on the local list at that time.

Yeah, folio may have 0 refcount on the local list after that
folio_put() before it is moved back to deferred list.

The main purpose for using folio_batch is to disambiguate list_empty()
so that we don't rely on this subtle behavior. But I soon realized
this may make deferred list lock contention worse when moving the
folios back to deferred list. Currently we just need to do list
splice, but we have to add every single folio back to deferred list
one by one with folio_batch. It depends on how often folio split
fails.

>
> > inadvertently depend on this behavior. Using folio_batch may break
> > some assumptions, but depending on this subtle behavior is definitely
> > not reliable IMHO.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ