When a user mode process accesses an address in the vmalloc area
do_page_fault tries to unlock the mmap semaphore when it isn't locked.
Signed-off-by: Andreas Schwab <[email protected]>
---
arch/riscv/mm/fault.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
index 88401d5125bc..c51878e5a66a 100644
--- a/arch/riscv/mm/fault.c
+++ b/arch/riscv/mm/fault.c
@@ -181,6 +181,7 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
up_read(&mm->mmap_sem);
/* User mode accesses just cause a SIGSEGV */
if (user_mode(regs)) {
+bad_area_do_trap:
do_trap(regs, SIGSEGV, code, addr, tsk);
return;
}
@@ -230,7 +231,7 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
int index;
if (user_mode(regs))
- goto bad_area;
+ goto bad_area_do_trap;
/*
* Synchronize this task's top level page-table
--
2.21.0
--
Andreas Schwab, SUSE Labs, [email protected]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On 7.05.19 г. 10:36 ч., Andreas Schwab wrote:
> When a user mode process accesses an address in the vmalloc area
> do_page_fault tries to unlock the mmap semaphore when it isn't locked.
>
> Signed-off-by: Andreas Schwab <[email protected]>
> ---
> arch/riscv/mm/fault.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
> index 88401d5125bc..c51878e5a66a 100644
> --- a/arch/riscv/mm/fault.c
> +++ b/arch/riscv/mm/fault.c
> @@ -181,6 +181,7 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
> up_read(&mm->mmap_sem);
> /* User mode accesses just cause a SIGSEGV */
> if (user_mode(regs)) {
> +bad_area_do_trap:
> do_trap(regs, SIGSEGV, code, addr, tsk);
> return;
> }
> @@ -230,7 +231,7 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
> int index;
>
> if (user_mode(regs))
> - goto bad_area;
> + goto bad_area_do_trap;
>
> /*
> * Synchronize this task's top level page-table
>
In this case I think it will be a lot cleaner if you just duplicated the
do_trap call. On a slightly different note - is there any reason why
do_page_fault is such a spaghetti mess? At the very least the code under
no_context label could go into it's own function since it just kills the
process and never returns? Furthermore the whole vmalloc_fault just
cries for being factored out in a function, it's explicitly in it's own
block.
On Mai 07 2019, Nikolay Borisov <[email protected]> wrote:
> At the very least the code under
> no_context label could go into it's own function since it just kills the
> process and never returns?
This is not true.
Andreas.
--
Andreas Schwab, SUSE Labs, [email protected]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On 7.05.19 г. 17:12 ч., Andreas Schwab wrote:
> On Mai 07 2019, Nikolay Borisov <[email protected]> wrote:
>
>> At the very least the code under
>> no_context label could go into it's own function since it just kills the
>> process and never returns?
>
> This is not true.
Be more specific, according to do_task_dead after the last __schedule is
called the calling context is no more?
>
> Andreas.
>
On Mai 07 2019, Nikolay Borisov <[email protected]> wrote:
> On 7.05.19 г. 17:12 ч., Andreas Schwab wrote:
>> On Mai 07 2019, Nikolay Borisov <[email protected]> wrote:
>>
>>> At the very least the code under
>>> no_context label could go into it's own function since it just kills the
>>> process and never returns?
>>
>> This is not true.
>
> Be more specific, according to do_task_dead after the last __schedule is
> called the calling context is no more?
/* Are we prepared to handle this kernel fault? */
if (fixup_exception(regs))
return;
Andreas.
--
Andreas Schwab, SUSE Labs, [email protected]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On Tue, 07 May 2019 00:36:46 PDT (-0700), [email protected] wrote:
> When a user mode process accesses an address in the vmalloc area
> do_page_fault tries to unlock the mmap semaphore when it isn't locked.
>
> Signed-off-by: Andreas Schwab <[email protected]>
> ---
> arch/riscv/mm/fault.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
> index 88401d5125bc..c51878e5a66a 100644
> --- a/arch/riscv/mm/fault.c
> +++ b/arch/riscv/mm/fault.c
> @@ -181,6 +181,7 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
> up_read(&mm->mmap_sem);
> /* User mode accesses just cause a SIGSEGV */
> if (user_mode(regs)) {
> +bad_area_do_trap:
> do_trap(regs, SIGSEGV, code, addr, tsk);
> return;
> }
> @@ -230,7 +231,7 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
> int index;
>
> if (user_mode(regs))
> - goto bad_area;
> + goto bad_area_do_trap;
>
> /*
> * Synchronize this task's top level page-table
I got lost with all the gotos, I think something like this is cleaner
diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
index 26293bc053a8..cec8be9e2d6a 100644
--- a/arch/riscv/mm/fault.c
+++ b/arch/riscv/mm/fault.c
@@ -229,8 +229,9 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
pte_t *pte_k;
int index;
+ /* User mode accesses just cause a SIGSEGV */
if (user_mode(regs))
- goto bad_area;
+ return do_trap(regs, SIGSEGV, code, addr, tsk);
/*
* Synchronize this task's top level page-table
Unless anyone has a better idea?
Either way:
Reviewed-by: Palmer Dabbelt <[email protected]>
LMK if you, or anyone else, has a preference. I'm assuming this will go in
through my tree, so I've picked up my version for now :)
On Mai 07 2019, Palmer Dabbelt <[email protected]> wrote:
> LMK if you, or anyone else, has a preference. I'm assuming this will go in
> through my tree, so I've picked up my version for now :)
You did?
Andreas.
--
Andreas Schwab, SUSE Labs, [email protected]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On Thu, 16 May 2019 00:42:01 PDT (-0700), [email protected] wrote:
> On Mai 07 2019, Palmer Dabbelt <[email protected]> wrote:
>
>> LMK if you, or anyone else, has a preference. I'm assuming this will go in
>> through my tree, so I've picked up my version for now :)
>
> You did?
It ended up landing in Linus' tree as 8fef9900d43f ("riscv: fix locking
violation in page fault handler"), so it looks like I did manage avoid losing
this one.