mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	"x86@kernel.org" <x86@kernel.org>,
	Tobias Regnery <tobias.regnery@gmail.com>,
	"Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
	Alexander Potapenko <glider@google.com>,
	kasan-dev <kasan-dev@googlegroups.com>,
	LKML <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>,
	Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH] x86/mm/ptdump: Fix soft lockup in page table walker.
Date: Fri, 10 Feb 2017 16:56:19 +0300	[thread overview]
Message-ID: <730837a1-ee6f-9891-0421-93616dd1c4eb@virtuozzo.com> (raw)
In-Reply-To: <CACT4Y+YMKBfDuMMhH3pAAJh9DMtyjwMLqZMZ-3SyC7kGRubGXw@mail.gmail.com>

On 02/10/2017 04:02 PM, Dmitry Vyukov wrote:
> On Fri, Feb 10, 2017 at 1:15 PM, Andrey Ryabinin
> <aryabinin@virtuozzo.com> wrote:
>>
>>
>> On 02/10/2017 02:18 PM, Thomas Gleixner wrote:
>>> On Fri, 10 Feb 2017, Dmitry Vyukov wrote:
>>>> This is the right thing to do per se, but I am concerned that now
>>>> people will just suffers from slow boot (it can take literally
>>>> minutes) and will not realize the root cause nor that it's fixable
>>>> (e.g. with rodata=n) and will probably just blame KASAN for slowness.
>>>>
>>>> Could we default this rodata check to n under KASAN? Or at least print
>>>> some explanatory warning message before doing marking rodata (it
>>>> should be printed right before "hang", so if you stare at it for a
>>>> minute during each boot you realize that it may be related)? Or
>>>> something along these lines. FWIW in my builds I just always disable
>>>> the check.
>>>
>>> That certainly makes sense and we emit such warnings in other places
>>> already (lockdep, trace_printk ...)
>>>
>>
>> Agreed, but perhaps it would be better to make this code faster for KASAN=y?
>> The main problem here is that we have many pgd entries containing kasan_zero_pud values
>> and ptdump walker checks kasan_zero_pud many times.
>> Instead, we could check it only once and skip further kasan_zero_pud's.
>>
>> I can't say I like this hack very much, but it wins me almost 20 seconds of boot time.
>> Any objections?
> 
> 
> Now I remember that we already discussed it in this thread:
> https://lkml.org/lkml/2016/11/8/775
> 
> Andrey, you proposed:
> 
> "I didn't look at any code, but we probably could can remember last
> visited pgd and skip next pgd if it's the same as previous."
> 
> Do you still think it's a good idea?

Ah, indeed. It will do roughly the same but with less of code churn, see bellow.

> Walking the same pgd multiple times does not make sense (right?). And
> it could probably speedup non-kasan builds to some degree in some
> contexts. And the code will be free of additional ifdefs.
> 

We could make it without ifdefs but this would be useless for KASAN=n
as page table entries normally unique. So I'm thinking to add #ifdef
at least for documentation purposes.



diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 8aa6bea..1599a5c 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -373,6 +373,11 @@ static inline bool is_hypervisor_range(int idx)
 #endif
 }
 
+static bool pgd_already_checked(pgd_t *prev_pgd, pgd_t *pgd, bool checkwx)
+{
+       return checkwx && prev_pgd && (pgd_val(*prev_pgd) == pgd_val(*pgd));
+}
+
 static void ptdump_walk_pgd_level_core(struct seq_file *m, pgd_t *pgd,
                                       bool checkwx)
 {
@@ -381,6 +386,7 @@ static void ptdump_walk_pgd_level_core(struct seq_file *m, pgd_t *pgd,
 #else
        pgd_t *start = swapper_pg_dir;
 #endif
+       pgd_t *prev_pgd = NULL;
        pgprotval_t prot;
        int i;
        struct pg_state st = {};
@@ -396,7 +402,8 @@ static void ptdump_walk_pgd_level_core(struct seq_file *m, pgd_t *pgd,
 
        for (i = 0; i < PTRS_PER_PGD; i++) {
                st.current_address = normalize_addr(i * PGD_LEVEL_MULT);
-               if (!pgd_none(*start) && !is_hypervisor_range(i)) {
+               if (!pgd_none(*start) && !is_hypervisor_range(i) &&
+                               !pgd_already_checked(prev_pgd, start, checkwx)) {
                        if (pgd_large(*start) || !pgd_present(*start)) {
                                prot = pgd_flags(*start);
                                note_page(m, &st, __pgprot(prot), 1);
@@ -408,6 +415,7 @@ static void ptdump_walk_pgd_level_core(struct seq_file *m, pgd_t *pgd,
                        note_page(m, &st, __pgprot(0), 1);
 
                cond_resched();
+               prev_pgd = start;
                start++;
        }

  reply	other threads:[~2017-02-10 13:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-09 12:46 BUG: soft lockup in 4.10-rc7 with KASAN enabled Tobias Regnery
2017-02-09 16:46 ` Paul E. McKenney
2017-02-09 16:56   ` Paul E. McKenney
2017-02-09 17:23     ` Dmitry Vyukov
2017-02-10  8:14       ` Tobias Regnery
2017-02-10  9:47 ` Andrey Ryabinin
2017-02-10  9:54   ` [PATCH] x86/mm/ptdump: Fix soft lockup in page table walker Andrey Ryabinin
2017-02-10 10:07     ` [tip:x86/urgent] " tip-bot for Andrey Ryabinin
2017-02-10 10:24     ` [PATCH] " Dmitry Vyukov
2017-02-10 11:18       ` Thomas Gleixner
2017-02-10 12:15         ` Andrey Ryabinin
2017-02-10 13:02           ` Dmitry Vyukov
2017-02-10 13:56             ` Andrey Ryabinin [this message]
2017-02-10 14:17               ` Dmitry Vyukov
2017-02-10 14:29               ` Mark Rutland
2017-02-10 14:38                 ` Andrey Ryabinin
2017-02-10 14:41                   ` Mark Rutland
2017-02-10 14:38             ` Mark Rutland

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=730837a1-ee6f-9891-0421-93616dd1c4eb@virtuozzo.com \
    --to=aryabinin@virtuozzo.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=hpa@zytor.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tobias.regnery@gmail.com \
    --cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®