public inbox for linux-staging@lists.linux.dev
 help / color / mirror / Atom feed
From: Phillip Potter <phil@philpotter.co.uk>
To: Martin Kaiser <lists@kaiser.cx>
Cc: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	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 21:12:17 +0100	[thread overview]
Message-ID: <YWyDobhWyrJx5fGK@equinox> (raw)
In-Reply-To: <20211017180237.bvc6spwbj72zyjhi@viti.kaiser.cx>

On Sun, Oct 17, 2021 at 08:02:37PM +0200, Martin Kaiser wrote:
> Hi Fabio and all,
> 
> Thus wrote Fabio M. De Francesco (fmdefrancesco@gmail.com):
> 
> > On Sunday, October 17, 2021 12:29:02 PM CEST Phillip Potter wrote:
> 
> > > 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.
> 
> And it seems that by default, a kthread can't be killed with SIGKILL.
> 

Ah, makes sense. This was a misconception on my part, apologies :-)

> > > 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.
> 
> Exactly. And this is probably not by intention. It would be consistent
> to either allow both or none - the latter makes more sense, and it's
> what most other drivers do.
> 
> > I think that kthreads must also allow  SIGKILL with "allow_signal(SIGKILL);" 
> > for allowing root to make them terminate.
> 
> Probably. nfsd seems to do this.
> 
> > 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.
> 
> That makes sense to me.
> 
> Let's see what Greg and others say...

I've found this discussion to be most enlightening :-) I certainly agree
that consistency in approach is a good thing, so perhaps
wait_for_completion() is a better choice therefore, despite it having
the same semantics in this instance due to us not allowing SIGKILL by
default anyway. Others will know far more than me in this regard though.

Regards,
Phil

  reply	other threads:[~2021-10-17 20:12 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
2021-10-17 14:13         ` Fabio M. De Francesco
2021-10-17 18:02         ` Martin Kaiser
2021-10-17 20:12           ` Phillip Potter [this message]
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=YWyDobhWyrJx5fGK@equinox \
    --to=phil@philpotter.co.uk \
    --cc=Larry.Finger@lwfinger.net \
    --cc=fmdefrancesco@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=lists@kaiser.cx \
    --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