• Baegjae Sung's avatar
    nvme-multipath: fix sysfs dangerously created links · 9bd82b1a
    Baegjae Sung authored
    If multipathing is enabled, each NVMe subsystem creates a head
    namespace (e.g., nvme0n1) and multiple private namespaces
    (e.g., nvme0c0n1 and nvme0c1n1) in sysfs. When creating links for
    private namespaces, links of head namespace are used, so the
    namespace creation order must be followed (e.g., nvme0n1 ->
    nvme0c1n1). If the order is not followed, links of sysfs will be
    incomplete or kernel panic will occur.
    
    The kernel panic was:
      kernel BUG at fs/sysfs/symlink.c:27!
      Call Trace:
        nvme_mpath_add_disk_links+0x5d/0x80 [nvme_core]
        nvme_validate_ns+0x5c2/0x850 [nvme_core]
        nvme_scan_work+0x1af/0x2d0 [nvme_core]
    
    Correct order
    Context A     Context B
    nvme0n1
    nvme0c0n1     nvme0c1n1
    
    Incorrect order
    Context A     Context B
                  nvme0c1n1
    nvme0n1
    nvme0c0n1
    
    The nvme_mpath_add_disk (for creating head namespace) is called
    just before the nvme_mpath_add_disk_links (for creating private
    namespaces). In nvme_mpath_add_disk, the first context acquires
    the lock of subsystem and creates a head namespace, and other
    contexts do nothing by checking GENHD_FL_UP of a head namespace
    after waiting to acquire the lock. We verified the code with or
    without multipathing using three vendors of dual-port NVMe SSDs.
    Signed-off-by: default avatarBaegjae Sung <baegjae@gmail.com>
    Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
    Signed-off-by: default avatarKeith Busch <keith.busch@intel.com>
    9bd82b1a
multipath.c 6.74 KB