August 2020 - Linux-stable-mirror

FAILED: patch "[PATCH] epoll: Keep a reference on files added to the check list" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a9ed4a6560b8562b7e2e2bed9527e88001f7b682 Mon Sep 17 00:00:00 2001 From: Marc Zyngier <maz(a)kernel.org> Date: Wed, 19 Aug 2020 17:12:17 +0100 Subject: [PATCH] epoll: Keep a reference on files added to the check list When adding a new fd to an epoll, and that this new fd is an epoll fd itself, we recursively scan the fds attached to it to detect cycles, and add non-epool files to a "check list" that gets subsequently parsed. However, this check list isn't completely safe when deletions can happen concurrently. To sidestep the issue, make sure that a struct file placed on the check list sees its f_count increased, ensuring that a concurrent deletion won't result in the file disapearing from under our feet. Cc: stable(a)vger.kernel.org Signed-off-by: Marc Zyngier <maz(a)kernel.org> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> diff --git a/fs/eventpoll.c b/fs/eventpoll.c index 12eebcdea9c8..196003d9242c 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -1994,9 +1994,11 @@ static int ep_loop_check_proc(void *priv, void *cookie, int call_nests) * not already there, and calling reverse_path_check() * during ep_insert(). */ - if (list_empty(&epi->ffd.file->f_tfile_llink)) + if (list_empty(&epi->ffd.file->f_tfile_llink)) { + get_file(epi->ffd.file); list_add(&epi->ffd.file->f_tfile_llink, &tfile_check_list); + } } } mutex_unlock(&ep->mtx); @@ -2040,6 +2042,7 @@ static void clear_tfile_check_list(void) file = list_first_entry(&tfile_check_list, struct file, f_tfile_llink); list_del_init(&file->f_tfile_llink); + fput(file); } INIT_LIST_HEAD(&tfile_check_list); } @@ -2204,13 +2207,17 @@ int do_epoll_ctl(int epfd, int op, int fd, struct epoll_event *epds, clear_tfile_check_list(); goto error_tgt_fput; } - } else + } else { + get_file(tf.file); list_add(&tf.file->f_tfile_llink, &tfile_check_list); + } error = epoll_mutex_lock(&ep->mtx, 0, nonblock); if (error) { out_del: list_del(&tf.file->f_tfile_llink); + if (!is_file_epoll(tf.file)) + fput(tf.file); goto error_tgt_fput; } if (is_file_epoll(tf.file)) {

4 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] epoll: Keep a reference on files added to the check list" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a9ed4a6560b8562b7e2e2bed9527e88001f7b682 Mon Sep 17 00:00:00 2001 From: Marc Zyngier <maz(a)kernel.org> Date: Wed, 19 Aug 2020 17:12:17 +0100 Subject: [PATCH] epoll: Keep a reference on files added to the check list When adding a new fd to an epoll, and that this new fd is an epoll fd itself, we recursively scan the fds attached to it to detect cycles, and add non-epool files to a "check list" that gets subsequently parsed. However, this check list isn't completely safe when deletions can happen concurrently. To sidestep the issue, make sure that a struct file placed on the check list sees its f_count increased, ensuring that a concurrent deletion won't result in the file disapearing from under our feet. Cc: stable(a)vger.kernel.org Signed-off-by: Marc Zyngier <maz(a)kernel.org> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> diff --git a/fs/eventpoll.c b/fs/eventpoll.c index 12eebcdea9c8..196003d9242c 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -1994,9 +1994,11 @@ static int ep_loop_check_proc(void *priv, void *cookie, int call_nests) * not already there, and calling reverse_path_check() * during ep_insert(). */ - if (list_empty(&epi->ffd.file->f_tfile_llink)) + if (list_empty(&epi->ffd.file->f_tfile_llink)) { + get_file(epi->ffd.file); list_add(&epi->ffd.file->f_tfile_llink, &tfile_check_list); + } } } mutex_unlock(&ep->mtx); @@ -2040,6 +2042,7 @@ static void clear_tfile_check_list(void) file = list_first_entry(&tfile_check_list, struct file, f_tfile_llink); list_del_init(&file->f_tfile_llink); + fput(file); } INIT_LIST_HEAD(&tfile_check_list); } @@ -2204,13 +2207,17 @@ int do_epoll_ctl(int epfd, int op, int fd, struct epoll_event *epds, clear_tfile_check_list(); goto error_tgt_fput; } - } else + } else { + get_file(tf.file); list_add(&tf.file->f_tfile_llink, &tfile_check_list); + } error = epoll_mutex_lock(&ep->mtx, 0, nonblock); if (error) { out_del: list_del(&tf.file->f_tfile_llink); + if (!is_file_epoll(tf.file)) + fput(tf.file); goto error_tgt_fput; } if (is_file_epoll(tf.file)) {

4 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] epoll: Keep a reference on files added to the check list" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a9ed4a6560b8562b7e2e2bed9527e88001f7b682 Mon Sep 17 00:00:00 2001 From: Marc Zyngier <maz(a)kernel.org> Date: Wed, 19 Aug 2020 17:12:17 +0100 Subject: [PATCH] epoll: Keep a reference on files added to the check list When adding a new fd to an epoll, and that this new fd is an epoll fd itself, we recursively scan the fds attached to it to detect cycles, and add non-epool files to a "check list" that gets subsequently parsed. However, this check list isn't completely safe when deletions can happen concurrently. To sidestep the issue, make sure that a struct file placed on the check list sees its f_count increased, ensuring that a concurrent deletion won't result in the file disapearing from under our feet. Cc: stable(a)vger.kernel.org Signed-off-by: Marc Zyngier <maz(a)kernel.org> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> diff --git a/fs/eventpoll.c b/fs/eventpoll.c index 12eebcdea9c8..196003d9242c 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -1994,9 +1994,11 @@ static int ep_loop_check_proc(void *priv, void *cookie, int call_nests) * not already there, and calling reverse_path_check() * during ep_insert(). */ - if (list_empty(&epi->ffd.file->f_tfile_llink)) + if (list_empty(&epi->ffd.file->f_tfile_llink)) { + get_file(epi->ffd.file); list_add(&epi->ffd.file->f_tfile_llink, &tfile_check_list); + } } } mutex_unlock(&ep->mtx); @@ -2040,6 +2042,7 @@ static void clear_tfile_check_list(void) file = list_first_entry(&tfile_check_list, struct file, f_tfile_llink); list_del_init(&file->f_tfile_llink); + fput(file); } INIT_LIST_HEAD(&tfile_check_list); } @@ -2204,13 +2207,17 @@ int do_epoll_ctl(int epfd, int op, int fd, struct epoll_event *epds, clear_tfile_check_list(); goto error_tgt_fput; } - } else + } else { + get_file(tf.file); list_add(&tf.file->f_tfile_llink, &tfile_check_list); + } error = epoll_mutex_lock(&ep->mtx, 0, nonblock); if (error) { out_del: list_del(&tf.file->f_tfile_llink); + if (!is_file_epoll(tf.file)) + fput(tf.file); goto error_tgt_fput; } if (is_file_epoll(tf.file)) {

4 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] epoll: Keep a reference on files added to the check list" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a9ed4a6560b8562b7e2e2bed9527e88001f7b682 Mon Sep 17 00:00:00 2001 From: Marc Zyngier <maz(a)kernel.org> Date: Wed, 19 Aug 2020 17:12:17 +0100 Subject: [PATCH] epoll: Keep a reference on files added to the check list When adding a new fd to an epoll, and that this new fd is an epoll fd itself, we recursively scan the fds attached to it to detect cycles, and add non-epool files to a "check list" that gets subsequently parsed. However, this check list isn't completely safe when deletions can happen concurrently. To sidestep the issue, make sure that a struct file placed on the check list sees its f_count increased, ensuring that a concurrent deletion won't result in the file disapearing from under our feet. Cc: stable(a)vger.kernel.org Signed-off-by: Marc Zyngier <maz(a)kernel.org> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> diff --git a/fs/eventpoll.c b/fs/eventpoll.c index 12eebcdea9c8..196003d9242c 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -1994,9 +1994,11 @@ static int ep_loop_check_proc(void *priv, void *cookie, int call_nests) * not already there, and calling reverse_path_check() * during ep_insert(). */ - if (list_empty(&epi->ffd.file->f_tfile_llink)) + if (list_empty(&epi->ffd.file->f_tfile_llink)) { + get_file(epi->ffd.file); list_add(&epi->ffd.file->f_tfile_llink, &tfile_check_list); + } } } mutex_unlock(&ep->mtx); @@ -2040,6 +2042,7 @@ static void clear_tfile_check_list(void) file = list_first_entry(&tfile_check_list, struct file, f_tfile_llink); list_del_init(&file->f_tfile_llink); + fput(file); } INIT_LIST_HEAD(&tfile_check_list); } @@ -2204,13 +2207,17 @@ int do_epoll_ctl(int epfd, int op, int fd, struct epoll_event *epds, clear_tfile_check_list(); goto error_tgt_fput; } - } else + } else { + get_file(tf.file); list_add(&tf.file->f_tfile_llink, &tfile_check_list); + } error = epoll_mutex_lock(&ep->mtx, 0, nonblock); if (error) { out_del: list_del(&tf.file->f_tfile_llink); + if (!is_file_epoll(tf.file)) + fput(tf.file); goto error_tgt_fput; } if (is_file_epoll(tf.file)) {

4 years, 8 months

1
0
0 0

[PATCH v4.4] powerpc: Allow 4224 bytes of stack expansion for the signal frame

by Daniel Axtens

From: Michael Ellerman <mpe(a)ellerman.id.au> commit 63dee5df43a31f3844efabc58972f0a206ca4534 upstream. We have powerpc specific logic in our page fault handling to decide if an access to an unmapped address below the stack pointer should expand the stack VMA. The code was originally added in 2004 "ported from 2.4". The rough logic is that the stack is allowed to grow to 1MB with no extra checking. Over 1MB the access must be within 2048 bytes of the stack pointer, or be from a user instruction that updates the stack pointer. The 2048 byte allowance below the stack pointer is there to cover the 288 byte "red zone" as well as the "about 1.5kB" needed by the signal delivery code. Unfortunately since then the signal frame has expanded, and is now 4224 bytes on 64-bit kernels with transactional memory enabled. This means if a process has consumed more than 1MB of stack, and its stack pointer lies less than 4224 bytes from the next page boundary, signal delivery will fault when trying to expand the stack and the process will see a SEGV. The total size of the signal frame is the size of struct rt_sigframe (which includes the red zone) plus __SIGNAL_FRAMESIZE (128 bytes on 64-bit). The 2048 byte allowance was correct until 2008 as the signal frame was: struct rt_sigframe { struct ucontext uc; /* 0 1440 */ /* --- cacheline 11 boundary (1408 bytes) was 32 bytes ago --- */ long unsigned int _unused[2]; /* 1440 16 */ unsigned int tramp[6]; /* 1456 24 */ struct siginfo * pinfo; /* 1480 8 */ void * puc; /* 1488 8 */ struct siginfo info; /* 1496 128 */ /* --- cacheline 12 boundary (1536 bytes) was 88 bytes ago --- */ char abigap[288]; /* 1624 288 */ /* size: 1920, cachelines: 15, members: 7 */ /* padding: 8 */ }; 1920 + 128 = 2048 Then in commit ce48b2100785 ("powerpc: Add VSX context save/restore, ptrace and signal support") (Jul 2008) the signal frame expanded to 2304 bytes: struct rt_sigframe { struct ucontext uc; /* 0 1696 */ <-- /* --- cacheline 13 boundary (1664 bytes) was 32 bytes ago --- */ long unsigned int _unused[2]; /* 1696 16 */ unsigned int tramp[6]; /* 1712 24 */ struct siginfo * pinfo; /* 1736 8 */ void * puc; /* 1744 8 */ struct siginfo info; /* 1752 128 */ /* --- cacheline 14 boundary (1792 bytes) was 88 bytes ago --- */ char abigap[288]; /* 1880 288 */ /* size: 2176, cachelines: 17, members: 7 */ /* padding: 8 */ }; 2176 + 128 = 2304 At this point we should have been exposed to the bug, though as far as I know it was never reported. I no longer have a system old enough to easily test on. Then in 2010 commit 320b2b8de126 ("mm: keep a guard page below a grow-down stack segment") caused our stack expansion code to never trigger, as there was always a VMA found for a write up to PAGE_SIZE below r1. That meant the bug was hidden as we continued to expand the signal frame in commit 2b0a576d15e0 ("powerpc: Add new transactional memory state to the signal context") (Feb 2013): struct rt_sigframe { struct ucontext uc; /* 0 1696 */ /* --- cacheline 13 boundary (1664 bytes) was 32 bytes ago --- */ struct ucontext uc_transact; /* 1696 1696 */ <-- /* --- cacheline 26 boundary (3328 bytes) was 64 bytes ago --- */ long unsigned int _unused[2]; /* 3392 16 */ unsigned int tramp[6]; /* 3408 24 */ struct siginfo * pinfo; /* 3432 8 */ void * puc; /* 3440 8 */ struct siginfo info; /* 3448 128 */ /* --- cacheline 27 boundary (3456 bytes) was 120 bytes ago --- */ char abigap[288]; /* 3576 288 */ /* size: 3872, cachelines: 31, members: 8 */ /* padding: 8 */ /* last cacheline: 32 bytes */ }; 3872 + 128 = 4000 And commit 573ebfa6601f ("powerpc: Increase stack redzone for 64-bit userspace to 512 bytes") (Feb 2014): struct rt_sigframe { struct ucontext uc; /* 0 1696 */ /* --- cacheline 13 boundary (1664 bytes) was 32 bytes ago --- */ struct ucontext uc_transact; /* 1696 1696 */ /* --- cacheline 26 boundary (3328 bytes) was 64 bytes ago --- */ long unsigned int _unused[2]; /* 3392 16 */ unsigned int tramp[6]; /* 3408 24 */ struct siginfo * pinfo; /* 3432 8 */ void * puc; /* 3440 8 */ struct siginfo info; /* 3448 128 */ /* --- cacheline 27 boundary (3456 bytes) was 120 bytes ago --- */ char abigap[512]; /* 3576 512 */ <-- /* size: 4096, cachelines: 32, members: 8 */ /* padding: 8 */ }; 4096 + 128 = 4224 Then finally in 2017, commit 1be7107fbe18 ("mm: larger stack guard gap, between vmas") exposed us to the existing bug, because it changed the stack VMA to be the correct/real size, meaning our stack expansion code is now triggered. Fix it by increasing the allowance to 4224 bytes. Hard-coding 4224 is obviously unsafe against future expansions of the signal frame in the same way as the existing code. We can't easily use sizeof() because the signal frame structure is not in a header. We will either fix that, or rip out all the custom stack expansion checking logic entirely. Fixes: ce48b2100785 ("powerpc: Add VSX context save/restore, ptrace and signal support") Cc: stable(a)vger.kernel.org # v2.6.27+ Reported-by: Tom Lane <tgl(a)sss.pgh.pa.us> Tested-by: Daniel Axtens <dja(a)axtens.net> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://lore.kernel.org/r/20200724092528.1578671-2-mpe@ellerman.id.au Signed-off-by: Daniel Axtens <dja(a)axtens.net> --- arch/powerpc/mm/fault.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c index d1f860ca03ad..101c202c813c 100644 --- a/arch/powerpc/mm/fault.c +++ b/arch/powerpc/mm/fault.c @@ -192,6 +192,9 @@ static int mm_fault_error(struct pt_regs *regs, unsigned long addr, int fault) return MM_FAULT_CONTINUE; } +// This comes from 64-bit struct rt_sigframe + __SIGNAL_FRAMESIZE +#define SIGFRAME_MAX_SIZE (4096 + 128) + /* * For 600- and 800-family processors, the error_code parameter is DSISR * for a data fault, SRR1 for an instruction fault. For 400-family processors @@ -341,7 +344,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address, /* * N.B. The POWER/Open ABI allows programs to access up to * 288 bytes below the stack pointer. - * The kernel signal delivery code writes up to about 1.5kB + * The kernel signal delivery code writes up to about 4kB * below the stack pointer (r1) before decrementing it. * The exec code can write slightly over 640kB to the stack * before setting the user r1. Thus we allow the stack to @@ -365,7 +368,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address, * between the last mapped region and the stack will * expand the stack rather than segfaulting. */ - if (address + 2048 < uregs->gpr[1] && !store_update_sp) + if (address + SIGFRAME_MAX_SIZE < uregs->gpr[1] && !store_update_sp) goto bad_area; } if (expand_stack(vma, address)) -- 2.25.1

4 years, 8 months

1
0
0 0

[PATCH v4.14] powerpc: Allow 4224 bytes of stack expansion for the signal frame

by Daniel Axtens

From: Michael Ellerman <mpe(a)ellerman.id.au> commit 63dee5df43a31f3844efabc58972f0a206ca4534 upstream. We have powerpc specific logic in our page fault handling to decide if an access to an unmapped address below the stack pointer should expand the stack VMA. The code was originally added in 2004 "ported from 2.4". The rough logic is that the stack is allowed to grow to 1MB with no extra checking. Over 1MB the access must be within 2048 bytes of the stack pointer, or be from a user instruction that updates the stack pointer. The 2048 byte allowance below the stack pointer is there to cover the 288 byte "red zone" as well as the "about 1.5kB" needed by the signal delivery code. Unfortunately since then the signal frame has expanded, and is now 4224 bytes on 64-bit kernels with transactional memory enabled. This means if a process has consumed more than 1MB of stack, and its stack pointer lies less than 4224 bytes from the next page boundary, signal delivery will fault when trying to expand the stack and the process will see a SEGV. The total size of the signal frame is the size of struct rt_sigframe (which includes the red zone) plus __SIGNAL_FRAMESIZE (128 bytes on 64-bit). The 2048 byte allowance was correct until 2008 as the signal frame was: struct rt_sigframe { struct ucontext uc; /* 0 1440 */ /* --- cacheline 11 boundary (1408 bytes) was 32 bytes ago --- */ long unsigned int _unused[2]; /* 1440 16 */ unsigned int tramp[6]; /* 1456 24 */ struct siginfo * pinfo; /* 1480 8 */ void * puc; /* 1488 8 */ struct siginfo info; /* 1496 128 */ /* --- cacheline 12 boundary (1536 bytes) was 88 bytes ago --- */ char abigap[288]; /* 1624 288 */ /* size: 1920, cachelines: 15, members: 7 */ /* padding: 8 */ }; 1920 + 128 = 2048 Then in commit ce48b2100785 ("powerpc: Add VSX context save/restore, ptrace and signal support") (Jul 2008) the signal frame expanded to 2304 bytes: struct rt_sigframe { struct ucontext uc; /* 0 1696 */ <-- /* --- cacheline 13 boundary (1664 bytes) was 32 bytes ago --- */ long unsigned int _unused[2]; /* 1696 16 */ unsigned int tramp[6]; /* 1712 24 */ struct siginfo * pinfo; /* 1736 8 */ void * puc; /* 1744 8 */ struct siginfo info; /* 1752 128 */ /* --- cacheline 14 boundary (1792 bytes) was 88 bytes ago --- */ char abigap[288]; /* 1880 288 */ /* size: 2176, cachelines: 17, members: 7 */ /* padding: 8 */ }; 2176 + 128 = 2304 At this point we should have been exposed to the bug, though as far as I know it was never reported. I no longer have a system old enough to easily test on. Then in 2010 commit 320b2b8de126 ("mm: keep a guard page below a grow-down stack segment") caused our stack expansion code to never trigger, as there was always a VMA found for a write up to PAGE_SIZE below r1. That meant the bug was hidden as we continued to expand the signal frame in commit 2b0a576d15e0 ("powerpc: Add new transactional memory state to the signal context") (Feb 2013): struct rt_sigframe { struct ucontext uc; /* 0 1696 */ /* --- cacheline 13 boundary (1664 bytes) was 32 bytes ago --- */ struct ucontext uc_transact; /* 1696 1696 */ <-- /* --- cacheline 26 boundary (3328 bytes) was 64 bytes ago --- */ long unsigned int _unused[2]; /* 3392 16 */ unsigned int tramp[6]; /* 3408 24 */ struct siginfo * pinfo; /* 3432 8 */ void * puc; /* 3440 8 */ struct siginfo info; /* 3448 128 */ /* --- cacheline 27 boundary (3456 bytes) was 120 bytes ago --- */ char abigap[288]; /* 3576 288 */ /* size: 3872, cachelines: 31, members: 8 */ /* padding: 8 */ /* last cacheline: 32 bytes */ }; 3872 + 128 = 4000 And commit 573ebfa6601f ("powerpc: Increase stack redzone for 64-bit userspace to 512 bytes") (Feb 2014): struct rt_sigframe { struct ucontext uc; /* 0 1696 */ /* --- cacheline 13 boundary (1664 bytes) was 32 bytes ago --- */ struct ucontext uc_transact; /* 1696 1696 */ /* --- cacheline 26 boundary (3328 bytes) was 64 bytes ago --- */ long unsigned int _unused[2]; /* 3392 16 */ unsigned int tramp[6]; /* 3408 24 */ struct siginfo * pinfo; /* 3432 8 */ void * puc; /* 3440 8 */ struct siginfo info; /* 3448 128 */ /* --- cacheline 27 boundary (3456 bytes) was 120 bytes ago --- */ char abigap[512]; /* 3576 512 */ <-- /* size: 4096, cachelines: 32, members: 8 */ /* padding: 8 */ }; 4096 + 128 = 4224 Then finally in 2017, commit 1be7107fbe18 ("mm: larger stack guard gap, between vmas") exposed us to the existing bug, because it changed the stack VMA to be the correct/real size, meaning our stack expansion code is now triggered. Fix it by increasing the allowance to 4224 bytes. Hard-coding 4224 is obviously unsafe against future expansions of the signal frame in the same way as the existing code. We can't easily use sizeof() because the signal frame structure is not in a header. We will either fix that, or rip out all the custom stack expansion checking logic entirely. Fixes: ce48b2100785 ("powerpc: Add VSX context save/restore, ptrace and signal support") Cc: stable(a)vger.kernel.org # v2.6.27+ Reported-by: Tom Lane <tgl(a)sss.pgh.pa.us> Tested-by: Daniel Axtens <dja(a)axtens.net> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://lore.kernel.org/r/20200724092528.1578671-2-mpe@ellerman.id.au Signed-off-by: Daniel Axtens <dja(a)axtens.net> --- arch/powerpc/mm/fault.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c index 5fc8a010fdf0..b990415d4922 100644 --- a/arch/powerpc/mm/fault.c +++ b/arch/powerpc/mm/fault.c @@ -227,6 +227,9 @@ static bool bad_kernel_fault(bool is_exec, unsigned long error_code, return is_exec || (address >= TASK_SIZE); } +// This comes from 64-bit struct rt_sigframe + __SIGNAL_FRAMESIZE +#define SIGFRAME_MAX_SIZE (4096 + 128) + static bool bad_stack_expansion(struct pt_regs *regs, unsigned long address, struct vm_area_struct *vma, bool store_update_sp) @@ -234,7 +237,7 @@ static bool bad_stack_expansion(struct pt_regs *regs, unsigned long address, /* * N.B. The POWER/Open ABI allows programs to access up to * 288 bytes below the stack pointer. - * The kernel signal delivery code writes up to about 1.5kB + * The kernel signal delivery code writes a bit over 4KB * below the stack pointer (r1) before decrementing it. * The exec code can write slightly over 640kB to the stack * before setting the user r1. Thus we allow the stack to @@ -258,7 +261,7 @@ static bool bad_stack_expansion(struct pt_regs *regs, unsigned long address, * between the last mapped region and the stack will * expand the stack rather than segfaulting. */ - if (address + 2048 < uregs->gpr[1] && !store_update_sp) + if (address + SIGFRAME_MAX_SIZE < uregs->gpr[1] && !store_update_sp) return true; } return false; -- 2.25.1

4 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] io_uring: find and cancel head link async work on files exit" failed to apply to 5.7-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.7-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From b711d4eaf0c408a811311ee3e94d6e9e5a230a9a Mon Sep 17 00:00:00 2001 From: Jens Axboe <axboe(a)kernel.dk> Date: Sun, 16 Aug 2020 08:23:05 -0700 Subject: [PATCH] io_uring: find and cancel head link async work on files exit Commit f254ac04c874 ("io_uring: enable lookup of links holding inflight files") only handled 2 out of the three head link cases we have, we also need to lookup and cancel work that is blocked in io-wq if that work has a link that's holding a reference to the files structure. Put the "cancel head links that hold this request pending" logic into io_attempt_cancel(), which will to through the motions of finding and canceling head links that hold the current inflight files stable request pending. Cc: stable(a)vger.kernel.org Reported-by: Pavel Begunkov <asml.silence(a)gmail.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/fs/io_uring.c b/fs/io_uring.c index dc506b75659c..346a3eb84785 100644 --- a/fs/io_uring.c +++ b/fs/io_uring.c @@ -8063,6 +8063,33 @@ static bool io_timeout_remove_link(struct io_ring_ctx *ctx, return found; } +static bool io_cancel_link_cb(struct io_wq_work *work, void *data) +{ + return io_match_link(container_of(work, struct io_kiocb, work), data); +} + +static void io_attempt_cancel(struct io_ring_ctx *ctx, struct io_kiocb *req) +{ + enum io_wq_cancel cret; + + /* cancel this particular work, if it's running */ + cret = io_wq_cancel_work(ctx->io_wq, &req->work); + if (cret != IO_WQ_CANCEL_NOTFOUND) + return; + + /* find links that hold this pending, cancel those */ + cret = io_wq_cancel_cb(ctx->io_wq, io_cancel_link_cb, req, true); + if (cret != IO_WQ_CANCEL_NOTFOUND) + return; + + /* if we have a poll link holding this pending, cancel that */ + if (io_poll_remove_link(ctx, req)) + return; + + /* final option, timeout link is holding this req pending */ + io_timeout_remove_link(ctx, req); +} + static void io_uring_cancel_files(struct io_ring_ctx *ctx, struct files_struct *files) { @@ -8116,10 +8143,8 @@ static void io_uring_cancel_files(struct io_ring_ctx *ctx, continue; } } else { - io_wq_cancel_work(ctx->io_wq, &cancel_req->work); - /* could be a link, check and remove if it is */ - if (!io_poll_remove_link(ctx, cancel_req)) - io_timeout_remove_link(ctx, cancel_req); + /* cancel this request, or head link requests */ + io_attempt_cancel(ctx, cancel_req); io_put_req(cancel_req); }

4 years, 8 months

3
4
0 0

stable-rc/linux-4.19.y baseline: 152 runs, 1 regressions (v4.19.141-19-ga76a89456133)

by kernelci.org bot

stable-rc/linux-4.19.y baseline: 152 runs, 1 regressions (v4.19.141-19-ga76a89456133) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | results ----------------------+------+--------------+----------+-----------------+-------- at91-sama5d4_xplained | arm | lab-baylibre | gcc-8 | sama5_defconfig | 0/1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.14… Test: baseline Tree: stable-rc Branch: linux-4.19.y Describe: v4.19.141-19-ga76a89456133 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: a76a89456133f91791ee74d2ea5c8d761a56a413 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | results ----------------------+------+--------------+----------+-----------------+-------- at91-sama5d4_xplained | arm | lab-baylibre | gcc-8 | sama5_defconfig | 0/1 Details: https://kernelci.org/test/plan/id/5f429023f6807a49a29fb438 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: sama5_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.141-19-ga76a8945… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.141-19-ga76a8945… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/armel/basel… * baseline.login: https://kernelci.org/test/case/id/5f429023f6807a49a29fb439 failing since 68 days (last pass: v4.19.126-55-gf6c346f2d42d, first fail: v4.19.126-113-gd694d4388e88)

4 years, 8 months

1
0
0 0

stable-rc/linux-5.4.y baseline: 168 runs, 1 regressions (v5.4.60-39-g6ba0cb3c0b4a)

by kernelci.org bot

stable-rc/linux-5.4.y baseline: 168 runs, 1 regressions (v5.4.60-39-g6ba0cb3c0b4a) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | results ----------------------+------+--------------+----------+-----------------+-------- at91-sama5d4_xplained | arm | lab-baylibre | gcc-8 | sama5_defconfig | 0/1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-5.4.y/kernel/v5.4.60-3… Test: baseline Tree: stable-rc Branch: linux-5.4.y Describe: v5.4.60-39-g6ba0cb3c0b4a URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 6ba0cb3c0b4a76216b617b5d6d4cf50208c96ba6 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | results ----------------------+------+--------------+----------+-----------------+-------- at91-sama5d4_xplained | arm | lab-baylibre | gcc-8 | sama5_defconfig | 0/1 Details: https://kernelci.org/test/plan/id/5f42988c49164b4afd9fb435 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: sama5_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.60-39-g6ba0cb3c0b4… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.60-39-g6ba0cb3c0b4… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/armel/basel… * baseline.login: https://kernelci.org/test/case/id/5f42988c49164b4afd9fb436 failing since 133 days (last pass: v5.4.30-54-g6f04e8ca5355, first fail: v5.4.30-81-gf163418797b9)

4 years, 8 months

1
0
0 0

stable-rc/linux-5.7.y baseline: 173 runs, 3 regressions (v5.7.17-28-gafe48ff97f9b)

by kernelci.org bot

stable-rc/linux-5.7.y baseline: 173 runs, 3 regressions (v5.7.17-28-gafe48ff97f9b) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | results ----------------------+-------+---------------+----------+------------------+-------- at91-sama5d4_xplained | arm | lab-baylibre | gcc-8 | sama5_defconfig | 0/1 bcm2837-rpi-3-b | arm64 | lab-baylibre | gcc-8 | defconfig | 3/4 exynos5422-odroidxu3 | arm | lab-collabora | gcc-8 | exynos_defconfig | 0/1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-5.7.y/kernel/v5.7.17-2… Test: baseline Tree: stable-rc Branch: linux-5.7.y Describe: v5.7.17-28-gafe48ff97f9b URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: afe48ff97f9bc86e17c4c8ee887eceba61d0620d Test Regressions ---------------- platform | arch | lab | compiler | defconfig | results ----------------------+-------+---------------+----------+------------------+-------- at91-sama5d4_xplained | arm | lab-baylibre | gcc-8 | sama5_defconfig | 0/1 Details: https://kernelci.org/test/plan/id/5f42891e2ae87ef87f9fb435 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: sama5_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-5.7.y/v5.7.17-28-gafe48ff97f9… HTML log: https://storage.kernelci.org//stable-rc/linux-5.7.y/v5.7.17-28-gafe48ff97f9… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/armel/basel… * baseline.login: https://kernelci.org/test/case/id/5f42891e2ae87ef87f9fb436 failing since 38 days (last pass: v5.7.8-167-gc2fb28a4b6e4, first fail: v5.7.9) platform | arch | lab | compiler | defconfig | results ----------------------+-------+---------------+----------+------------------+-------- bcm2837-rpi-3-b | arm64 | lab-baylibre | gcc-8 | defconfig | 3/4 Details: https://kernelci.org/test/plan/id/5f4284339a583013a99fb444 Results: 3 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-5.7.y/v5.7.17-28-gafe48ff97f9… HTML log: https://storage.kernelci.org//stable-rc/linux-5.7.y/v5.7.17-28-gafe48ff97f9… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/arm64/basel… * baseline.dmesg.crit: https://kernelci.org/test/case/id/5f4284339a583013a99fb448 new failure (last pass: v5.7.17) 2 lines 2020-08-23 14:56:35.591000 Connected to bcm2837-rpi-3-b console [channel connected] (~$quit to exit) 2020-08-23 14:56:35.591000 (user:khilman) is already connected 2020-08-23 14:56:51.155000 2020-08-23 14:56:51.155000 2020-08-23 14:56:51.155000 U-Boot 2018.11 (Dec 04 2018 - 10:54:32 -0800) 2020-08-23 14:56:51.156000 2020-08-23 14:56:51.156000 DRAM: 948 MiB 2020-08-23 14:56:51.171000 RPI 3 Model B (0xa02082) 2020-08-23 14:56:51.259000 MMC: mmc@7e202000: 0, sdhci@7e300000: 1 2020-08-23 14:56:51.290000 Loading Environment from FAT... *** Warning - bad CRC, using default environment ... (385 line(s) more) platform | arch | lab | compiler | defconfig | results ----------------------+-------+---------------+----------+------------------+-------- exynos5422-odroidxu3 | arm | lab-collabora | gcc-8 | exynos_defconfig | 0/1 Details: https://kernelci.org/test/plan/id/5f4293e0612319fe999fb43b Results: 0 PASS, 1 FAIL, 0 SKIP Full config: exynos_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-5.7.y/v5.7.17-28-gafe48ff97f9… HTML log: https://storage.kernelci.org//stable-rc/linux-5.7.y/v5.7.17-28-gafe48ff97f9… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/armel/basel… * baseline.login: https://kernelci.org/test/case/id/5f4293e0612319fe999fb43c failing since 3 days (last pass: v5.7.16-99-gc5aad81e7f2d, first fail: v5.7.16-205-g7366707e7e99)

4 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2020