[pull] master from linux-nvme:master#240
Merged
Merged
Conversation
The nvme_registry_test.py integration test still drove the original registry CLI: device passed via -d, retrieve defaulting its attribute to owner, and writing owner rejected as immutable. The CLI was since reworked -- the device is a positional argument, retrieve and update require --attr, and changing ownership is gated by an interactive confirmation that proceeds for non-interactive callers instead of being refused. The test had drifted out of sync and failed once CI began running it. Switch every invocation to the positional device form, drop the no-longer-valid "default attr is owner" case, and replace the "owner is rejected" case with one asserting a non-interactive owner write succeeds. Run the nvme binary with stdin connected to /dev/null so the confirmation prompt deterministically takes the non-interactive path. Signed-off-by: Martin Belanger <martin.belanger@dell.com>
The build matrix runs the test suite under valgrind (build.sh -x), which skips the fork-based tests: the python multiprocessing registry test is @unittest.skipIf(_under_valgrind), because forked children misbehave under valgrind. Nothing else exercised that path, so a regression in it -- for example Python 3.14 making forkserver the default multiprocessing start method -- could land unnoticed. Add a single job that builds on ghcr.io/linux-nvme/fedora:latest and runs the suite without valgrind (no -x), so the skipped tests execute. Fedora tracks the newest Python, where interpreter-default changes surface before the other CI distros. Signed-off-by: Martin Belanger <martin.belanger@dell.com>
Run the analyzer workflow inside the Fedora container image instead of the Debian image. Fedora ships a newer Clang Static Analyzer release, allowing the workflow to use the latest analyzer improvements. Signed-off-by: Nilay Shroff <nilay@linux.ibm.com>
When processing discovery log entries, _nvmf_discovery() may recurse
into another discovery service after successfully creating a child
discovery controller via nvmf_connect_disc_entry().
However, the recursive discovery path is currently guarded by:
if (!child) {
...
_nvmf_discovery(ctx, &nfctx, true, child);
...
}
which is the opposite of what is intended. The recursion is only
attempted when @child is NULL, while the recursive call expects a
valid @child pointer. Here @child is a pointer to libnvme controller.
As a result, _nvmf_discovery() may be invoked with a NULL @child
argument and subsequently dereference it.
Fix this by inverting the condition so that recursive discovery and
the associated cleanup logic are only executed when a valid child
controller has been created.
This issue was reported by the clang static analyzer.
Signed-off-by: Sarah Ahmed <sarah.ahmed@ibm.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )