diff options
| author | Linus Torvalds | 2023-06-29 23:04:57 -0700 |
|---|---|---|
| committer | Greg Kroah-Hartman | 2023-07-01 13:16:26 +0200 |
| commit | 4a1db15878aacb89e8f24c98a2f96fad6db3f967 (patch) | |
| tree | 4c8a5108218bb129561935378b5815b5a3dd1966 /arch/parisc | |
| parent | 0a1da2dde461cc8adac196a10d76a1fb977b7cdf (diff) | |
parisc: fix expand_stack() conversion
commit ea3f8272876f2958463992f6736ab690fde7fa9c upstream.
In commit 8d7071af8907 ("mm: always expand the stack with the mmap write
lock held") I tried to deal with the remaining odd page fault handling
cases. The oddest one is ia64, which has stacks that grow both up and
down. And because ia64 was _so_ odd, I asked people to verify the end
result.
But a close second oddity is parisc, which is the only one that has a
main stack growing up (our "CONFIG_STACK_GROWSUP" config option). But
it looked obvious enough that I didn't worry about it.
I should have worried a bit more. Not because it was particularly
complex, but because I just used the wrong variable name.
The previous vma isn't called "prev", it's called "prev_vma". Blush.
Fixes: 8d7071af8907 ("mm: always expand the stack with the mmap write lock held")
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'arch/parisc')
| -rw-r--r-- | arch/parisc/mm/fault.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c index 1843b493910c..b00aa98b582c 100644 --- a/arch/parisc/mm/fault.c +++ b/arch/parisc/mm/fault.c @@ -289,7 +289,7 @@ retry: mmap_read_lock(mm); vma = find_vma_prev(mm, address, &prev_vma); if (!vma || address < vma->vm_start) { - if (!prev || !(prev->vm_flags & VM_GROWSUP)) + if (!prev_vma || !(prev_vma->vm_flags & VM_GROWSUP)) goto bad_area; vma = expand_stack(mm, address); if (!vma) |