Merging upstream version 2.3~rc5.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 1 insertions, 0 deletions

diff --git a/NEWS.md b/NEWS.md
index 7404015..b7abb7c 100644
--- a/NEWS.md
+++ b/NEWS.md
@@ -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