Hi Oleg,
On 6/28/07, 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_
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, th
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_rcvt
On 6/28/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
[...]
[ BTW even there
we're safe as long as we check kthread_stop() _before_ flushing or
^^
Whoops, that should have been "kthread_should_stop()".
dequeueing the signals, but then that'll be an u
On 6/28/07, Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> [...]
> Hmm... actually, such a change breaks the
>
> while (signal_pending(current))
> dequeue_signal_and_so_something();
>
> loop, see jffs2_garbage_collect_thread() for example.
BTW jffs2_garbage_collect_thread() i
On 6/28/07, Oleg Nesterov <[EMAIL PROTECTED]> wrote:
(trimmed the cc: list)
On 06/28, Satyam Sharma wrote:
> On 6/27/07, Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> >
> >Contrary, I believe we should avoid signals when it
> >comes to kernel threads.
>
> And I agree, but there's quite a subtle diff
(trimmed the cc: list)
On 06/28, Satyam Sharma wrote:
>
> On 6/27/07, Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> >
> >Contrary, I believe we should avoid signals when it
> >comes to kernel threads.
>
> And I agree, but there's quite a subtle difference between signals being
> used like they normal
Hi Oleg,
On 6/27/07, Oleg Nesterov <[EMAIL PROTECTED]> wrote:
On 06/27, Satyam Sharma wrote:
>
> Thanks for your comments, I'm still not convinced, however.
An perhaps you are right. I don't have a very strong opinion on that.
Still I can't understand why it is better if kthread_stop() sends a
On 06/27, Satyam Sharma wrote:
>
> Thanks for your comments, I'm still not convinced, however.
An perhaps you are right. I don't have a very strong opinion on that.
Still I can't understand why it is better if kthread_stop() sends a
signal as well. Contrary, I believe we should avoid signals when
On 6/27/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
[...]
On 6/26/07, Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> On 06/26, Satyam Sharma wrote:
[...]
> > So could we have signals in _addition_ to kthread_stop_info and change
> > kthread_should_stop() to check for both:
> >
> > kthread_stop_info.
Hi Oleg,
Thanks for your comments, I'm still not convinced, however.
On 6/26/07, Oleg Nesterov <[EMAIL PROTECTED]> wrote:
On 06/26, Satyam Sharma wrote:
>
> Yes, why not embed a send_sig(SIGKILL) just before the wake_up_process()
> in kthread_stop() itself?
Personally, I don't think we should
On 06/26, Satyam Sharma wrote:
>
> Yes, why not embed a send_sig(SIGKILL) just before the wake_up_process()
> in kthread_stop() itself?
Personally, I don't think we should do this.
kthread_stop() doesn't always mean "kill this thread asap". Suppose that
CPU_DOWN does kthread_stop(workqueue->thre
On Tue, 26 Jun 2007 03:39:23 +0530
"Satyam Sharma" <[EMAIL PROTECTED]> wrote:
> Hi Jeff,
>
> [ Trimmed netdev from Cc: list, added Christoph. ]
>
> On 6/26/07, Jeff Layton <[EMAIL PROTECTED]> wrote:
> > On Tue, 26 Jun 2007 01:11:20 +0530
> > "Satyam Sharma" <[EMAIL PROTECTED]> wrote:
> > > [...]
Hi Jeff,
[ Trimmed netdev from Cc: list, added Christoph. ]
On 6/26/07, Jeff Layton <[EMAIL PROTECTED]> wrote:
On Tue, 26 Jun 2007 01:11:20 +0530
"Satyam Sharma" <[EMAIL PROTECTED]> wrote:
> [...]
> Yes, why not embed a send_sig(SIGKILL) just before the wake_up_process()
> in kthread_stop() its
On Tue, 26 Jun 2007 01:11:20 +0530
"Satyam Sharma" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On 6/9/07, Jeff Layton <[EMAIL PROTECTED]> wrote:
> > On Sat, 09 Jun 2007 11:30:04 +1000
> > Herbert Xu <[EMAIL PROTECTED]> wrote:
> >
> > > Please cc networking patches to [EMAIL PROTECTED]
> > >
> > > Jeff L
Hi,
On 6/9/07, Jeff Layton <[EMAIL PROTECTED]> wrote:
On Sat, 09 Jun 2007 11:30:04 +1000
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Please cc networking patches to [EMAIL PROTECTED]
>
> Jeff Layton <[EMAIL PROTECTED]> wrote:
> >
> > The following patch is a first stab at removing this need. It mak
On Sat, 09 Jun 2007 11:30:04 +1000
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Please cc networking patches to [EMAIL PROTECTED]
>
> Jeff Layton <[EMAIL PROTECTED]> wrote:
> >
> > The following patch is a first stab at removing this need. It makes it
> > so that in tcp_recvmsg() we also check kthrea
Please cc networking patches to [EMAIL PROTECTED]
Jeff Layton <[EMAIL PROTECTED]> wrote:
>
> The following patch is a first stab at removing this need. It makes it
> so that in tcp_recvmsg() we also check kthread_should_stop() at any
> point where we currently check to see if the task was signall
18 matches
Mail list logo
