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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250410173817.5cdlnnooxwgbkpov@offworld>
Date: Thu, 10 Apr 2025 10:38:17 -0700
From: Davidlohr Bueso <dave@...olabs.net>
To: Jan Kara <jack@...e.cz>
Cc: Luis Chamberlain <mcgrof@...nel.org>, brauner@...nel.org, tytso@....edu,
	adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
	riel@...riel.com, willy@...radead.org, hannes@...xchg.org,
	oliver.sang@...el.com, david@...hat.com, axboe@...nel.dk,
	hare@...e.de, david@...morbit.com, djwong@...nel.org,
	ritesh.list@...il.com, linux-fsdevel@...r.kernel.org,
	linux-block@...r.kernel.org, linux-mm@...ck.org,
	gost.dev@...sung.com, p.raghav@...sung.com, da.gomez@...sung.com
Subject: Re: [PATCH v2 2/8] fs/buffer: try to use folio lock for pagecache
 lookups

On Thu, 10 Apr 2025, Jan Kara wrote:

>I'd rather do:
>
>	if (atomic) {
>		spin_lock(&bd_mapping->i_private_lock);
>		folio_locked = false;
>	} else {
>		folio_lock(folio);
>	}
>

Fine with me. I just think the trylock for the atomic scenario would have
given greater chances of successful migration, but at a lack of determinism,
of course.

>I'd actually love to do something like:
>
>	if (atomic) {
>		if (!folio_trylock(folio))
>			bail...
>	} else {
>		folio_lock(folio);
>	}
>
>but that may be just too radical this point and would need some serious
>testing how frequent the trylock failures are. No point in blocking this
>series with it. So just go with the deterministic use of i_private_lock for
>atomic users for now.

This acually crossed my mind, but I also considered the scheme a little
too much for this series.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ