>> Does the hardirq handler need to do something to make the TI_flags >> work properly against _TIF_WORK_MASK ? _TIF_WORK_MASK doesn't >> include TIF_NEED_RESCHED so it seems that this wouldn't be the right >> way to do it? > > To be honest I was puzzled for a second by that mysel after reading > your mail, but you got tricked by really obfuscated macro magic: > Ok that was a silly miss, sorry about the confusion. Just curious, what is the rationale for irq_default_primary_handler() not to invoke set_need_resched()? Drivers that set up with plain-old request_irq() will have a scheduled softirq handler, but the hardirq will return to wherever it was without the priority of the softirq task coming into play. For my drivers I can work around it with request_threaded_irq() but is the potential inversion for request_irq()-installed handlers really the expected behavior? Sorry if this question has been gone over before, I couldn't find anything with a quick search of the archives. -burns -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
