On Friday, 15 June 2007 13:31, Oleg Nesterov wrote:
> On 06/15, Rafael J. Wysocki wrote:
> >
> > +static void freeze_task(struct task_struct *p)
> > +{
> > if (!freezing(p)) {
> > rmb();
> > if (!frozen(p)) {
> > set_freeze_flag(p);
> > -
On 06/15, Rafael J. Wysocki wrote:
>
> +static void freeze_task(struct task_struct *p)
> +{
> if (!freezing(p)) {
> rmb();
> if (!frozen(p)) {
> set_freeze_flag(p);
> - if (p->state == TASK_STOPPED)
> -
On 06/15, Rafael J. Wysocki wrote:
+static void freeze_task(struct task_struct *p)
+{
if (!freezing(p)) {
rmb();
if (!frozen(p)) {
set_freeze_flag(p);
- if (p-state == TASK_STOPPED)
-
On Friday, 15 June 2007 13:31, Oleg Nesterov wrote:
On 06/15, Rafael J. Wysocki wrote:
+static void freeze_task(struct task_struct *p)
+{
if (!freezing(p)) {
rmb();
if (!frozen(p)) {
set_freeze_flag(p);
- if
On Thu, 2007-06-14 at 16:58 +0400, Oleg Nesterov wrote:
>
> > Well, the only code path in which we'd want to call cancel_freezing() for
> > kernel
> > threads is when the freezing of kernel threads. However, this only happens
> > if
> > one of the kernel threads declares itself as freezable
On Thursday, 14 June 2007 14:58, Oleg Nesterov wrote:
> On 06/14, Rafael J. Wysocki wrote:
> >
> > Sorry for being late, I've just realized that you are discussing the freezer
> > here. ;-)
>
> my fault, I was going to cc you but forgot, sorry!
No problem. :-)
> > On Wednesday, 13 June 2007
On 06/14, Rafael J. Wysocki wrote:
>
> Sorry for being late, I've just realized that you are discussing the freezer
> here. ;-)
my fault, I was going to cc you but forgot, sorry!
> On Wednesday, 13 June 2007 17:15, Oleg Nesterov wrote:
>
> > > @@ -105,7 +105,11 @@ static int
Sorry for being late, I've just realized that you are discussing the freezer
here. ;-)
On Wednesday, 13 June 2007 17:15, Oleg Nesterov wrote:
> Sorry for delay, I was completely offline,
>
> On 06/06, Roland McGrath wrote:
> >
> > [PATCH] Restrict clearing TIF_SIGPENDING
> >
> > This patch
Sorry for being late, I've just realized that you are discussing the freezer
here. ;-)
On Wednesday, 13 June 2007 17:15, Oleg Nesterov wrote:
Sorry for delay, I was completely offline,
On 06/06, Roland McGrath wrote:
[PATCH] Restrict clearing TIF_SIGPENDING
This patch should get a
On 06/14, Rafael J. Wysocki wrote:
Sorry for being late, I've just realized that you are discussing the freezer
here. ;-)
my fault, I was going to cc you but forgot, sorry!
On Wednesday, 13 June 2007 17:15, Oleg Nesterov wrote:
@@ -105,7 +105,11 @@ static int recalc_sigpending_tsk(struct
On Thursday, 14 June 2007 14:58, Oleg Nesterov wrote:
On 06/14, Rafael J. Wysocki wrote:
Sorry for being late, I've just realized that you are discussing the freezer
here. ;-)
my fault, I was going to cc you but forgot, sorry!
No problem. :-)
On Wednesday, 13 June 2007 17:15, Oleg
On Thu, 2007-06-14 at 16:58 +0400, Oleg Nesterov wrote:
Well, the only code path in which we'd want to call cancel_freezing() for
kernel
threads is when the freezing of kernel threads. However, this only happens
if
one of the kernel threads declares itself as freezable and the fails
> btw, another interesting grep is to see how tweak TIF_SIGPENDING by
> hand ... there's some scary bits in the tty code too...
All I see there are the calls just added recently by Oleg, which are
correct and necessary to fix a bug. Wrapping it in something less magical
might be nice. It is the
On Wed, 2007-06-13 at 16:01 -0700, Roland McGrath wrote:
>
> > What about something like:
> >
> > do {
> > rm_from_queue_full(, >pending);
> > - recalc_sigpending_and_wake(t);
> > t =
> The freezer is crap... news at 11. Maybe a quick hack would be to let it
> clear sigpending if tsk->mm == NULL but that's ugly. Note that there's
> anything pretty about the freezer anyway...
I think it might be made not too unreasonable by adding a TASK_FROZEN state.
But I am still persuaded
> This breaks cancel_freezing(). Somehow we should clear TIF_SIGPENDING for
> kernel threads. Otherwise we may have subtle failures if try_to_freeze_tasks()
> fails.
Ok.
> Also, whith this change do_sigaction()->recalc_sigpending_and_wake() doesn't
> make sense any longer, yes?
Yes. As we
On Wed, 2007-06-13 at 19:15 +0400, Oleg Nesterov wrote:
>
> This breaks cancel_freezing(). Somehow we should clear TIF_SIGPENDING
> for kernel threads. Otherwise we may have subtle failures if
> try_to_freeze_tasks() fails.
The freezer is crap... news at 11. Maybe a quick hack would be to let it
> HOWEVER: I'm still a bit worried about the fact that we have about ~180
> calls to "recalc_sigpending()" around the kernel, and I'm not AT ALL sure
> that they are all supposed to possibly clear the TIF_SIGPENDING flag.
Most of those calls are in arch or compat code's sigreturn, sigsuspend,
Sorry for delay, I was completely offline,
On 06/06, Roland McGrath wrote:
>
> [PATCH] Restrict clearing TIF_SIGPENDING
>
> This patch should get a few birds. It prevents sigaction calls from
> clearing TIF_SIGPENDING in other threads, which could leak -ERESTART*.
> It fixes ptrace_stop not to
Sorry for delay, I was completely offline,
On 06/06, Roland McGrath wrote:
[PATCH] Restrict clearing TIF_SIGPENDING
This patch should get a few birds. It prevents sigaction calls from
clearing TIF_SIGPENDING in other threads, which could leak -ERESTART*.
It fixes ptrace_stop not to clear
HOWEVER: I'm still a bit worried about the fact that we have about ~180
calls to recalc_sigpending() around the kernel, and I'm not AT ALL sure
that they are all supposed to possibly clear the TIF_SIGPENDING flag.
Most of those calls are in arch or compat code's sigreturn, sigsuspend, et
al
On Wed, 2007-06-13 at 19:15 +0400, Oleg Nesterov wrote:
This breaks cancel_freezing(). Somehow we should clear TIF_SIGPENDING
for kernel threads. Otherwise we may have subtle failures if
try_to_freeze_tasks() fails.
The freezer is crap... news at 11. Maybe a quick hack would be to let it
This breaks cancel_freezing(). Somehow we should clear TIF_SIGPENDING for
kernel threads. Otherwise we may have subtle failures if try_to_freeze_tasks()
fails.
Ok.
Also, whith this change do_sigaction()-recalc_sigpending_and_wake() doesn't
make sense any longer, yes?
Yes. As we discussed
The freezer is crap... news at 11. Maybe a quick hack would be to let it
clear sigpending if tsk-mm == NULL but that's ugly. Note that there's
anything pretty about the freezer anyway...
I think it might be made not too unreasonable by adding a TASK_FROZEN state.
But I am still persuaded by my
On Wed, 2007-06-13 at 16:01 -0700, Roland McGrath wrote:
What about something like:
do {
rm_from_queue_full(mask, t-pending);
- recalc_sigpending_and_wake(t);
t =
btw, another interesting grep is to see how tweak TIF_SIGPENDING by
hand ... there's some scary bits in the tty code too...
All I see there are the calls just added recently by Oleg, which are
correct and necessary to fix a bug. Wrapping it in something less magical
might be nice. It is the
Don't let signalfd dequeue private signals off other threads (in the
case of things like SIGILL or SIGSEGV, trying to do so would result
in undefined behaviour on who actually gets the signal, since they
are force unblocked).
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
Davide
Don't let signalfd dequeue private signals off other threads (in the
case of things like SIGILL or SIGSEGV, trying to do so would result
in undefined behaviour on who actually gets the signal, since they
are force unblocked).
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
Davide
On Thu, 2007-06-07 at 20:18 -0700, Linus Torvalds wrote:
>
> > Oh and Roland patch doesn't prevent signalfd() from stealing synchronous
> > signals such as SIGSEGV etc... which I think would result in random
> > behaviour do you want a patch for that or we just consider it broken
> > API
On Fri, 8 Jun 2007, Benjamin Herrenschmidt wrote:
>
> Looks good to me. Do you think we need to do something about the DRM
> notifier thingy too ?
No. I think that anybody who uses that gets whatever he deserves. It's
designed for one particular usage scenario (where it should work fine), if
Hi Linus,
At Thu, 7 Jun 2007 08:54:33 -0700 (PDT),
Linus Torvalds wrote:
>
>
>
> On Thu, 7 Jun 2007, Satoru Takeuchi wrote:
> >
> > I tested your patch and my problem didn't occur again, so it seems to my
> > this case at least.
>
> Ok. I applied Roland's slightly bigger patch instead, since
On Thu, 2007-06-07 at 08:54 -0700, Linus Torvalds wrote:
>
> On Thu, 7 Jun 2007, Satoru Takeuchi wrote:
> >
> > I tested your patch and my problem didn't occur again, so it seems to my
> > this case at least.
>
> Ok. I applied Roland's slightly bigger patch instead, since Ben and Paul
> pointed
On Thu, 7 Jun 2007, Satoru Takeuchi wrote:
>
> I tested your patch and my problem didn't occur again, so it seems to my
> this case at least.
Ok. I applied Roland's slightly bigger patch instead, since Ben and Paul
pointed out that some kernel threads depend on dequeue_signal clearing the
Hi Linus,
At Wed, 6 Jun 2007 08:35:27 -0700 (PDT),
Linus Torvalds wrote:
> On Wed, 6 Jun 2007, Roland McGrath wrote:
> >
> > [PATCH] Restrict clearing TIF_SIGPENDING
> >
> > This patch should get a few birds. It prevents sigaction calls from
> > clearing TIF_SIGPENDING in other threads, which
On Fri, 8 Jun 2007, Benjamin Herrenschmidt wrote:
Looks good to me. Do you think we need to do something about the DRM
notifier thingy too ?
No. I think that anybody who uses that gets whatever he deserves. It's
designed for one particular usage scenario (where it should work fine), if
Hi Linus,
At Thu, 7 Jun 2007 08:54:33 -0700 (PDT),
Linus Torvalds wrote:
On Thu, 7 Jun 2007, Satoru Takeuchi wrote:
I tested your patch and my problem didn't occur again, so it seems to my
this case at least.
Ok. I applied Roland's slightly bigger patch instead, since Ben and
On Thu, 2007-06-07 at 20:18 -0700, Linus Torvalds wrote:
Oh and Roland patch doesn't prevent signalfd() from stealing synchronous
signals such as SIGSEGV etc... which I think would result in random
behaviour do you want a patch for that or we just consider it broken
API usage and let
Hi Linus,
At Wed, 6 Jun 2007 08:35:27 -0700 (PDT),
Linus Torvalds wrote:
On Wed, 6 Jun 2007, Roland McGrath wrote:
[PATCH] Restrict clearing TIF_SIGPENDING
This patch should get a few birds. It prevents sigaction calls from
clearing TIF_SIGPENDING in other threads, which could leak
On Thu, 7 Jun 2007, Satoru Takeuchi wrote:
I tested your patch and my problem didn't occur again, so it seems to my
this case at least.
Ok. I applied Roland's slightly bigger patch instead, since Ben and Paul
pointed out that some kernel threads depend on dequeue_signal clearing the
bit.
On Thu, 2007-06-07 at 08:54 -0700, Linus Torvalds wrote:
On Thu, 7 Jun 2007, Satoru Takeuchi wrote:
I tested your patch and my problem didn't occur again, so it seems to my
this case at least.
Ok. I applied Roland's slightly bigger patch instead, since Ben and Paul
pointed out that
On Wed, 2007-06-06 at 08:35 -0700, Linus Torvalds wrote:
> So now we should do "recalc_sigpending()" only when signals may be
> *added*
> (where messing with the "blocked" mask obviously is a form of adding
> signals, and possibly the most common reason for having to recalculate
> the
>
On Wed, 2007-06-06 at 08:35 -0700, Linus Torvalds wrote:
>
> So I think that the *right* place to clear TIF_SIGPENDING is actually in
> "get_signal_to_deliver()", because that function is called _only_ by the
> actual per-architecture "I'm going to deliver a signal now".
That was my initial
On Wed, 2007-06-06 at 03:59 -0700, Roland McGrath wrote:
> Oleg and I were just discussing this issue in relation to other problems.
> We established that it is never safe to clear TIF_SIGPENDING on another
> thread. But I hadn't really thought through that it's sometimes not safe
> to clear your
Linus Torvalds writes:
> So I think that the *right* place to clear TIF_SIGPENDING is actually in
> "get_signal_to_deliver()", because that function is called _only_ by the
> actual per-architecture "I'm going to deliver a signal now".
I agree that's the right place for real user processes,
On Wed, 6 Jun 2007, Roland McGrath wrote:
>
> [PATCH] Restrict clearing TIF_SIGPENDING
>
> This patch should get a few birds. It prevents sigaction calls from
> clearing TIF_SIGPENDING in other threads, which could leak -ERESTART*.
> It fixes ptrace_stop not to clear it, which done at the
Oleg and I were just discussing this issue in relation to other problems.
We established that it is never safe to clear TIF_SIGPENDING on another
thread. But I hadn't really thought through that it's sometimes not safe
to clear your own TIF_SIGPENDING either. That is, any time you are not
Oleg and I were just discussing this issue in relation to other problems.
We established that it is never safe to clear TIF_SIGPENDING on another
thread. But I hadn't really thought through that it's sometimes not safe
to clear your own TIF_SIGPENDING either. That is, any time you are not
On Wed, 6 Jun 2007, Roland McGrath wrote:
[PATCH] Restrict clearing TIF_SIGPENDING
This patch should get a few birds. It prevents sigaction calls from
clearing TIF_SIGPENDING in other threads, which could leak -ERESTART*.
It fixes ptrace_stop not to clear it, which done at the syscall
Linus Torvalds writes:
So I think that the *right* place to clear TIF_SIGPENDING is actually in
get_signal_to_deliver(), because that function is called _only_ by the
actual per-architecture I'm going to deliver a signal now.
I agree that's the right place for real user processes, but I
On Wed, 2007-06-06 at 03:59 -0700, Roland McGrath wrote:
Oleg and I were just discussing this issue in relation to other problems.
We established that it is never safe to clear TIF_SIGPENDING on another
thread. But I hadn't really thought through that it's sometimes not safe
to clear your own
On Wed, 2007-06-06 at 08:35 -0700, Linus Torvalds wrote:
So I think that the *right* place to clear TIF_SIGPENDING is actually in
get_signal_to_deliver(), because that function is called _only_ by the
actual per-architecture I'm going to deliver a signal now.
That was my initial idea but
On Wed, 2007-06-06 at 08:35 -0700, Linus Torvalds wrote:
So now we should do recalc_sigpending() only when signals may be
*added*
(where messing with the blocked mask obviously is a form of adding
signals, and possibly the most common reason for having to recalculate
the
sigpending mask).
Hi,
If there is a multithread process which is waiting on restartable syscall
and ptraced, some threads may return from syscalls with a errno which should
never be seen by user programs when they receive SIGSTOP. It is not a rare
case beacuse strace send SIGSTOP to attached process on its exit
Hi,
If there is a multithread process which is waiting on restartable syscall
and ptraced, some threads may return from syscalls with a errno which should
never be seen by user programs when they receive SIGSTOP. It is not a rare
case beacuse strace send SIGSTOP to attached process on its exit
54 matches
Mail list logo
