Skip to content
  • Julien Grall's avatar
    lib/ubsan: don't serialize UBSAN report · ce5c31db
    Julien Grall authored
    At the moment, UBSAN report will be serialized using a spin_lock().  On
    RT-systems, spinlocks are turned to rt_spin_lock and may sleep.  This
    will result to the following splat if the undefined behavior is in a
    context that can sleep:
    
      BUG: sleeping function called from invalid context at /src/linux/kernel/locking/rtmutex.c:968
      in_atomic(): 1, irqs_disabled(): 128, pid: 3447, name: make
      1 lock held by make/3447:
       #0: 000000009a966332 (&mm->mmap_sem){++++}, at: do_page_fault+0x140/0x4f8
      irq event stamp: 6284
      hardirqs last  enabled at (6283): [<ffff000011326520>] _raw_spin_unlock_irqrestore+0x90/0xa0
      hardirqs last disabled at (6284): [<ffff0000113262b0>] _raw_spin_lock_irqsave+0x30/0x78
      softirqs last  enabled at (2430): [<ffff000010088ef8>] fpsimd_restore_current_state+0x60/0xe8
      softirqs last disabled at (2427): [<ffff000010088ec0>] fpsimd_restore_current_state+0x28/0xe8
      Preemption disabled at:
      [<ffff000011324a4c>] rt_mutex_futex_unlock+0x4c/0xb0
      CPU: 3 PID: 3447 Comm: make Tainted: G        W         5.2.14-rt7-01890-ge6e057589653 #911
      Call trace:
        dump_backtrace+0x0/0x148
        show_stack+0x14/0x20
        dump_stack+0xbc/0x104
        ___might_sleep+0x154/0x210
        rt_spin_lock+0x68/0xa0
        ubsan_prologue+0x30/0x68
        handle_overflow+0x64/0xe0
        __ubsan_handle_add_overflow+0x10/0x18
        __lock_acquire+0x1c28/0x2a28
        lock_acquire+0xf0/0x370
        _raw_spin_lock_irqsave+0x58/0x78
        rt_mutex_futex_unlock+0x4c/0xb0
        rt_spin_unlock+0x28/0x70
        get_page_from_freelist+0x428/0x2b60
        __alloc_pages_nodemask+0x174/0x1708
        alloc_pages_vma+0x1ac/0x238
        __handle_mm_fault+0x4ac/0x10b0
        handle_mm_fault+0x1d8/0x3b0
        do_page_fault+0x1c8/0x4f8
        do_translation_fault+0xb8/0xe0
        do_mem_abort+0x3c/0x98
        el0_da+0x20/0x24
    
    The spin_lock() will protect against multiple CPUs to output a report
    together, I guess to prevent them from being interleaved.  However, they
    can still interleave with other messages (and even splat from
    __might_sleep).
    
    So the lock usefulness seems pretty limited.  Rather than trying to
    accomodate RT-system by switching to a raw_spin_lock(), the lock is now
    completely dropped.
    
    Link: http://lkml.kernel.org/r/20190920100835.14999-1-julien.grall@arm.com
    
    
    Signed-off-by: default avatarJulien Grall <julien.grall@arm.com>
    Reported-by: default avatarAndre Przywara <andre.przywara@arm.com>
    Acked-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    ce5c31db