Linux-S390 Archive mirror
 help / color / mirror / Atom feed
* [PATCH v1 0/2] s390/mm: fix improper use of __storage_key_init_range
@ 2024-04-16 11:42 Claudio Imbrenda
  2024-04-16 11:42 ` [PATCH v1 1/2] s390/mm: fix storage key clearing for guest huge pages Claudio Imbrenda
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Claudio Imbrenda @ 2024-04-16 11:42 UTC (permalink / raw
  To: linux-s390
  Cc: linux-kernel, frankja, nrb, nsg, borntraeger, hca,
	gerald.schaefer, david

The function __storage_key_init_range() expects the end address to be
the first byte outside the range to be initialized. I.e. end - start
should be the size of the area to be initialized.

This small series fixes two cases in which the last address in the
range was passed as end address. This was still functionally correct,
since __storage_key_init_range() will still loop over single pages and
correctly clear the given range, but it will be slower than clearing
the storage keys for the whole 1M block with a single instruction.

Claudio Imbrenda (2):
  s390/mm: fix storage key clearing for guest huge pages
  s390/mm: fix clearing storage keys for huge pages

 arch/s390/mm/gmap.c        | 2 +-
 arch/s390/mm/hugetlbpage.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.44.0


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH v1 1/2] s390/mm: fix storage key clearing for guest huge pages
  2024-04-16 11:42 [PATCH v1 0/2] s390/mm: fix improper use of __storage_key_init_range Claudio Imbrenda
@ 2024-04-16 11:42 ` Claudio Imbrenda
  2024-04-16 11:42 ` [PATCH v1 2/2] s390/mm: fix clearing storage keys for " Claudio Imbrenda
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Claudio Imbrenda @ 2024-04-16 11:42 UTC (permalink / raw
  To: linux-s390
  Cc: linux-kernel, frankja, nrb, nsg, borntraeger, hca,
	gerald.schaefer, david

The function __storage_key_init_range() expects the end address to be
the first byte outside the range to be initialized. I.e. end - start
should be the size of the area to be initialized.

The current code works because __storage_key_init_range() will still loop
over every page in the range, but it is slower than using sske_frame().

Fixes: 964c2c05c9f3 ("s390/mm: Clear huge page storage keys on enable_skey")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
---
 arch/s390/mm/gmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/s390/mm/gmap.c b/arch/s390/mm/gmap.c
index 094b43b121cd..12d22a7fa32f 100644
--- a/arch/s390/mm/gmap.c
+++ b/arch/s390/mm/gmap.c
@@ -2661,7 +2661,7 @@ static int __s390_enable_skey_hugetlb(pte_t *pte, unsigned long addr,
 		return 0;
 
 	start = pmd_val(*pmd) & HPAGE_MASK;
-	end = start + HPAGE_SIZE - 1;
+	end = start + HPAGE_SIZE;
 	__storage_key_init_range(start, end);
 	set_bit(PG_arch_1, &page->flags);
 	cond_resched();
-- 
2.44.0


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* [PATCH v1 2/2] s390/mm: fix clearing storage keys for huge pages
  2024-04-16 11:42 [PATCH v1 0/2] s390/mm: fix improper use of __storage_key_init_range Claudio Imbrenda
  2024-04-16 11:42 ` [PATCH v1 1/2] s390/mm: fix storage key clearing for guest huge pages Claudio Imbrenda
@ 2024-04-16 11:42 ` Claudio Imbrenda
  2024-04-16 13:24 ` [PATCH v1 0/2] s390/mm: fix improper use of __storage_key_init_range Heiko Carstens
  2024-04-16 15:53 ` Alexander Gordeev
  3 siblings, 0 replies; 5+ messages in thread
From: Claudio Imbrenda @ 2024-04-16 11:42 UTC (permalink / raw
  To: linux-s390
  Cc: linux-kernel, frankja, nrb, nsg, borntraeger, hca,
	gerald.schaefer, david

The function __storage_key_init_range() expects the end address to be
the first byte outside the range to be initialized. I.e. end - start
should be the size of the area to be initialized.

The current code works because __storage_key_init_range() will still loop
over every page in the range, but it is slower than using sske_frame().

Fixes: 3afdfca69870 ("s390/mm: Clear skeys for newly mapped huge guest pmds")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
---
 arch/s390/mm/hugetlbpage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/s390/mm/hugetlbpage.c b/arch/s390/mm/hugetlbpage.c
index c2e8242bd15d..dc3db86e13ff 100644
--- a/arch/s390/mm/hugetlbpage.c
+++ b/arch/s390/mm/hugetlbpage.c
@@ -139,7 +139,7 @@ static void clear_huge_pte_skeys(struct mm_struct *mm, unsigned long rste)
 	}
 
 	if (!test_and_set_bit(PG_arch_1, &page->flags))
-		__storage_key_init_range(paddr, paddr + size - 1);
+		__storage_key_init_range(paddr, paddr + size);
 }
 
 void __set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
-- 
2.44.0


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH v1 0/2] s390/mm: fix improper use of __storage_key_init_range
  2024-04-16 11:42 [PATCH v1 0/2] s390/mm: fix improper use of __storage_key_init_range Claudio Imbrenda
  2024-04-16 11:42 ` [PATCH v1 1/2] s390/mm: fix storage key clearing for guest huge pages Claudio Imbrenda
  2024-04-16 11:42 ` [PATCH v1 2/2] s390/mm: fix clearing storage keys for " Claudio Imbrenda
@ 2024-04-16 13:24 ` Heiko Carstens
  2024-04-16 15:53 ` Alexander Gordeev
  3 siblings, 0 replies; 5+ messages in thread
From: Heiko Carstens @ 2024-04-16 13:24 UTC (permalink / raw
  To: Claudio Imbrenda, Alexander Gordeev, Vasily Gorbik
  Cc: linux-s390, linux-kernel, frankja, nrb, nsg, borntraeger,
	gerald.schaefer, david

On Tue, Apr 16, 2024 at 01:42:18PM +0200, Claudio Imbrenda wrote:
> The function __storage_key_init_range() expects the end address to be
> the first byte outside the range to be initialized. I.e. end - start
> should be the size of the area to be initialized.
> 
> This small series fixes two cases in which the last address in the
> range was passed as end address. This was still functionally correct,
> since __storage_key_init_range() will still loop over single pages and
> correctly clear the given range, but it will be slower than clearing
> the storage keys for the whole 1M block with a single instruction.
> 
> Claudio Imbrenda (2):
>   s390/mm: fix storage key clearing for guest huge pages
>   s390/mm: fix clearing storage keys for huge pages
> 
>  arch/s390/mm/gmap.c        | 2 +-
>  arch/s390/mm/hugetlbpage.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Heiko Carstens <hca@linux.ibm.com>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v1 0/2] s390/mm: fix improper use of __storage_key_init_range
  2024-04-16 11:42 [PATCH v1 0/2] s390/mm: fix improper use of __storage_key_init_range Claudio Imbrenda
                   ` (2 preceding siblings ...)
  2024-04-16 13:24 ` [PATCH v1 0/2] s390/mm: fix improper use of __storage_key_init_range Heiko Carstens
@ 2024-04-16 15:53 ` Alexander Gordeev
  3 siblings, 0 replies; 5+ messages in thread
From: Alexander Gordeev @ 2024-04-16 15:53 UTC (permalink / raw
  To: Claudio Imbrenda
  Cc: linux-s390, linux-kernel, frankja, nrb, nsg, borntraeger, hca,
	gerald.schaefer, david

On Tue, Apr 16, 2024 at 01:42:18PM +0200, Claudio Imbrenda wrote:
>  arch/s390/mm/gmap.c        | 2 +-
>  arch/s390/mm/hugetlbpage.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Applied, thanks!

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2024-04-16 15:53 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-16 11:42 [PATCH v1 0/2] s390/mm: fix improper use of __storage_key_init_range Claudio Imbrenda
2024-04-16 11:42 ` [PATCH v1 1/2] s390/mm: fix storage key clearing for guest huge pages Claudio Imbrenda
2024-04-16 11:42 ` [PATCH v1 2/2] s390/mm: fix clearing storage keys for " Claudio Imbrenda
2024-04-16 13:24 ` [PATCH v1 0/2] s390/mm: fix improper use of __storage_key_init_range Heiko Carstens
2024-04-16 15:53 ` Alexander Gordeev

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).