Yeah, I knowingly glossed over freezer. I don't really want to think about
it. There are more problems than just this with how it goes about it, but
I'd rather leave that alone until it really bites us.
Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On 05/29, Roland McGrath wrote:
>
> Your fix seems like the only way to go. From skimming all the ERESTART*
> uses, I think that in all cases (except for n_tty.c:job_control before your
> patch), TIF_SIGPENDING is indeed set when a thread returns -ERESTART*.
>
> But it makes me realize that there
Hi Andrew,
> What kernel versions is this occurring on?
2.6.22-rc3 is.
Satoru
At Tue, 29 May 2007 01:03:15 -0700,
Andrew Morton wrote:
>
> On Mon, 28 May 2007 11:32:00 +0900 Satoru Takeuchi <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I found a bug on signal subsystem. If there is some multi
Off hand I think it can happen on all 2.6 kernels in theory.
-
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/
On Mon, 28 May 2007 11:32:00 +0900 Satoru Takeuchi <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I found a bug on signal subsystem. If there is some multithread program
> and one of the thread is blocking on the system call, it returns with
> wrong errno on receiving SIGSTOP and following SIGCONT.
>
> Ar
Your fix seems like the only way to go. From skimming all the ERESTART*
uses, I think that in all cases (except for n_tty.c:job_control before your
patch), TIF_SIGPENDING is indeed set when a thread returns -ERESTART*.
But it makes me realize that there is a danger of leaking a -ERESTART*
return
On 05/28, Satoru Takeuchi wrote:
>
> At Mon, 28 May 2007 11:07:53 +0400,
> Oleg Nesterov wrote:
> >
> > drivers/char/n_tty.c:job_control()
> >
> > kill_pgrp(task_pgrp(current), SIGTTIN, 1);
> > return -ERESTARTSYS;
> >
> > This is wrong. kill_pgrp()->__group_send_sig
Hi Oleg,
At Mon, 28 May 2007 11:07:53 +0400,
Oleg Nesterov wrote:
>
> Satoru Takeuchi wrote:
> >
> > I found a bug on signal subsystem. If there is some multithread program
> > and one of the thread is blocking on the system call, it returns with
> > wrong errno on receiving SIGSTOP and following
Satoru Takeuchi wrote:
>
> I found a bug on signal subsystem. If there is some multithread program
> and one of the thread is blocking on the system call, it returns with
> wrong errno on receiving SIGSTOP and following SIGCONT.
It doesn't matter in this particular case, but in general it is good
Hi,
I found a bug on signal subsystem. If there is some multithread program
and one of the thread is blocking on the system call, it returns with
wrong errno on receiving SIGSTOP and following SIGCONT.
Arch dependency
===
succeed to reproduce: i386, ia64
Unknown: any oth
10 matches
Mail list logo
