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: <ZmiRcUYxrZ5NQQX8@casper.infradead.org>
Date: Tue, 11 Jun 2024 19:03:29 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Andrew Bresticker <abrestic@...osinc.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	David Hildenbrand <david@...hat.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] mm/memory: Don't require head page for do_set_pmd()

On Tue, Jun 11, 2024 at 08:32:16AM -0700, Andrew Bresticker wrote:
> -	if (page != &folio->page || folio_order(folio) != HPAGE_PMD_ORDER)
> +	if (folio_order(folio) != HPAGE_PMD_ORDER)
>  		return ret;
> +	page = &folio->page;

This works today, but in about six months time it's going to be a pain.

+	page = folio_page(folio, 0);

is the one which works today and in the future.

Of course, as I'm writing this now I'm thinking we could make this work
for folios which are larger than PMD size.  Which we currently prohibit
(at least in part because this function doesn't work with folios larger
than PMD size)

	pgoff_t idx = ((haddr - vma->vm_start) / PAGE_SIZE) + vma->vm_pgoff;
	page = folio_file_page(folio, idx);

(there might be a more succinct way to write that, and I might have
messed up the polarity on something).

Worth starting to fix these places that don't work with folios larger
than PMD size?  I think it'd be worth supporting, eg 4MB folios.

Current bandwidth of a gen5 x8 link is 32GB/s, so we can read 8,000
4MB pages/second at a latency of 125us.  My laptop only has a gen4 x2
SSD, so a 4MB folio would take 1ms to read which might be a little
excessive for normal use.  Of course allocating an order 10 folio is
hard, so it's not going to happen terribly often anyway.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ