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] [day] [month] [year] [list]

Message-ID: <a781481a0706281222l6bd21c9fgda1554db97825514@mail.gmail.com>
Date:	Fri, 29 Jun 2007 00:52:56 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Oleg Nesterov" <oleg@...sign.ru>
Cc:	"Jeff Layton" <jlayton@...hat.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

Hi Oleg,

On 6/28/07, 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.

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/