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: <20210206024711.GE3195@xz-x1>
Date:   Fri, 5 Feb 2021 21:47:11 -0500
From:   Peter Xu <peterx@...hat.com>
To:     Hugh Dickins <hughd@...gle.com>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Mike Rapoport <rppt@...ux.vnet.ibm.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Jerome Glisse <jglisse@...hat.com>,
        "Kirill A . Shutemov" <kirill@...temov.name>,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        Matthew Wilcox <willy@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Nadav Amit <nadav.amit@...il.com>
Subject: Re: [PATCH RFC 00/30] userfaultfd-wp: Support shmem and hugetlbfs

On Fri, Feb 05, 2021 at 02:21:47PM -0800, Hugh Dickins wrote:
> On Fri, 29 Jan 2021, Peter Xu wrote:
> > 
> > Huge & Mike,
> > 
> > Would any of you have comment/concerns on the high-level design of this series?
> > 
> > It would be great to know it, especially major objection, before move on to an
> > non-rfc version.
> 
> Seeing Mike's update prompts me to speak up: I have been looking, and
> will continue to look through it - will report when done; but find I've
> been making very little forward progress from one day to the next.
> 
> It is very confusing, inevitably; but you have done an *outstanding*
> job on acknowledging the confusion, and commenting it in great detail.

I'm honored to receive such an evaluation, thanks Hugh!

As a quick summary - what I did in this series is mostly what you've suggested
on using swp_type==1 && swp_offset=0 as a special pte, so the swap code can
trap it.  The only difference is that "swp_type==1 && swp_offset=0" still uses
valid swp_entry address space, so I introduced the "swap special pte" idea
hoping to make it clearer, which is also based on Andrea's suggestion.  I hope
I didn't make it even worse. :)

It's just that I don't want to make this idea that "only works for uffd-wp".
What I'm thinking is whether we can provide such a common way to keep some
records in pgtable entries that point to file-backed memory.  Say, currently
for a file-backed memory we can only have either a valid pte (either RO or RW)
or a none pte.  So maybe we could provide a way to start using the rest pte
address space that we haven't yet used.

Please take your time on reviewing the series.  Any of your future comment
would be greatly welcomed.

Thanks,

-- 
Peter Xu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ