linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: enh <enh@google.com>
To: "Liam R. Howlett" <Liam.Howlett@oracle.com>, enh <enh@google.com>,
	 Jeff Xu <jeffxu@chromium.org>,
	Pedro Falcato <pedro.falcato@gmail.com>,
	 Benjamin Berg <benjamin@sipsolutions.net>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	 Kees Cook <kees@kernel.org>,
	akpm@linux-foundation.org, jannh@google.com,
	 torvalds@linux-foundation.org, adhemerval.zanella@linaro.org,
	oleg@redhat.com,  linux-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org,  linux-mm@kvack.org,
	jorgelo@chromium.org, sroettger@google.com,  ojeda@kernel.org,
	adobriyan@gmail.com, anna-maria@linutronix.de,
	 mark.rutland@arm.com, linus.walleij@linaro.org, Jason@zx2c4.com,
	 deller@gmx.de, rdunlap@infradead.org, davem@davemloft.net,
	hch@lst.de,  peterx@redhat.com, hca@linux.ibm.com,
	f.fainelli@gmail.com, gerg@kernel.org,
	 dave.hansen@linux.intel.com, mingo@kernel.org, ardb@kernel.org,
	 mhocko@suse.com, 42.hyeyoo@gmail.com, peterz@infradead.org,
	ardb@google.com,  rientjes@google.com, groeck@chromium.org,
	mpe@ellerman.id.au,  Vlastimil Babka <vbabka@suse.cz>,
	Andrei Vagin <avagin@gmail.com>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	 Mike Rapoport <mike.rapoport@gmail.com>,
	 Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Subject: Re: [PATCH v4 1/1] exec: seal system mappings
Date: Tue, 21 Jan 2025 10:38:32 -0500	[thread overview]
Message-ID: <CAJgzZopv+jKmDncYDJEQTymqQ1oRpy8HNpOsmcoM7Chb=uBJzg@mail.gmail.com> (raw)
In-Reply-To: <ocstrhpyoyxzurvvxbrbnlzfqzo6hiqt7dxj7vu45ipj4min6z@ffnpao72slda>

On Fri, Jan 17, 2025 at 5:08 PM Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
>
> * enh <enh@google.com> [250117 14:35]:
> ...
>
> >
> > as a maintainer of a different linux libc, i've long wanted a "tell me
> > everything there is to know about this vma" syscall rather than having
> > to parse /proc/maps...
> >
>
> You mean an ioctl()-based API to query VMAs from /proc/<pid>/maps?

i wasn't imagining an ioctl(), no, just a regular syscall, but that
would work too.

> Andrii had something like that [1], check out ed5d583a88a92 ("fs/procfs:
> implement efficient VMA querying API for /proc/<pid>/maps")

yeah, that would work for the use cases i've seen too (some of which
are similar to the ones mentioned in the patch description, but other
ones too).

the other motivation we've had that i didn't notice mentioned there is
avoiding the awkward /proc/<pid>/maps behavior when you have too many
vmas to fit all the output into a page.

i'd definitely use this in Android's libc, and several of our
profiling/unwinding libraries.

> Regards,
> Liam
>
> [1]. https://lore.kernel.org/linux-mm/20240627170900.1672542-1-andrii@kernel.org/


  reply	other threads:[~2025-01-21 15:38 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-25 20:20 [PATCH v4 0/1] Seal " jeffxu
2024-11-25 20:20 ` [PATCH v4 1/1] exec: seal " jeffxu
2024-11-25 20:40   ` Matthew Wilcox
2024-12-02 17:22     ` Jeff Xu
2024-12-02 17:57       ` Lorenzo Stoakes
2024-12-02 20:05         ` Jeff Xu
2024-12-02 19:57       ` Jeff Xu
2024-12-02 18:29   ` Lorenzo Stoakes
2024-12-02 20:38     ` Jeff Xu
2024-12-03  7:35       ` Lorenzo Stoakes
2024-12-03 18:19         ` Jeff Xu
2024-12-03 20:16           ` Lorenzo Stoakes
2024-12-04 14:04   ` Benjamin Berg
2024-12-04 17:43     ` Jeff Xu
2024-12-04 18:24       ` Benjamin Berg
2024-12-10  4:12   ` Andrei Vagin
2024-12-11 22:46     ` Jeff Xu
2024-12-13  6:33       ` Andrei Vagin
2024-12-16 18:35         ` Jeff Xu
2024-12-16 18:56           ` Liam R. Howlett
2024-12-16 20:20             ` Jeff Xu
2024-12-17 22:18   ` Kees Cook
2025-01-02 19:15     ` Andrei Vagin
2025-01-03 20:48     ` Liam R. Howlett
2025-01-07  1:17       ` Kees Cook
2025-02-04 18:17       ` Johannes Berg
2025-01-03 21:38     ` Lorenzo Stoakes
2025-01-07  1:12       ` Kees Cook
2025-01-13 21:26         ` Jeff Xu
2025-01-14  4:19           ` Matthew Wilcox
2025-01-15 19:02           ` Jeff Xu
2025-01-15 19:46             ` Lorenzo Stoakes
2025-01-15 20:20               ` Jeff Xu
2025-01-16 15:48                 ` Lorenzo Stoakes
2025-01-16 17:01                   ` Benjamin Berg
2025-01-16 17:16                     ` Lorenzo Stoakes
2025-01-16 17:18                     ` Pedro Falcato
2025-01-17 18:20                       ` Jeff Xu
2025-01-17 19:35                         ` enh
2025-01-17 20:15                           ` Jeff Xu
2025-01-17 22:08                           ` Liam R. Howlett
2025-01-21 15:38                             ` enh [this message]
2025-01-22 17:23                               ` Liam R. Howlett
2025-01-22 22:29                                 ` enh
2025-01-23  8:40                                   ` Vlastimil Babka
2025-01-23 21:50                                     ` enh
2025-01-23 22:38                                       ` Matthew Wilcox
2025-02-06 14:19                                         ` enh
2025-02-06 13:20                           ` Thomas Weißschuh
2025-02-06 14:38                             ` enh
2025-02-06 15:28                               ` Thomas Weißschuh
2025-02-06 15:51                                 ` enh
2025-02-06 16:37                                   ` Thomas Weißschuh
2025-01-17 18:08                   ` Jeff Xu
2025-01-15 23:52               ` Kees Cook
2025-01-16  5:26                 ` Christoph Hellwig
2025-01-16 19:40                   ` Kees Cook
2025-01-17 10:14                     ` Heiko Carstens
2025-01-16 15:34                 ` Lorenzo Stoakes
2025-01-16 19:44                   ` Kees Cook
2024-11-26 16:39 ` [PATCH v4 0/1] Seal " Lorenzo Stoakes
2024-12-02 17:28   ` Jeff Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJgzZopv+jKmDncYDJEQTymqQ1oRpy8HNpOsmcoM7Chb=uBJzg@mail.gmail.com' \
    --to=enh@google.com \
    --cc=0x7f454c46@gmail.com \
    --cc=42.hyeyoo@gmail.com \
    --cc=Jason@zx2c4.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=aleksandr.mikhalitsyn@canonical.com \
    --cc=anna-maria@linutronix.de \
    --cc=ardb@google.com \
    --cc=ardb@kernel.org \
    --cc=avagin@gmail.com \
    --cc=benjamin@sipsolutions.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --cc=f.fainelli@gmail.com \
    --cc=gerg@kernel.org \
    --cc=groeck@chromium.org \
    --cc=hca@linux.ibm.com \
    --cc=hch@lst.de \
    --cc=jannh@google.com \
    --cc=jeffxu@chromium.org \
    --cc=jorgelo@chromium.org \
    --cc=kees@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mark.rutland@arm.com \
    --cc=mhocko@suse.com \
    --cc=mike.rapoport@gmail.com \
    --cc=mingo@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=ojeda@kernel.org \
    --cc=oleg@redhat.com \
    --cc=pedro.falcato@gmail.com \
    --cc=peterx@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rientjes@google.com \
    --cc=sroettger@google.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox