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 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
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:1
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
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 shou
> 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(&mask, &t->pending);
> > - recalc_sigpending_and_wake(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 by
> 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 discu
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, e
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
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 a
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
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
bit.
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 c
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
> sigpendi
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 ide
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, but
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 sysc
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
positiv
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 (e.
27 matches
Mail list logo
