• Yang Yingliang's avatar
    genirq/irqdesc: Don't try to remove non-existing sysfs files · 9049e1ca
    Yang Yingliang authored
    Fault injection tests trigger warnings like this:
    
      kernfs: can not remove 'chip_name', no directory
      WARNING: CPU: 0 PID: 253 at fs/kernfs/dir.c:1616 kernfs_remove_by_name_ns+0xce/0xe0
      RIP: 0010:kernfs_remove_by_name_ns+0xce/0xe0
      Call Trace:
       <TASK>
       remove_files.isra.1+0x3f/0xb0
       sysfs_remove_group+0x68/0xe0
       sysfs_remove_groups+0x41/0x70
       __kobject_del+0x45/0xc0
       kobject_del+0x29/0x40
       free_desc+0x42/0x70
       irq_free_descs+0x5e/0x90
    
    The reason is that the interrupt descriptor sysfs handling does not roll
    back on a failing kobject_add() during allocation. If the descriptor is
    freed later on, kobject_del() is invoked with a not added kobject resulting
    in the above warnings.
    
    A proper rollback in case of a kobject_add() failure would be the straight
    forward solution. But this is not possible due to the way how interrupt
    descriptor sysfs handling works.
    
    Interrupt descriptors are allocated before sysfs becomes available. So the
    sysfs files for the early allocated descriptors are added later in the boot
    process. At this point there can be nothing useful done about a failing
    kobject_add(). For consistency the interrupt descriptor allocation always
    treats kobject_add() failures as non-critical and just emits a warning.
    
    To solve this problem, keep track in the interrupt descriptor whether
    kobject_add() was successful or not and make the invocation of
    kobject_del() conditional on that.
    
    [ tglx: Massage changelog, comments and use a state bit. ]
    
    Fixes: ecb3f394 ("genirq: Expose interrupt information through sysfs")
    Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20221128151612.1786122-1-yangyingliang@huawei.com
    9049e1ca
irqdesc.c 23.7 KB