On Thu, 28 Jun 2007 21:08:25 +0400
Oleg Nesterov <[email protected]> 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 <[email protected]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
