[GIT PULL] Block fixes for 5.7-rc1

[GIT PULL] Block fixes for 5.7-rc1

[Jens Axboe]

Hi Linus,

Here's a set of fixes that should go into this merge window. This pull
request contains:

- NVMe pull request from Christoph with various fixes

- Better discard support for loop (Evan)

- Only call ->commit_rqs() if we have queued IO (Keith)

- blkcg offlining fixes (Tejun)

Please pull! 


  git://git.kernel.dk/linux-block.git tags/block-5.7-2020-04-09


----------------------------------------------------------------
Christoph Hellwig (1):
      block: fix busy device checking in blk_drop_partitions

Evan Green (2):
      loop: Report EOPNOTSUPP properly
      loop: Better discard support for block devices

Israel Rukshin (2):
      nvme-rdma: Replace comma with a semicolon
      nvmet-rdma: fix double free of rdma queue

James Smart (3):
      nvme-fcloop: fix deallocation of working context
      nvmet-fc: fix typo in comment
      nvme-fc: Revert "add module to ops template to allow module references"

Jens Axboe (1):
      Merge branch 'nvme-5.7' of git://git.infradead.org/nvme into block-5.7

Keith Busch (1):
      blk-mq: don't commit_rqs() if none were queued

Nick Bowler (1):
      nvme: fix compat address handling in several ioctls

Sagi Grimberg (7):
      nvme-tcp: fix possible crash in write_zeroes processing
      nvme-tcp: don't poll a non-live queue
      nvme-tcp: fix possible crash in recv error flow
      nvme: inherit stable pages constraint in the mpath stack device
      nvmet: fix NULL dereference when removing a referral
      nvmet-rdma: fix bonding failover possible NULL deref
      nvme: fix deadlock caused by ANA update wrong locking

Tejun Heo (2):
      blkcg: rename blkcg->cgwb_refcnt to ->online_pin and always use it
      blkcg: don't offline parent blkcg first

 block/blk-cgroup.c              |  22 ++++-
 block/blk-mq.c                  |   9 +-
 block/partitions/core.c         |   2 +-
 drivers/block/loop.c            |  49 +++++++---
 drivers/nvme/host/core.c        |  34 +++++--
 drivers/nvme/host/fc.c          |  14 +--
 drivers/nvme/host/multipath.c   |   4 +-
 drivers/nvme/host/rdma.c        |   2 +-
 drivers/nvme/host/tcp.c         |  18 ++--
 drivers/nvme/target/configfs.c  |  10 +-
 drivers/nvme/target/fc.c        |   2 +-
 drivers/nvme/target/fcloop.c    |  77 ++++++++++-----
 drivers/nvme/target/rdma.c      | 205 +++++++++++++++++++++++++++-------------
 drivers/scsi/lpfc/lpfc_nvme.c   |   2 -
 drivers/scsi/qla2xxx/qla_nvme.c |   1 -
 include/linux/blk-cgroup.h      |  43 ++++-----
 include/linux/nvme-fc-driver.h  |   4 -
 mm/backing-dev.c                |   6 +-
 18 files changed, 324 insertions(+), 180 deletions(-)

-- 
Jens Axboe

Re: [GIT PULL] Block fixes for 5.7-rc1

[Jens Axboe]

On 4/9/20 6:07 PM, Jens Axboe wrote:
> Hi Linus,
> 
> Here's a set of fixes that should go into this merge window. This pull
> request contains:
> 
> - NVMe pull request from Christoph with various fixes
> 
> - Better discard support for loop (Evan)
> 
> - Only call ->commit_rqs() if we have queued IO (Keith)
> 
> - blkcg offlining fixes (Tejun)
> 
> Please pull! 
> 
> 
>   git://git.kernel.dk/linux-block.git tags/block-5.7-2020-04-09

Followup pull request, as the partition check from Christoph had a
one-off that caused a boot failure on S390 (and perhaps others, but
didn't see it in my testing, and that's the only known report).

This one sits on top of the previous, figured that was easier than
redoing the other one fully.

Please pull after pulling tags/block-5.7-2020-04-09!


  git://git.kernel.dk/linux-block.git tags/block-5.7-2020-04-10


----------------------------------------------------------------
Christoph Hellwig (1):
      block: fix busy device checking in blk_drop_partitions again

 block/partitions/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Jens Axboe

Re: [GIT PULL] Block fixes for 5.7-rc1

[Linus Torvalds]

On Fri, Apr 10, 2020 at 7:37 AM Jens Axboe <axboe@kernel.dk> wrote:
>
> This one sits on top of the previous, figured that was easier than
> redoing the other one fully.

It's actually easier for me if you remove the broken tag when you
notice things like this (or use the same name for the fix tag and just
force-update it).

And then send a "oops, me bad, I updated it" with the new pull data.

The reason: when I opened this thread, I didn't notice your follow-up
at first, so I pulled the old tag, and so got the known-broken code.

And yes, I double-checked and caught it, unpulled and then re-pulled
the fixed-up tag instead.

But if the wrong tag had been just overwritten or deleted, the extra
steps wouldn't have been necessary.

Not a huge deal, it's not like it took me a lot of effort (it's more
painful if I have to fix up conflicts twice, although even that isn't
usually much of a bother since the second time I don't have to really
analyze them again).

So just a heads up for "I wish you'd done X instead".

Btw, on the subject of "I wish you had done X": this is not at all
particular to you, and a lot of people do this, but pull requests tend
to have the same pattern that we are trying to discourage in patch
descriptions.

So in Documentation/process/submitting-patches.rst, we talk about this:

 "Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
  instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
  to do frotz", as if you are giving orders to the codebase to change
  its behaviour"

because once it's then accepted into git, the whole "this patch" kind
of language doesn't really make much sense. It's much better to just
describe what the change does, than say "this change does X".

The same is actually true when I merge your pull request, and I take
the description from your email. Because the same way "This patch does
X" does not make a regular commit message any more legible, the "This
pull request does X" does not make sense in the commit message of a
merge.

So I end up editing peoples messages a lot (and I occasionally forget
or miss it).

Again, this is _not_ a huge deal, and I obviously haven't made a stink
about it, but I thought I'd mention it since I was on the subject of
"this causes me extra work".

           Linus

Re: [GIT PULL] Block fixes for 5.7-rc1

[pr-tracker-bot]

The pull request you sent on Thu, 9 Apr 2020 18:07:56 -0700:

> git://git.kernel.dk/linux-block.git tags/block-5.7-2020-04-09

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/cb6b771b05c3026a85ed4817c1b87c5e6f41d136

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: Re: [GIT PULL] Block fixes for 5.7-rc1

[pr-tracker-bot]

The pull request you sent on Fri, 10 Apr 2020 07:37:47 -0700:

> git://git.kernel.dk/linux-block.git tags/block-5.7-2020-04-10

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8df2a0a6da450b0fc28f1fed110817c1d98b84c2

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT PULL] Block fixes for 5.7-rc1

[Jens Axboe]

On 4/10/20 10:25 AM, Linus Torvalds wrote:
> On Fri, Apr 10, 2020 at 7:37 AM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> This one sits on top of the previous, figured that was easier than
>> redoing the other one fully.
> 
> It's actually easier for me if you remove the broken tag when you
> notice things like this (or use the same name for the fix tag and just
> force-update it).
> 
> And then send a "oops, me bad, I updated it" with the new pull data.
> 
> The reason: when I opened this thread, I didn't notice your follow-up
> at first, so I pulled the old tag, and so got the known-broken code.
> 
> And yes, I double-checked and caught it, unpulled and then re-pulled
> the fixed-up tag instead.
> 
> But if the wrong tag had been just overwritten or deleted, the extra
> steps wouldn't have been necessary.
> 
> Not a huge deal, it's not like it took me a lot of effort (it's more
> painful if I have to fix up conflicts twice, although even that isn't
> usually much of a bother since the second time I don't have to really
> analyze them again).
> 
> So just a heads up for "I wish you'd done X instead".

Noted! Since I sent out this pull yesterday and I knew I'd be away from
a keyborad all day today, I had to rush this followup pull this morning.
Normally I probably would have killed the branch and sent a new one.
Thanks for doing the right thing, and just pulling the new tag instead.

> Btw, on the subject of "I wish you had done X": this is not at all
> particular to you, and a lot of people do this, but pull requests tend
> to have the same pattern that we are trying to discourage in patch
> descriptions.
> 
> So in Documentation/process/submitting-patches.rst, we talk about this:
> 
>  "Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
>   instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
>   to do frotz", as if you are giving orders to the codebase to change
>   its behaviour"
> 
> because once it's then accepted into git, the whole "this patch" kind
> of language doesn't really make much sense. It's much better to just
> describe what the change does, than say "this change does X".
> 
> The same is actually true when I merge your pull request, and I take
> the description from your email. Because the same way "This patch does
> X" does not make a regular commit message any more legible, the "This
> pull request does X" does not make sense in the commit message of a
> merge.
> 
> So I end up editing peoples messages a lot (and I occasionally forget
> or miss it).
> 
> Again, this is _not_ a huge deal, and I obviously haven't made a stink
> about it, but I thought I'd mention it since I was on the subject of
> "this causes me extra work".

I like it, I'll word my pull requests imperatively going forward.

-- 
Jens Axboe