All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qian Cai <cai@lca.pw>
To: David Hildenbrand <david@redhat.com>
Cc: Michal Hocko <mhocko@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	pmladek@suse.com, rostedt@goodmis.org, peterz@infradead.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -next v4] mm/hotplug: silence a lockdep splat with printk()
Date: Fri, 17 Jan 2020 14:42:32 -0500	[thread overview]
Message-ID: <9E07384A-0C7F-4462-852F-B5A386AC10EB@lca.pw> (raw)
In-Reply-To: <06AE045D-F167-406B-A78B-CAE246058C9D@redhat.com>



> On Jan 17, 2020, at 2:15 PM, David Hildenbrand <david@redhat.com> wrote:
> 
> 
> 
>> Am 17.01.2020 um 19:49 schrieb Qian Cai <cai@lca.pw>:
>> 
>> 
>> 
>>> On Jan 17, 2020, at 10:46 AM, Michal Hocko <mhocko@kernel.org> wrote:
>>> 
>>>> On Fri 17-01-20 10:05:12, Qian Cai wrote:
>>>> 
>>>> 
>>>>> On Jan 17, 2020, at 9:39 AM, Michal Hocko <mhocko@kernel.org> wrote:
>>>>> 
>>>>> Thanks a lot. Having it in a separate patch would be great.
>>>> 
>>>> I was thinking about removing that WARN together in this v5 patch,
>>>> so there is less churn to touch the same function again. However, I
>>>> am fine either way, so just shout out if you feel strongly towards a
>>>> separate patch.
>>> 
>>> I hope you meant moving rather than removing ;). The warning is useful
>>> because we shouldn't see unmovable pages in the movable zone. And a
>>> separate patch makes more sense because the justification is slightly
>>> different. We do not want to have a way for userspace to trigger the
>>> warning from userspace - even though it shouldn't be possible, but
>>> still. Only the offlining path should complain.
>> 
>> Something like this?
>> 
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 621716a25639..32c854851e1f 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -8307,7 +8307,6 @@ struct page *has_unmovable_pages(struct zone *zone, struct page *page,
>>       }
>>       return NULL;
>> unmovable:
>> -       WARN_ON_ONCE(zone_idx(zone) == ZONE_MOVABLE);
>>       return pfn_to_page(pfn + iter);
>> }
>> 
>> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
>> index e70586523ca3..08571b515d9f 100644
>> --- a/mm/page_isolation.c
>> +++ b/mm/page_isolation.c
>> @@ -54,9 +54,11 @@ static int set_migratetype_isolate(struct page *page, int migratetype, int isol_
>> 
>> out:
>>       spin_unlock_irqrestore(&zone->lock, flags);
>> +
>>       if (!ret)
>>               drain_all_pages(zone);
>>       else if ((isol_flags & REPORT_FAILURE) && unmovable)
> 
> We have a dedicated flag for the offlining part.

This should do the trick then,

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 621716a25639..4bb3e503cb9e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -8231,7 +8231,7 @@ struct page *has_unmovable_pages(struct zone *zone, struct page *page,
                if (is_migrate_cma(migratetype))
                        return NULL;
 
-               goto unmovable;
+               return page;
        }
 
        for (; iter < pageblock_nr_pages; iter++) {
@@ -8241,7 +8241,7 @@ struct page *has_unmovable_pages(struct zone *zone, struct page *page,
                page = pfn_to_page(pfn + iter);
 
                if (PageReserved(page))
-                       goto unmovable;
+                       return page;
 
                /*
                 * If the zone is movable and we have ruled out all reserved
@@ -8303,12 +8303,9 @@ struct page *has_unmovable_pages(struct zone *zone, struct page *page,
                 * is set to both of a memory hole page and a _used_ kernel
                 * page at boot.
                 */
-               goto unmovable;
+               return pfn_to_page(pfn + iter);
        }
        return NULL;
-unmovable:
-       WARN_ON_ONCE(zone_idx(zone) == ZONE_MOVABLE);
-       return pfn_to_page(pfn + iter);
 }
 
 #ifdef CONFIG_CONTIG_ALLOC
diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index e70586523ca3..e140eaa901b2 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -54,14 +54,20 @@ static int set_migratetype_isolate(struct page *page, int migratetype, int isol_
 
 out:
        spin_unlock_irqrestore(&zone->lock, flags);
-       if (!ret)
+
+       if (!ret) {
                drain_all_pages(zone);
-       else if ((isol_flags & REPORT_FAILURE) && unmovable)
-               /*
-                * printk() with zone->lock held will guarantee to trigger a
-                * lockdep splat, so defer it here.
-                */
-               dump_page(unmovable, "unmovable page");
+       } else {
+               if (isol_flags & MEMORY_OFFLINE)
+                       WARN_ON_ONCE(zone_idx(zone) == ZONE_MOVABLE);
+
+               if ((isol_flags & REPORT_FAILURE) && unmovable)
+                       /*
+                        * printk() with zone->lock held will likely trigger a
+                        * lockdep splat, so defer it here.
+                        */
+                       dump_page(unmovable, "unmovable page");
+       }
 
        return ret;
 }

> 
>> +               WARN_ON_ONCE(zone_idx(zone) == ZONE_MOVABLE);
>>               /*
>>                * printk() with zone->lock held will guarantee to trigger a
>>                * lockdep splat, so defer it here.
>> 
> 
> So, are we fine with unmovable data ending up in ZONE_MOVABLE as long as we can offline it? 
> 
> This might make my life in virtio-mem a little easier (I can unplug chunks falling into ZONE_MOVABLE).


      reply	other threads:[~2020-01-17 19:42 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-17  2:21 [PATCH -next v4] mm/hotplug: silence a lockdep splat with printk() Qian Cai
2020-01-17  2:49 ` Sergey Senozhatsky
2020-01-17  8:51 ` David Hildenbrand
2020-01-17  8:59   ` Michal Hocko
2020-01-17  9:25     ` David Hildenbrand
2020-01-17  9:40       ` Michal Hocko
2020-01-17  9:42         ` David Hildenbrand
2020-01-17 10:17           ` Michal Hocko
2020-01-17 10:18             ` David Hildenbrand
2020-01-17 12:40   ` Qian Cai
2020-01-17 12:53     ` David Hildenbrand
2020-01-17 13:30       ` Qian Cai
2020-01-17 13:42         ` David Hildenbrand
2020-01-17 14:42     ` Michal Hocko
2020-01-17 14:43       ` David Hildenbrand
2020-01-17 15:26         ` Michal Hocko
2020-01-17  8:59 ` Michal Hocko
2020-01-17 12:32   ` Qian Cai
2020-01-17 14:39     ` Michal Hocko
2020-01-17 15:05       ` Qian Cai
2020-01-17 15:46         ` Michal Hocko
2020-01-17 18:49           ` Qian Cai
2020-01-17 19:15             ` David Hildenbrand
2020-01-17 19:42               ` Qian Cai [this message]

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=9E07384A-0C7F-4462-852F-B5A386AC10EB@lca.pw \
    --to=cai@lca.pw \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky.work@gmail.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.