Re: [PATCH V2 3/5] genirq/affinity: move actual irq vector spread into one helper

Can you fix this up and resend? On Tue, Mar 06, 2018 at 12:28:32AM +0800, kbuild test robot wrote: > Hi Ming, > > Thank you for the patch! Perhaps something to improve: > > [auto build test WARNING on tip/irq/core] > [also build test WARNING on v4.16-rc4 next-20180305] > [if your patch is

[PATCH] block: bio_check_eod() needs to consider partition

.com> Signed-off-by: Christoph Hellwig <h...@lst.de> --- block/blk-core.c | 76 ++-- 1 file changed, 30 insertions(+), 46 deletions(-) diff --git a/block/blk-core.c b/block/blk-core.c index 3ba4326a63b5..ba07f970e011 100644 --- a/block/b

Re: [PATCH 3/5] genirq/affinity: support to do irq vectors spread starting from any vector

Looks fine, Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: [PATCH 4/5] genirq/affinity: irq vector spread among online CPUs as far as possible

Looks fine, Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: [PATCH 2/5] genirq/affinity: move actual irq vector spread into one helper

On Tue, Feb 06, 2018 at 08:17:39PM +0800, Ming Lei wrote: > No functional change, just prepare for converting to 2-stage > irq vector spread. > > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Christoph Hellwig <h...@lst.de> > Signed-off-by: Ming Lei <ming...

Re: [PATCH 1/5] genirq/affinity: rename *node_to_possible_cpumask as *node_to_cpumask

Looks good, Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: [PATCH] block: Suppress kernel-doc warnings triggered by blk-zoned.c

Looks good, Reviewed-by: Christoph Hellwig <h...@lst.de> Although I think this should say 'fixes kernel-doc warnings' instead of supressing them, as the old comments use invalid syntax.

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

On Thu, Mar 01, 2018 at 11:53:16PM +, Stephen Bates wrote: > > There's a meaningful difference between writing to an NVMe CMB vs PMR > > When the PMR spec becomes public we can discuss how best to integrate it into > the P2P framework (if at all) ;-).

Re: [PATCH 5/5] nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors

Looks fine, and we should pick this up for 4.16 independent of the rest, which I might need a little more review time for. Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: [PATCH 4/4] block: fix a typo

Looks fine, Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: [PATCH 3/4] block: display the correct diskname for bio

Looks fine, Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: [PATCH 1/4] block: fix the count of PGPGOUT for WRITE_SAME

Looks fine, Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: [PATCH 1/6] genhd: Fix leaked module reference for NVME devices

sary. > > Arguably the function naming here is misleading as put_disk() is *not* > the counterpart of get_disk() but let's fix that in the follow up > commit since that will be more intrusive. Looks good, Reviewed-by: Christoph Hellwig <h...@lst.de>

[GIT PULL] additional nvme updates for 4.16

The additional week before the 4.15 release gave us time for a few more nvme fixes, as well as the nifty trace points from Johannes: The following changes since commit 475a055e62a1eb92f4358ad8a9059df973c190ac: blk-throttle: use queue_is_rq_based (2018-01-19 21:10:20 -0700) are available in

Re: [dm-devel] [PATCH 0/2] dm: add new loop and ram targets

On Wed, Jan 17, 2018 at 08:33:59PM +0100, Heinz Mauelshagen wrote: > Enhancing IO performance compared to the kernels existing > loop driver thus better suiting respective requirements in > test setups, this patch series adds new "loop" and "ram" targets. For a fair comparism vs loop you'll need

Re: [PATCH 1/5] blk-mq: introduce BLK_STS_DEV_RESOURCE

> - if (ret == BLK_STS_RESOURCE) { > + if ((ret == BLK_STS_RESOURCE) || (ret == BLK_STS_DEV_RESOURCE)) > { No need for the inner braces here. > + if ((ret == BLK_STS_RESOURCE) || (ret == BLK_STS_DEV_RESOURCE)) Same here. > +/* > + * This status is returned from

[GIT PULL] additional nvme fixes and cleanups for Linux 4.16

to 88de4598bca84e27b261685c06fff816b8d932a1: nvme-pci: clean up SMBSZ bit definitions (2018-01-17 17:55:14 +0100) Christoph Hellwig (2): nvme-pci: clean up CMB initialization nvme-pci: clean up SMBSZ bit definitions James

Re: [PATCH v2 3/3] block: Protect less code with sysfs_lock in blk_{un,}register_queue()

Looks good, Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: [PATCH v2 2/3] block: Document scheduler modification locking requirements

Looks fine, Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: [PATCH v2 1/3] block: Unexport elv_register_queue() and elv_unregister_queue()

Looks fine, Reviewed-by: Christoph Hellwig <h...@lst.de>

two more nvme fixes for Linux 4.15

Hi Jens, below are the two fixes for the new SGL support in 4.15 as a patch series due to the issues with the git server.

[PATCH 2/2] nvme-pci: take sglist coalescing in dma_map_sg into account

the number of mapped segments into account. Reported-by: Fangjian (Turing) <f.fangj...@huawei.com> Fixes: a7a7cbe3 ("nvme-pci: add SGL support") Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Keith Busch <keith.bu...@intel.com> Reviewed-by: Sagi Grimberg <s..

[PATCH 1/2] nvme-pci: check segement valid for SGL use

-n...@molgen.mpg.de> Reviewed-by: Paul Menzel <pmenzel+linux-n...@molgen.mpg.de> Signed-off-by: Keith Busch <keith.bu...@intel.com> Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/nvme/host/pci.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/dri

Re: [GIT PULL] two more nvme fixes for Linux 4.15

On Wed, Jan 17, 2018 at 01:30:44PM -0700, Jens Axboe wrote: > On 1/17/18 11:36 AM, Christoph Hellwig wrote: > > Hi Jens, > > > > two more last minute fixes for regressions due to the SGL support that > > is new in Linux 4.15. > > >

[GIT PULL] two more nvme fixes for Linux 4.15

) Christoph Hellwig (1): nvme-pci: take sglist coalescing in dma_map_sg into account Keith Busch (1): nvme-pci: check segement valid for SGL use drivers/nvme/host/pci.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-)

[ANNOUNCE] Participate at the Linux FAST Summit '18

with kernel practitioners and/or academics to linuxfast18cha...@usenix.org. Submissions are due by Friday, January 26, 2018. We look forward to receiving your submissions! Christoph Hellwig Erik Riedel, Dell EMC Linux FAST Summit '18 Program Co-Chairs linuxfast18cha...@usenix.org [1] https

Re: [PATCH 0/2] genirq/affinity: try to make sure online CPU is assgined to irq vector

On Tue, Jan 16, 2018 at 12:03:43AM +0800, Ming Lei wrote: > Hi, > > These two patches fixes IO hang issue reported by Laurence. > > 84676c1f21 ("genirq/affinity: assign vectors to all possible CPUs") > may cause one irq vector assigned to all offline CPUs, then this vector > can't handle irq any

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

Thanks for looking into this Ming, I had missed it in the my current work overload. Can you send the updated series to Jens?

Re: [PATCH v2 1/2] block: fail op_is_write() requests to read-only partitions

On Wed, Jan 10, 2018 at 09:34:02AM -0700, Jens Axboe wrote: > It's yet another check that adds part lookup and rcu lock/unlock in that > path. Can we combine some of them? Make this part of the remap? This > overhead impacts every IO, let's not bloat it more than absolutely > necessary. Yes, we

Re: [PATCH v2] block: silently forbid sending any ioctl to a partition

let alone on a partition. > > Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> Nice, thanks! Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: [for-4.16 PATCH v2 2/3] block: cope with gendisk's 'queue' being added later

On Tue, Jan 09, 2018 at 09:41:03PM -0500, Mike Snitzer wrote: > Since I can remember DM has forced the block layer to allow the > allocation and initialization of the request_queue to be distinct > operations. Reason for this was block/genhd.c:add_disk() has required > that the request_queue (and

Re: [for-4.16 PATCH v2 1/3] block: only bdi_unregister() in del_gendisk() if !GENHD_FL_HIDDEN

It's in fact completely harmless :) But not even calling it obviously is just as fine.

Re: [PATCHv2 0/5] nvme/dm failover unification

The whole series looks fine to me: Reviewed-by: Christoph Hellwig <h...@lst.de> Jens, do you want me to apply this to the nvme tree, or pick it up directly?

Re: [PATCH 2/5] nvme/multipath: Consult blk_status_t for failover

On Tue, Jan 09, 2018 at 10:38:58AM -0700, Keith Busch wrote: > On Mon, Jan 08, 2018 at 01:57:07AM -0800, Christoph Hellwig wrote: > > > - if (unlikely(nvme_req(req)->status && nvme_req_needs_retry(req))) { > > > - if (nvme_req_needs_failover(req

Re: [PATCH 06/12] IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]()

On Mon, Jan 08, 2018 at 12:05:57PM -0700, Logan Gunthorpe wrote: > Ok, so if we shouldn't touch the dma_map infrastructure how should the > workaround to opt-out HFI and QIB look? I'm not that familiar with the RDMA > code. We can add a no_p2p quirk, I'm just not sure what the right place for

Re: [PATCH 06/12] IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]()

On Mon, Jan 08, 2018 at 11:44:41AM -0700, Logan Gunthorpe wrote: >> Think about what the dma mapping routines do: >> >> (a) translate from host address to bus addresses >> >> and >> >> (b) flush caches (in non-coherent architectures) >> >> Both are obviously not needed for P2P transfers, as

[GIT PULL] nvme fixes for Linux 4.16

Hi Jens, below are the pending nvme updates for Linux 4.16. Just fixes and cleanups from various contributors this time around. The following changes since commit fb350e0ad99359768e1e80b4784692031ec340e4: blk-mq: fix race between updating nr_hw_queues and switching io sched (2018-01-06

Re: [PATCH 06/12] IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]()

On Mon, Jan 08, 2018 at 11:09:17AM -0700, Jason Gunthorpe wrote: > > As usual we implement what actually has a consumer. On top of that the > > R/W API is the only core RDMA API that actually does DMA mapping for the > > ULP at the moment. > > Well again the same can be said for dma_map_page vs

Re: [PATCH 1/5] nvme: Add more command status translation

On Mon, Jan 08, 2018 at 10:29:33AM -0500, Mike Snitzer wrote: > No argument needed. Definitely needs fixing. Too many upper layers > consider BLK_STS_NOSPC retryable (XFS, ext4, dm-thinp, etc). Which > NVME_SC_LBA_RANGE absolutely isn't. > > When I backfilled NVME_SC_LBA_RANGE handling I

Re: [PATCH 06/12] IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]()

On Thu, Jan 04, 2018 at 09:50:31PM -0700, Jason Gunthorpe wrote: > Well that argument applies equally to the RDMA RW API wrappers around > the DMA API. I think it is fine if sgl are defined to only have P2P or > not, and that debugging support seemed reasonable to me.. > > > It's also very

Re: [GIT PULL 24/25] lightnvm: pblk: add iostat support

On Fri, Jan 05, 2018 at 07:33:36PM +0100, Matias Bjørling wrote: > On 01/05/2018 04:42 PM, Jens Axboe wrote: > > On Fri, Jan 05 2018, Matias Bjørling wrote: > > > From: Javier González > > > > > > Since pblk registers its own block device, the iostat accounting is > > > not

Re: [PATCH 0/4] mylex: Replace DAC960 block driver

Btw, did you manage to get any further with these new drivers?

Re: [PATCH 1/5] nvme: Add more command status translation

On Mon, Jan 08, 2018 at 11:09:03AM +0100, Hannes Reinecke wrote: > >>case NVME_SC_SUCCESS: > >>return BLK_STS_OK; > >>case NVME_SC_CAP_EXCEEDED: > >> + case NVME_SC_LBA_RANGE: > >>return BLK_STS_NOSPC; > > > > lba range isn't really enospc. It is returned when

Re: [PATCH 0/5] Failover criteria unification

On Thu, Jan 04, 2018 at 04:47:27PM -0700, Keith Busch wrote: > It looks like you can also touch up dm to allow it to multipath nvme > even if CONFIG_NVME_MULTIPATH is set. It may be useful since native NVMe > doesn't multipath namespaces across subsystems, and some crack smoking > people want to

Re: [PATCH 2/5] nvme/multipath: Consult blk_status_t for failover

> - if (unlikely(nvme_req(req)->status && nvme_req_needs_retry(req))) { > - if (nvme_req_needs_failover(req)) { > + blk_status_t status = nvme_error_status(req); > + > + if (unlikely(status != BLK_STS_OK && nvme_req_needs_retry(req))) { > + if

[GIT PULL] nvme fixes for Linux 4.15

Hi Jens, I have a few more small nvme fixes for you for Linux 4.15: The following changes since commit 6d0e4827b72afc71349784336d5eb6df4df106e6: Revert "bdi: add error handle for bdi_debug_register" (2017-12-21 10:01:30 -0700) are available in the git repository at:

Re: [PATCH] block: loop: remove & invalidate partitions when detaching

On Thu, Jan 04, 2018 at 06:39:24PM +0800, Ming Lei wrote: > When detaching loop disk, neither we remove loop partitions, nor > invalidate them. This way may cause data loss, and often confuse > people. > > This patch fixes the above issue by removing & invalidating loop > partitions in

Re: [for-4.16 PATCH v2 1/5] block: establish request failover callback

On Fri, Dec 29, 2017 at 03:19:04PM -0500, Mike Snitzer wrote: > On Fri, Dec 29 2017 at 5:10am -0500, > Christoph Hellwig <h...@lst.de> wrote: > > > On Tue, Dec 26, 2017 at 10:22:53PM -0500, Mike Snitzer wrote: > > > All requests allocated from a request_qu

Re: [for-4.16 PATCH v2 0/5] block, nvme, dm: allow DM multipath to use NVMe's error handler

On Tue, Jan 02, 2018 at 04:29:43PM -0700, Keith Busch wrote: > Instead of hiding NVMe path related errors, the NVMe driver needs to > code an appropriate generic block status from an NVMe status. > > We already do this translation whether or not CONFIG_NVME_MULTIPATHING is > set, so I think it's

Re: [for-4.16 PATCH v2 2/5] nvme: use request_queue's failover_rq_fn callback for multipath failover

Independent on any policy question as raised in reply to the previous patch: until the ANA (ALUA equivalent for NVMe) spec has been finalized and our code for it has landed there is no way we're going to expose anything from this code based as it will be highly in flux.

Re: [for-4.16 PATCH v2 1/5] block: establish request failover callback

On Tue, Dec 26, 2017 at 10:22:53PM -0500, Mike Snitzer wrote: > All requests allocated from a request_queue with this callback set can > failover their requests during completion. > > This callback is expected to use the blk_steal_bios() interface to > transfer a request's bios back to an

Re: [PATCH V2 5/6] blk-mq: fix race between updating nr_hw_queues and switching io sched

Looks good, Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: [PATCH V2 3/6] blk-mq: quiesce queue during switching io sched and updating nr_requests

Looks good, Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: [PATCH V2 4/6] blk-mq: avoid to map CPU into stale hw queue

Looks good, Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: [PATCH V2 2/6] blk-mq: support concurrent blk_mq_quiesce_queue()

The quiesce count looks good to me. But I'm really worried about the force unquiesce in nvme. I'd feel much better if we could find a way to move this into the core.

Re: [PATCH V2 1/6] blk-mq: quiesce queue before freeing queue

Looks good, Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: [PATCH 3/3] block: Polling completion performance optimization

On Thu, Dec 21, 2017 at 02:34:00PM -0700, Keith Busch wrote: > It would be nice, but the driver doesn't know a request's completion > is going to be a polled. We can trivially set a REQ_POLL bit. In fact my initial patch kit had those on the insitence of Jens, but then I removed it because we

Re: [PATCH 2/3] nvme/pci: Remove cq_vector check in IO path

On Wed, Dec 27, 2017 at 11:01:48PM +0200, Sagi Grimberg wrote: > >> Awesome! >> >> Reviewed-by: Sagi Grimberg > > Wait, aren't we unquiesce queues also in nvme_dev_disable? > > Doesn't that rely that the queues are suspended and queue_rq > will fail there? We don't seem to have

Re: [PATCH 1/3] nvme/pci: Start request after doorbell ring

On Mon, Dec 25, 2017 at 12:12:52PM +0200, Sagi Grimberg wrote: > >>> But that does bring up the fact if we should always be doing the >>> nvme_process_cq(nvmeq) after IO submission. For direct/hipri IO, >>> maybe it's better to make the submission path faster and skip it? >> >> Yes, I am okay to

Re: [PATCH 1/3] nvme/pci: Start request after doorbell ring

Looks fine, although I agree a comment on the q_lock exclusion would be useful.

[GIT PULLL] nvme fixes for Linux 4.15

Hi Jens, below are a couple important one or two liners fixes for Linux 4.15: The following changes since commit fcf38cdf332a81b20a59e3ebaea81f6b316bbe0c: kyber: fix another domain token wait queue hang (2017-12-06 12:33:07 -0700) are available in the git repository at:

Re: [PATCH 6/6] nvme: remove .init_request callback

On Tue, Dec 12, 2017 at 07:02:32PM +0800, Ming Lei wrote: > It may cause race by setting 'nvmeq' in nvme_init_request() > because .init_request is called inside switching io scheduler, which > may happen when the NVMe device is being resetted and its nvme queues > are being freed and created. We

Re: [PATCH 4/6] blk-mq: avoid to map CPU into stale hw queue

On Tue, Dec 12, 2017 at 07:02:30PM +0800, Ming Lei wrote: > blk_mq_pci_map_queues() may not map one CPU into any hw queue, but its > previous map isn't cleared yet, and may point to one stale hw queue > index. > > This patch fixes the following issue by clearing the mapping table before > setting

Re: [PATCH 00/10] block: cleanup on direct access to bvec table(prepare for multipage bvec)

Most of this looks sane, but I'd really like to see it in context of the actual multipage bvec patches. Do you have an updated branch on top of these?

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

On Wed, Dec 06, 2017 at 01:25:11PM +0100, Christian Borntraeger wrote: t > commit 11b2025c3326f7096ceb588c3117c7883850c068-> bad > blk-mq: create a blk_mq_ctx for each possible CPU > does not boot on DASD and > commit 9c6ae239e01ae9a9f8657f05c55c4372e9fc8bcc-> good >

[PATCH 2/3] arm64: don't override dma_max_pfn

The generic version now takes dma_pfn_offset into account, so there is no more need for an architecture override. Signed-off-by: Christoph Hellwig <h...@lst.de> --- arch/arm64/include/asm/dma-mapping.h | 9 - 1 file changed, 9 deletions(-) diff --git a/arch/arm64/include/a

[PATCH 1/3] dma-mapping: take dma_pfn_offset into account in dma_max_pfn

This makes sure the generic version can be used with architectures / devices that have a DMA offset in the direct mapping. Signed-off-by: Christoph Hellwig <h...@lst.de> --- include/linux/dma-mapping.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/lin

[PATCH 3/3] dma-mapping: replace PCI_DMA_BUS_IS_PHYS with a flag in struct dma_map_ops

by it on a few architectures. Note that this means that we now need a struct device parent in the Scsi_Host or netdevice. Every modern driver has these, but there might still be a few outdated legacy drivers out there, which now won't make an intelligent decision. Signed-off-by: Christoph Hellwig &l

replace PCI_DMA_BUS_IS_PHYS with a per-instance flag

Hi all, this small series tries to get rid of the global and misnamed PCI_DMA_BUS_IS_PHYS flag, and replace it with a setting in each struct dma_map_ops instance.

Re: [PATCH] um: Convert ubd driver to blk-mq

On Sun, Dec 03, 2017 at 10:49:23PM +0100, Richard Weinberger wrote: > Convert the driver to the modern blk-mq framework. > As byproduct we get rid of our open coded restart logic and let > blk-mq handle it. > > Signed-off-by: Richard Weinberger > --- > arch/um/drivers/ubd_kern.c

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

On Wed, Nov 29, 2017 at 08:18:09PM +0100, Christian Borntraeger wrote: > Works fine under KVM with virtio-blk, but still hangs during boot in an LPAR. > FWIW, the system not only has scsi disks via fcp but also DASDs as a boot > disk. > Seems that this is the place where the system stops. (see

Re: [PATCH] [RFC] um: Convert ubd driver to blk-mq

On Sun, Nov 26, 2017 at 02:10:53PM +0100, Richard Weinberger wrote: > MAX_SG is 64, used for blk_queue_max_segments(). This comes from > a0044bdf60c2 ("uml: batch I/O requests"). Is this still a good/sane > value for blk-mq? blk-mq itself doesn't change the tradeoff. > The driver does IO

Re: [PATCH 2/4] bcache: Fix building error on MIPS

> diff --git a/include/uapi/linux/bcache.h b/include/uapi/linux/bcache.h > index 90fc490f973f..821f71a2e48f 100644 > --- a/include/uapi/linux/bcache.h > +++ b/include/uapi/linux/bcache.h > @@ -91,7 +91,7 @@ PTR_FIELD(PTR_GEN, 0, 8) > > #define PTR_CHECK_DEV

Re: [PATCH] block: Add default switch case to blk_pm_allow_request() to kill warning

What an annoying compiler :) But otherwise this looks good: Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

On Thu, Nov 23, 2017 at 07:28:31PM +0100, Christian Borntraeger wrote: > zfcp on s390. Ok, so it can't be the interrupt code, but probably is the blk-mq-cpumap.c changes. Can you try to revert just those for a quick test?

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

What HBA driver do you use in the host?

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

[fullquote deleted] > What will happen for the CPU hotplug case? > Wouldn't we route I/O to a disabled CPU with this patch? Why would we route I/O to a disabled CPU (we generally route I/O to devices to start with). How would including possible but not present cpus change anything?

[GIT PULL] nvme fixes for Linux 4.15

Hi Jens, a couple nvme fixes for 4.15: - expand the queue ready fix that we only had for RDMA to also cover FC and loop by moving it to common code (Sagi) - fix an array out of bounds in the PCIe HMB code (Minwoo Im) - two new device quirks (Jeff Lien and Kai-Heng Feng) - static checkers

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

FYI, the patch below changes both the irq and block mappings to always use the cpu possible map (should be split in two in due time). I think this is the right way forward. For every normal machine those two are the same, but for VMs with maxcpus above their normal count or some big iron that

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

Ok, it helps to make sure we're actually doing I/O from the CPU, I've reproduced it now.

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

I can't reproduce it in my VM with adding a new CPU. Do you have any interesting blk-mq like actually using multiple queues? I'll give that a spin next.

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

Jens, please don't just revert the commit in your for-linus tree. On its own this will totally mess up the interrupt assignments. Give me a bit of time to sort this out properly.

Re: [RFC PATCH 0/2] apply write hints to select the type of segments

Next time please coordinate this with the block list and Jens, who actually wrote the patch. > hints segment type > - > WRITE_LIFE_SHORT CURSEG_COLD_DATA > WRITE_LIFE_EXTREMECURSEG_HOT_DATA > others

Re: Regression in 4.14: wrong data being read from bcache device

On Thu, Nov 16, 2017 at 07:07:40PM -0800, Michael Lyle wrote: > I think the probable cause is this: we construct bios based on > previously completed bios in a few places, That is an extremely bad idea in many ways, so I think we'll need to fix this as the priority.

Re: for-4.15/block rebased

Yikes. Can you at least re-pull the nvme bits so we can keep the original commit dates for those? Those actually are a huge part of the rebased commits, and that way we might not get Linus shouting at us this merge window at least.. On Fri, Nov 10, 2017 at 08:02:00PM -0700, Jens Axboe wrote: >

Re: [PATCH] blk-mq: only run the hardware queue if IO is pending

On Fri, Nov 10, 2017 at 10:31:29AM -0700, Jens Axboe wrote: > On 11/10/2017 10:29 AM, Christoph Hellwig wrote: > > On Fri, Nov 10, 2017 at 09:12:18AM -0700, Jens Axboe wrote: > >> Currently we are inconsistent in when we decide to run the queue. Using > >> blk_

Re: [GIT PULL] nvme updates for Linux 4.15

On Fri, Nov 10, 2017 at 10:27:24AM -0700, Jens Axboe wrote: > That makes for a bit of an awkward merge, why wasn't this fixed up > in your tree? Because you asked me to always base on for-4.15/block last time?

Re: [PATCH] blk-mq: only run the hardware queue if IO is pending

e CPU overhead of blk-mq. > > Move the has-pending check into the run function instead of having > callers do it. > > Signed-off-by: Jens Axboe <ax...@kernel.dk> Do we even still need the blk_mq_hctx_has_pending helper at all? Except for that this looks fine to me: Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: [GIT PULL] nvme updates for Linux 4.15

On Fri, Nov 10, 2017 at 08:22:32AM -0700, Jens Axboe wrote: > Actually, double checking, one of them is a little suspicious: > > if (a == _attr_uuid.attr) { > <<< HEAD > if (uuid_is_null(>uuid) && > !memchr_inv(ns->nguid, 0, sizeof(ns->nguid))) >

[GIT PULL] nvme updates for Linux 4.15

: nvme: expose subsys attribute to sysfs (2017-11-10 12:16:19 +0100) Christoph Hellwig (14): nvme: move the dying queue check from cancel to completion nvme: always unregister the integrity profile in __nvme_revalidate_disk

Re: nvme multipath support V7

I've updated the git tree with the Kconfig type fix, the instance fixup from Keith (plus extensive comments explaning the issue) and the various reviews. I'll wait for the buildbot a and do a little more manual testing and will send it to Jens in the afternoon.

Re: [PATCH] block: avoid null pointer dereference on null disk

Looks good, Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: [PATCH 4/7] nvme: implement multipath access to nvme subsystems

On Fri, Nov 10, 2017 at 05:52:36AM +0100, Christoph Hellwig wrote: > > If we've CMIC capabilities, we'll use the subsys->instance; if we don't > > have CMIC, we use the ctrl->instance. > > > > Since the two instances are independent of each other, they

Re: [PATCH 4/7] nvme: implement multipath access to nvme subsystems

On Thu, Nov 09, 2017 at 04:22:17PM -0500, Mike Snitzer wrote: > Your 0th header speaks to the NVMe multipath IO path leveraging NVMe's > lack of partial completion but I think it'd be useful to have this > header (that actually gets committed) speak to it. There is a comment above blk_steal_bios

Re: [PATCH 4/7] nvme: implement multipath access to nvme subsystems

> If we've CMIC capabilities, we'll use the subsys->instance; if we don't > have CMIC, we use the ctrl->instance. > > Since the two instances are independent of each other, they can create > duplicate names. > > To fix, I think we'll need to always use the subsys instance for > consistency if

[PATCH 4/7] nvme: implement multipath access to nvme subsystems

it alive needs to be implemented at the controller level. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/nvme/host/Kconfig | 9 ++ drivers/nvme/host/Makefile| 1 + drivers/nvme/host/core.c | 133 +++--- drivers/nvme/host/multipath.c

[PATCH 5/7] nvme: also expose the namespace identification sysfs files for mpath nodes

We do this by adding a helper that returns the ns_head for a device that can belong to either the per-controller or per-subsystem block device nodes, and otherwise reuse all the existing code. Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Keith Busch <keith.bu...@intel.com&

[PATCH 3/7] nvme: track shared namespaces

. Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Keith Busch <keith.bu...@intel.com> Reviewed-by: Javier González <jav...@cnexlabs.com> Reviewed-by: Sagi Grimberg <s...@grimberg.me> Reviewed-by: Johannes Thumshirn <jthumsh...@suse.de> Reviewed-by:

nvme multipath support V7

Hi all, this series adds support for multipathing, that is accessing nvme namespaces through multiple controllers to the nvme core driver. I think we are pretty much done with with very little changes in the last reposts. Unless I hear objections I plan to send this to Jens tomorrow with the

[PATCH 7/7] nvme: create 'slaves' and 'holders' entries for hidden controllers

ltipath code] Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/nvme/host/core.c | 2 ++ drivers/nvme/host/multipath.c | 30 ++ drivers/nvme/host/nvme.h | 8 3 files changed, 40 insertions(+) diff --git a/drivers/nvme/host/core.c b

<    3   4   5   6   7   8   9   10   11   12   >