diff mbox series

powerpc/mm: fix mmap_lock bad unlock

Message ID 20230306135520.4222-1-ldufour@linux.ibm.com (mailing list archive)
State New
Headers show
Series powerpc/mm: fix mmap_lock bad unlock | expand

Commit Message

Laurent Dufour March 6, 2023, 1:55 p.m. UTC
When page fault is tried holding the per VMA lock, bad_access_pkey() and
bad_access() should not be called because it is assuming the mmap_lock is
held.
In the case a bad access is detected, fall back to the default path,
grabbing the mmap_lock to handle the fault and report the error.

Fixes: 169db3bb4609 ("powerc/mm: try VMA lock-based page fault handling first")
Reported-by: Sachin Sant <sachinp@linux.ibm.com>
Link: https://lore.kernel.org/linux-mm/842502FB-F99C-417C-9648-A37D0ECDC9CE@linux.ibm.com
Cc: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
---
 arch/powerpc/mm/fault.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

Comments

David Hildenbrand March 6, 2023, 2:07 p.m. UTC | #1
On 06.03.23 14:55, Laurent Dufour wrote:
> When page fault is tried holding the per VMA lock, bad_access_pkey() and
> bad_access() should not be called because it is assuming the mmap_lock is
> held.
> In the case a bad access is detected, fall back to the default path,
> grabbing the mmap_lock to handle the fault and report the error.
> 
> Fixes: 169db3bb4609 ("powerc/mm: try VMA lock-based page fault handling first")
> Reported-by: Sachin Sant <sachinp@linux.ibm.com>
> Link: https://lore.kernel.org/linux-mm/842502FB-F99C-417C-9648-A37D0ECDC9CE@linux.ibm.com
> Cc: Suren Baghdasaryan <surenb@google.com>
> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
> ---
>   arch/powerpc/mm/fault.c | 8 ++------
>   1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index c7ae86b04b8a..e191b3ebd8d6 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -479,17 +479,13 @@ static int ___do_page_fault(struct pt_regs *regs, unsigned long address,
>   
>   	if (unlikely(access_pkey_error(is_write, is_exec,
>   				       (error_code & DSISR_KEYFAULT), vma))) {
> -		int rc = bad_access_pkey(regs, address, vma);
> -
>   		vma_end_read(vma);
> -		return rc;
> +		goto lock_mmap;
>   	}
>   
>   	if (unlikely(access_error(is_write, is_exec, vma))) {
> -		int rc = bad_access(regs, address);
> -
>   		vma_end_read(vma);
> -		return rc;
> +		goto lock_mmap;
>   	}
>   
>   	fault = handle_mm_fault(vma, address, flags | FAULT_FLAG_VMA_LOCK, regs);

IIUC, that commit is neither upstream not in mm-stable -- it's unstable. 
Maybe raise that as a review comment in reply to the original patch, so 
we can easily connect the dots and squash it into the original, 
problematic patch that is still under review.
Laurent Dufour March 6, 2023, 2:09 p.m. UTC | #2
On 06/03/2023 15:07:26, David Hildenbrand wrote:
> On 06.03.23 14:55, Laurent Dufour wrote:
>> When page fault is tried holding the per VMA lock, bad_access_pkey() and
>> bad_access() should not be called because it is assuming the mmap_lock is
>> held.
>> In the case a bad access is detected, fall back to the default path,
>> grabbing the mmap_lock to handle the fault and report the error.
>>
>> Fixes: 169db3bb4609 ("powerc/mm: try VMA lock-based page fault handling
>> first")
>> Reported-by: Sachin Sant <sachinp@linux.ibm.com>
>> Link:
>> https://lore.kernel.org/linux-mm/842502FB-F99C-417C-9648-A37D0ECDC9CE@linux.ibm.com
>> Cc: Suren Baghdasaryan <surenb@google.com>
>> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
>> ---
>>   arch/powerpc/mm/fault.c | 8 ++------
>>   1 file changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
>> index c7ae86b04b8a..e191b3ebd8d6 100644
>> --- a/arch/powerpc/mm/fault.c
>> +++ b/arch/powerpc/mm/fault.c
>> @@ -479,17 +479,13 @@ static int ___do_page_fault(struct pt_regs *regs,
>> unsigned long address,
>>         if (unlikely(access_pkey_error(is_write, is_exec,
>>                          (error_code & DSISR_KEYFAULT), vma))) {
>> -        int rc = bad_access_pkey(regs, address, vma);
>> -
>>           vma_end_read(vma);
>> -        return rc;
>> +        goto lock_mmap;
>>       }
>>         if (unlikely(access_error(is_write, is_exec, vma))) {
>> -        int rc = bad_access(regs, address);
>> -
>>           vma_end_read(vma);
>> -        return rc;
>> +        goto lock_mmap;
>>       }
>>         fault = handle_mm_fault(vma, address, flags |
>> FAULT_FLAG_VMA_LOCK, regs);
> 
> IIUC, that commit is neither upstream not in mm-stable -- it's unstable.
> Maybe raise that as a review comment in reply to the original patch, so we
> can easily connect the dots and squash it into the original, problematic
> patch that is still under review.
> 
Oh yes, I missed that. I'll reply to the Suren's thread.

Thanks,
Laurent.
Suren Baghdasaryan March 6, 2023, 5:13 p.m. UTC | #3
On Mon, Mar 6, 2023 at 6:09 AM Laurent Dufour <ldufour@linux.ibm.com> wrote:
>
> On 06/03/2023 15:07:26, David Hildenbrand wrote:
> > On 06.03.23 14:55, Laurent Dufour wrote:
> >> When page fault is tried holding the per VMA lock, bad_access_pkey() and
> >> bad_access() should not be called because it is assuming the mmap_lock is
> >> held.
> >> In the case a bad access is detected, fall back to the default path,
> >> grabbing the mmap_lock to handle the fault and report the error.
> >>
> >> Fixes: 169db3bb4609 ("powerc/mm: try VMA lock-based page fault handling
> >> first")
> >> Reported-by: Sachin Sant <sachinp@linux.ibm.com>
> >> Link:
> >> https://lore.kernel.org/linux-mm/842502FB-F99C-417C-9648-A37D0ECDC9CE@linux.ibm.com
> >> Cc: Suren Baghdasaryan <surenb@google.com>
> >> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
> >> ---
> >>   arch/powerpc/mm/fault.c | 8 ++------
> >>   1 file changed, 2 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> >> index c7ae86b04b8a..e191b3ebd8d6 100644
> >> --- a/arch/powerpc/mm/fault.c
> >> +++ b/arch/powerpc/mm/fault.c
> >> @@ -479,17 +479,13 @@ static int ___do_page_fault(struct pt_regs *regs,
> >> unsigned long address,
> >>         if (unlikely(access_pkey_error(is_write, is_exec,
> >>                          (error_code & DSISR_KEYFAULT), vma))) {
> >> -        int rc = bad_access_pkey(regs, address, vma);
> >> -
> >>           vma_end_read(vma);
> >> -        return rc;
> >> +        goto lock_mmap;
> >>       }
> >>         if (unlikely(access_error(is_write, is_exec, vma))) {
> >> -        int rc = bad_access(regs, address);
> >> -
> >>           vma_end_read(vma);
> >> -        return rc;
> >> +        goto lock_mmap;
> >>       }
> >>         fault = handle_mm_fault(vma, address, flags |
> >> FAULT_FLAG_VMA_LOCK, regs);
> >
> > IIUC, that commit is neither upstream not in mm-stable -- it's unstable.
> > Maybe raise that as a review comment in reply to the original patch, so we
> > can easily connect the dots and squash it into the original, problematic
> > patch that is still under review.
> >
> Oh yes, I missed that. I'll reply to the Suren's thread.

Thanks Laurent! Seems simple enough to patch the original change.

>
> Thanks,
> Laurent.
diff mbox series

Patch

diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index c7ae86b04b8a..e191b3ebd8d6 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -479,17 +479,13 @@  static int ___do_page_fault(struct pt_regs *regs, unsigned long address,
 
 	if (unlikely(access_pkey_error(is_write, is_exec,
 				       (error_code & DSISR_KEYFAULT), vma))) {
-		int rc = bad_access_pkey(regs, address, vma);
-
 		vma_end_read(vma);
-		return rc;
+		goto lock_mmap;
 	}
 
 	if (unlikely(access_error(is_write, is_exec, vma))) {
-		int rc = bad_access(regs, address);
-
 		vma_end_read(vma);
-		return rc;
+		goto lock_mmap;
 	}
 
 	fault = handle_mm_fault(vma, address, flags | FAULT_FLAG_VMA_LOCK, regs);