[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdW4=HScVk2C+vkG_JqO9uMCF2VoJTuGqSi1-H=86e2RqQ@mail.gmail.com>
Date: Thu, 5 Dec 2024 09:04:56 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Zi Yan <ziy@...dia.com>
Cc: Matthew Wilcox <willy@...radead.org>, Vlastimil Babka <vbabka@...e.cz>, linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>, David Hildenbrand <david@...hat.com>,
Miaohe Lin <linmiaohe@...wei.com>, Kefeng Wang <wangkefeng.wang@...wei.com>,
John Hubbard <jhubbard@...dia.com>, "Huang, Ying" <ying.huang@...el.com>,
Ryan Roberts <ryan.roberts@....com>, Alexander Potapenko <glider@...gle.com>,
Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org,
linux-mips@...r.kernel.org
Subject: Re: [PATCH] mm: avoid zeroing user movable page twice with init_on_alloc=1
Hi Zi,
On Wed, Dec 4, 2024 at 7:30 PM Zi Yan <ziy@...dia.com> wrote:
> On 4 Dec 2024, at 12:33, Zi Yan wrote:
> > On 4 Dec 2024, at 11:29, Matthew Wilcox wrote:
> >> On Wed, Dec 04, 2024 at 11:16:51AM -0500, Zi Yan wrote:
> >>>> So maybe the clearing done as part of page allocator isn't enough here.
> >>>>
> >>> Basically, mips needs to flush data cache if kmap address is aliased to
> >>
> >> People use "aliased" in contronym ways. Do you mean "has a
> >> non-congruent alias" or "has a congruent alias"?
> >>
> >>> userspace address. This means when mips has THP on, the patch below
> >>> is not enough to fix the issue.
> >>>
> >>> In post_alloc_hook(), it does not make sense to pass userspace address
> >>> in to determine whether to flush dcache or not.
> >>>
> >>> One way to fix it is to add something like arch_userpage_post_alloc()
> >>> to flush dcache if kmap address is aliased to userspace address.
> >>> But my questions are that
> >>> 1) if kmap address will always be the same for two separate kmap_local() calls,
> >>
> >> No. It just takes the next address in the stack.
> >
> > Hmm, if kmap_local() gives different addresses, wouldn’t init_on_alloc be
> > causing issues before my patch? In the page allocator, the page is zeroed
> > from one kmap address without flush, then clear_user_highpage() clears
> > it again with another kmap address with flush. After returning to userspace,
> > the user application works on the page but when the cache line used by
> > init_on_alloc is written back (with 0s) at eviction, user data is corrupted.
> > Am I missing anything? Or all arch with cache aliasing never enables
> > init_on_alloc?
>
> Hi Geert,
>
> Regarding the above concern, have you ever had CONFIG_INIT_ON_ALLOC_DEFAULT_ON
> for your MIPS machine and encountered any issue? Or let me know if my reasoning
> above is flawed.
>
> To test it, I wonder if you can 1) revert my patch and 2) turn on
> CONFIG_INIT_ON_ALLOC_DEFAULT_ON for your MIPS machine and run some applications
> to see if any error happens.
That seems to work fine...
Kernel log confirms it's enabled:
-mem auto-init: stack:off, heap alloc:off, heap free:off
+mem auto-init: stack:off, heap alloc:on, heap free:off
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists