Re: [PATCH 4/5] nvmet: use atomic allocations when allocating fc requests

On 5/15/2018 12:40 AM, Johannes Thumshirn wrote: fcloop_fcp_req() runs with the hctx_lock (a rcu_read_lock() locked section) held, so memory allocations done in this context have to be atomic. ... Signed-off-by: Johannes Thumshirn --- drivers/nvme/target/fcloop.c | 2 +- 1 file changed,

Re: [PATCH 4/5] nvmet: use atomic allocations when allocating fc requests

On 5/31/2018 2:31 AM, Sagi Grimberg wrote: Question, why isn't tfcp_req embedded in fcpreq? don't they have the same lifetime? no they don't.  To properly simulate cable-pulls, etc - the host side and controller side effectively have their own "exchange" structure. tfcp_req corresponds t

Re: [PATCH 4/5] nvmet: use atomic allocations when allocating fc requests

diff --git a/drivers/nvme/target/fcloop.c b/drivers/nvme/target/fcloop.c index 34712def81b1..d2209c60f95f 100644 --- a/drivers/nvme/target/fcloop.c +++ b/drivers/nvme/target/fcloop.c @@ -509,7 +509,7 @@ fcloop_fcp_req(struct nvme_fc_local_port *localport, if (!rport->targetport)

[PATCH 4/5] nvmet: use atomic allocations when allocating fc requests

fcloop_fcp_req() runs with the hctx_lock (a rcu_read_lock() locked section) held, so memory allocations done in this context have to be atomic. This fixes the follwing lockdep complaint: [9.753313] BUG: sleeping function called from invalid context at mm/slab.h:421 [9.754518] in_atomic():