From: Dmitry Vyukov <dvyukov@google.com>
To: Joonsoo Kim <js1304@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Alexander Potapenko <glider@google.com>,
kasan-dev <kasan-dev@googlegroups.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
kernel-team@lge.com
Subject: Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption
Date: Wed, 24 May 2017 19:19:50 +0200 [thread overview]
Message-ID: <CACT4Y+ZwL+iTMvF5NpsovThQrdhunCc282ffjqQcgZg3tAQH4w@mail.gmail.com> (raw)
In-Reply-To: <20170524074539.GA9697@js1304-desktop>
On Wed, May 24, 2017 at 9:45 AM, Joonsoo Kim <js1304@gmail.com> wrote:
>> > What does make your current patch work then?
>> > Say we map a new shadow page, update the page shadow to say that there
>> > is mapped shadow. Then another CPU loads the page shadow and then
>> > loads from the newly mapped shadow. If we don't flush TLB, what makes
>> > the second CPU see the newly mapped shadow?
>>
>> /\/\/\/\/\/\
>>
>> Joonsoo, please answer this question above.
>
> Hello, I've answered it in another e-mail however it would not be
> sufficient. I try again.
>
> If the page isn't used for kernel stack, slab, and global variable
> (aka. kernel memory), black shadow is mapped for the page. We map a
> new shadow page if the page will be used for kernel memory. We need to
> flush TLB in all cpus when mapping a new shadow however it's not
> possible in some cases. So, this patch does just flushing local cpu's
> TLB. Another cpu could have stale TLB that points black shadow for
> this page. If that cpu with stale TLB try to check vailidity of the
> object on this page, result would be invalid since stale TLB points
> the black shadow and it's shadow value is non-zero. We need a magic
> here. At this moment, we cannot make sure if invalid is correct result
> or not since we didn't do full TLB flush. So fixup processing is
> started. It is implemented in check_memory_region_slow(). Flushing
> local TLB and re-checking the shadow value. With flushing local TLB,
> we will use fresh TLB at this time. Therefore, we can pass the
> validity check as usual.
>
>> I am trying to understand if there is any chance to make mapping a
>> single page for all non-interesting shadow ranges work. That would be
>
> This is what this patchset does. Mapping a single (zero/black) shadow
> page for all non-interesting (non-kernel memory) shadow ranges.
> There is only single instance of zero/black shadow page. On v1,
> I used black shadow page only so fail to get enough performance. On
> v2 mentioned in another thread, I use zero shadow for some region. I
> guess that performance problem would be gone.
I can't say I understand everything here, but after staring at the
patch I don't understand why we need pshadow at all now. Especially
with this commit
https://github.com/JoonsooKim/linux/commit/be36ee65f185e3c4026fe93b633056ea811120fb.
It seems that the current shadow is enough.
If we see bad shadow when the actual shadow value is good, we fall
onto slow path, flush tlb, reload shadow, see that it is good and
return. Pshadow is not needed in this case.
If we see good shadow when the actual shadow value is bad, we return
immediately and get false negative. Pshadow is not involved as well.
What am I missing?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-05-24 17:20 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-16 1:16 js1304
2017-05-16 1:16 ` [PATCH v1 01/11] mm/kasan: rename XXX_is_zero to XXX_is_nonzero js1304
2017-05-16 1:16 ` [PATCH v1 02/11] mm/kasan: don't fetch the next shadow value speculartively js1304
2017-05-16 1:16 ` [PATCH v1 03/11] mm/kasan: handle unaligned end address in zero_pte_populate js1304
2017-05-16 1:16 ` [PATCH v1 04/11] mm/kasan: extend kasan_populate_zero_shadow() js1304
2017-05-16 1:16 ` [PATCH v1 05/11] mm/kasan: introduce per-page shadow memory infrastructure js1304
2017-05-16 1:16 ` [PATCH v1 06/11] mm/kasan: mark/unmark the target range that is for original shadow memory js1304
2017-05-16 1:16 ` [PATCH v1 07/11] x86/kasan: use per-page " js1304
2017-05-16 1:16 ` [PATCH v1 08/11] mm/kasan: support on-demand shadow allocation/mapping js1304
2017-05-16 1:16 ` [PATCH v1 09/11] x86/kasan: support on-demand shadow mapping js1304
2017-05-16 1:16 ` [PATCH v1 10/11] mm/kasan: support dynamic shadow memory free js1304
2017-05-16 1:16 ` [PATCH v1 11/11] mm/kasan: change the order of shadow memory check js1304
2017-05-16 1:28 ` [PATCH(RE-RESEND) v1 01/11] mm/kasan: rename _is_zero to _is_nonzero Joonsoo Kim
2017-05-16 4:34 ` [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption Dmitry Vyukov
2017-05-16 4:47 ` Dmitry Vyukov
2017-05-16 6:23 ` Joonsoo Kim
2017-05-16 20:49 ` Dmitry Vyukov
2017-05-17 7:23 ` Joonsoo Kim
2017-05-17 7:25 ` Joonsoo Kim
2017-05-24 6:57 ` Dmitry Vyukov
2017-05-24 7:45 ` Joonsoo Kim
2017-05-24 17:19 ` Dmitry Vyukov [this message]
2017-05-25 0:41 ` Joonsoo Kim
2017-05-29 15:07 ` Dmitry Vyukov
2017-05-29 15:12 ` Dmitry Vyukov
2017-05-29 15:29 ` Dmitry Vyukov
2017-05-30 7:58 ` Vladimir Murzin
2017-05-30 8:15 ` Dmitry Vyukov
2017-05-30 8:31 ` Vladimir Murzin
2017-05-30 8:40 ` Vladimir Murzin
2017-05-30 8:49 ` Dmitry Vyukov
2017-05-30 9:08 ` Vladimir Murzin
2017-05-30 9:26 ` Dmitry Vyukov
2017-05-30 9:39 ` Vladimir Murzin
2017-05-30 9:45 ` Dmitry Vyukov
2017-05-30 9:54 ` Vladimir Murzin
2017-05-30 14:16 ` Andrey Ryabinin
2017-05-31 5:50 ` Joonsoo Kim
2017-05-31 16:31 ` Andrey Ryabinin
2017-06-08 2:43 ` Joonsoo Kim
2017-06-01 15:16 ` 王靖天
2017-06-01 18:06 ` Dmitry Vyukov
2017-06-08 2:40 ` Joonsoo Kim
2017-06-13 16:49 ` Andrey Ryabinin
2017-06-14 0:12 ` Joonsoo Kim
2017-05-17 12:17 ` Andrey Ryabinin
2017-05-19 1:53 ` Joonsoo Kim
2017-05-22 6:02 ` Dmitry Vyukov
2017-05-24 6:04 ` Joonsoo Kim
2017-05-24 16:31 ` Dmitry Vyukov
2017-05-25 0:46 ` Joonsoo Kim
2017-05-22 14:00 ` Andrey Ryabinin
2017-05-24 6:18 ` Joonsoo Kim
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=CACT4Y+ZwL+iTMvF5NpsovThQrdhunCc282ffjqQcgZg3tAQH4w@mail.gmail.com \
--to=dvyukov@google.com \
--cc=akpm@linux-foundation.org \
--cc=aryabinin@virtuozzo.com \
--cc=glider@google.com \
--cc=hpa@zytor.com \
--cc=js1304@gmail.com \
--cc=kasan-dev@googlegroups.com \
--cc=kernel-team@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
/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