Skip to content

Commit

Permalink
Merge pull request #388 from martin-belanger/udev-test-for-tp8013
Browse files Browse the repository at this point in the history
udev: Fix subsysnqn comparison (TP8013)
  • Loading branch information
martin-belanger authored Aug 23, 2023
2 parents 71ab506 + 6b5e6a7 commit a8dfc5b
Show file tree
Hide file tree
Showing 3 changed files with 10 additions and 7 deletions.
1 change: 1 addition & 0 deletions NEWS.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,7 @@ Bug fixes:
* Udev event handling: use `systemctl restart` instead of `systemctl start`. There is a small chance that a `start` operation has not completed when a new `start` is required. Issuing a `start` while a `start` is being performed has no effect. However, a `restart` will be handled properly.
* `stafd`: Do not delete and recreate DC objects on kernel events indicating that an nvme device associated to a discovery controller was removed by the kernel. This was done to kick start the reconnect process, but was also causing the DLPE (Discovery Log Page Entries) cache to be lost. This could potentially result in `stacd` disconnecting from I/O controllers. Instead, keep the existing DC object which contains a valid DLPE cache and simply restart the "retry to connect" timer. This way the DLPE cache is maintained throughout the reconnect to DC process.
* While testing Boot from SAN (BFS) and using a Host NQN during boot that is different from the Host NQN used after boot (i.e. the Host NQN defined in `/etc/nvme/hostnqn`), we found that nvme-stas and libnvme are reusing existing connections even if the Host NQN doesn't match. nvme-stas will now take a connection's Host NQN into consideration before deciding if a connection can be reused. A similar fix will be provided in libnvme as well.
* `Udev._cid_matches_tid()` - When checking `subsysnqn`, take well-known NQN (`nqn.2014-08.org.nvmexpress.discovery`) into account. Per TP8013, Discovery Controllers may use a unique NQN instead of the well-known NQN. This can cause a discrepancy between the candidate connection DC and existing connections and cause a matching existing connection to fail to match the candidate connection.

## Changes with release 2.2.3

Expand Down
2 changes: 1 addition & 1 deletion meson.build
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@
project(
'nvme-stas',
meson_version: '>= 0.53.0',
version: '2.3-rc4',
version: '2.3-rc5',
license: 'Apache-2.0',
default_options: [
'buildtype=release',
Expand Down
14 changes: 8 additions & 6 deletions staslib/udev.py
Original file line number Diff line number Diff line change
Expand Up @@ -251,12 +251,14 @@ def _cid_matches_tid(tid, cid, ifaces): # pylint: disable=too-many-return-stat
6.1.
'''
# 'transport', 'traddr', 'trsvcid', 'subsysnqn', and 'host-nqn' must exactly match.
if (
cid['transport'] != tid.transport
or cid['trsvcid'] != tid.trsvcid
or cid['subsysnqn'] != tid.subsysnqn
or cid['host-nqn'] != tid.host_nqn
):
if tid.transport != cid['transport'] or tid.trsvcid != cid['trsvcid'] or tid.host_nqn != cid['host-nqn']:
return False

# With TP8013, Discovery Controllers may respond with a unique NQN even
# when a connection request is made with the well-known NQN. Therefore,
# the subsysnqn is not reliable when the candidate requests the well-
# known NQN.
if tid.subsysnqn not in (defs.WELL_KNOWN_DISC_NQN, cid['subsysnqn']):
return False

if tid.transport in ('tcp', 'rdma'):
Expand Down

0 comments on commit a8dfc5b

Please sign in to comment.