linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: chenqiwu <qiwuchen55@gmail.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	chenqiwu <chenqiwu@xiaomi.com>
Subject: Re: [PATCH] mm/memory: add refcount for special mapping page in copy_one_pte()
Date: Fri, 17 Apr 2020 17:23:31 +0200	[thread overview]
Message-ID: <20200417152331.GP26707@dhcp22.suse.cz> (raw)
In-Reply-To: <20200417142618.GA31882@cqw-OptiPlex-7050>

On Fri 17-04-20 22:26:18, chenqiwu wrote:
> On Fri, Apr 17, 2020 at 01:43:12PM +0200, Michal Hocko wrote:
> > On Fri 17-04-20 18:31:54, qiwuchen55@gmail.com wrote:
> > > From: chenqiwu <chenqiwu@xiaomi.com>
> > > 
> > > If we get a special mapping page like device mapping page or zero page
> > > when copy_one_pte, it's necessary add the page refcount count.
> > 
> > From the changelog it is not clear what is the actual problem and how
> > the patch address it. Please be more verbose.
> >
> I don't find any actual problem, but I think there should be addressed
> to update the page refcount for special mappings include devmap and zero
> page instead of doing nothing else, since we copy the pte from one task
> to the other.

As Matthew pointed out, zero pages are special. Just check how
vm_normal_page returns NULL (the same is the case for pte_devmap). This
means, among other things that zap_pte_range which is called during
munmap will only clear the pte but it doesn't operate on those pages so
there is no put_page for your get_page here.

I do realize that this might be a subtle details that might be
confusing. On the other hand trying to formulate the specific problem
and add an explanation of the fix in the changelog could have revealed
this. It is really trivial to generate mappings backed by zero pages and
if the reference count was not handled properly then it would blow up
pretty quickly.

-- 
Michal Hocko
SUSE Labs


  parent reply	other threads:[~2020-04-17 15:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-17 10:31 qiwuchen55
2020-04-17 11:43 ` Michal Hocko
2020-04-17 14:26   ` chenqiwu
2020-04-17 14:45     ` Matthew Wilcox
2020-04-17 15:23     ` Michal Hocko [this message]
2020-04-18  3:12       ` chenqiwu
2020-04-20  7:42         ` Michal Hocko

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=20200417152331.GP26707@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=chenqiwu@xiaomi.com \
    --cc=linux-mm@kvack.org \
    --cc=qiwuchen55@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox