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

[Satyam Sharma]

Hi Oleg,

On 6/28/07, Oleg Nesterov <oleg@xxxxxxxxxx> 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.

Well, I definitely wouldn't call it "buggy" ... skb_recv_datagram()
(if with sock->sk_rcvtimeo != MAX_SCHEDULE_TIMEOUT) would then
needlessly have to be put into it's own little while(1) (or put a
"continue;" after it back to main kthread loop). A question arises,
what timeout value to use? (too little => needless wastage of CPU;
too high => see below)

More importantly, the other thread that does a kthread_stop() on our
kthread (probably a umount(2) or rmmod) would then unfortunately hang
(on wait_for_completion i.e. TASK_UNINTERRUPTIBLE) for the duration
of the time it takes for our kthread to finish it's timeout, which plays
havoc with userspace scripts.

> OK, I suggest to stop this thread. I don't claim you are wrong, just
> we think differently ;)

That's fine, we can still "agree to disagree" here :-)

Cheers,
Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/