linux-kernel - Re: [RFC PATCH] block, fs: use FOLL_LONGTERM as gup

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] [day] [month] [year] [list]

Message-ID: <CAJuCfpFKuQfQ74f4pLtEO3K1GGeMazb6z52d+oO005ciR8b9+g@mail.gmail.com>
Date: Fri, 7 Mar 2025 13:37:12 -0800
From: Suren Baghdasaryan <surenb@...gle.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Christoph Hellwig <hch@...radead.org>, Sooyong Suk <s.suk@...sung.com>, viro@...iv.linux.org.uk, 
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org, linux-mm@...ck.org, 
	jaewon31.kim@...il.com, spssyr@...il.com
Subject: Re: [RFC PATCH] block, fs: use FOLL_LONGTERM as gup_flags for direct IO

On Fri, Mar 7, 2025 at 12:23 PM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Thu, Mar 06, 2025 at 07:26:52AM -0800, Christoph Hellwig wrote:
> > On Thu, Mar 06, 2025 at 04:40:56PM +0900, Sooyong Suk wrote:
> > > There are GUP references to pages that are serving as direct IO buffers.
> > > Those pages can be allocated from CMA pageblocks despite they can be
> > > pinned until the DIO is completed.
> >
> > direct I/O is eactly the case that is not FOLL_LONGTERM and one of
> > the reasons to even have the flag.  So big fat no to this.
> >
> > You also completely failed to address the relevant mailinglist and
> > maintainers.
>
> You're right; this patch is so bad that it's insulting.
>
> Howver, the problem is real.  And the alternative "solution" being
> proposed is worse -- reintroducing cleancache and frontswap.

Matthew, if you are referring to the GCMA proposal I'm working on,
that's not to address this problem. My goal with GCMA is to reuse
memory carveouts (when they are not used) for extending pagecache.

The way I understand this particular problem is that we know direct
I/O will allocate pages and make them unmovable and we do nothing to
prevent these allocations from using CMA.

>
> What I've been asking for and don't have the answer to yet is:

I'll send my findings related to GCMA usecases separately since I
don't want to mix that with the problem discussed here.

>
>  - What latency is acceptable to reclaim the pages allocated from CMA
>    pageblocks?
>     - Can we afford a TLB shootdown?  An rmap walk?
>  - Is the problem with anonymous or pagecache memory?
>
> I have vaguely been wondering about creating a separate (fake) NUMA node
> for the CMA memory so that userspace can control "none of this memory is
> in the CMA blocks".  But that's not a great solution either.
>