[GIT PULL] nvme update for Linux 4.14

[GIT PULL] nvme update for Linux 4.14

[Christoph Hellwig]

Hi Jens,

below is the current set of NVMe updates for Linux 4.14.

The biggest bit comes from Sagi and refactors the RDMA driver to prepare
for more code sharing in the setup and teardown path.  But we have various
features and bug fixes from a lot of people as well.

The following changes since commit 16a5a480f067f945fd27bf91ffdce3f959b0d4b6:

  nvmet-fc: correct use after free on list teardown (2017-08-16 10:06:18 +0200)

are available in the git repository at:

  git://git.infradead.org/nvme.git nvme-4.14

for you to fetch changes up to 16edd3d0272368eee5cac13356787c1f4d4eb255:

  nvme: honor RTD3 Entry Latency for shutdowns (2017-08-28 16:29:29 +0200)

----------------------------------------------------------------
Arnav Dawn (2):
      nvme: add support for FW activation without reset
      nvme: define NVME_NSID_ALL

Christoph Hellwig (1):
      nvmet: use NVME_NSID_ALL

Guan Junxiong (2):
      nvmet: fix the return error code of target if host is not allowed
      nvme-fabrics: log a warning if hostid is invalid

James Smart (2):
      nvme-fc: Reattach to localports on re-registration
      nvmet-fc: simplify sg list handling

Jan H. Sch�nherr (1):
      nvme: fix uninitialized prp2 value on small transfers

Johannes Thumshirn (2):
      nvmet-fcloop: remove ALL_OPTS define
      nvme-rdma: remove NVME_RDMA_MAX_SEGMENT_SIZE

Jon Derrick (1):
      nvme: add support for NVMe 1.3 Timestamp Feature

Martin K. Petersen (1):
      nvme: honor RTD3 Entry Latency for shutdowns

Martin Wilck (2):
      string.h: add memcpy_and_pad()
      nvmet: use memcpy_and_pad for identify sn/fr

Max Gurtovoy (3):
      nvme: add symbolic constants for CC identifiers
      nvme: rename AMS symbolic constants to fit specification
      nvme-rdma: Use unlikely macro in the fast path

Sagi Grimberg (13):
      nvme-rdma: move nvme_rdma_configure_admin_queue code location
      nvme: Add admin_tagset pointer to nvme_ctrl
      nvme-rdma: move tagset allocation to a dedicated routine
      nvme-rdma: disable the controller on resets
      nvme-rdma: don't free tagset on resets
      nvme-rdma: reuse configure/destroy_admin_queue
      nvme-rdma: introduce configure/destroy io queues
      nvme-rdma: stop queues instead of simply flipping their state
      nvme-rdma: rename nvme_rdma_init_queue to nvme_rdma_alloc_queue
      nvme-rdma: introduce nvme_rdma_start_queue
      nvme-rdma: cleanup error path in controller reset
      nvme-rdma: call ops->reg_read64 instead of nvmf_reg_read64
      nvme: fix identify namespace logging

 drivers/nvme/host/core.c        | 120 ++++++++-
 drivers/nvme/host/fabrics.c     |   1 +
 drivers/nvme/host/fc.c          | 145 ++++++++---
 drivers/nvme/host/nvme.h        |   4 +
 drivers/nvme/host/pci.c         |   5 +-
 drivers/nvme/host/rdma.c        | 559 ++++++++++++++++++++--------------------
 drivers/nvme/target/admin-cmd.c |  16 +-
 drivers/nvme/target/configfs.c  |   2 +-
 drivers/nvme/target/core.c      |  15 +-
 drivers/nvme/target/fc.c        |  48 +---
 drivers/nvme/target/fcloop.c    |   3 -
 drivers/nvme/target/loop.c      |   1 +
 include/linux/nvme-fc-driver.h  |   2 +-
 include/linux/nvme.h            |  37 ++-
 include/linux/string.h          |  30 +++
 15 files changed, 600 insertions(+), 388 deletions(-)

[GIT PULL] nvme update for Linux 4.14

[Christoph Hellwig]

Hi Jens,

below is the current set of NVMe updates for Linux 4.14.

The biggest bit comes from Sagi and refactors the RDMA driver to prepare
for more code sharing in the setup and teardown path.  But we have various
features and bug fixes from a lot of people as well.

The following changes since commit 16a5a480f067f945fd27bf91ffdce3f959b0d4b6:

  nvmet-fc: correct use after free on list teardown (2017-08-16 10:06:18 +0200)

are available in the git repository at:

  git://git.infradead.org/nvme.git nvme-4.14

for you to fetch changes up to 16edd3d0272368eee5cac13356787c1f4d4eb255:

  nvme: honor RTD3 Entry Latency for shutdowns (2017-08-28 16:29:29 +0200)

----------------------------------------------------------------
Arnav Dawn (2):
      nvme: add support for FW activation without reset
      nvme: define NVME_NSID_ALL

Christoph Hellwig (1):
      nvmet: use NVME_NSID_ALL

Guan Junxiong (2):
      nvmet: fix the return error code of target if host is not allowed
      nvme-fabrics: log a warning if hostid is invalid

James Smart (2):
      nvme-fc: Reattach to localports on re-registration
      nvmet-fc: simplify sg list handling

Jan H. Sch?nherr (1):
      nvme: fix uninitialized prp2 value on small transfers

Johannes Thumshirn (2):
      nvmet-fcloop: remove ALL_OPTS define
      nvme-rdma: remove NVME_RDMA_MAX_SEGMENT_SIZE

Jon Derrick (1):
      nvme: add support for NVMe 1.3 Timestamp Feature

Martin K. Petersen (1):
      nvme: honor RTD3 Entry Latency for shutdowns

Martin Wilck (2):
      string.h: add memcpy_and_pad()
      nvmet: use memcpy_and_pad for identify sn/fr

Max Gurtovoy (3):
      nvme: add symbolic constants for CC identifiers
      nvme: rename AMS symbolic constants to fit specification
      nvme-rdma: Use unlikely macro in the fast path

Sagi Grimberg (13):
      nvme-rdma: move nvme_rdma_configure_admin_queue code location
      nvme: Add admin_tagset pointer to nvme_ctrl
      nvme-rdma: move tagset allocation to a dedicated routine
      nvme-rdma: disable the controller on resets
      nvme-rdma: don't free tagset on resets
      nvme-rdma: reuse configure/destroy_admin_queue
      nvme-rdma: introduce configure/destroy io queues
      nvme-rdma: stop queues instead of simply flipping their state
      nvme-rdma: rename nvme_rdma_init_queue to nvme_rdma_alloc_queue
      nvme-rdma: introduce nvme_rdma_start_queue
      nvme-rdma: cleanup error path in controller reset
      nvme-rdma: call ops->reg_read64 instead of nvmf_reg_read64
      nvme: fix identify namespace logging

 drivers/nvme/host/core.c        | 120 ++++++++-
 drivers/nvme/host/fabrics.c     |   1 +
 drivers/nvme/host/fc.c          | 145 ++++++++---
 drivers/nvme/host/nvme.h        |   4 +
 drivers/nvme/host/pci.c         |   5 +-
 drivers/nvme/host/rdma.c        | 559 ++++++++++++++++++++--------------------
 drivers/nvme/target/admin-cmd.c |  16 +-
 drivers/nvme/target/configfs.c  |   2 +-
 drivers/nvme/target/core.c      |  15 +-
 drivers/nvme/target/fc.c        |  48 +---
 drivers/nvme/target/fcloop.c    |   3 -
 drivers/nvme/target/loop.c      |   1 +
 include/linux/nvme-fc-driver.h  |   2 +-
 include/linux/nvme.h            |  37 ++-
 include/linux/string.h          |  30 +++
 15 files changed, 600 insertions(+), 388 deletions(-)

Re: [GIT PULL] nvme update for Linux 4.14

[Jens Axboe]

On 08/28/2017 08:33 AM, Christoph Hellwig wrote:
> Hi Jens,
> 
> below is the current set of NVMe updates for Linux 4.14.
> 
> The biggest bit comes from Sagi and refactors the RDMA driver to prepare
> for more code sharing in the setup and teardown path.  But we have various
> features and bug fixes from a lot of people as well.
> 
> The following changes since commit 16a5a480f067f945fd27bf91ffdce3f959b0d4b6:
> 
>   nvmet-fc: correct use after free on list teardown (2017-08-16 10:06:18 +0200)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/nvme.git nvme-4.14
> 
> for you to fetch changes up to 16edd3d0272368eee5cac13356787c1f4d4eb255:
> 
>   nvme: honor RTD3 Entry Latency for shutdowns (2017-08-28 16:29:29 +0200)

What is this against, exactly? It doesn't merge cleanly with my 4.14 branch.
>From a quick look, looks like it's conflicting with:

commit d09f2b45f346f0a9e5e1b5fcea531b1b393671dc
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Sun Jul 2 10:56:43 2017 +0300

    nvme: split nvme_uninit_ctrl into stop and uninit

which went into master after for-4.14/block was forked off. I can fix it
up, but would be best if you did it.

-- 
Jens Axboe

[GIT PULL] nvme update for Linux 4.14

[Jens Axboe]

On 08/28/2017 08:33 AM, Christoph Hellwig wrote:
> Hi Jens,
> 
> below is the current set of NVMe updates for Linux 4.14.
> 
> The biggest bit comes from Sagi and refactors the RDMA driver to prepare
> for more code sharing in the setup and teardown path.  But we have various
> features and bug fixes from a lot of people as well.
> 
> The following changes since commit 16a5a480f067f945fd27bf91ffdce3f959b0d4b6:
> 
>   nvmet-fc: correct use after free on list teardown (2017-08-16 10:06:18 +0200)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/nvme.git nvme-4.14
> 
> for you to fetch changes up to 16edd3d0272368eee5cac13356787c1f4d4eb255:
> 
>   nvme: honor RTD3 Entry Latency for shutdowns (2017-08-28 16:29:29 +0200)

What is this against, exactly? It doesn't merge cleanly with my 4.14 branch.
>From a quick look, looks like it's conflicting with:

commit d09f2b45f346f0a9e5e1b5fcea531b1b393671dc
Author: Sagi Grimberg <sagi at grimberg.me>
Date:   Sun Jul 2 10:56:43 2017 +0300

    nvme: split nvme_uninit_ctrl into stop and uninit

which went into master after for-4.14/block was forked off. I can fix it
up, but would be best if you did it.

-- 
Jens Axboe

Re: [GIT PULL] nvme update for Linux 4.14

[Christoph Hellwig]

On Mon, Aug 28, 2017 at 09:51:38AM -0600, Jens Axboe wrote:
> What is this against, exactly? It doesn't merge cleanly with my 4.14 branch.
> >From a quick look, looks like it's conflicting with:

It was based on the nvme-3.13 tree from about two weeks ago,
which was based on your for-linus at about that time.

[GIT PULL] nvme update for Linux 4.14

[Christoph Hellwig]

On Mon, Aug 28, 2017@09:51:38AM -0600, Jens Axboe wrote:
> What is this against, exactly? It doesn't merge cleanly with my 4.14 branch.
> >From a quick look, looks like it's conflicting with:

It was based on the nvme-3.13 tree from about two weeks ago,
which was based on your for-linus at about that time.

Re: [GIT PULL] nvme update for Linux 4.14

[Jens Axboe]

On 08/28/2017 09:53 AM, Christoph Hellwig wrote:
> On Mon, Aug 28, 2017 at 09:51:38AM -0600, Jens Axboe wrote:
>> What is this against, exactly? It doesn't merge cleanly with my 4.14 branch.
>> >From a quick look, looks like it's conflicting with:
> 
> It was based on the nvme-3.13 tree from about two weeks ago,
> which was based on your for-linus at about that time.

Changes for 4.14 should be against the 4.14 branch. for-linus is
for 4.13. In any case, there will be a conflict against master...

-- 
Jens Axboe

[GIT PULL] nvme update for Linux 4.14

[Jens Axboe]

On 08/28/2017 09:53 AM, Christoph Hellwig wrote:
> On Mon, Aug 28, 2017@09:51:38AM -0600, Jens Axboe wrote:
>> What is this against, exactly? It doesn't merge cleanly with my 4.14 branch.
>> >From a quick look, looks like it's conflicting with:
> 
> It was based on the nvme-3.13 tree from about two weeks ago,
> which was based on your for-linus at about that time.

Changes for 4.14 should be against the 4.14 branch. for-linus is
for 4.13. In any case, there will be a conflict against master...

-- 
Jens Axboe

Re: [GIT PULL] nvme update for Linux 4.14

[Christoph Hellwig]

On Mon, Aug 28, 2017 at 09:55:55AM -0600, Jens Axboe wrote:
> > It was based on the nvme-3.13 tree from about two weeks ago,
> > which was based on your for-linus at about that time.
> 
> Changes for 4.14 should be against the 4.14 branch. for-linus is
> for 4.13. In any case, there will be a conflict against master...

We would have otherwise had conflicts against changes in Linus'
tree for 4.13, so we were between a rock and a hard place here.

[GIT PULL] nvme update for Linux 4.14

[Christoph Hellwig]

On Mon, Aug 28, 2017@09:55:55AM -0600, Jens Axboe wrote:
> > It was based on the nvme-3.13 tree from about two weeks ago,
> > which was based on your for-linus at about that time.
> 
> Changes for 4.14 should be against the 4.14 branch. for-linus is
> for 4.13. In any case, there will be a conflict against master...

We would have otherwise had conflicts against changes in Linus'
tree for 4.13, so we were between a rock and a hard place here.

Re: [GIT PULL] nvme update for Linux 4.14

[Jens Axboe]

On 08/28/2017 09:59 AM, Christoph Hellwig wrote:
> On Mon, Aug 28, 2017 at 09:55:55AM -0600, Jens Axboe wrote:
>>> It was based on the nvme-3.13 tree from about two weeks ago,
>>> which was based on your for-linus at about that time.
>>
>> Changes for 4.14 should be against the 4.14 branch. for-linus is
>> for 4.13. In any case, there will be a conflict against master...
> 
> We would have otherwise had conflicts against changes in Linus'
> tree for 4.13, so we were between a rock and a hard place here.

But one rock is shittier than the other. If you based it against
4.14, then at least I only have to resolve the the problem once.

The real problem is that the patch that went into master had
cleanups too. You should push back against that, since it will
inevitably cause problems by diverging 4.13 and 4.14 more than
absolutely necessary. Having conflicts in nvme for the block tree
is not isolated to this series, unfortunately.

-- 
Jens Axboe

[GIT PULL] nvme update for Linux 4.14

[Jens Axboe]

On 08/28/2017 09:59 AM, Christoph Hellwig wrote:
> On Mon, Aug 28, 2017@09:55:55AM -0600, Jens Axboe wrote:
>>> It was based on the nvme-3.13 tree from about two weeks ago,
>>> which was based on your for-linus at about that time.
>>
>> Changes for 4.14 should be against the 4.14 branch. for-linus is
>> for 4.13. In any case, there will be a conflict against master...
> 
> We would have otherwise had conflicts against changes in Linus'
> tree for 4.13, so we were between a rock and a hard place here.

But one rock is shittier than the other. If you based it against
4.14, then at least I only have to resolve the the problem once.

The real problem is that the patch that went into master had
cleanups too. You should push back against that, since it will
inevitably cause problems by diverging 4.13 and 4.14 more than
absolutely necessary. Having conflicts in nvme for the block tree
is not isolated to this series, unfortunately.

-- 
Jens Axboe

Re: [GIT PULL] nvme update for Linux 4.14

[Christoph Hellwig]

On Mon, Aug 28, 2017 at 10:03:39AM -0600, Jens Axboe wrote:
> But one rock is shittier than the other. If you based it against
> 4.14, then at least I only have to resolve the the problem once.
> 
> The real problem is that the patch that went into master had
> cleanups too. You should push back against that, since it will
> inevitably cause problems by diverging 4.13 and 4.14 more than
> absolutely necessary. Having conflicts in nvme for the block tree
> is not isolated to this series, unfortunately.

Given that the update doesn't appear to be in your for-next branch
yet: do you want me to rebase it and resend?

[GIT PULL] nvme update for Linux 4.14

[Christoph Hellwig]

On Mon, Aug 28, 2017@10:03:39AM -0600, Jens Axboe wrote:
> But one rock is shittier than the other. If you based it against
> 4.14, then at least I only have to resolve the the problem once.
> 
> The real problem is that the patch that went into master had
> cleanups too. You should push back against that, since it will
> inevitably cause problems by diverging 4.13 and 4.14 more than
> absolutely necessary. Having conflicts in nvme for the block tree
> is not isolated to this series, unfortunately.

Given that the update doesn't appear to be in your for-next branch
yet: do you want me to rebase it and resend?

Re: [GIT PULL] nvme update for Linux 4.14

[Jens Axboe]

On 08/28/2017 11:57 AM, Christoph Hellwig wrote:
> On Mon, Aug 28, 2017 at 10:03:39AM -0600, Jens Axboe wrote:
>> But one rock is shittier than the other. If you based it against
>> 4.14, then at least I only have to resolve the the problem once.
>>
>> The real problem is that the patch that went into master had
>> cleanups too. You should push back against that, since it will
>> inevitably cause problems by diverging 4.13 and 4.14 more than
>> absolutely necessary. Having conflicts in nvme for the block tree
>> is not isolated to this series, unfortunately.
> 
> Given that the update doesn't appear to be in your for-next branch
> yet: do you want me to rebase it and resend?

Yes please.

-- 
Jens Axboe

[GIT PULL] nvme update for Linux 4.14

[Jens Axboe]

On 08/28/2017 11:57 AM, Christoph Hellwig wrote:
> On Mon, Aug 28, 2017@10:03:39AM -0600, Jens Axboe wrote:
>> But one rock is shittier than the other. If you based it against
>> 4.14, then at least I only have to resolve the the problem once.
>>
>> The real problem is that the patch that went into master had
>> cleanups too. You should push back against that, since it will
>> inevitably cause problems by diverging 4.13 and 4.14 more than
>> absolutely necessary. Having conflicts in nvme for the block tree
>> is not isolated to this series, unfortunately.
> 
> Given that the update doesn't appear to be in your for-next branch
> yet: do you want me to rebase it and resend?

Yes please.

-- 
Jens Axboe

Re: [GIT PULL] nvme update for Linux 4.14

[Christoph Hellwig]

Meh, I don't think that'll work out - the rdma refactoring from
Sagi deeply depends on the unіnit_ctrl split..

[GIT PULL] nvme update for Linux 4.14

[Christoph Hellwig]

Meh, I don't think that'll work out - the rdma refactoring from
Sagi deeply depends on the un?nit_ctrl split..

Re: [GIT PULL] nvme update for Linux 4.14

[Jens Axboe]

On 08/28/2017 12:40 PM, Christoph Hellwig wrote:
> Meh, I don't think that'll work out - the rdma refactoring from
> Sagi deeply depends on the unіnit_ctrl split..

I can do a for-4.14/block-postmerge branch, which is for-4.14/block
with -rc7 pulled in. Should apply on top of that.

Did that branch, doesn't apply. But should be easier for you to
rebase on top of that branch. Pushed it out.

-- 
Jens Axboe

[GIT PULL] nvme update for Linux 4.14

[Jens Axboe]

On 08/28/2017 12:40 PM, Christoph Hellwig wrote:
> Meh, I don't think that'll work out - the rdma refactoring from
> Sagi deeply depends on the un?nit_ctrl split..

I can do a for-4.14/block-postmerge branch, which is for-4.14/block
with -rc7 pulled in. Should apply on top of that.

Did that branch, doesn't apply. But should be easier for you to
rebase on top of that branch. Pushed it out.

-- 
Jens Axboe

Re: [GIT PULL] nvme update for Linux 4.14

[Christoph Hellwig]

On Mon, Aug 28, 2017 at 01:01:53PM -0600, Jens Axboe wrote:
> On 08/28/2017 12:40 PM, Christoph Hellwig wrote:
> > Meh, I don't think that'll work out - the rdma refactoring from
> > Sagi deeply depends on the unіnit_ctrl split..
> 
> I can do a for-4.14/block-postmerge branch, which is for-4.14/block
> with -rc7 pulled in. Should apply on top of that.
> 
> Did that branch, doesn't apply. But should be easier for you to
> rebase on top of that branch. Pushed it out.

I've pushed out a nvme-4.14-rebase branch with the rebase, but I didn't
have time for non-trivial testing yet, that'll have to wait for
tomorrow.

Sagi: can you double check the resolutions around blk_mq_reinit_tagse?

[GIT PULL] nvme update for Linux 4.14

[Christoph Hellwig]

On Mon, Aug 28, 2017@01:01:53PM -0600, Jens Axboe wrote:
> On 08/28/2017 12:40 PM, Christoph Hellwig wrote:
> > Meh, I don't think that'll work out - the rdma refactoring from
> > Sagi deeply depends on the un?nit_ctrl split..
> 
> I can do a for-4.14/block-postmerge branch, which is for-4.14/block
> with -rc7 pulled in. Should apply on top of that.
> 
> Did that branch, doesn't apply. But should be easier for you to
> rebase on top of that branch. Pushed it out.

I've pushed out a nvme-4.14-rebase branch with the rebase, but I didn't
have time for non-trivial testing yet, that'll have to wait for
tomorrow.

Sagi: can you double check the resolutions around blk_mq_reinit_tagse?

Re: [GIT PULL] nvme update for Linux 4.14

[Sagi Grimberg]

>>> Meh, I don't think that'll work out - the rdma refactoring from
>>> Sagi deeply depends on the unіnit_ctrl split..
>>
>> I can do a for-4.14/block-postmerge branch, which is for-4.14/block
>> with -rc7 pulled in. Should apply on top of that.
>>
>> Did that branch, doesn't apply. But should be easier for you to
>> rebase on top of that branch. Pushed it out.
> 
> I've pushed out a nvme-4.14-rebase branch with the rebase, but I didn't
> have time for non-trivial testing yet, that'll have to wait for
> tomorrow.
> 
> Sagi: can you double check the resolutions around blk_mq_reinit_tagse?

Thanks for doing it Christoph,

It looks good to me, there is one glitch in patch:
"nvme-rdma: reuse configure/destroy_admin_queue"

The "nvme_rdma_configure_admin_queue" block needs to
be squashed into "nvme-rdma: don't free tagset on resets".

I'll do that now.

[GIT PULL] nvme update for Linux 4.14

[Sagi Grimberg]

>>> Meh, I don't think that'll work out - the rdma refactoring from
>>> Sagi deeply depends on the un?nit_ctrl split..
>>
>> I can do a for-4.14/block-postmerge branch, which is for-4.14/block
>> with -rc7 pulled in. Should apply on top of that.
>>
>> Did that branch, doesn't apply. But should be easier for you to
>> rebase on top of that branch. Pushed it out.
> 
> I've pushed out a nvme-4.14-rebase branch with the rebase, but I didn't
> have time for non-trivial testing yet, that'll have to wait for
> tomorrow.
> 
> Sagi: can you double check the resolutions around blk_mq_reinit_tagse?

Thanks for doing it Christoph,

It looks good to me, there is one glitch in patch:
"nvme-rdma: reuse configure/destroy_admin_queue"

The "nvme_rdma_configure_admin_queue" block needs to
be squashed into "nvme-rdma: don't free tagset on resets".

I'll do that now.

Re: [GIT PULL] nvme update for Linux 4.14

[Jens Axboe]

On 08/28/2017 01:56 PM, Sagi Grimberg wrote:
>>>> Meh, I don't think that'll work out - the rdma refactoring from
>>>> Sagi deeply depends on the unіnit_ctrl split..
>>>
>>> I can do a for-4.14/block-postmerge branch, which is for-4.14/block
>>> with -rc7 pulled in. Should apply on top of that.
>>>
>>> Did that branch, doesn't apply. But should be easier for you to
>>> rebase on top of that branch. Pushed it out.
>>
>> I've pushed out a nvme-4.14-rebase branch with the rebase, but I didn't
>> have time for non-trivial testing yet, that'll have to wait for
>> tomorrow.
>>
>> Sagi: can you double check the resolutions around blk_mq_reinit_tagse?
> 
> Thanks for doing it Christoph,
> 
> It looks good to me, there is one glitch in patch:
> "nvme-rdma: reuse configure/destroy_admin_queue"
> 
> The "nvme_rdma_configure_admin_queue" block needs to
> be squashed into "nvme-rdma: don't free tagset on resets> 
> I'll do that now.

Let me know when it's ready.

-- 
Jens Axboe

[GIT PULL] nvme update for Linux 4.14

[Jens Axboe]

On 08/28/2017 01:56 PM, Sagi Grimberg wrote:
>>>> Meh, I don't think that'll work out - the rdma refactoring from
>>>> Sagi deeply depends on the un?nit_ctrl split..
>>>
>>> I can do a for-4.14/block-postmerge branch, which is for-4.14/block
>>> with -rc7 pulled in. Should apply on top of that.
>>>
>>> Did that branch, doesn't apply. But should be easier for you to
>>> rebase on top of that branch. Pushed it out.
>>
>> I've pushed out a nvme-4.14-rebase branch with the rebase, but I didn't
>> have time for non-trivial testing yet, that'll have to wait for
>> tomorrow.
>>
>> Sagi: can you double check the resolutions around blk_mq_reinit_tagse?
> 
> Thanks for doing it Christoph,
> 
> It looks good to me, there is one glitch in patch:
> "nvme-rdma: reuse configure/destroy_admin_queue"
> 
> The "nvme_rdma_configure_admin_queue" block needs to
> be squashed into "nvme-rdma: don't free tagset on resets> 
> I'll do that now.

Let me know when it's ready.

-- 
Jens Axboe

Re: [GIT PULL] nvme update for Linux 4.14

[Christoph Hellwig]

On Tue, Aug 29, 2017 at 08:34:29AM -0600, Jens Axboe wrote:
> Let me know when it's ready.

I'll send you another pull request in a bit.

[GIT PULL] nvme update for Linux 4.14

[Christoph Hellwig]

On Tue, Aug 29, 2017@08:34:29AM -0600, Jens Axboe wrote:
> Let me know when it's ready.

I'll send you another pull request in a bit.