linux-kernel - Re: [PATCH v14 124/138] fs: Convert vfs_dedupe_file_range

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YPC0oYG/fsnPXcac@casper.infradead.org>
Date:   Thu, 15 Jul 2021 23:20:17 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     "Darrick J. Wong" <djwong@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v14 124/138] fs: Convert vfs_dedupe_file_range_compare to
 folios

On Thu, Jul 15, 2021 at 03:08:40PM -0700, Darrick J. Wong wrote:
> On Thu, Jul 15, 2021 at 04:36:50AM +0100, Matthew Wilcox (Oracle) wrote:
> > We still only operate on a single page of data at a time due to using
> > kmap().  A more complex implementation would work on each page in a folio,
> > but it's not clear that such a complex implementation would be worthwhile.
> 
> Does this break up a compound folio into smaller pages?

No.  We just operate on each page in turn.  Splitting a folio is an
expensive and unrealiable thing to do, so we avoid it unless necessary.

> > +/* Unlock two folios, being careful not to unlock the same folio twice. */
> > +static void vfs_unlock_two_folios(struct folio *folio1, struct folio *folio2)
> >  {
> > -	unlock_page(page1);
> > -	if (page1 != page2)
> > -		unlock_page(page2);
> > +	folio_unlock(folio1);
> > +	if (folio1 != folio2)
> > +		folio_unlock(folio2);
> 
> This could result in a lot of folio lock cycling.  Do you think it's
> worth the effort to minimize this by keeping the folio locked if the
> next page is going to be from the same one?

I think that might well be a worthwhile optimisation.  I'd like to do
that as a separate patch, though (and maybe somebody other than me could
do it ;-)