From: Paolo Bonzini <pbonzini@redhat.com>
To: Dominik Dingel <dingel@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, Mel Gorman <mgorman@suse.de>,
Michal Hocko <mhocko@suse.cz>,
Dave Hansen <dave.hansen@intel.com>,
Rik van Riel <riel@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
Andy Lutomirski <luto@amacapital.net>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Bob Liu <lliubbo@gmail.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Cornelia Huck <cornelia.huck@de.ibm.com>,
Gleb Natapov <gleb@kernel.org>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"H. Peter Anvin" <hpa@linux.intel.com>,
Hugh Dickins <hughd@google.com>, Ingo Molnar <mingo@kernel.org>,
Jianyu Zhan <nasa4836@gmail.com>,
Johannes Weiner <hannes@cmpxchg.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Konstantin Weitz <konstantin.weitz@gmail.com>,
kvm@vger.kernel.org, linux390@de.ibm.com,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH 3/4] s390/mm: prevent and break zero page mappings in case of storage keys
Date: Wed, 22 Oct 2014 12:09:31 +0200 [thread overview]
Message-ID: <5447825B.5040608@redhat.com> (raw)
In-Reply-To: <1413966624-12447-4-git-send-email-dingel@linux.vnet.ibm.com>
On 10/22/2014 10:30 AM, Dominik Dingel wrote:
> As use_skey is already the condition on which we call s390_enable_skey
> we need to introduce a new flag for the mm->context on which we decide
> if zero page mapping is allowed.
Can you explain better why "mm->context.use_skey = 1" cannot be done
before the walk_page_range? Where does the walk or __s390_enable_skey
or (after the next patch) ksm_madvise rely on
"mm->context.forbids_zeropage && !mm->context.use_skey"?
The only reason I can think of, is that the next patch does not reset
"mm->context.forbids_zeropage" to 0 if the ksm_madvise fails. Why
doesn't it do that---or is it a bug?
Thanks, and sorry for the flurry of questions! :)
Paolo
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Dominik Dingel <dingel@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, Mel Gorman <mgorman@suse.de>,
Michal Hocko <mhocko@suse.cz>,
Dave Hansen <dave.hansen@intel.com>,
Rik van Riel <riel@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
Andy Lutomirski <luto@amacapital.net>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Bob Liu <lliubbo@gmail.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Cornelia Huck <cornelia.huck@de.ibm.com>,
Gleb Natapov <gleb@kernel.org>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"H. Peter Anvin" <hpa@linux.intel.com>,
Hugh Dickins <hughd@google.com>, Ingo Molnar <mingo@kernel.org>,
Jianyu Zhan <nasa4836@gmail.com>,
Johannes Weiner <hannes@cmpxchg.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Konstantin Weitz <konstantin.weitz@gmail.com>,
kvm@vger.kernel.org, linux390@de.ibm.com,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH 3/4] s390/mm: prevent and break zero page mappings in case of storage keys
Date: Wed, 22 Oct 2014 12:09:31 +0200 [thread overview]
Message-ID: <5447825B.5040608@redhat.com> (raw)
In-Reply-To: <1413966624-12447-4-git-send-email-dingel@linux.vnet.ibm.com>
On 10/22/2014 10:30 AM, Dominik Dingel wrote:
> As use_skey is already the condition on which we call s390_enable_skey
> we need to introduce a new flag for the mm->context on which we decide
> if zero page mapping is allowed.
Can you explain better why "mm->context.use_skey = 1" cannot be done
before the walk_page_range? Where does the walk or __s390_enable_skey
or (after the next patch) ksm_madvise rely on
"mm->context.forbids_zeropage && !mm->context.use_skey"?
The only reason I can think of, is that the next patch does not reset
"mm->context.forbids_zeropage" to 0 if the ksm_madvise fails. Why
doesn't it do that---or is it a bug?
Thanks, and sorry for the flurry of questions! :)
Paolo
next prev parent reply other threads:[~2014-10-22 10:09 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-22 8:30 [PATCH v2 0/4] mm: new function to forbid zeropage mappings for a process Dominik Dingel
2014-10-22 8:30 ` Dominik Dingel
2014-10-22 8:30 ` Dominik Dingel
2014-10-22 8:30 ` Dominik Dingel
2014-10-22 8:30 ` [PATCH 1/4] s390/mm: recfactor global pgste updates Dominik Dingel
2014-10-22 8:30 ` Dominik Dingel
2014-10-22 8:30 ` Dominik Dingel
2014-10-22 8:30 ` Dominik Dingel
2014-10-22 8:30 ` [PATCH 2/4] mm: introduce mm_forbids_zeropage function Dominik Dingel
2014-10-22 8:30 ` Dominik Dingel
2014-10-22 8:30 ` Dominik Dingel
2014-10-22 8:30 ` Dominik Dingel
2014-10-22 8:30 ` [PATCH 3/4] s390/mm: prevent and break zero page mappings in case of storage keys Dominik Dingel
2014-10-22 8:30 ` Dominik Dingel
2014-10-22 8:30 ` Dominik Dingel
2014-10-22 8:30 ` Dominik Dingel
2014-10-22 10:09 ` Paolo Bonzini
2014-10-22 10:09 ` Paolo Bonzini
2014-10-22 10:09 ` Paolo Bonzini [this message]
2014-10-22 10:09 ` Paolo Bonzini
2014-10-22 10:32 ` Dominik Dingel
2014-10-22 10:32 ` Dominik Dingel
2014-10-22 10:32 ` Dominik Dingel
2014-10-22 8:30 ` [PATCH 4/4] s390/mm: disable KSM for storage key enabled pages Dominik Dingel
2014-10-22 8:30 ` Dominik Dingel
2014-10-22 8:30 ` Dominik Dingel
2014-10-22 8:30 ` Dominik Dingel
-- strict thread matches above, loose matches on Subject: below --
2014-10-22 11:09 [PATCH v3 0/4] mm: new function to forbid zeropage mappings for a process Dominik Dingel
2014-10-22 11:09 ` [PATCH 3/4] s390/mm: prevent and break zero page mappings in case of storage keys Dominik Dingel
2014-10-22 11:09 ` Dominik Dingel
2014-10-22 11:09 ` Dominik Dingel
2014-10-22 11:09 ` Dominik Dingel
2014-10-22 14:00 ` Paolo Bonzini
2014-10-22 14:00 ` Paolo Bonzini
2014-10-22 14:00 ` Paolo Bonzini
2014-10-22 14:00 ` Paolo Bonzini
2014-10-17 14:09 [PATCH 0/4] mm: new flag to forbid zero page mappings for a vma Dominik Dingel
2014-10-17 14:09 ` [PATCH 3/4] s390/mm: prevent and break zero page mappings in case of storage keys Dominik Dingel
2014-10-17 14:09 ` Dominik Dingel
2014-10-17 14:09 ` Dominik Dingel
2014-10-17 14:09 ` Dominik Dingel
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=5447825B.5040608@redhat.com \
--to=pbonzini@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=dave.hansen@intel.com \
--cc=dingel@linux.vnet.ibm.com \
--cc=gleb@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@linux.intel.com \
--cc=hughd@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=konstantin.weitz@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux390@de.ibm.com \
--cc=lliubbo@gmail.com \
--cc=luto@amacapital.net \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=mingo@kernel.org \
--cc=nasa4836@gmail.com \
--cc=riel@redhat.com \
--cc=schwidefsky@de.ibm.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.