From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: Phillip Potter <phil@philpotter.co.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Martin Kaiser <martin@kaiser.cx>,
Larry Finger <Larry.Finger@lwfinger.net>,
Michael Straube <straube.linux@gmail.com>,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] staging: r8188eu: don't accept SIGTERM for cmd thread
Date: Sun, 17 Oct 2021 14:51:40 +0200 [thread overview]
Message-ID: <1957621.GeRc3qvyWe@localhost.localdomain> (raw)
In-Reply-To: <YWv67ozbJGxMa69t@equinox>
On Sunday, October 17, 2021 12:29:02 PM CEST Phillip Potter wrote:
> On Sat, Oct 16, 2021 at 08:53:15PM +0200, Fabio M. De Francesco wrote:
> > On Saturday, October 16, 2021 8:13:43 PM CEST Martin Kaiser wrote:
> > > At the moment, our command thread can be killed by user space.
> > >
> > > [root@host ]# kill `pidof RTW_CMD_THREAD`
> > >
> > > The driver will then stop working until the module is unloaded
> > > and reloaded.
> > >
> > > Don't process SIGTERM in the command thread. Other drivers that have a
> > > command thread don't process SIGTERM either.
> >
> > Hi Martin,
> >
> > This is _really_ interesting :)
> >
> > May be that you have had time to read my last email in reply to a message
of
> > Phillip P. Soon after writing of the arguments in favor of using
> > wait_for_completion_killable() (in patch 2/3 of the series I sent today),
I
> > read your patch.
> >
> > If you are right (and I think you are) I'll have to send a v2 that
replaces
> > the killable wait with an uninterruptible one.
> >
> > Unfortunately I have not the needed experience to decide whether or not
to
> > ack your patch, even if I'm strongly tempted to do it.
> >
> > Let's wait for more experienced people.
> >
> > Thanks,
> >
> > Fabio
> >
>
> So I myself am a little confused on this one :-)
>
> Based on my understanding, so correct me if I'm wrong, a process (kthread
or
> otherwise) can still be killed if marked TASK_KILLABLE, even if ignoring
> SIGTERM. Indeed, from a userspace perspective, SIGKILL is unblockable
> anyway - although of course kernel code can choose how to respond to it.
Correct.
>
> So in other words, the kthread could still be killed while waiting
> in the wait_for_completion_killable() call, even if we are ignoring
> SIGTERM. From that perspective I guess, it is therefore not 'incorrect' as
> such - if indeed we wanted that behaviour.
No. This misunderstandings is my fault. :(
In Martin's patch I read "SIGTERM" but for some reason I thought he was
talking of "SIGKILL".
At the moment, without Martin's patch, the kthread can be terminated by the
command "kill -TERM <PID>". If we try "kill -KILL <PID>", nothing happens.
This is because only "allow_signal(SIGTERM);" is present in the code.
I think that kthreads must also allow SIGKILL with "allow_signal(SIGKILL);"
for allowing root to make them terminate.
For what relates to my patch, it doesn't matter if I either leave
wait_for_completion_killable() as-is or change it to wait_for_completion().
This is because at the moment SIGKILL cannot kill rtw_cmd_thread(), while
SIGTERM can.
However, for consistency, I should better change it to the uninterruptible
version.
@Martin: Please correct me if I'm wrong. Thanks.
Regards,
Fabio
>
> That said, killing it would still cause the behaviour Martin mentions -
> I guess we don't want it to be either killable or interruptible based on
> that logic?
>
> Regards,
> Phil
>
next prev parent reply other threads:[~2021-10-17 14:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-16 18:13 [PATCH 0/3] staging: r8188eu: clean up osdep_service.h Martin Kaiser
2021-10-16 18:13 ` [PATCH 1/3] staging: r8188eu: res_to_status is unused Martin Kaiser
2021-10-16 18:54 ` Fabio M. De Francesco
2021-10-17 12:46 ` Michael Straube
2021-10-16 18:13 ` [PATCH 2/3] staging: r8188eu: daemonize is not defined Martin Kaiser
2021-10-16 18:59 ` Fabio M. De Francesco
2021-10-17 12:48 ` Michael Straube
2021-10-16 18:13 ` [PATCH 3/3] staging: r8188eu: don't accept SIGTERM for cmd thread Martin Kaiser
2021-10-16 18:53 ` Fabio M. De Francesco
2021-10-17 10:29 ` Phillip Potter
2021-10-17 12:51 ` Fabio M. De Francesco [this message]
2021-10-17 14:13 ` Fabio M. De Francesco
2021-10-17 18:02 ` Martin Kaiser
2021-10-17 20:12 ` Phillip Potter
2021-10-17 13:14 ` Fabio M. De Francesco
2021-10-17 14:11 ` Fabio M. De Francesco
2021-10-17 13:19 ` Fabio M. De Francesco
2021-10-17 14:47 ` Fabio M. De Francesco
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=1957621.GeRc3qvyWe@localhost.localdomain \
--to=fmdefrancesco@gmail.com \
--cc=Larry.Finger@lwfinger.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=martin@kaiser.cx \
--cc=phil@philpotter.co.uk \
--cc=straube.linux@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox