From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Yeoreum Yun <yeoreum.yun@arm.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Lorenzo Stoakes <ljs@kernel.org>, Jason Gunthorpe <jgg@ziepe.ca>,
John Hubbard <jhubbard@nvidia.com>, Peter Xu <peterx@redhat.com>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Andrew Morton <akpm@linux-foundation.org>,
Rik van Riel <riel@surriel.com>,
Yuan-Hao Hsu <aa9736195201@gmail.com>
Subject: Re: [PATCH v2 2/4] mm: internal: fix inconsistent in folio_pte_batch_flags() for shadow stack
Date: Mon, 2 Nov 2026 15:08:38 +0100 [thread overview]
Message-ID: <d70b6ac2-a8b2-4c34-acc4-ee421eb70aac@kernel.org> (raw)
In-Reply-To: <auiZFJ7Bb6cQnqtX@e129823.arm.com>
On 11/2/26 15:07, Yeoreum Yun wrote:
>>>
>>> Sorry. But I couldn't follow. If we accumalate with any_unwritable
>>> and check it out of loop once only, we couldn't properly nr value or
>>> Am I missing something?
>>
>> Ah. The idea was to simply reject the batch entirely if that happens. It would
>> only matter if some folio PTEs are writable while others are not ... well, ok,
>> there are some cases where that can happen, but it's not really the common case.
>>
>> I think we should simply disallow ever getting large folios into shadow stack
>> VMAs for now. So I'd prefer the fix below.
>>
>> Thoughts?
>
> That's my preference too and we've discussed :)
> I'll repost with below unless anyone has any strong comment.
Yes, best to wait a couple of days for people to catch up.
--
Cheers,
David
next prev parent reply other threads:[~2026-11-02 14:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 11:30 [PATCH v2 0/4] mm: gup: batch PTE-mapped large folios in gup_fast_pte_range() Yeoreum Yun
2026-11-02 11:30 ` [PATCH v2 1/4] mm: gup: introduce gup_unshared_pages() Yeoreum Yun
2026-11-02 12:18 ` David Hildenbrand (Arm)
2026-11-02 13:45 ` Yeoreum Yun
2026-11-02 11:30 ` [PATCH v2 2/4] mm: internal: fix inconsistent in folio_pte_batch_flags() for shadow stack Yeoreum Yun
2026-11-02 12:10 ` David Hildenbrand (Arm)
2026-11-02 12:58 ` Yeoreum Yun
2026-11-02 14:01 ` David Hildenbrand (Arm)
2026-11-02 14:07 ` Yeoreum Yun
2026-11-02 14:08 ` David Hildenbrand (Arm) [this message]
2026-11-06 9:21 ` Yeoreum Yun
2026-11-06 12:43 ` David Hildenbrand (Arm)
2026-11-06 13:15 ` Yeoreum Yun
2026-11-02 11:30 ` [PATCH v2 3/4] mm: internal: introduce FPB_LOCKLESS for folio_pte_batch_flags() Yeoreum Yun
2026-11-02 12:23 ` David Hildenbrand (Arm)
2026-11-02 11:30 ` [PATCH v2 4/4] mm: gup: batch PTE-mapped large folios in gup_fast_pte_range() Yeoreum Yun
2026-11-03 17:00 ` David Hildenbrand (Arm)
2026-11-04 11:30 ` Yeoreum Yun
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=d70b6ac2-a8b2-4c34-acc4-ee421eb70aac@kernel.org \
--to=david@kernel.org \
--cc=aa9736195201@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=peterx@redhat.com \
--cc=riel@surriel.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=yeoreum.yun@arm.com \
/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.