All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	 "Liam R. Howlett" <liam@infradead.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	 Jann Horn <jannh@google.com>, Pedro Falcato <pfalcato@suse.de>,
	 Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	 Michal Hocko <mhocko@suse.com>, Hugh Dickins <hughd@google.com>,
	 Baolin Wang <baolin.wang@linux.alibaba.com>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	 Jan Kara <jack@suse.cz>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	 linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 3/6] mm/vma: only permit MAP_PRIVATE /dev/zero to be mapped anonymous
Date: Tue, 8 Sep 2026 09:46:30 +0100	[thread overview]
Message-ID: <ap_LD6lE6JTYouGr@gremlin> (raw)
In-Reply-To: <8f797f01-e958-404e-bcdf-283da960e95c@kernel.org>

On Mon, Sep 07, 2026 at 09:54:04PM +0200, David Hildenbrand (Arm) wrote:
> Yes, but my point is that the comment
>
> "cannot mark themselves anonymous"
>
> will not really be correct after the next patch, no?

Ah ok ack I get your point. I will update this comment in the next patch.

> >>>  		set_vma_user_defined_fields(vma, &map);
> >>
> >> Ah, we have mmap_zero_prepare() for handling the shmem_zero_setup_desc(). I was
> >> just about to ask whether we can just get rid of this here.
> >>
> >>
> >> But, hold on, do we now even need that? Could core-mm now take care of that as
> >> well, and we could just remove mmap_zero_prepare() entirely?
> >>
> >> That is, we'd make shmem_zero_setup() in __mmap_new_vma() take care of this?
> >> Then we might not even need shmem_zero_setup_desc() anymore.
> >>
> >> Maybe harder than it sounds at first.
> >
> > I think I'd rather that be a follow up :) this series is about eliminiating the
> > one last (I hope?) corner case for anon VMAs.
> Right; having to deal with anonymous mappings that have mmap_prepare is rather
> suboptimal. Ideally we'd just handle the odd dev-zero special-casing early in
> the mmap path also for MAP_SHARED, and avoid messing with mmap_prepare entirely.
>
> So agreed that this can be done separately.

Yeah, really life will be easier once the mmap path is gone in general :)

>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo


  reply	other threads:[~2026-09-08  8:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 18:00 [PATCH 0/6] mm: make MAP_PRIVATE-/dev/zero mappings truly anonymous Lorenzo Stoakes (ARM)
2026-09-02 18:00 ` [PATCH 1/6] mm: move drivers/char/mem.c to mm/char-mem.c Lorenzo Stoakes (ARM)
2026-09-03 12:34   ` Mike Rapoport
2026-09-07 16:20   ` David Hildenbrand (Arm)
2026-09-02 18:00 ` [PATCH 2/6] mm: implement file_is_dev_zero() to uniquely identify /dev/zero Lorenzo Stoakes (ARM)
2026-09-07 16:21   ` David Hildenbrand (Arm)
2026-09-07 16:29     ` Lorenzo Stoakes (ARM)
2026-09-02 18:00 ` [PATCH 3/6] mm/vma: only permit MAP_PRIVATE /dev/zero to be mapped anonymous Lorenzo Stoakes (ARM)
2026-09-07 16:04   ` Gregory Price
2026-09-07 16:26     ` Lorenzo Stoakes (ARM)
2026-09-07 16:56   ` David Hildenbrand (Arm)
2026-09-07 17:38     ` Lorenzo Stoakes (ARM)
2026-09-07 19:54       ` David Hildenbrand (Arm)
2026-09-08  8:46         ` Lorenzo Stoakes (ARM) [this message]
2026-09-02 18:00 ` [PATCH 4/6] mm/vma: make MAP_PRIVATE-mapped /dev/zero mappings truly anonymous Lorenzo Stoakes (ARM)
2026-09-02 18:00 ` [PATCH 5/6] tools/testing/vma: add test to assert MAP_PRIVATE-/dev/zero is anon Lorenzo Stoakes (ARM)
2026-09-02 18:00 ` [PATCH 6/6] tools/testing/selftests/mm: add MAP_PRIVATE-/dev/zero merge tests Lorenzo Stoakes (ARM)
2026-09-07 17:08   ` David Hildenbrand (Arm)
2026-09-08  8:56     ` Lorenzo Stoakes (ARM)

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=ap_LD6lE6JTYouGr@gremlin \
    --to=ljs@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hughd@google.com \
    --cc=jack@suse.cz \
    --cc=jannh@google.com \
    --cc=liam@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=pfalcato@suse.de \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=willy@infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.