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
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 <[email protected]>
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!