From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini 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:07 +0200 Message-ID: <54478243.7010108@redhat.com> References: <1413966624-12447-1-git-send-email-dingel@linux.vnet.ibm.com> <1413966624-12447-4-git-send-email-dingel@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org To: kvm@vger.kernel.org Return-path: Received: from plane.gmane.org ([80.91.229.3]:51568 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754546AbaJVKJ2 (ORCPT ); Wed, 22 Oct 2014 06:09:28 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xgsr2-0001wF-Qk for kvm@vger.kernel.org; Wed, 22 Oct 2014 12:09:20 +0200 Received: from net-37-117-142-149.cust.vodafonedsl.it ([37.117.142.149]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Oct 2014 12:09:20 +0200 Received: from pbonzini by net-37-117-142-149.cust.vodafonedsl.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Oct 2014 12:09:20 +0200 In-Reply-To: <1413966624-12447-4-git-send-email-dingel@linux.vnet.ibm.com> Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org Sender: kvm-owner@vger.kernel.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini 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:07 +0200 Message-ID: <54478243.7010108@redhat.com> References: <1413966624-12447-1-git-send-email-dingel@linux.vnet.ibm.com> <1413966624-12447-4-git-send-email-dingel@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1413966624-12447-4-git-send-email-dingel@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org To: kvm@vger.kernel.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.orglinux-kernel@vger.kernel.org List-Id: linux-mm.kvack.org 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