Re: [tip:x86/asm] x86/entry: Add new, comprehensible entry and exit handlers written in C

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 15, 2015 at 12:56 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Jul 14, 2015 at 4:07 PM, Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote:
>> On Tue, Jul 07, 2015 at 03:51:48AM -0700, tip-bot for Andy Lutomirski wrote:
>>> +     while (true) {
>>> +             u32 cached_flags =
>>> +                     READ_ONCE(pt_regs_to_thread_info(regs)->flags);
>>> +
>>> +             if (!(cached_flags & (_TIF_SIGPENDING | _TIF_NOTIFY_RESUME |
>>> +                                   _TIF_UPROBE | _TIF_NEED_RESCHED)))
>>> +                     break;
>>> +
>>> +             /* We have work to do. */
>>> +             local_irq_enable();
>>> +
>>> +             if (cached_flags & _TIF_NEED_RESCHED)
>>> +                     schedule();
>>> +
>>> +             if (cached_flags & _TIF_UPROBE)
>>> +                     uprobe_notify_resume(regs);
>>> +
>>> +             /* deal with pending signal delivery */
>>> +             if (cached_flags & _TIF_SIGPENDING)
>>> +                     do_signal(regs);
>>> +
>>> +             if (cached_flags & _TIF_NOTIFY_RESUME) {
>>> +                     clear_thread_flag(TIF_NOTIFY_RESUME);
>>> +                     tracehook_notify_resume(regs);
>>> +             }
>>> +
>>> +             if (cached_flags & _TIF_USER_RETURN_NOTIFY)
>>> +                     fire_user_return_notifiers();
>>> +
>>> +             /* Disable IRQs and retry */
>>> +             local_irq_disable();
>>> +     }
>>
>> I dreamed so many times about this loop in C!
>
> So this made me look at it again, and now I'm worried.
>
> There's that "early break", but it doesn't check
> _TIF_USER_RETURN_NOTIFY. So if *only* USER_RETURN_NOTIFY is set, we're
> screwed.

Crap, that's a bug.  I'll send a patch.

>
> It migth be that that doesn't happen for some reason, but I'm not
> seeing what that reason would be.
>
> The other thing that worries me is that this depends on all the
> handler routines to clear the flags (except for
> tracehook_notify_resume()). Which they hopefully do. But that means
> that just looking at this locally, it's not at all obvious that it
> works right.

The old do_notify_resume work loop worked more or less the same way,
so we should be okay here.  See below.

>
> So wouldn't it be much nicer to do:
>
>         u32 cached_flags = READ_ONCE(pt_regs_to_thread_info(regs)->flags);
>
>         cached_flags &= _TIF_SIGPENDING | _TIF_NOTIFY_RESUME |
> _TIF_USER_RETURN_NOTIFY | _TIF_UPROBE | _TIF_NEED_RESCHED;
>
>         if (!cached_flags)
>                 break;
>
>         atomic_clear_mask(cached_flags, &pt_regs_to_thread_info(regs)->flags);
>
> and then have those bit tests after that?
>

Yes, but it would be a slowdown unless we converted all the various
handlers stopped clearing the bits separately (two atomics instead of
one).  And to do that, we'd probably want to change all the arches,

Signal handling has all the recalc_sigpending stuff.  schedule() had
better clear TIF_NEED_RESCHED.  fire_user_return_notifiers is totally
absurd but it does clear the bit.  uprobes clears the bit directly.

I'd be all for changing this, but coordinating with the generic code
could be annoying.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Stable Commits]     [Linux Stable Kernel]     [Linux Kernel]     [Linux USB Devel]     [Linux Video &Media]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux