Messages in this thread |  | | Date | Wed, 22 Oct 2014 12:32:08 +0200 | From | Dominik Dingel <> | Subject | Re: [PATCH 3/4] s390/mm: prevent and break zero page mappings in case of storage keys |
| |
On Wed, 22 Oct 2014 12:09:31 +0200 Paolo Bonzini <pbonzini@redhat.com> wrote:
> 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"?
I can't, my reasoning there is wrong. I remembered incorrectly that we use mm_use_skey in arch/s390/kvm/priv.c to check if we need to call s390_enable_skey, but that does happen with the interception bits.
So every vCPU which get the a interception for a storage key instruction will call s390_enable_skey and wait there for the mmap_sem.
> 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?
You are right, this is a bug, where we will drop to userspace with -ENOMEM.
I will fix this as well.
> Thanks, and sorry for the flurry of questions! :)
I really appreciate your questions and remarks. Thank you!
> Paolo >
|  |