All of lore.kernel.org
 help / color / mirror / Atom feed
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>,
	kvm@vger.kernel.org, linux390@de.ibm.com,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>, Sasha Levin <sasha.levi>
Subject: Re: [PATCH 3/4] s390/mm: prevent and break zero page mappings in case of storage keys
Date: Wed, 22 Oct 2014 16:00:02 +0200	[thread overview]
Message-ID: <5447B862.4060707@redhat.com> (raw)
In-Reply-To: <1413976170-42501-4-git-send-email-dingel@linux.vnet.ibm.com>

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

On 10/22/2014 01:09 PM, Dominik Dingel wrote:
> As soon as storage keys are enabled we need to stop working on zero page
> mappings to prevent inconsistencies between storage keys and pgste.
> 
> Otherwise following data corruption could happen:
> 1) guest enables storage key
> 2) guest sets storage key for not mapped page X
>    -> change goes to PGSTE
> 3) guest reads from page X
>    -> as X was not dirty before, the page will be zero page backed,
>       storage key from PGSTE for X will go to storage key for zero page
> 4) guest sets storage key for not mapped page Y (same logic as above
> 5) guest reads from page Y
>    -> as Y was not dirty before, the page will be zero page backed,
>       storage key from PGSTE for Y will got to storage key for zero page
>       overwriting storage key for X
> 
> While holding the mmap sem, we are safe against changes on entries we
> already fixed, as every fault would need to take the mmap_sem (read).
> 
> Other vCPUs executing storage key instructions will get a one time interception
> and be serialized also with mmap_sem.
> 
> Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
> ---
>  arch/s390/include/asm/pgtable.h |  5 +++++
>  arch/s390/mm/pgtable.c          | 13 ++++++++++++-
>  2 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
> index 1e991f6a..0da98d6 100644
> --- a/arch/s390/include/asm/pgtable.h
> +++ b/arch/s390/include/asm/pgtable.h
> @@ -481,6 +481,11 @@ static inline int mm_has_pgste(struct mm_struct *mm)
>  	return 0;
>  }
>  
> +/*
> + * In the case that a guest uses storage keys
> + * faults should no longer be backed by zero pages
> + */
> +#define mm_forbids_zeropage mm_use_skey
>  static inline int mm_use_skey(struct mm_struct *mm)
>  {
>  #ifdef CONFIG_PGSTE
> diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
> index ab55ba8..58d7eb2 100644
> --- a/arch/s390/mm/pgtable.c
> +++ b/arch/s390/mm/pgtable.c
> @@ -1309,6 +1309,15 @@ static int __s390_enable_skey(pte_t *pte, unsigned long addr,
>  	pgste_t pgste;
>  
>  	pgste = pgste_get_lock(pte);
> +	/*
> +	 * Remove all zero page mappings,
> +	 * after establishing a policy to forbid zero page mappings
> +	 * following faults for that page will get fresh anonymous pages
> +	 */
> +	if (is_zero_pfn(pte_pfn(*pte))) {
> +		ptep_flush_direct(walk->mm, addr, pte);
> +		pte_val(*pte) = _PAGE_INVALID;
> +	}
>  	/* Clear storage key */
>  	pgste_val(pgste) &= ~(PGSTE_ACC_BITS | PGSTE_FP_BIT |
>  			      PGSTE_GR_BIT | PGSTE_GC_BIT);
> @@ -1327,9 +1336,11 @@ void s390_enable_skey(void)
>  	down_write(&mm->mmap_sem);
>  	if (mm_use_skey(mm))
>  		goto out_up;
> +
> +	mm->context.use_skey = 1;
> +
>  	walk.mm = mm;
>  	walk_page_range(0, TASK_SIZE, &walk);
> -	mm->context.use_skey = 1;
>  
>  out_up:
>  	up_write(&mm->mmap_sem);
> 

--
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>,
	kvm@vger.kernel.org, linux390@de.ibm.com,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Sasha Levin <sasha.levi
Subject: Re: [PATCH 3/4] s390/mm: prevent and break zero page mappings in case of storage keys
Date: Wed, 22 Oct 2014 16:00:02 +0200	[thread overview]
Message-ID: <5447B862.4060707@redhat.com> (raw)
In-Reply-To: <1413976170-42501-4-git-send-email-dingel@linux.vnet.ibm.com>

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

On 10/22/2014 01:09 PM, Dominik Dingel wrote:
> As soon as storage keys are enabled we need to stop working on zero page
> mappings to prevent inconsistencies between storage keys and pgste.
> 
> Otherwise following data corruption could happen:
> 1) guest enables storage key
> 2) guest sets storage key for not mapped page X
>    -> change goes to PGSTE
> 3) guest reads from page X
>    -> as X was not dirty before, the page will be zero page backed,
>       storage key from PGSTE for X will go to storage key for zero page
> 4) guest sets storage key for not mapped page Y (same logic as above
> 5) guest reads from page Y
>    -> as Y was not dirty before, the page will be zero page backed,
>       storage key from PGSTE for Y will got to storage key for zero page
>       overwriting storage key for X
> 
> While holding the mmap sem, we are safe against changes on entries we
> already fixed, as every fault would need to take the mmap_sem (read).
> 
> Other vCPUs executing storage key instructions will get a one time interception
> and be serialized also with mmap_sem.
> 
> Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
> ---
>  arch/s390/include/asm/pgtable.h |  5 +++++
>  arch/s390/mm/pgtable.c          | 13 ++++++++++++-
>  2 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
> index 1e991f6a..0da98d6 100644
> --- a/arch/s390/include/asm/pgtable.h
> +++ b/arch/s390/include/asm/pgtable.h
> @@ -481,6 +481,11 @@ static inline int mm_has_pgste(struct mm_struct *mm)
>  	return 0;
>  }
>  
> +/*
> + * In the case that a guest uses storage keys
> + * faults should no longer be backed by zero pages
> + */
> +#define mm_forbids_zeropage mm_use_skey
>  static inline int mm_use_skey(struct mm_struct *mm)
>  {
>  #ifdef CONFIG_PGSTE
> diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
> index ab55ba8..58d7eb2 100644
> --- a/arch/s390/mm/pgtable.c
> +++ b/arch/s390/mm/pgtable.c
> @@ -1309,6 +1309,15 @@ static int __s390_enable_skey(pte_t *pte, unsigned long addr,
>  	pgste_t pgste;
>  
>  	pgste = pgste_get_lock(pte);
> +	/*
> +	 * Remove all zero page mappings,
> +	 * after establishing a policy to forbid zero page mappings
> +	 * following faults for that page will get fresh anonymous pages
> +	 */
> +	if (is_zero_pfn(pte_pfn(*pte))) {
> +		ptep_flush_direct(walk->mm, addr, pte);
> +		pte_val(*pte) = _PAGE_INVALID;
> +	}
>  	/* Clear storage key */
>  	pgste_val(pgste) &= ~(PGSTE_ACC_BITS | PGSTE_FP_BIT |
>  			      PGSTE_GR_BIT | PGSTE_GC_BIT);
> @@ -1327,9 +1336,11 @@ void s390_enable_skey(void)
>  	down_write(&mm->mmap_sem);
>  	if (mm_use_skey(mm))
>  		goto out_up;
> +
> +	mm->context.use_skey = 1;
> +
>  	walk.mm = mm;
>  	walk_page_range(0, TASK_SIZE, &walk);
> -	mm->context.use_skey = 1;
>  
>  out_up:
>  	up_write(&mm->mmap_sem);
> 

--
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>,
	kvm@vger.kernel.org, linux390@de.ibm.com,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Sasha Levin <sasha.levin@oracle.com>
Subject: Re: [PATCH 3/4] s390/mm: prevent and break zero page mappings in case of storage keys
Date: Wed, 22 Oct 2014 16:00:02 +0200	[thread overview]
Message-ID: <5447B862.4060707@redhat.com> (raw)
In-Reply-To: <1413976170-42501-4-git-send-email-dingel@linux.vnet.ibm.com>

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

On 10/22/2014 01:09 PM, Dominik Dingel wrote:
> As soon as storage keys are enabled we need to stop working on zero page
> mappings to prevent inconsistencies between storage keys and pgste.
> 
> Otherwise following data corruption could happen:
> 1) guest enables storage key
> 2) guest sets storage key for not mapped page X
>    -> change goes to PGSTE
> 3) guest reads from page X
>    -> as X was not dirty before, the page will be zero page backed,
>       storage key from PGSTE for X will go to storage key for zero page
> 4) guest sets storage key for not mapped page Y (same logic as above
> 5) guest reads from page Y
>    -> as Y was not dirty before, the page will be zero page backed,
>       storage key from PGSTE for Y will got to storage key for zero page
>       overwriting storage key for X
> 
> While holding the mmap sem, we are safe against changes on entries we
> already fixed, as every fault would need to take the mmap_sem (read).
> 
> Other vCPUs executing storage key instructions will get a one time interception
> and be serialized also with mmap_sem.
> 
> Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
> ---
>  arch/s390/include/asm/pgtable.h |  5 +++++
>  arch/s390/mm/pgtable.c          | 13 ++++++++++++-
>  2 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
> index 1e991f6a..0da98d6 100644
> --- a/arch/s390/include/asm/pgtable.h
> +++ b/arch/s390/include/asm/pgtable.h
> @@ -481,6 +481,11 @@ static inline int mm_has_pgste(struct mm_struct *mm)
>  	return 0;
>  }
>  
> +/*
> + * In the case that a guest uses storage keys
> + * faults should no longer be backed by zero pages
> + */
> +#define mm_forbids_zeropage mm_use_skey
>  static inline int mm_use_skey(struct mm_struct *mm)
>  {
>  #ifdef CONFIG_PGSTE
> diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
> index ab55ba8..58d7eb2 100644
> --- a/arch/s390/mm/pgtable.c
> +++ b/arch/s390/mm/pgtable.c
> @@ -1309,6 +1309,15 @@ static int __s390_enable_skey(pte_t *pte, unsigned long addr,
>  	pgste_t pgste;
>  
>  	pgste = pgste_get_lock(pte);
> +	/*
> +	 * Remove all zero page mappings,
> +	 * after establishing a policy to forbid zero page mappings
> +	 * following faults for that page will get fresh anonymous pages
> +	 */
> +	if (is_zero_pfn(pte_pfn(*pte))) {
> +		ptep_flush_direct(walk->mm, addr, pte);
> +		pte_val(*pte) = _PAGE_INVALID;
> +	}
>  	/* Clear storage key */
>  	pgste_val(pgste) &= ~(PGSTE_ACC_BITS | PGSTE_FP_BIT |
>  			      PGSTE_GR_BIT | PGSTE_GC_BIT);
> @@ -1327,9 +1336,11 @@ void s390_enable_skey(void)
>  	down_write(&mm->mmap_sem);
>  	if (mm_use_skey(mm))
>  		goto out_up;
> +
> +	mm->context.use_skey = 1;
> +
>  	walk.mm = mm;
>  	walk_page_range(0, TASK_SIZE, &walk);
> -	mm->context.use_skey = 1;
>  
>  out_up:
>  	up_write(&mm->mmap_sem);
> 

--
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>,
	kvm@vger.kernel.org, linux390@de.ibm.com,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Sasha Levin <sasha.levin@oracle.com>
Subject: Re: [PATCH 3/4] s390/mm: prevent and break zero page mappings in case of storage keys
Date: Wed, 22 Oct 2014 16:00:02 +0200	[thread overview]
Message-ID: <5447B862.4060707@redhat.com> (raw)
In-Reply-To: <1413976170-42501-4-git-send-email-dingel@linux.vnet.ibm.com>

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

On 10/22/2014 01:09 PM, Dominik Dingel wrote:
> As soon as storage keys are enabled we need to stop working on zero page
> mappings to prevent inconsistencies between storage keys and pgste.
> 
> Otherwise following data corruption could happen:
> 1) guest enables storage key
> 2) guest sets storage key for not mapped page X
>    -> change goes to PGSTE
> 3) guest reads from page X
>    -> as X was not dirty before, the page will be zero page backed,
>       storage key from PGSTE for X will go to storage key for zero page
> 4) guest sets storage key for not mapped page Y (same logic as above
> 5) guest reads from page Y
>    -> as Y was not dirty before, the page will be zero page backed,
>       storage key from PGSTE for Y will got to storage key for zero page
>       overwriting storage key for X
> 
> While holding the mmap sem, we are safe against changes on entries we
> already fixed, as every fault would need to take the mmap_sem (read).
> 
> Other vCPUs executing storage key instructions will get a one time interception
> and be serialized also with mmap_sem.
> 
> Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
> ---
>  arch/s390/include/asm/pgtable.h |  5 +++++
>  arch/s390/mm/pgtable.c          | 13 ++++++++++++-
>  2 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
> index 1e991f6a..0da98d6 100644
> --- a/arch/s390/include/asm/pgtable.h
> +++ b/arch/s390/include/asm/pgtable.h
> @@ -481,6 +481,11 @@ static inline int mm_has_pgste(struct mm_struct *mm)
>  	return 0;
>  }
>  
> +/*
> + * In the case that a guest uses storage keys
> + * faults should no longer be backed by zero pages
> + */
> +#define mm_forbids_zeropage mm_use_skey
>  static inline int mm_use_skey(struct mm_struct *mm)
>  {
>  #ifdef CONFIG_PGSTE
> diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
> index ab55ba8..58d7eb2 100644
> --- a/arch/s390/mm/pgtable.c
> +++ b/arch/s390/mm/pgtable.c
> @@ -1309,6 +1309,15 @@ static int __s390_enable_skey(pte_t *pte, unsigned long addr,
>  	pgste_t pgste;
>  
>  	pgste = pgste_get_lock(pte);
> +	/*
> +	 * Remove all zero page mappings,
> +	 * after establishing a policy to forbid zero page mappings
> +	 * following faults for that page will get fresh anonymous pages
> +	 */
> +	if (is_zero_pfn(pte_pfn(*pte))) {
> +		ptep_flush_direct(walk->mm, addr, pte);
> +		pte_val(*pte) = _PAGE_INVALID;
> +	}
>  	/* Clear storage key */
>  	pgste_val(pgste) &= ~(PGSTE_ACC_BITS | PGSTE_FP_BIT |
>  			      PGSTE_GR_BIT | PGSTE_GC_BIT);
> @@ -1327,9 +1336,11 @@ void s390_enable_skey(void)
>  	down_write(&mm->mmap_sem);
>  	if (mm_use_skey(mm))
>  		goto out_up;
> +
> +	mm->context.use_skey = 1;
> +
>  	walk.mm = mm;
>  	walk_page_range(0, TASK_SIZE, &walk);
> -	mm->context.use_skey = 1;
>  
>  out_up:
>  	up_write(&mm->mmap_sem);
> 

  reply	other threads:[~2014-10-22 14:00 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 ` Dominik Dingel
2014-10-22 11:09 ` Dominik Dingel
2014-10-22 11:09 ` Dominik Dingel
2014-10-22 11:09 ` [PATCH 1/4] s390/mm: recfactor global pgste updates 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 11:09 ` [PATCH 2/4] mm: introduce mm_forbids_zeropage function 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 13:59   ` Paolo Bonzini
2014-10-22 13:59     ` Paolo Bonzini
2014-10-22 13:59     ` Paolo Bonzini
2014-10-22 13:59     ` Paolo Bonzini
2014-10-22 19:22   ` Andrew Morton
2014-10-22 19:22     ` Andrew Morton
2014-10-22 19:22     ` Andrew Morton
2014-10-22 19:22     ` Andrew Morton
2014-10-22 19:45     ` Dominik Dingel
2014-10-22 19:45       ` Dominik Dingel
2014-10-22 19:45       ` Dominik Dingel
2014-10-22 19:49       ` Andrew Morton
2014-10-22 19:49         ` Andrew Morton
2014-10-22 19:49         ` Andrew Morton
2014-10-22 19:49         ` Andrew Morton
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 [this message]
2014-10-22 14:00     ` Paolo Bonzini
2014-10-22 14:00     ` Paolo Bonzini
2014-10-22 14:00     ` Paolo Bonzini
2014-10-22 11:09 ` [PATCH 4/4] s390/mm: disable KSM for storage key enabled pages 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-22 13:59 ` [PATCH v3 0/4] mm: new function to forbid zeropage mappings for a process Paolo Bonzini
2014-10-22 13:59   ` Paolo Bonzini
2014-10-22 13:59   ` Paolo Bonzini
2014-10-22 13:59   ` Paolo Bonzini
2014-10-23 10:19 ` Martin Schwidefsky
2014-10-23 10:19   ` Martin Schwidefsky
2014-10-23 10:19   ` Martin Schwidefsky
  -- strict thread matches above, loose matches on Subject: below --
2014-10-22  8:30 [PATCH v2 " 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
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-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=5447B862.4060707@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=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=peterz@infradead.org \
    --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.