On 2017-11-27 12:16:36 [+0530], Sam Kappen wrote: > Hi, Hi, > 1.) > I had derived and tried a patch based on the below analysis. > ( I referred below open source commit, to derive on this patch. > https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/commit/?h=v4.9.47-rt37-rebase&id=7a347757f027190c95a363a491c18156a926a370 > ) > > In some cases pi_lock in rt_spin_lock_slowlock does not retain the > irqs state while exiting function, this causes > issue in migrate_disable() + enable as they are not symmetrical in > regard to the status of interrupts. > To fix pi_lock & pi_unlock in rt_spin_lock_slowlock, it has been > modified to retain irq state by using > raw_spin_lock and raw_spin_unlock and also modified wait_lock in > rt_spin_lock_slowlock with raw_spin_lock_irqsave & *_restore. Can you provide more informations on this? Like a stack strace that shows that this happens and when it happens? It should not happen. … > We were testing above patch on multiple targets we could experience > some stuck issue on some remote target after 2 days. I am not > sure what really happens there, may be the issue when try for > scheduling with irq in disabled state. > The systems I have tested found to be worked 7 days after that I > stopped the test. Which patch? The patch I've sent and ask you for testing or the patch you had in this email? > > 2.) With your patch during the slab allocations irqs will be in enabled state. > So if we enable irqs in early stage will there be any side effects? I > am sorry if my question doesn't seem > to be logical. You must not enable the interrupts too early. At the time of scheduling it is okay. > Regards, > Sam Sebastian -- 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
