On Thu, 7 Apr 2016, Jessica Yu wrote: > Been sort of rattling my head over the scheduler code :-) Just following > the calls in and out of __schedule() it doesn't look like there is a > current flag/mechanism to tell whether or not a task has been > preempted.. Performing the complete stack unwind just to determine whether task has been preempted non-volutarily is a slight overkill indeed :/ > Is there any reason why you didn't just create a new task flag, > something like TIF_PREEMPTED_IRQ, which would be set once > preempt_schedule_irq() is entered and unset after __schedule() returns > (for that task)? This would roughly correspond to setting the task flag > when the frame for preempt_schedule_irq() is pushed and unsetting it > just before the frame preempt_schedule_irq() is popped for that task. > This seems simpler than walking through all the frames just to see if > in_preempt_schedule_irq() had been called. Would that work? Alternatively, without eating up a TIF_ space, it'd be possible to push a magic contents on top of the stack in preempt_schedule_irq() (and pop it once we are returning from there), and if such magic value is detected, we just don't bother and claim unreliability. That has advantages of both aproaches combined, i.e. it's relatively low-cost in terms of performance penalty, and it's reliable (in a sense that you don't have false positives). The small disadvantage is that you can (very rarely, depending on the chosen magic) have false negatives. That probably doesn't hurt too much, given the high inprobability and non-lethal consequences. How does that sound? -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
