[GIT PULL] Block fixes for 5.9-rc2

[GIT PULL] Block fixes for 5.9-rc2

[Jens Axboe]

Hi Linus,

- NVMe pull request from Sagi:
	- nvme completion rework from Christoph and Chao that mostly
	  came from a bit of divergence of how we classify errors related
	  to pathing/retry etc.
	- nvmet passthru fixes from Chaitanya
	- minor nvmet fixes from Amit and I
	- mpath round-robin path selection fix from Martin
	- ignore noiob for zoned devices from Keith
	- minor nvme-fc fix from Tianjia"

- BFQ cgroup leak fix (Dmitry)

- Block layer MAINTAINERS addition (Geert)

- Fix null_blk FUA checking (Hou)

- get_max_io_size() size fix (Keith)

- Fix block page_is_mergeable() for compound pages (Matthew)

- Discard granularity fixes (Ming)

- IO scheduler ordering fix (Ming)

- Misc fixes


The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:

  Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)

are available in the Git repository at:

  git://git.kernel.dk/linux-block.git tags/io_uring-5.9-2020-08-23

for you to fetch changes up to 2d62e6b038e729c3e4bfbfcfbd44800ef0883680:

  null_blk: fix passing of REQ_FUA flag in null_handle_rq (2020-08-21 17:14:28 -0600)

----------------------------------------------------------------
io_uring-5.9-2020-08-23

----------------------------------------------------------------
Amit Engel (1):
      nvmet: Disable keep-alive timer when kato is cleared to 0h

Chaitanya Kulkarni (3):
      nvmet: add ns tear down label for pt-cmd handling
      nvmet: fix oops in pt cmd execution
      nvmet: call blk_mq_free_request() directly

Chao Leng (1):
      nvme: redirect commands on dying queue

Christoph Hellwig (4):
      nvme-pci: fix PRP pool size
      nvme: rename and document nvme_end_request
      nvme: refactor command completion
      nvme: just check the status code type in nvme_is_path_error

Dmitry Monakhov (1):
      bfq: fix blkio cgroup leakage v4

Geert Uytterhoeven (1):
      MAINTAINERS: Add missing header files to BLOCK LAYER section

Hou Pu (1):
      null_blk: fix passing of REQ_FUA flag in null_handle_rq

John Garry (1):
      nvme-pci: Use u32 for nvme_dev.q_depth and nvme_queue.q_depth

Keith Busch (2):
      block: fix get_max_io_size()
      nvme: skip noiob for zoned devices

Logan Gunthorpe (2):
      nvmet-passthru: Reject commands with non-sgl flags set
      nvme: Use spin_lock_irq() when taking the ctrl->lock

Martin Wilck (2):
      nvme: multipath: round-robin: fix single non-optimized path case
      nvme: multipath: round-robin: eliminate "fallback" variable

Matthew Wilcox (Oracle) (1):
      block: Fix page_is_mergeable() for compound pages

Ming Lei (5):
      blk-mq: order adding requests to hctx->dispatch and checking SCHED_RESTART
      block: loop: set discard granularity and alignment for block device backed loop
      block: respect queue limit of max discard segment
      block: virtio_blk: fix handling single range discard request
      blk-mq: insert request not through ->queue_rq into sw/scheduler queue

Nathan Chancellor (1):
      block/rnbd: Ensure err is always initialized in process_rdma

Randy Dunlap (1):
      block: blk-mq.c: fix @at_head kernel-doc warning

Sagi Grimberg (1):
      nvmet: fix a memory leak

Tianjia Zhang (1):
      nvme-fc: Fix wrong return value in __nvme_fc_init_request()

Xu Wang (1):
      bsg-lib: convert comma to semicolon

Yufen Yu (1):
      blkcg: fix memleak for iolatency

 .../fault-injection/nvme-fault-injection.rst       |  2 +-
 MAINTAINERS                                        |  1 +
 block/bfq-cgroup.c                                 |  2 +-
 block/bfq-iosched.h                                |  1 -
 block/bfq-wf2q.c                                   | 12 +--
 block/bio.c                                        | 10 +--
 block/blk-cgroup.c                                 |  8 +-
 block/blk-merge.c                                  | 13 +++-
 block/blk-mq-sched.c                               |  9 +++
 block/blk-mq.c                                     | 13 +++-
 block/bsg-lib.c                                    |  2 +-
 drivers/block/loop.c                               | 33 +++++----
 drivers/block/null_blk_main.c                      |  2 +-
 drivers/block/rnbd/rnbd-srv.c                      |  3 +-
 drivers/block/virtio_blk.c                         | 31 ++++++--
 drivers/nvme/host/core.c                           | 86 ++++++++++++++--------
 drivers/nvme/host/fc.c                             |  6 +-
 drivers/nvme/host/multipath.c                      | 69 +++++++----------
 drivers/nvme/host/nvme.h                           | 31 +++++++-
 drivers/nvme/host/pci.c                            | 17 +++--
 drivers/nvme/host/rdma.c                           |  2 +-
 drivers/nvme/host/tcp.c                            |  4 +-
 drivers/nvme/target/configfs.c                     |  1 +
 drivers/nvme/target/core.c                         |  6 ++
 drivers/nvme/target/loop.c                         |  2 +-
 drivers/nvme/target/passthru.c                     | 25 +++++--
 26 files changed, 238 insertions(+), 153 deletions(-)

-- 
Jens Axboe

Re: [GIT PULL] Block fixes for 5.9-rc2

[Linus Torvalds]

On Sun, Aug 23, 2020 at 12:27 PM Jens Axboe <axboe@kernel.dk> wrote:
>
> io_uring-5.9-2020-08-23

.. you ran the wrong script. Oops.

But it builds cleanly this time.

                Linus

Re: [GIT PULL] Block fixes for 5.9-rc2

[pr-tracker-bot]

The pull request you sent on Sun, 23 Aug 2020 13:27:48 -0600:

> git://git.kernel.dk/linux-block.git tags/io_uring-5.9-2020-08-23

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

Thank you!

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

Re: [GIT PULL] Block fixes for 5.9-rc2

[Jens Axboe]

On Mon, Aug 24, 2020 at 12:56 PM Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Sun, Aug 23, 2020 at 12:27 PM Jens Axboe <axboe@kernel.dk> wrote:
> >
> > io_uring-5.9-2020-08-23
>
> .. you ran the wrong script. Oops.

Oops yes indeed, guess it was too much on my mind when I tagged it.

-- 
Jens Axboe

Re: [GIT PULL] Block fixes for 5.9-rc2

[Jens Axboe]

On 8/21/20 5:29 PM, Linus Torvalds wrote:
> On Fri, Aug 21, 2020 at 4:01 PM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> The tree is totally warning clean right now on build, but that's usually
>> not the case, and missing a single warning isn't that hard.
> 
> Actually, my tree is generally entirely warning-free and has been for
> years, because I absolutely hate warnings.
> 
> You're not the only person I haven't pulled from because I saw a
> single warning. This is the second one just this release window.  I'm
> not singling you out. A warning to me is simply a hard "No".
> 
> Because I know very well that if there is even a single warning,
> people will then ignore the other warnings.
> 
> So there is no such thing as a harmless warning - it doesn't matter
> _what_ it warns about, it's a bad thing, because even one bogus
> warning will then mean that people ignore warnings that _aren't_
> bogus, and it goes all downhill from there.

We're in violent agreement on this part. None of the projects I maintain
throw any warnings, exactly for the same reason. My test box is using
gcc-10 and it definitely hasn't been "clean for years". It is now, and
has been for probably a release or two. The warnings do condition you to
ignore new warnings, which is of course a sad outcome that shouldn't
happen. I don't think anyone sane would disagree on that.

> So the reason I notice is exactly because I keep my build tree 100%
> clean. I do allmodconfig builds that are entirely clean, and I check
> it after each and every pull I do, and each patch series I apply.
> Mistakes can happen, but I try _very_ hard to keep my tree clean.
> 
> Now, that said, I'll miss warnings too, because I don't do
> cross-builds for other architectures, and I really only do a couple of
> fairly basic configurations.
> 
> But perhaps more importantly - I don't build with a lot of different
> compilers. I do in fact test two different compilers (both gcc and
> clang), but I use two different configurations, so it's not really
> overlapping testing, it's more that these days I make sure the clang
> build is warning free at least for the core kernel too.
> 
> So "warning free" is always relative to some compiler base (and some
> config base). But the baseline should absolutely be "zero warnings".
> 
> Generally, new warnings in my tree is because of a compiler upgrade or
> similar congifuration issues.
> 
> And it's sadly the "different compilers" thing that then means that
> *my* clean tree might not then necessarily be clean for others. It's
> also why I can't just enable "-Werror" to make it harder to miss.
> 
> But I've been tempted. Many times. There's been a couple of times I've
> added that "-Werror" to the Makefile, only to never commit it.
> 
> But if you have warnings that you see due to different compilers or
> configurations, holler. We'll get them fixed.

I obviously don't disagree with any of this, it'd be hard to, and it
wasn't really what any of my replies were about. It was about how this
was dealt with. But I won't keep beating the dead horse.

As I said, I'll rebase the branch, and in fact I already did. I likely
won't be able to get it out before after -rc2, which is pretty sad since
there's an nvme regression in there that would have been nice to have.
There's an off chance that I'll send it out tomorrow, depends on timing.

-- 
Jens Axboe

Re: [GIT PULL] Block fixes for 5.9-rc2

[Linus Torvalds]

On Fri, Aug 21, 2020 at 4:01 PM Jens Axboe <axboe@kernel.dk> wrote:
>
> The tree is totally warning clean right now on build, but that's usually
> not the case, and missing a single warning isn't that hard.

Actually, my tree is generally entirely warning-free and has been for
years, because I absolutely hate warnings.

You're not the only person I haven't pulled from because I saw a
single warning. This is the second one just this release window.  I'm
not singling you out. A warning to me is simply a hard "No".

Because I know very well that if there is even a single warning,
people will then ignore the other warnings.

So there is no such thing as a harmless warning - it doesn't matter
_what_ it warns about, it's a bad thing, because even one bogus
warning will then mean that people ignore warnings that _aren't_
bogus, and it goes all downhill from there.

So the reason I notice is exactly because I keep my build tree 100%
clean. I do allmodconfig builds that are entirely clean, and I check
it after each and every pull I do, and each patch series I apply.
Mistakes can happen, but I try _very_ hard to keep my tree clean.

Now, that said, I'll miss warnings too, because I don't do
cross-builds for other architectures, and I really only do a couple of
fairly basic configurations.

But perhaps more importantly - I don't build with a lot of different
compilers. I do in fact test two different compilers (both gcc and
clang), but I use two different configurations, so it's not really
overlapping testing, it's more that these days I make sure the clang
build is warning free at least for the core kernel too.

So "warning free" is always relative to some compiler base (and some
config base). But the baseline should absolutely be "zero warnings".

Generally, new warnings in my tree is because of a compiler upgrade or
similar congifuration issues.

And it's sadly the "different compilers" thing that then means that
*my* clean tree might not then necessarily be clean for others. It's
also why I can't just enable "-Werror" to make it harder to miss.

But I've been tempted. Many times. There's been a couple of times I've
added that "-Werror" to the Makefile, only to never commit it.

But if you have warnings that you see due to different compilers or
configurations, holler. We'll get them fixed.

                     Linus

Re: [GIT PULL] Block fixes for 5.9-rc2

[Jens Axboe]

On 8/21/20 4:45 PM, Linus Torvalds wrote:
> On Fri, Aug 21, 2020 at 3:09 PM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> I had to look for that, because it obviously didn't complain for me.
>> Looks like it's the one in drivers/block/rnbd/rnbd-srv.c which changes
>> from PTR_ERR() to using 'err' which is indeed an int.
> 
> You clearly didn't even build the patch you applied.
> 
> You can claim it's some odd uninteresting file, but then you damn well
> shouldn't have applied the patch if you can't even be bothered to
> compile-test it.
> 
> It really is that simple - this is not some odd configuration that has
> a build problem because it's esoteric.  That file *will* warn if you
> compile it. I don't think you can avoid it.
> 
> So it's literally a patch that cannot have been build-tested AT ALL.
> 
> I don't see why you even make excuses for it.

I'm not trying to make excuses. Should it have been compiled? Yes it
should. Did I miss it because it isn't part of my regular testing? Yes
obviously. Did I assume it was probably fine since multiple people
reviewed it, including the maintainer. Definitely. That doesn't excuse
the fact that it was missed, and it should not have been.

The tree is totally warning clean right now on build, but that's usually
not the case, and missing a single warning isn't that hard. It happens!
I think faulting someone severely for missing a mostly harmless warning
in a driver that can't be considered critical or tier 1 is a little out
there. That's all I'm trying to say.

And FWIW, this isn't some frivolous cleanup patch, it's fixing a real
error handling issue.

> Send me the fixes part of the pull, no new features, and no untested
> garbage.

There are no new features in here! The only patch I'd argue you could
object to is the raw deprecation, which should have gone in for -rc1.
I'm happy to drop that, was only trying to make the deprecation period a
bit longer for it. The majority is pure fixes, and there are a few
cleanups in there that just seem silly to defer when they show up.
You're making this sound like it's some pile of garbage, and frankly I
think that's way out of line.

> And no, I'm not your test build server that you send crap to and then
> when I notice it was broken you try to fix it up.
> 
> So it's your choice. If you want to let it simmer in linux-next for
> better testing and sending it to me for 5.10, I guess that's a choice
> too.
> 
> But I'm very very fed up with people sending me stuff that they didn't
> care enough to even check for warnings for. And no, I don't want to
> get some minimal fixup. I want a clean tree.

Right, and it totally shows since once the beaker flows over, then some
rando gets the wrath. Your delivery sucks, and you need to work on that.
This could have been handled so much better.

I'll rebase and re-test, but it'll be after -rc2.

-- 
Jens Axboe

Re: [GIT PULL] Block fixes for 5.9-rc2

[Linus Torvalds]

On Fri, Aug 21, 2020 at 3:09 PM Jens Axboe <axboe@kernel.dk> wrote:
>
> I had to look for that, because it obviously didn't complain for me.
> Looks like it's the one in drivers/block/rnbd/rnbd-srv.c which changes
> from PTR_ERR() to using 'err' which is indeed an int.

You clearly didn't even build the patch you applied.

You can claim it's some odd uninteresting file, but then you damn well
shouldn't have applied the patch if you can't even be bothered to
compile-test it.

It really is that simple - this is not some odd configuration that has
a build problem because it's esoteric.  That file *will* warn if you
compile it. I don't think you can avoid it.

So it's literally a patch that cannot have been build-tested AT ALL.

I don't see why you even make excuses for it.

Send me the fixes part of the pull, no new features, and no untested garbage.

And no, I'm not your test build server that you send crap to and then
when I notice it was broken you try to fix it up.

So it's your choice. If you want to let it simmer in linux-next for
better testing and sending it to me for 5.10, I guess that's a choice
too.

But I'm very very fed up with people sending me stuff that they didn't
care enough to even check for warnings for. And no, I don't want to
get some minimal fixup. I want a clean tree.

                      Linus

Re: [GIT PULL] Block fixes for 5.9-rc2

[Jens Axboe]

On 8/21/20 3:58 PM, Linus Torvalds wrote:
> On Fri, Aug 21, 2020 at 1:51 PM Jens Axboe <axboe@kernel.dk> wrote:
>>>
>> Some general fixes, and a bit of late stragglers that missed -rc1 and
>> really should have been there. Nothing major, though. I
> 
> Pulled, test-built, and unpulled.
> 
> This crap doesn't even compile cleanly.
> 
> It is printing out an 'int' using '%ld', so nobody could possibly have
> compile-tested this.

I had to look for that, because it obviously didn't complain for me.
Looks like it's the one in drivers/block/rnbd/rnbd-srv.c which changes
from PTR_ERR() to using 'err' which is indeed an int.

> And as I've said elsewhere - compile-testing doesn't mean "show it to
> a compiler".
> 
> It means "look at what the compiler says" too. Otherwise it's not
> compile-testing, it's just throwing it away.
> 
> So send me a properly tested and *MINIMAL* pull request. because I
> will not take this crap, and I will not take anythign that *looks*&
> like this crap.
> 
> Real fixes, and fixes ONLY.

I think you're overreacting here. I *always* test these pulls, it's run
through the test box with the tests there, and it's always running on my
laptop a day or two in advance. Typing it right now from that branch.
Stop making it sound like it's not being tested at all, according to the
above it obviously never saw a compiler which is just blatantly untrue.

I obviously missed a *warning* because I don't have any way to test that
part and it's not part of my config. Hardly seems like a shootable
offense. I have to defer to the maintainer there, which did ack this
patch.

This is all fixes and innocous changes otherwise. My suggestion here
would be:

1) You pull it, change that rnbd mistake at merge time.
2) I queue a patch on top with that single change.

Let me know what you prefer, and can we please tone down the aggression
here?

-- 
Jens Axboe

Re: [GIT PULL] Block fixes for 5.9-rc2

[Linus Torvalds]

On Fri, Aug 21, 2020 at 1:51 PM Jens Axboe <axboe@kernel.dk> wrote:
>>
> Some general fixes, and a bit of late stragglers that missed -rc1 and
> really should have been there. Nothing major, though. I

Pulled, test-built, and unpulled.

This crap doesn't even compile cleanly.

It is printing out an 'int' using '%ld', so nobody could possibly have
compile-tested this.

And as I've said elsewhere - compile-testing doesn't mean "show it to
a compiler".

It means "look at what the compiler says" too. Otherwise it's not
compile-testing, it's just throwing it away.

So send me a properly tested and *MINIMAL* pull request. because I
will not take this crap, and I will not take anythign that *looks*&
like this crap.

Real fixes, and fixes ONLY.

                   Linus

[GIT PULL] Block fixes for 5.9-rc2

[Jens Axboe]

Hi Linus,

Some general fixes, and a bit of late stragglers that missed -rc1 and
really should have been there. Nothing major, though. In detail:

- NVMe pull request from Sagi:
	- nvme completion rework from Christoph and Chao that mostly
	  came from a bit of divergence of how we classify errors related
	  to pathing/retry etc.
	- nvmet passthru fixes from Chaitanya
	- minor nvmet fixes from Amit and I
	- mpath round-robin path selection fix from Martin
	- ignore noiob for zoned devices from Keith
	- minor nvme-fc fix from Tianjia"

- Deprecate /dev/raw*, we've been using O_DIRECT on the block device
  for almost two decades at this point (Christoph).

- BFQ cgroup leak fix (Dmitry)

- Block layer MAINTAINERS addition (Geert)

- Cleanup rpm_status non-enum status (Geert)

- Fix null_blk FUA checking (Hou)

- get_max_io_size() size fix (Keith)

- Fix block page_is_mergeable() for compound pages (Matthew)

- Discard granularity fixes (Ming)

- IO scheduler ordering fix (Ming)

- Misc fixes

Please pull!



The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:

  Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)

are available in the Git repository at:

  git://git.kernel.dk/linux-block.git tags/block-5.9-2020-08-21

for you to fetch changes up to 2113d4f63da33fb960c4e276101a06c1a06c6e5e:

  virtio-blk: Use kobj_to_dev() instead of container_of() (2020-08-21 08:44:51 -0600)

----------------------------------------------------------------
block-5.9-2020-08-21

----------------------------------------------------------------
Amit Engel (1):
      nvmet: Disable keep-alive timer when kato is cleared to 0h

Chaitanya Kulkarni (3):
      nvmet: add ns tear down label for pt-cmd handling
      nvmet: fix oops in pt cmd execution
      nvmet: call blk_mq_free_request() directly

Chao Leng (1):
      nvme: redirect commands on dying queue

Christoph Hellwig (5):
      raw: deprecate the raw driver
      nvme-pci: fix PRP pool size
      nvme: rename and document nvme_end_request
      nvme: refactor command completion
      nvme: just check the status code type in nvme_is_path_error

Dmitry Monakhov (1):
      bfq: fix blkio cgroup leakage v4

Geert Uytterhoeven (2):
      MAINTAINERS: Add missing header files to BLOCK LAYER section
      block: Make request_queue.rpm_status an enum

Hou Pu (1):
      null_blk: fix passing of REQ_FUA flag in null_handle_rq

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

John Garry (1):
      nvme-pci: Use u32 for nvme_dev.q_depth and nvme_queue.q_depth

Keith Busch (2):
      block: fix get_max_io_size()
      nvme: skip noiob for zoned devices

Logan Gunthorpe (2):
      nvmet-passthru: Reject commands with non-sgl flags set
      nvme: Use spin_lock_irq() when taking the ctrl->lock

Martin Wilck (2):
      nvme: multipath: round-robin: fix single non-optimized path case
      nvme: multipath: round-robin: eliminate "fallback" variable

Matthew Wilcox (Oracle) (1):
      block: Fix page_is_mergeable() for compound pages

Miaohe Lin (1):
      block: Convert to use the preferred fallthrough macro

Ming Lei (5):
      blk-mq: order adding requests to hctx->dispatch and checking SCHED_RESTART
      block: loop: set discard granularity and alignment for block device backed loop
      block: respect queue limit of max discard segment
      block: virtio_blk: fix handling single range discard request
      blk-mq: insert request not through ->queue_rq into sw/scheduler queue

Nathan Chancellor (1):
      block/rnbd: Ensure err is always initialized in process_rdma

Randy Dunlap (1):
      block: blk-mq.c: fix @at_head kernel-doc warning

Sagi Grimberg (1):
      nvmet: fix a memory leak

Tian Tao (1):
      virtio-blk: Use kobj_to_dev() instead of container_of()

Tianjia Zhang (1):
      nvme-fc: Fix wrong return value in __nvme_fc_init_request()

Xu Wang (1):
      bsg-lib: convert comma to semicolon

Yufen Yu (1):
      blkcg: fix memleak for iolatency

 .../fault-injection/nvme-fault-injection.rst       |  2 +-
 MAINTAINERS                                        |  1 +
 block/badblocks.c                                  |  2 +-
 block/bfq-cgroup.c                                 |  2 +-
 block/bfq-iosched.c                                |  4 +-
 block/bfq-iosched.h                                |  1 -
 block/bfq-wf2q.c                                   | 12 +--
 block/bio.c                                        | 10 +--
 block/blk-cgroup.c                                 |  8 +-
 block/blk-merge.c                                  | 13 +++-
 block/blk-mq-sched.c                               |  9 +++
 block/blk-mq.c                                     | 13 +++-
 block/blk-wbt.c                                    |  2 +-
 block/bsg-lib.c                                    |  2 +-
 block/ioprio.c                                     |  2 +-
 drivers/block/loop.c                               | 33 +++++----
 drivers/block/null_blk_main.c                      |  2 +-
 drivers/block/rnbd/rnbd-srv.c                      |  3 +-
 drivers/block/virtio_blk.c                         | 33 ++++++---
 drivers/char/raw.c                                 |  5 ++
 drivers/nvme/host/core.c                           | 86 ++++++++++++++--------
 drivers/nvme/host/fc.c                             |  6 +-
 drivers/nvme/host/multipath.c                      | 69 +++++++----------
 drivers/nvme/host/nvme.h                           | 31 +++++++-
 drivers/nvme/host/pci.c                            | 17 +++--
 drivers/nvme/host/rdma.c                           |  2 +-
 drivers/nvme/host/tcp.c                            |  4 +-
 drivers/nvme/target/configfs.c                     |  1 +
 drivers/nvme/target/core.c                         |  6 ++
 drivers/nvme/target/loop.c                         |  2 +-
 drivers/nvme/target/passthru.c                     | 25 +++++--
 include/linux/blkdev.h                             |  3 +-
 32 files changed, 251 insertions(+), 160 deletions(-)

-- 
Jens Axboe