• Steven Rostedt's avatar
    preempt-count: force hardirq-count to max of 10 · 5a5fb7db
    Steven Rostedt authored
    To add a bit in the preempt_count to be set when in NMI context, we
    found that some archs did not have enough bits to spare. This is
    due to the hardirq_count being a mask that can hold NR_IRQS.
    
    Some archs allow for over 16000 IRQs, and that would require a mask
    of 14 bits. The sofitrq mask is 8 bits and the preempt disable mask
    is also 8 bits.  The PREEMP_ACTIVE bit is bit 30, and bit 31 would
    make the preempt_count (which is type int) a negative number.
    A negative preempt_count is a sign of failure.
    
    Add them up 14+8+8+1+1 you get 32 bits. No room for the NMI bit.
    
    But the hardirq_count is to track the number of nested IRQs, not
    the number of total IRQs.  This originally took the paranoid approach
    of setting the max nesting to NR_IRQS. But when we have archs with
    over 1000 IRQs, it is not practical to think they will ever all
    nest on a single CPU. Not to mention that this would most definitely
    cause a stack overflow.
    
    This patch sets a max of 10 bits to be used for IRQ nesting.
    I did a 'git grep HARDIRQ' to examine all users of HARDIRQ_BITS and
    HARDIRQ_MASK, and found that making it a max of 10 would not hurt
    anyone. I did find that the m68k expected it to be 8 bits, so
    I allow for the archs to set the number to be less than 10.
    
    I removed the setting of HARDIRQ_BITS from the archs that set it
    to more than 10. This includes ALPHA, ia64 and avr32.
    
    This will always allow room for the NMI bit, and if we need to allow
    for NMI nesting, we have 4 bits to play with.
    Signed-off-by: default avatarSteven Rostedt <srostedt@redhat.com>
    5a5fb7db
hardirq.h 485 Bytes