All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: Max Gurtovoy <maxg@mellanox.com>,
	linux-block@vger.kernel.org, axboe@kernel.dk,
	martin.petersen@oracle.com, linux-nvme@lists.infradead.org,
	keith.busch@intel.com, hch@lst.de, shlomin@mellanox.com,
	israelr@mellanox.com
Subject: Re: [PATCH 3/4] nvme-tcp: introduce nvme_tcp_complete_rq callback
Date: Wed, 4 Sep 2019 07:54:19 +0200	[thread overview]
Message-ID: <20190904055419.GD10553@lst.de> (raw)
In-Reply-To: <c5757c95-2a4f-410d-a275-85d8c9da737f@grimberg.me>

On Tue, Sep 03, 2019 at 12:15:48PM -0700, Sagi Grimberg wrote:
>
>> The nvme_cleanup_cmd function should be called to avoid resource leakage
>> (it's the opposite to nvme_setup_cmd). Fix the error flow during command
>> submission and also fix the missing call in command completion.
>
> Is it always called with nvme_complete_rq? Why not just put it there?

Yes, unless I am missing something we could call nvme_cleanup_cmd
at the beginning of nvme_complete_rq.

Max, can you send one series for all the nvme_cleanup_cmd fixes and
cleanups and split that from the PI work?  That might be a little
less confusing.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: axboe@kernel.dk, keith.busch@intel.com,
	martin.petersen@oracle.com, israelr@mellanox.com,
	linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
	shlomin@mellanox.com, Max Gurtovoy <maxg@mellanox.com>,
	hch@lst.de
Subject: Re: [PATCH 3/4] nvme-tcp: introduce nvme_tcp_complete_rq callback
Date: Wed, 4 Sep 2019 07:54:19 +0200	[thread overview]
Message-ID: <20190904055419.GD10553@lst.de> (raw)
In-Reply-To: <c5757c95-2a4f-410d-a275-85d8c9da737f@grimberg.me>

On Tue, Sep 03, 2019 at 12:15:48PM -0700, Sagi Grimberg wrote:
>
>> The nvme_cleanup_cmd function should be called to avoid resource leakage
>> (it's the opposite to nvme_setup_cmd). Fix the error flow during command
>> submission and also fix the missing call in command completion.
>
> Is it always called with nvme_complete_rq? Why not just put it there?

Yes, unless I am missing something we could call nvme_cleanup_cmd
at the beginning of nvme_complete_rq.

Max, can you send one series for all the nvme_cleanup_cmd fixes and
cleanups and split that from the PI work?  That might be a little
less confusing.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

  reply	other threads:[~2019-09-04  5:54 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-03 15:14 [PATCH 1/4] block: centrelize PI remapping logic to the block layer Max Gurtovoy
2019-09-03 15:14 ` Max Gurtovoy
2019-09-03 15:14 ` [PATCH 2/4] nvme-rdma: simplify error flow in nvme_rdma_queue_rq Max Gurtovoy
2019-09-03 15:14   ` Max Gurtovoy
2019-09-04  5:51   ` Christoph Hellwig
2019-09-04  5:51     ` Christoph Hellwig
2019-09-03 15:14 ` [PATCH 3/4] nvme-tcp: introduce nvme_tcp_complete_rq callback Max Gurtovoy
2019-09-03 15:14   ` Max Gurtovoy
2019-09-03 19:15   ` Sagi Grimberg
2019-09-03 19:15     ` Sagi Grimberg
2019-09-04  5:54     ` Christoph Hellwig [this message]
2019-09-04  5:54       ` Christoph Hellwig
2019-09-04  9:02       ` Max Gurtovoy
2019-09-04  9:02         ` Max Gurtovoy
2019-09-03 15:14 ` [PATCH 4/4] nvmet-loop: fix possible leakage during error flow Max Gurtovoy
2019-09-03 15:14   ` Max Gurtovoy
2019-09-04  5:50   ` Christoph Hellwig
2019-09-04  5:50     ` Christoph Hellwig
2019-09-03 19:11 ` [PATCH 1/4] block: centrelize PI remapping logic to the block layer Sagi Grimberg
2019-09-03 19:11   ` Sagi Grimberg
2019-09-03 19:21   ` Jens Axboe
2019-09-03 19:21     ` Jens Axboe
2019-09-04  5:49     ` Christoph Hellwig
2019-09-04  5:49       ` Christoph Hellwig
2019-09-04  8:32       ` Max Gurtovoy
2019-09-04  8:32         ` Max Gurtovoy
2019-09-04 12:49         ` Christoph Hellwig
2019-09-04 12:49           ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190904055419.GD10553@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=israelr@mellanox.com \
    --cc=keith.busch@intel.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=martin.petersen@oracle.com \
    --cc=maxg@mellanox.com \
    --cc=sagi@grimberg.me \
    --cc=shlomin@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.