linux-kernel - Re: [PATCH] RFC: have tcp_recvmsg() check kthread_should_stop() and treat it as if it were signalled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Jun 2007 14:41:39 -0400
From:	Jeff Layton <jlayton@...hat.com>
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	Satyam Sharma <satyam.sharma@...il.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	linux-kernel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH] RFC: have tcp_recvmsg() check kthread_should_stop() and
 treat it as if it were signalled

On Thu, 28 Jun 2007 21:08:25 +0400
Oleg Nesterov <oleg@...sign.ru> wrote:

> On 06/28, Satyam Sharma wrote:
> >
> > Second, we *must* break that tcp_recvmsg() inside the kthread's
> > main loop, of course! We want it stopped, after all, and if we don't
> > make it "break" out of that function, the kthread _will_never_exit_.
> 
> In that case this kthread is buggy. We have sock->sk_rcvtimeo.
> 
> > Please note that this
> > whole thing is about functions that will _simply_*never*_exit_ever_
> > _unless_ given a signal.
> 
> ditto. kthread should not do this.
> 
> OK, I suggest to stop this thread. I don't claim you are wrong, just
> we think differently ;)
> 
> > >This is what I can't understand completely. Why should we check SIGKILL
> > >or signal_pending() in addition to kthread_stop_info.k, what is the point?
> >
> > ... so kthread_stop_info will go away too.
> 
> it should go away regardless, we have patches. Still I see no point
> to check signal_pending() in kthread_stop().
> 
> Oleg.
> 

Again, this isn't an area where I have great expertise...

Adding signalling into kthread_stop would seem to be making some
assumptions about how kthreads are used and how they should respond to
signals. That sounds unsafe and might potentially limit flexibility.

agree with Oleg here -- I don't see the benefit to doing this for all
kthreads. If you're aware that your kthread might be blocked on a call,
then it doesn't seem burdensome to add in an extra send/force_sig call. 

-- 
Jeff Layton <jlayton@...hat.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/