All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH] sh: add support for TIF_NOTIFY_SIGNAL
Date: Mon, 09 Nov 2020 16:29:28 +0000	[thread overview]
Message-ID: <1222fc17-dc3b-5def-e9c1-743b2436d6d7@kernel.dk> (raw)
In-Reply-To: <5fcc82b4-89ae-3bca-10ab-6ad933565cee@kernel.dk>

On 11/9/20 9:34 AM, Rob Landley wrote:
> On 11/9/20 9:10 AM, Jens Axboe wrote:
>> On 11/9/20 8:15 AM, Rob Landley wrote:
>>>
>>>
>>> On 11/9/20 8:14 AM, Jens Axboe wrote:
>>>> On 11/9/20 1:15 AM, Rob Landley wrote:
>>>>> On 11/5/20 11:15 AM, Jens Axboe wrote:
>>>>>> On 11/5/20 9:20 AM, John Paul Adrian Glaubitz wrote:
>>>>>>> Hi Jens!
>>>>>>>
>>>>>>> On 11/5/20 5:17 PM, Jens Axboe wrote:
>>>>>>>> Gentle nudge on this one.
>>>>>>>
>>>>>>> I can build- and boot-test on SH and IA64.
>>>>>>
>>>>>> That'd be great, thanks!
>>>>>>
>>>>>>> I assume Rich will be fine with the SH changes, not sure about the IA64 and Tony.
>>>>>>
>>>>>> Let's add Tony - maybe he'll have a chance to take a look at the ia64 change.
>>>>>
>>>>> It breaks my ARCH=sh j2_defconfig build:
>>>>>
>>>>> arch/sh/kernel/signal_32.c: In function 'do_signal':
>>>>> arch/sh/kernel/signal_32.c:469:6: error: 'ti_work' undeclared (first use in this
>>>>> function)
>>>>>
>>>>> Admittedly I'm testing a stack of 6 other patches at the same time:
>>>>>
>>>>> [PATCH -next v2] sh: intc: Convert to DEFINE_SHOW_ATTRIBUTE.eml
>>>>> [PATCH] sh: dma: fix kconfig dependency for G2_DMA.eml
>>>>> [PATCH] sh: remove CONFIG_IDE from most defconfig.eml
>>>>> [PATCH] sh: Remove unused HAVE_COPY_THREAD_TLS macro.eml
>>>>> [PATCH v1] sh: Drop ARCH_NR_GPIOS definition.eml
>>>>> [PATCH v2 RESEND +TRIVIAL] arch_sh: hyphenate Non-Uniform in Kconfig prompt.eml
>>>>>
>>>>> But this is the one I need to revert to get 5.10-rc3 to build, the rest compile.
>>>>
>>>> Yeah that's my fault, this one should be a lot better...
>>>
>>> arch/sh/kernel/signal_32.c: In function 'do_signal':
>>> arch/sh/kernel/signal_32.c:471:3: error: implicit declaration of function
>>> 'tracehook_notify_signal'; did you mean 'tracehook_notify_resume'?
>>> [-Werror=implicit-function-declaration]
>>>
>>> Keep 'em coming...
>>
>> Gah, it was still using the old style. This one should work and be correct,
>> promise, double checked :-)
> 
> This one compiled fine. What does it do? (I ask having read
> https://lwn.net/Articles/835340/ and come out none the wiser.)

The motivation is in another patch:

https://git.kernel.dk/cgit/linux-block/commit/?h=tif-task_work&idýb5f027ce662d1e10d8d16793b1f588b8543277

Basically it decouples TWA_SIGNAL task_work from actual signals, since
they contend on the sighand lock, particularly for threads. Hence the
goal is to get all archs supporting TIF_NOTIFY_SIGNAL, so we can use
that for TWA_SIGNAL.

The patches are done such that the signal handling core still handles
running the task_work, but if invoked without TIF_SIGPENDING, we don't
do actual signal delivery, just the syscall restart part.

> I can try it on hardware in the morning, it's 1am in this time zone...

Thanks, that'd be great! It really should be a no-op, as you can see
from the final patch, it's just masking in an extra flag for when to
call get_signal(). At least it should've been, if I hadn't neglected
to properly updated the 'sh' patch for the cleaner setup...

-- 
Jens Axboe

  parent reply	other threads:[~2020-11-09 16:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-29 16:21 [PATCH] sh: add support for TIF_NOTIFY_SIGNAL Jens Axboe
2020-11-05 16:17 ` Jens Axboe
2020-11-05 16:20 ` John Paul Adrian Glaubitz
2020-11-05 17:15 ` Jens Axboe
2020-11-09  8:15 ` Rob Landley
2020-11-09 10:59 ` John Paul Adrian Glaubitz
2020-11-09 14:14 ` Jens Axboe
2020-11-09 14:14 ` Jens Axboe
2020-11-09 15:10 ` Jens Axboe
2020-11-09 15:15 ` Rob Landley
2020-11-09 16:29 ` Jens Axboe [this message]
2020-11-09 16:34 ` Rob Landley
2020-11-17  5:26 ` John Paul Adrian Glaubitz
2020-11-17 15:06 ` Jens Axboe
2021-01-01 14:06   ` John Paul Adrian Glaubitz
2021-01-01 14:06     ` John Paul Adrian Glaubitz
2021-01-01 15:08     ` Jens Axboe
2021-01-01 15:08       ` Jens Axboe
2021-01-01 15:30       ` John Paul Adrian Glaubitz
2021-01-01 15:30         ` John Paul Adrian Glaubitz
2021-01-01 15:35         ` Jens Axboe
2021-01-01 15:35           ` Jens Axboe
2021-01-01 18:16           ` John Paul Adrian Glaubitz
2021-01-01 18:16             ` John Paul Adrian Glaubitz
2021-01-01 18:22             ` Jens Axboe
2021-01-01 18:22               ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1222fc17-dc3b-5def-e9c1-743b2436d6d7@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=linux-sh@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.