| Message ID | 111f501e-33e7-ad38-6476-9874f1226ad7@kernel.dk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: add support for TIF_NOTIFY_SIGNAL | expand |
Hi Jens, [+ Catalin] On Thu, Oct 29, 2020 at 10:11:55AM -0600, Jens Axboe wrote: > Cc: linux-arm-kernel@lists.infradead.org > Signed-off-by: Jens Axboe <axboe@kernel.dk> > --- > > 5.11 has support queued up for TIF_NOTIFY_SIGNAL, see this posting > for details: > > https://lore.kernel.org/io-uring/20201026203230.386348-1-axboe@kernel.dk/ > > As part of that work, I'm adding TIF_NOTIFY_SIGNAL support to all archs, > as that will enable a set of cleanups once all of them support it. I'm > happy carrying this patch if need be, or it can be funelled through the > arch tree. Let me know. > > arch/arm64/include/asm/thread_info.h | 5 ++++- > arch/arm64/kernel/signal.c | 2 +- > 2 files changed, 5 insertions(+), 2 deletions(-) I think it makes sense for this to go via the arm64 tree, as it's self-contained and we can handle any conflicts directly. Catalin -- would you be able to pick this up when you start queueing stuff around -rc3, please? But either way: Acked-by: Will Deacon <will@kernel.org> Cheers, Will
On 10/30/20 12:48 AM, Will Deacon wrote: > Hi Jens, > > [+ Catalin] > > On Thu, Oct 29, 2020 at 10:11:55AM -0600, Jens Axboe wrote: >> Cc: linux-arm-kernel@lists.infradead.org >> Signed-off-by: Jens Axboe <axboe@kernel.dk> >> --- >> >> 5.11 has support queued up for TIF_NOTIFY_SIGNAL, see this posting >> for details: >> >> https://lore.kernel.org/io-uring/20201026203230.386348-1-axboe@kernel.dk/ >> >> As part of that work, I'm adding TIF_NOTIFY_SIGNAL support to all archs, >> as that will enable a set of cleanups once all of them support it. I'm >> happy carrying this patch if need be, or it can be funelled through the >> arch tree. Let me know. >> >> arch/arm64/include/asm/thread_info.h | 5 ++++- >> arch/arm64/kernel/signal.c | 2 +- >> 2 files changed, 5 insertions(+), 2 deletions(-) > > I think it makes sense for this to go via the arm64 tree, as it's > self-contained and we can handle any conflicts directly. Catalin -- would > you be able to pick this up when you start queueing stuff around -rc3, > please? Works for me, it's done as such that it can be carried outside of the main series. > But either way: > > Acked-by: Will Deacon <will@kernel.org> Thanks!
Gentle nudge on this one. On 10/29/20 10:11 AM, Jens Axboe wrote: > Cc: linux-arm-kernel@lists.infradead.org > Signed-off-by: Jens Axboe <axboe@kernel.dk> > --- > > 5.11 has support queued up for TIF_NOTIFY_SIGNAL, see this posting > for details: > > https://lore.kernel.org/io-uring/20201026203230.386348-1-axboe@kernel.dk/ > > As part of that work, I'm adding TIF_NOTIFY_SIGNAL support to all archs, > as that will enable a set of cleanups once all of them support it. I'm > happy carrying this patch if need be, or it can be funelled through the > arch tree. Let me know. > > arch/arm64/include/asm/thread_info.h | 5 ++++- > arch/arm64/kernel/signal.c | 2 +- > 2 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h > index 1fbab854a51b..cdcf307764aa 100644 > --- a/arch/arm64/include/asm/thread_info.h > +++ b/arch/arm64/include/asm/thread_info.h > @@ -68,6 +68,7 @@ void arch_release_task_struct(struct task_struct *tsk); > #define TIF_UPROBE 4 /* uprobe breakpoint or singlestep */ > #define TIF_FSCHECK 5 /* Check FS is USER_DS on return */ > #define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */ > +#define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */ > #define TIF_SYSCALL_TRACE 8 /* syscall trace active */ > #define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ > #define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ > @@ -98,10 +99,12 @@ void arch_release_task_struct(struct task_struct *tsk); > #define _TIF_32BIT (1 << TIF_32BIT) > #define _TIF_SVE (1 << TIF_SVE) > #define _TIF_MTE_ASYNC_FAULT (1 << TIF_MTE_ASYNC_FAULT) > +#define _TIF_NOTIFY_SIGNAL (1 << TIF_NOTIFY_SIGNAL) > > #define _TIF_WORK_MASK (_TIF_NEED_RESCHED | _TIF_SIGPENDING | \ > _TIF_NOTIFY_RESUME | _TIF_FOREIGN_FPSTATE | \ > - _TIF_UPROBE | _TIF_FSCHECK | _TIF_MTE_ASYNC_FAULT) > + _TIF_UPROBE | _TIF_FSCHECK | _TIF_MTE_ASYNC_FAULT | \ > + _TIF_NOTIFY_SIGNAL) > > #define _TIF_SYSCALL_WORK (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | \ > _TIF_SYSCALL_TRACEPOINT | _TIF_SECCOMP | \ > diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c > index a8184cad8890..bec6ef69704f 100644 > --- a/arch/arm64/kernel/signal.c > +++ b/arch/arm64/kernel/signal.c > @@ -942,7 +942,7 @@ asmlinkage void do_notify_resume(struct pt_regs *regs, > (void __user *)NULL, current); > } > > - if (thread_flags & _TIF_SIGPENDING) > + if (thread_flags & (_TIF_SIGPENDING | _TIF_NOTIFY_SIGNAL)) > do_signal(regs); > > if (thread_flags & _TIF_NOTIFY_RESUME) { >
On Thu, Nov 05, 2020 at 09:19:49AM -0700, Jens Axboe wrote:
> Gentle nudge on this one.
I'll pick it up for 5.11, though I only start queuing patches usually at
-rc3 (so next week).
Thanks.
On 11/6/20 5:14 AM, Catalin Marinas wrote: > On Thu, Nov 05, 2020 at 09:19:49AM -0700, Jens Axboe wrote: >> Gentle nudge on this one. > > I'll pick it up for 5.11, though I only start queuing patches usually at > -rc3 (so next week). Thanks! I can carry it too with your ack, I got some patches that depend on all archs being switched over. But not a huge deal if you want to take it through your tree, I'll likely need to split into a prep and post series anyway.
On Fri, Nov 06, 2020 at 07:38:21AM -0700, Jens Axboe wrote: > On 11/6/20 5:14 AM, Catalin Marinas wrote: > > On Thu, Nov 05, 2020 at 09:19:49AM -0700, Jens Axboe wrote: > >> Gentle nudge on this one. > > > > I'll pick it up for 5.11, though I only start queuing patches usually at > > -rc3 (so next week). > > Thanks! I can carry it too with your ack, I got some patches that depend > on all archs being switched over. But not a huge deal if you want to > take it through your tree, I'll likely need to split into a prep and > post series anyway. If you have a dependency, feel free to take it through your tree but please provide a stable branch in case we get a non-trivial conflict. Will's ack would suffice but if you need another: Acked-by: Catalin Marinas <catalin.marinas@arm.com>
On 11/6/20 7:41 AM, Catalin Marinas wrote: > On Fri, Nov 06, 2020 at 07:38:21AM -0700, Jens Axboe wrote: >> On 11/6/20 5:14 AM, Catalin Marinas wrote: >>> On Thu, Nov 05, 2020 at 09:19:49AM -0700, Jens Axboe wrote: >>>> Gentle nudge on this one. >>> >>> I'll pick it up for 5.11, though I only start queuing patches usually at >>> -rc3 (so next week). >> >> Thanks! I can carry it too with your ack, I got some patches that depend >> on all archs being switched over. But not a huge deal if you want to >> take it through your tree, I'll likely need to split into a prep and >> post series anyway. > > If you have a dependency, feel free to take it through your tree but > please provide a stable branch in case we get a non-trivial conflict. I'll likely keep rebasing this series for a bit - not doing code changes, but just adding acks etc from folks. I'll keep an eye on potential conflicts, but given the nature of the patch and the size of it, even if we had any they are likely going to be very trivial. That said, if you want a stable branch, then I can provide one now and just have everything that's acked up until this point. Either way is fine with me. > Will's ack would suffice but if you need another: > > Acked-by: Catalin Marinas <catalin.marinas@arm.com> Thanks - I had missed Will already acked it, but 2 is better than 1 :-)
On Fri, Nov 06, 2020 at 07:55:13AM -0700, Jens Axboe wrote: > On 11/6/20 7:41 AM, Catalin Marinas wrote: > > On Fri, Nov 06, 2020 at 07:38:21AM -0700, Jens Axboe wrote: > >> On 11/6/20 5:14 AM, Catalin Marinas wrote: > >>> On Thu, Nov 05, 2020 at 09:19:49AM -0700, Jens Axboe wrote: > >>>> Gentle nudge on this one. > >>> > >>> I'll pick it up for 5.11, though I only start queuing patches usually at > >>> -rc3 (so next week). > >> > >> Thanks! I can carry it too with your ack, I got some patches that depend > >> on all archs being switched over. But not a huge deal if you want to > >> take it through your tree, I'll likely need to split into a prep and > >> post series anyway. > > > > If you have a dependency, feel free to take it through your tree but > > please provide a stable branch in case we get a non-trivial conflict. > > I'll likely keep rebasing this series for a bit - not doing code changes, > but just adding acks etc from folks. I'll keep an eye on potential > conflicts, but given the nature of the patch and the size of it, even > if we had any they are likely going to be very trivial. > > That said, if you want a stable branch, then I can provide one now > and just have everything that's acked up until this point. Either way > is fine with me. That's not needed for now. I (or sfr) will let you know in the next 2 weeks or so once I start queuing patches. As you said, the conflicts may be trivial, if any.
On 11/6/20 7:59 AM, Catalin Marinas wrote: > On Fri, Nov 06, 2020 at 07:55:13AM -0700, Jens Axboe wrote: >> On 11/6/20 7:41 AM, Catalin Marinas wrote: >>> On Fri, Nov 06, 2020 at 07:38:21AM -0700, Jens Axboe wrote: >>>> On 11/6/20 5:14 AM, Catalin Marinas wrote: >>>>> On Thu, Nov 05, 2020 at 09:19:49AM -0700, Jens Axboe wrote: >>>>>> Gentle nudge on this one. >>>>> >>>>> I'll pick it up for 5.11, though I only start queuing patches usually at >>>>> -rc3 (so next week). >>>> >>>> Thanks! I can carry it too with your ack, I got some patches that depend >>>> on all archs being switched over. But not a huge deal if you want to >>>> take it through your tree, I'll likely need to split into a prep and >>>> post series anyway. >>> >>> If you have a dependency, feel free to take it through your tree but >>> please provide a stable branch in case we get a non-trivial conflict. >> >> I'll likely keep rebasing this series for a bit - not doing code changes, >> but just adding acks etc from folks. I'll keep an eye on potential >> conflicts, but given the nature of the patch and the size of it, even >> if we had any they are likely going to be very trivial. >> >> That said, if you want a stable branch, then I can provide one now >> and just have everything that's acked up until this point. Either way >> is fine with me. > > That's not needed for now. I (or sfr) will let you know in the next 2 > weeks or so once I start queuing patches. As you said, the conflicts may > be trivial, if any. Sounds good, thanks. Stephen's email are usually a good indication of the magnitude of conflicts indeed.
diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h index 1fbab854a51b..cdcf307764aa 100644 --- a/arch/arm64/include/asm/thread_info.h +++ b/arch/arm64/include/asm/thread_info.h @@ -68,6 +68,7 @@ void arch_release_task_struct(struct task_struct *tsk); #define TIF_UPROBE 4 /* uprobe breakpoint or singlestep */ #define TIF_FSCHECK 5 /* Check FS is USER_DS on return */ #define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */ +#define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */ #define TIF_SYSCALL_TRACE 8 /* syscall trace active */ #define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ #define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ @@ -98,10 +99,12 @@ void arch_release_task_struct(struct task_struct *tsk); #define _TIF_32BIT (1 << TIF_32BIT) #define _TIF_SVE (1 << TIF_SVE) #define _TIF_MTE_ASYNC_FAULT (1 << TIF_MTE_ASYNC_FAULT) +#define _TIF_NOTIFY_SIGNAL (1 << TIF_NOTIFY_SIGNAL) #define _TIF_WORK_MASK (_TIF_NEED_RESCHED | _TIF_SIGPENDING | \ _TIF_NOTIFY_RESUME | _TIF_FOREIGN_FPSTATE | \ - _TIF_UPROBE | _TIF_FSCHECK | _TIF_MTE_ASYNC_FAULT) + _TIF_UPROBE | _TIF_FSCHECK | _TIF_MTE_ASYNC_FAULT | \ + _TIF_NOTIFY_SIGNAL) #define _TIF_SYSCALL_WORK (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | \ _TIF_SYSCALL_TRACEPOINT | _TIF_SECCOMP | \ diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c index a8184cad8890..bec6ef69704f 100644 --- a/arch/arm64/kernel/signal.c +++ b/arch/arm64/kernel/signal.c @@ -942,7 +942,7 @@ asmlinkage void do_notify_resume(struct pt_regs *regs, (void __user *)NULL, current); } - if (thread_flags & _TIF_SIGPENDING) + if (thread_flags & (_TIF_SIGPENDING | _TIF_NOTIFY_SIGNAL)) do_signal(regs); if (thread_flags & _TIF_NOTIFY_RESUME) {
Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Jens Axboe <axboe@kernel.dk> --- 5.11 has support queued up for TIF_NOTIFY_SIGNAL, see this posting for details: https://lore.kernel.org/io-uring/20201026203230.386348-1-axboe@kernel.dk/ As part of that work, I'm adding TIF_NOTIFY_SIGNAL support to all archs, as that will enable a set of cleanups once all of them support it. I'm happy carrying this patch if need be, or it can be funelled through the arch tree. Let me know. arch/arm64/include/asm/thread_info.h | 5 ++++- arch/arm64/kernel/signal.c | 2 +- 2 files changed, 5 insertions(+), 2 deletions(-)