Commit Graph

4 Commits

Author SHA1 Message Date
Josh Soref
c9c7c281f8 spelling: test
Part of #2256

* achieve
* additionally
* against
* aliases
* already
* another
* arguments
* between
* capabilities
* comparison
* compatibility
* configuration
* continuing
* controlq
* cpumask
* default
* depends
* dereferenced
* discussed
* dissect
* driver
* environment
* everything
* excluded
* existing
* expectation
* failed
* fails
* following
* functions
* hugepages
* identifiers
* implicitly
* in_capsule
* increment
* initialization
* initiator
* integrity
* iteration
* latencies
* libraries
* management
* namespace
* negotiated
* negotiation
* nonexistent
* number
* occur
* occurred
* occurring
* offsetting
* operations
* outstanding
* overwhelmed
* parameter
* parameters
* partition
* preempts
* provisioned
* responded
* segment
* skipped
* struct
* subsystem
* success
* successfully
* sufficiently
* this
* threshold
* transfer
* transferred
* unchanged
* unexpected
* unregistered
* useless
* utility
* value
* variable
* workload

Change-Id: I21ca7dab4ef575b5767e50aaeabc34314ab13396
Signed-off-by: Josh Soref <jsoref@gmail.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/10409
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
2021-12-03 08:13:22 +00:00
Alexey Marchuk
97385af196 nvmf: Fix double controller destruction when subsys is deleted
When a subsystem is being deleted, we disconnect all qpairs
and when the last qpair for some controller is disconnected,
we start controller desctruction process. This process requires
to send a message to subsystem's thread to remove the controller
from the list in the subsystem and after that send a message to
controller's thread to release resources.
The problem is that the subsystem also destroys all attached
controllers. This order is unpredictable and we may get
heap-use-after-free or double free.

To fix this problem we can rely on the fact that the subsystem
can only be destroyed in incative state, that means that all
qpairs linked to the subsystem are already disconnected and
all controllers are already destroyed or in the process of
destruction.

spdk_nvmf_subsystem_destroy API is now can be asyncrhonous,
it accepts a callback with cb argument.

Change-Id: Ic72d69200bc8302dae2f8cd8ca44bc640c6a8116
Signed-off-by: Alexey Marchuk <alexeymar@mellanox.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/6660
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Community-CI: Mellanox Build Bot
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
2021-09-08 08:04:04 +00:00
Jim Harris
1763a126cc test: optimize unit test .gitignore files
Just add a single .gitignore file in test/unit
that covers *_ut.  That allows us to eliminate
100 .gitignore files in the test/unit directory
hierarchy.

Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: Ia190587b4d5c6f1847471be27550cbfb843dc01e

Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/9235
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Community-CI: Mellanox Build Bot
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Aleksey Marchuk <alexeymar@mellanox.com>
2021-08-20 07:29:57 +00:00
Ben Walker
af935f768e event: Shift subsystem initialization code to a separate library
This is useful for applications even if they elect not to use the SPDK
event framework.

This doesn't shift everything in one go - just the subsystem
initialization logic. Configuration file loading also needs to move
in a separate patch later.

Change-Id: Id419df1045442d416650ed90e5ee78adfdd623d7
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/6641
Community-CI: Broadcom CI
Community-CI: Mellanox Build Bot
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Aleksey Marchuk <alexeymar@mellanox.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Paul Luse <paul.e.luse@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
2021-05-24 10:12:50 +00:00