linux-kernel - Re: [RFC 1/2] shmem: set shmem

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]

Date:   Wed, 8 Feb 2023 08:08:45 -0800
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     hughd@...gle.com, akpm@...ux-foundation.org, linux-mm@...ck.org,
        p.raghav@...sung.com, dave@...olabs.net, a.manzanares@...sung.com,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC 1/2] shmem: set shmem_writepage() variables early

On Tue, Feb 07, 2023 at 03:52:53AM +0000, Matthew Wilcox wrote:
> On Mon, Feb 06, 2023 at 06:52:58PM -0800, Luis Chamberlain wrote:
> > shmem_writepage() sets up variables typically used *after* a possible
> > huge page split. However even if that does happen the address space
> > mapping should not change. So it should be safe to set that from
> > the beginning.
> 
> Yes, we can get mapping from the folio early.  It doesn't change
> on split.

Great.

> > The folio should always be locked from the start as well. It however
> > was not clear if the folio address can / should change, as well as
> > the first inode.
> > 
> > This commit makes no functional changes other a double check on the
> > folio locking which might be superflous. This change should help make
> > the subsequent patch easier to review.
> 
> You don't need to check that the folio's locked,

That BUG_ON() has been on shmem since linux-history days it's probably
best as a separate patch.

> and you don't
> need to reassign inode after the split.

Great! Thanks for this confirmation!

  Luis