[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGudoHE74SbDjO+4863JVTL_dyZKCt7aCXudjXnBkoy6ELujtQ@mail.gmail.com>
Date: Sun, 19 Jan 2025 11:28:47 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Tavian Barnes <tavianator@...ianator.com>
Cc: Jan Kara <jack@...e.cz>, linux-fsdevel@...r.kernel.org,
Alexander Viro <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] coredump: allow interrupting dumps of large anonymous regions
On Thu, Jan 16, 2025 at 6:04 PM Tavian Barnes <tavianator@...ianator.com> wrote:
>
> On Thu, Jan 16, 2025 at 01:04:42PM +0100, Mateusz Guzik wrote:
> > In this context there are next to no pages found, but there is a
> > gazillion relocks as the entire VA is being walked.
>
> Do I understand correctly that all the relocks are to look up the VMA
> associated with each address, one page at a time? That's especially
> wasteful as dump_user_range() is called separately for each VMA, so it's
> going to find the same VMA every time anyway.
>
it indeed is a loop over vmas, and then over the entire range with
PAGE_SIZE'd steps
> > I however vote for someone mm-savvy to point out an easy way (if any)> > to just iterate pages which are there instead.
>
> It seems like some of the <linux/pagewalk.h> APIs might be relevant?
> Not sure which one has the right semantics. Can we just use
> folio_walk_start()?
>
> I guess the main complexity is every time we find a page, we have to
> stop the walk, unlock mmap_sem, call dump_emit_page(), and restart the
> walk from the next address. Maybe an mm expert can weigh in.
>
I don't know the way, based on my epsilon understanding of the area I
*suspect* walking the maple tree would do it.
--
Mateusz Guzik <mjguzik gmail.com>
Powered by blists - more mailing lists