From: Liu Jiang
Previously msi_domain_alloc() assumes MSI irqdomains always have parent
irqdomains, but that's not true for the new Intel VMD devices. So relax
msi_domain_alloc() to support parentless MSI irqdomains.
Signed-off-by: Jiang Liu
Tested-by: Keith Busch
---
kernel/irq/msi.c | 8
And use the max bus resource from the parent rather than assume 255.
Signed-off-by: Keith Busch
---
drivers/pci/probe.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index f14a970..ae5a4b3 100644
--- a/drivers/pci
ngs.
Commended the potential list corruption if NMI, interrupt, and irq
teardown occur concurrently.
Using raw spinlock for irq list manipulation.
Fix IRQ flags: removed IRQF_SHARED.
Fixed the SoB in patch 1, added my Tested-by.
Keith Busch (5):
pci: skip child bus with conflicting resour
es should either not be placed below VMD-owned
root ports, or VMD should be disabled by BIOS for such endpoints.
Signed-off-by: Keith Busch
---
arch/x86/Kconfig | 13 +
arch/x86/include/asm/hw_irq.h | 5 +
arch/x86/pci/Makefile | 2 +
arch/
PCI-e segments will continue to use the lower 16 bits as required by
ACPI. Special domains may use the full 32-bits.
Signed-off-by: Keith Busch
---
lib/filter.c |2 +-
lib/pci.h|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/filter.c b/lib/filter.c
index
New x86 pci h/w will require dma operations specific to that domain. This
patch allows those domains to register their operations, and sets devices
as they are discovere3d in that domain to use them.
Signed-off-by: Keith Busch
---
arch/x86/include/asm/device.h | 10 ++
arch/x86/pci
Signed-off-by: Keith Busch
---
drivers/pci/msi.c | 2 ++
kernel/irq/irqdomain.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 45a5148..1aa1ad4 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1120,6 +1120,7 @@ struct pci_dev
On Fri, Nov 13, 2015 at 04:27:07PM -0500, Thomas Gleixner wrote:
> On Fri, 13 Nov 2015, Keith Busch wrote:
> > +/**
> > + * struct vmd_irq_list - list of driver requested irq's mapping to a vmd
> > vector
> > + * _list: list of child irq's the VMD one demuxes to.
&
On Fri, 2 Oct 2015, Johannes Thumshirn wrote:
Lee Duncan writes:
Simplify ida index allocation and removal by
using the ida_simple_* helper functions.
Looks good to me. Just one comment:
static void nvme_release_instance(struct nvme_dev *dev)
{
spin_lock(_list_lock);
-
On Wed, Dec 02, 2015 at 02:07:34PM -0700, Jens Axboe wrote:
> Christoph, for-4.5/nvme also fails if integrity isn't enabled:
I forgot about this since I've merged this in my repo to fix:
https://lkml.org/lkml/2015/10/26/546
That ok, or should we handle this differently?
--
To unsubscribe from
On Sat, Feb 06, 2016 at 02:32:24PM +, Wenbo Wang wrote:
> Keith,
>
> Is the following solution OK?
> synchronize_rcu guarantee that no queue_rq is running concurrently with
> device disable code. Together with your another patch (adding
> blk_sync_queue), both sync/async path shall be
On Mon, Feb 08, 2016 at 11:13:50AM +0100, Christoph Hellwig wrote:
> On Mon, Feb 08, 2016 at 12:01:16PM +0200, Sagi Grimberg wrote:
> >
> >> Do we have defined sysfs attributes for NVMe devices nowadays?
> >
> > /sys/block/nvme0n1/uuid
>
> That's only supported for NVMe 1.1 and higher devices,
On Mon, Feb 08, 2016 at 04:19:13PM +0100, Hannes Reinecke wrote:
> Ok, so what about having a 'wwid' attribute which provides combined
> information (like scsi has)?
That looks like the sensible thing to do. Thanks for pointer.
Going forward, I will solicite more feedback from scsi developers
so
On Tue, Feb 09, 2016 at 11:22:04AM +, Wenbo Wang wrote:
> In most cases, rcu read lock is just a preempt_disable, which is what get_cpu
> does. I don't see any risk.
Yes, many rcu_read_lock cases expand similarly to get_cpu. What about
the other cases?
FWIW, I don't think we'll hit the
ar
> case, the init ordering remains unchanged with this commit.
>
> We also delete the MODULE_LICENSE tag etc. since all that information
> was (or is now) contained at the top of the file in the comments.
Thanks for cleaning this up.
FWIW, all of the other pcie service drivers look like they could use
the same cleanup.
Reviewed-by: Keith Busch
On Fri, Aug 05, 2016 at 12:03:23PM -0700, Marc MERLIN wrote:
> Would this patch make sense as being the reason why I can't S3 sleep
> anymore and would you have a test patch against 4.5, 4.6, or 4.7 I can
> try to see if it fixes the problem?
Hi Marc,
It might be blk-mq's hot cpu notifier is
On Tue, Aug 16, 2016 at 01:45:03PM -0700, J Freyensee wrote:
> On Mon, 2016-08-15 at 22:41 -0300, Helen Koike wrote:
> > struct nvmf_connect_command connect;
> > struct nvmf_property_set_command prop_set;
> > struct nvmf_property_get_command prop_get;
> > +
On Mon, Aug 15, 2016 at 05:21:07AM +, Wenbo Wang wrote:
> Keith,
>
> Is this patch accepted? Thanks.
The patch looks fine, though Jens has to apply these. I'm just an
ostensibly glorified reviewer. :)
Reviewed-by: Keith Busch
On Sat, May 21, 2016 at 01:36:00AM +0300, Alexey Khoroshilov wrote:
> kref_put(>kref, nvme_free_ns) is called in nvme_get_ns_from_disk()
> under dev_list_lock spinlock, while nvme_free_ns() locks the spinlock
> by itself. This can lead to a deadlock.
>
> The patch moves try_module_get() and its
On Sun, Jun 19, 2016 at 04:06:31PM -0700, Jethro Beekman wrote:
> If an NVMe drive is locked with ATA Security, most commands sent to the drive
> will fail. This includes commands sent by the kernel upon discovery to probe
> for partitions. The failing happens in such a way that trying to do
On Mon, Jun 20, 2016 at 11:21:09AM -0700, Jethro Beekman wrote:
> On 20-06-16 08:26, Keith Busch wrote:
>
> Would this just be a matter of setting req->retries and checking for it in
> nvme_req_needs_retry? How does one keep track of the number of tries so far?
I just sent a pa
On Wed, Jun 15, 2016 at 10:50:53PM +0200, Bart Van Assche wrote:
> Does it matter on x86 systems whether or not these interrupt vectors are
> also associated with a CPU with a higher CPU number? Although multiple bits
> can be set in /proc/irq//smp_affinity only the first bit counts on x86
>
to randomness since they are
not random.
Signed-off-by: Keith Busch
---
include/linux/irq.h| 1 +
kernel/irq/chip.c | 43 +++
kernel/irq/handle.c| 18 ++
kernel/irq/internals.h | 1 +
4 files changed, 59 insertions(+), 4
t;, but do
not want to force a system setting just to keep this domain functional.
Signed-off-by: Keith Busch
---
arch/x86/pci/vmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/pci/vmd.c b/arch/x86/pci/vmd.c
index 7792aba..613cac7 100644
--- a/arch/x86/pci/vmd.c
+++ b/ar
On Thu, Mar 17, 2016 at 12:20:28PM +0100, Vitaly Kuznetsov wrote:
> Keith Busch writes:
> > been combined. In any case, I think you can get what you're after just
> > by moving the gap check after BIOVEC_PHYS_MERGABLE. Does the following
> > look ok to you?
> >
>
&g
On Wed, Mar 16, 2016 at 05:26:28PM +0100, Vitaly Kuznetsov wrote:
> Ming Lei writes:
> > We do have the above merge in bio_add_page(), so the two bios in
> > your above example shouldn't have been observed if the two buffers
> > are added to bio via the bio_add_page().
> >
> > If you see short
On Tue, Mar 15, 2016 at 04:17:56PM +0100, Vitaly Kuznetsov wrote:
> The reason of the slowdown is the fact that bios don't get merged and we
> end up sending many short requests to the host. My investigation led me to
> the following code (__bvec_gap_to_prev()):
>
> return offset ||
>
On Tue, Feb 02, 2016 at 02:41:37PM +0200, Sagi Grimberg wrote:
> First of all, I think we need to cancel all
> inflight requests before nvme_dev_unmap.
IO cancelling is where it is because it protects against host memory
corruption. If you're going to mess with the ordering, just make sure
the
On Tue, Feb 02, 2016 at 04:33:10PM +0200, Sagi Grimberg wrote:
> Hey Keith,
>
> >>First of all, I think we need to cancel all
> >>inflight requests before nvme_dev_unmap.
> >
> >IO cancelling is where it is because it protects against host memory
> >corruption. If you're going to mess with the
On Tue, Feb 02, 2016 at 07:15:57AM +, Wenbo Wang wrote:
> Jens,
>
> I did the following test to validate the issue.
>
> 1. Modify code as below to increase the chance of races.
> Add 10s delay after nvme_dev_unmap() in nvme_dev_disable()
> Add 10s delay before __nvme_submit_cmd()
On Tue, Feb 02, 2016 at 07:15:57AM +, Wenbo Wang wrote:
> I did the following test to validate the issue.
>
> 1. Modify code as below to increase the chance of races.
> Add 10s delay after nvme_dev_unmap() in nvme_dev_disable()
> Add 10s delay before __nvme_submit_cmd()
> 2. Run
On Wed, Feb 03, 2016 at 04:35:03PM +, Wenbo Wang wrote:
> For async io (executed by run_work worker) it should work. However for sync
> io in blk_mq_run_hw_queue, this seems not help, there is still a window.
Alright, for lack of a better way to sync a stopped queue, the driver's
indication
On Mon, Feb 22, 2016 at 04:10:24PM -0600, Bjorn Helgaas wrote:
> I'm not sure how to deal with the question of a hot-added VMD. Maybe
> all we can do now is add a comment to the effect that we assume BIOS
> has assigned the non-prefetchable BAR below 4GB, and if Linux assigns
> that BAR for
On Tue, Feb 23, 2016 at 02:50:13PM -0700, Jon Derrick wrote:
> This patch attaches the new VMD domain's resources to the VMD device's
> resources. This allows /proc/iomem to display a more complete picture.
>
> Before:
> c000-c1ff : :5d:05.5
> c200-c3ff : :5d:05.5
>
On Thu, Feb 25, 2016 at 08:42:19AM -0600, Bjorn Helgaas wrote:
> On Tue, Feb 23, 2016 at 06:24:00PM +0000, Keith Busch wrote:
> > On Mon, Feb 22, 2016 at 04:10:24PM -0600, Bjorn Helgaas wrote:
> > > + /*
> > > + * If the window is below 4GB, clear IORESOURCE_MEM_64 so w
ith
On Thu, Feb 25, 2016 at 08:42:19AM -0600, Bjorn Helgaas wrote:
> On Tue, Feb 23, 2016 at 06:24:00PM +, Keith Busch wrote:
> > On Mon, Feb 22, 2016 at 04:10:24PM -0600, Bjorn Helgaas wrote:
> > > I'm not sure how to deal with the question of a hot-added VMD. Maybe
> >
On Mon, Jun 06, 2016 at 11:23:35PM +0200, Christoph Hellwig wrote:
> To connect to all NVMe over Fabrics controller reachable on a given taget
> port using RDMA/CM use the following command:
>
> nvme connect-all -t rdma -a $IPADDR
>
> This requires the latest version of nvme-cli with
On Mon, Jun 06, 2016 at 11:21:52PM +0200, Christoph Hellwig wrote:
> +struct request *blk_mq_alloc_request_hctx(struct request_queue *q, int rw,
> + unsigned int flags, unsigned int hctx_idx)
> +{
> + struct blk_mq_hw_ctx *hctx;
> + struct blk_mq_ctx *ctx;
> + struct
On Tue, May 24, 2016 at 02:19:17AM -0700, Christoph Hellwig wrote:
> On Tue, May 24, 2016 at 11:15:52AM +0200, Johannes Thumshirn wrote:
> > As I've probably missed v4.7, is it possible to get it for v4.8?
> > Or should I take on the PCI helper functions Christoph suggested first?
>
> Let's get
On Wed, Jun 15, 2016 at 12:42:53PM +0200, Bart Van Assche wrote:
> Today irqbalanced is responsible for deciding how to assign interrupts from
> different adapters to CPU cores. Does the above mean that for adapters that
> support multiple MSI-X interrupts the kernel will have full responsibility
On Wed, Jun 15, 2016 at 05:28:54PM +0200, Bart Van Assche wrote:
> On 06/15/2016 05:14 PM, Keith Busch wrote:
> >I think the idea is have the irq_affinity mask match the CPU mapping on
> >the submission side context associated with that particular vector. If
> >two identi
On Wed, Jun 15, 2016 at 09:36:54PM +0200, Bart Van Assche wrote:
> Sorry that I had not yet this made this clear but my concern is about a
> system equipped with two or more adapters and with more CPU cores than the
> number of MSI-X interrupts per adapter. Consider e.g. a system with two
>
On Wed, Jun 15, 2016 at 04:06:55PM -0400, Keith Busch wrote:
> >
> > 0: A0 B0
> > 1: A1 B1
> > 2: A2 B2
> > 3: A3 B3
> > 4: A4 B4
> > 5: A5 B5
> > 6: A6 B6
> > 7: A7 B7
> > 8: (none)
> > ...
> > 31: (none)
>
> I
quired by the NVMe target
> - more helpers in core code that can be used by various transports
> - add some missing constants and identify attributes
This series looks good.
Reviewed-by: Keith Busch
For patch ordering, I had thought there were no issues with these
I submitted:
http://lists
This creates a system memory reclaim work queue and has lru_add_drain_all
use this new work queue. This allows memory reclaim work that invalidates
block devices to flush all lru add caches without triggering the
check_flush_dependency warning.
Signed-off-by: Keith Busch
---
This is similar
On Tue, May 31, 2016 at 05:01:16PM -0400, Tejun Heo wrote:
> So, WQ_MEM_RECLAIM on a shared workqueue doesn't make much sense.
> That flag guarantees single concurrency level to the workqueue. How
> would multiple users of a shared workqueue coordinate around that?
> What prevents one
On Thu, Nov 05, 2015 at 02:35:31PM +0800, Jiang Liu wrote:
> Hi Keith,
> Could you please try the attached patch?
> Thanks!
> Gerry
Thanks! I anticipated this and tested the same thing yesterday, and it
is successful.
I'll apply to the series and send a new revision hopefully today. Not
ut it's
> very useful for testing. For now, it's a per-device opt-in feature.
> To enable it, you echo 1 to /sys/block//queue/io_poll.
This really looks good. I verified similar performance improvements on
various NVMe controller types as well.
Acked-by: Keith Busch
--
To unsubscribe fr
PCI-e segments will continue to use the lower 16 bits as required by
ACPI. Special domains may use the full 32-bits.
Signed-off-by: Keith Busch
---
lib/filter.c |2 +-
lib/pci.h|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/filter.c b/lib/filter.c
index
New x86 pci h/w will require DMA operations specific to that domain. This
patch allows those domains to register their operations, and sets devices
as they are discovered in that domain to use them.
Signed-off-by: Keith Busch
---
arch/x86/include/asm/device.h | 10 ++
arch/x86/pci
Signed-off-by: Keith Busch
---
drivers/pci/msi.c | 2 ++
kernel/irq/irqdomain.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 4a7da3c..5fb932b 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1119,6 +1119,7 @@ struct pci_dev
tor to share.
Lots style fixes/updates and additional code comments.
The one review comment I have not fixed is the affinity hint. We are
still developing a way to better handle this, so have left it as a error
returning stub. It's less than optimal, but isn't more harmful than that.
Keith Busch
And use the max bus resource from the parent rather than assume 255.
Signed-off-by: Keith Busch
---
drivers/pci/probe.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 8361d27..1cb3be7 100644
--- a/drivers/pci
From: Liu Jiang
Previously msi_domain_alloc() assumes MSI irqdomains always have parent
irqdomains, but that's not true for the new Intel VMD devices. So relax
msi_domain_alloc() to support parentless MSI irqdomains.
Signed-off-by: Jiang Liu
Signed-off-by: Liu Jiang
---
kernel/irq/msi.c | 8
es should either not be placed below VMD-owned
root ports, or VMD should be disabled by BIOS for such endpoints.
Signed-off-by: Keith Busch
---
arch/x86/Kconfig | 13 +
arch/x86/include/asm/hw_irq.h | 5 +
arch/x86/pci/Makefile | 2 +
arch/
On Fri, Nov 06, 2015 at 03:46:07PM -0800, Elliott, Robert (Persistent Memory)
wrote:
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> > ow...@vger.kernel.org] On Behalf Of Jens Axboe
> > Sent: Friday, November 6, 2015 11:20 AM
> ...
> > Subject:
On Tue, Nov 03, 2015 at 05:18:24AM -0800, Christoph Hellwig wrote:
> On Fri, Oct 30, 2015 at 02:35:11PM -0700, Nishanth Aravamudan wrote:
> > diff --git a/drivers/block/nvme-core.c b/drivers/block/nvme-core.c
> > index ccc0c1f93daa..a9a5285bdb39 100644
> > --- a/drivers/block/nvme-core.c
> > +++
On Tue, Nov 03, 2015 at 12:42:02PM +0100, Thomas Gleixner wrote:
> On Tue, 3 Nov 2015, Keith Busch wrote:
> > > > + msi_irqdomain = pci_msi_create_irq_domain(NULL,
> > > > _chained_msi_domain_info,
> > > > +
On Fri, Oct 30, 2015 at 02:35:11PM -0700, Nishanth Aravamudan wrote:
> Given that it's 4K just about everywhere by default (and sort of
> implicitly expected to be, I guess), I think I'd prefer we default to
> 4K. That should mitigate the performance impact (I'll ask our IO team to
> do some runs,
On Mon, Nov 02, 2015 at 07:35:15PM +0100, Thomas Gleixner wrote:
> On Tue, 27 Oct 2015, Keith Busch wrote:
Thomas,
Thanks a bunch for the feedback! I'll reply what I can right now, and
will take more time to consider or fix the rest for the next revision.
> I'm just looking at the int
d
root ports, or VMD should be disabled by BIOS for such endpoints.
Contributers to this patch include:
Artur Paszkiewicz
Bryan Veal
Jon Derrick
Signed-off-by: Keith Busch
---
v1 -> v2:
The original RFC used custom x86_msi_ops to provide the VMD device
specific interrupt
On Mon, 28 Sep 2015, Ming Lei wrote:
This patchset introduces .map_changed callback into 'struct blk_mq_ops',
and use this callback to get NVMe notified about the mapping changed event,
then NVMe can update the irq affinity hint for its queues.
I think this is going the wrong direction.
On Tue, 29 Sep 2015, Ming Lei wrote:
Yes, I thought of that before, but it has the following cons:
- some drivers/devices may need different IRQ affinity policy, such as virtio
devices which has its own set affinity handler(see virtqueue_set_affinity()),
That's not a very good example to
On Fri, Feb 12, 2016 at 04:24:35PM +0800, Ming Lei wrote:
> On Fri, 12 Feb 2016 00:41:28 -0500
> Hi Sasha,
>
> It should be about timing of setting q->mq_ops, and
> I believe the following patch may fix the issue, could
> you give a test?
Thanks, Ming, that looks better and looks like the same
On Thu, Dec 17, 2015 at 11:15:45AM -0600, Bjorn Helgaas wrote:
> > @@ -45,7 +45,7 @@ pci_filter_parse_slot_v33(struct pci_filter *f, char *str)
> > if (str[0] && strcmp(str, "*"))
> > {
> > long int x = strtol(str, , 16);
> > - if ((e && *e) || (x < 0 || x >
On Thu, Dec 17, 2015 at 11:27:18AM -0600, Bjorn Helgaas wrote:
> On Mon, Dec 07, 2015 at 02:32:24PM -0700, Keith Busch wrote:
> > + if (busnr > parent->busn_res.end) {
> > + dev_printk(KERN_DEBUG, >dev,
> > + "can n
On Thu, Dec 17, 2015 at 11:46:15AM -0600, Bjorn Helgaas wrote:
> On Mon, Dec 07, 2015 at 02:32:28PM -0700, Keith Busch wrote:
> > - u16 domain;
> > + int domain;
>
> If you want 32 bits explicitly, why don't you use u32 here?
It matches the types already defi
On Thu, Dec 17, 2015 at 12:14:48PM -0600, Bjorn Helgaas wrote:
> On Mon, Dec 07, 2015 at 02:32:27PM -0700, Keith Busch wrote:
> > +/*
> > + * VMD h/w converts posted config writes to non-posted. The read-back in
> > this
> > + * function forces the completion so it re
On Tue, Dec 29, 2015 at 01:10:48PM -0500, Nicholas Krause wrote:
> - blk_integrity_register(ns->disk, );
> + if (blk_integrity_register(ns->disk, )) {
Nak; blk_integrity_register returns 'void'.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Hi, thanks for the feedback. I've a few follow up questions.
On Sun, Jan 03, 2016 at 03:11:24PM +0100, Martin Mares wrote:
> This is definitely not enough. Try grepping the source for "domain" :-)
>
> At least the following places need updating, too:
>
> o struct pci_filter and operations on
On Thu, Jan 21, 2016 at 08:15:37PM -0800, Linus Torvalds wrote:
> For the case of nvme, for example, I think the max sector number is so
> high that you'll never hit that anyway, and you'll only ever hit the
> chunk limit. No?
The device's max transfer and chunk size are not very large, both
On Fri, Jan 22, 2016 at 10:43:59AM -0800, Linus Torvalds wrote:
> On Fri, Jan 22, 2016 at 10:29 AM, Ming Lei wrote:
> >
> > This patch fixes the issue by making the max io size aligned
> > to logical block size.
>
> Looks better, thanks.
>
> I'd suggest also moving the "max_sectors" variable
On Fri, Jan 22, 2016 at 12:22:18PM -0800, Linus Torvalds wrote:
>
> On Jan 22, 2016 12:11 PM, "Keith Busch" wrote:
> >
> > The value of max_sectors doesn't change in this function
>
> Why do you say that? It depends on the offset, so it clearly *doe
On Mon, Feb 01, 2021 at 10:30:17AM -0800, Jianxiong Gao wrote:
> @@ -868,12 +871,24 @@ static blk_status_t nvme_map_data(struct nvme_dev *dev,
> struct request *req,
> if (!iod->nents)
> goto out_free_sg;
>
> + offset_ret = dma_set_min_align_mask(dev->dev,
On Thu, Mar 25, 2021 at 09:48:37AM +, Niklas Cassel wrote:
> From: Niklas Cassel
>
> When a passthru command targets a specific namespace, the ns parameter to
> nvme_user_cmd()/nvme_user_cmd64() is set. However, there is currently no
> validation that the nsid specified in the passthru
For the subject, s/superflues/superfluous
A 'false' return means the value was safely set, so the comment should
say 'true' for when it is not considered safe.
Cc: Jason Gunthorpe
Cc: Kees Cook
Signed-off-by: Keith Busch
---
include/linux/overflow.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux
On Thu, Apr 01, 2021 at 12:00:39PM +0300, Dan Carpenter wrote:
> Hi Keith,
>
> I've been trying to figure out ways Smatch can check for device managed
> resources. Like adding rules that if we call dev_set_name(>bar)
> then it's device managaged and if there is a kfree(foo) without calling
>
On Mon, Apr 05, 2021 at 11:42:31PM +, Chuck Lever III wrote:
> > On Apr 5, 2021, at 4:07 PM, Jason Gunthorpe wrote:
> > On Mon, Apr 05, 2021 at 03:41:15PM +0200, Christoph Hellwig wrote:
> >> On Mon, Apr 05, 2021 at 08:23:54AM +0300, Leon Romanovsky wrote:
> >>> From: Leon Romanovsky
> >>>
On Tue, Mar 30, 2021 at 10:34:25AM -0700, Sagi Grimberg wrote:
>
> > > It is, but in this situation, the controller is sending a second
> > > completion that results in a use-after-free, which makes the
> > > transport irrelevant. Unless there is some other flow (which is
> > > unclear
> > > to
On Wed, Mar 10, 2021 at 02:41:10PM +0100, Christoph Hellwig wrote:
> On Wed, Mar 10, 2021 at 02:21:56PM +0100, Christoph Hellwig wrote:
> > Can you try this patch instead?
> >
> > http://lists.infradead.org/pipermail/linux-nvme/2021-February/023183.html
>
> Actually, please try the patch below
On Mon, Mar 01, 2021 at 05:53:25PM +0100, Hannes Reinecke wrote:
> On 3/1/21 5:05 PM, Keith Busch wrote:
> > On Mon, Mar 01, 2021 at 02:55:30PM +0100, Hannes Reinecke wrote:
> > > On 3/1/21 2:26 PM, Daniel Wagner wrote:
> > > > On Sat, Feb 27, 2021 at 02:19
On Fri, Feb 26, 2021 at 01:54:00PM +0100, Hannes Reinecke wrote:
> On 2/26/21 1:35 PM, Daniel Wagner wrote:
> > On Mon, Feb 15, 2021 at 01:29:45PM -0800, Sagi Grimberg wrote:
> > > Well, I think we should probably figure out why that is happening first.
> >
> > I got my hands on a tcpdump trace.
On Tue, Mar 02, 2021 at 08:18:40AM +0100, Hannes Reinecke wrote:
> On 3/1/21 9:59 PM, Keith Busch wrote:
> > On Mon, Mar 01, 2021 at 05:53:25PM +0100, Hannes Reinecke wrote:
> >> On 3/1/21 5:05 PM, Keith Busch wrote:
> >>> On Mon, Mar 01, 2021 at 02:55:30P
On Mon, Mar 01, 2021 at 02:55:30PM +0100, Hannes Reinecke wrote:
> On 3/1/21 2:26 PM, Daniel Wagner wrote:
> > On Sat, Feb 27, 2021 at 02:19:01AM +0900, Keith Busch wrote:
> >> Crashing is bad, silent data corruption is worse. Is there truly no
> >> defense against that
On Fri, Feb 26, 2021 at 05:42:46PM +0100, Hannes Reinecke wrote:
> On 2/26/21 5:13 PM, Keith Busch wrote:
> >
> > That's just addressing a symptom. You can't fully verify the request is
> > valid this way because the host could have started the same command ID
> > the
On Fri, Feb 12, 2021 at 12:58:27PM -0800, Sagi Grimberg wrote:
> > blk_mq_tag_to_rq() will always return a request if the command_id is
> > in the valid range. Check if the request has been started. If we
> > blindly process the request we might double complete a request which
> > can be fatal.
>
On Sat, Feb 20, 2021 at 06:01:56PM +, David Laight wrote:
> From: SelvaKumar S
> > Sent: 19 February 2021 12:45
> >
> > This patchset tries to add support for TP4065a ("Simple Copy Command"),
> > v2020.05.04 ("Ratified")
> >
> > The Specification can be found in following link.
> >
On Sat, Feb 20, 2021 at 05:10:18PM +0800, Yang Li wrote:
> fixed the following coccicheck:
> ./drivers/nvme/host/core.c:3440:60-61: WARNING opportunity for
> kobj_to_dev()
> ./drivers/nvme/host/core.c:3679:60-61: WARNING opportunity for
> kobj_to_dev()
>
> Reported-by: Abaci Robot
>
Commit-ID: 8844aad89ed61545b4db6a3467e1b21ca1c49460
Gitweb: http://git.kernel.org/tip/8844aad89ed61545b4db6a3467e1b21ca1c49460
Author: Keith Busch keith.bu...@intel.com
AuthorDate: Mon, 30 Jun 2014 16:24:44 -0600
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Sat, 5 Jul 2014
Commit-ID: edd14cfebc4404698544d407ecf8eda6e19aa19e
Gitweb: http://git.kernel.org/tip/edd14cfebc4404698544d407ecf8eda6e19aa19e
Author: Keith Busch <keith.bu...@intel.com>
AuthorDate: Fri, 17 Jun 2016 16:00:20 -0600
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate:
Commit-ID: 30ce0350381351646ef86b64e6d3840b3869833b
Gitweb: http://git.kernel.org/tip/30ce0350381351646ef86b64e6d3840b3869833b
Author: Keith Busch <keith.bu...@intel.com>
AuthorDate: Fri, 17 Jun 2016 16:00:21 -0600
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate:
Commit-ID: 7bf8222b9bd0ba867e18b7f4537b61ef2e92eee8
Gitweb: http://git.kernel.org/tip/7bf8222b9bd0ba867e18b7f4537b61ef2e92eee8
Author: Keith Busch <keith.bu...@intel.com>
AuthorDate: Mon, 3 Apr 2017 15:25:53 -0400
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate
Commit-ID: 3412386b531244f24a27c79ee003506a52a00848
Gitweb: http://git.kernel.org/tip/3412386b531244f24a27c79ee003506a52a00848
Author: Keith Busch <keith.bu...@intel.com>
AuthorDate: Thu, 13 Apr 2017 13:28:12 -0400
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate:
Commit-ID: b72f8051f34b8164a62391e3676edc34523c5952
Gitweb: http://git.kernel.org/tip/b72f8051f34b8164a62391e3676edc34523c5952
Author: Keith Busch <keith.bu...@intel.com>
AuthorDate: Wed, 19 Apr 2017 19:51:10 -0400
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate:
Commit-ID: 8844aad89ed61545b4db6a3467e1b21ca1c49460
Gitweb: http://git.kernel.org/tip/8844aad89ed61545b4db6a3467e1b21ca1c49460
Author: Keith Busch
AuthorDate: Mon, 30 Jun 2014 16:24:44 -0600
Committer: Thomas Gleixner
CommitDate: Sat, 5 Jul 2014 21:42:08 +0200
genirq: Fix memory leak
Commit-ID: b72f8051f34b8164a62391e3676edc34523c5952
Gitweb: http://git.kernel.org/tip/b72f8051f34b8164a62391e3676edc34523c5952
Author: Keith Busch
AuthorDate: Wed, 19 Apr 2017 19:51:10 -0400
Committer: Thomas Gleixner
CommitDate: Thu, 20 Apr 2017 16:03:09 +0200
genirq/affinity: Fix
Commit-ID: 3412386b531244f24a27c79ee003506a52a00848
Gitweb: http://git.kernel.org/tip/3412386b531244f24a27c79ee003506a52a00848
Author: Keith Busch
AuthorDate: Thu, 13 Apr 2017 13:28:12 -0400
Committer: Thomas Gleixner
CommitDate: Thu, 13 Apr 2017 23:41:00 +0200
irq/affinity: Fix extra
Commit-ID: 7bf8222b9bd0ba867e18b7f4537b61ef2e92eee8
Gitweb: http://git.kernel.org/tip/7bf8222b9bd0ba867e18b7f4537b61ef2e92eee8
Author: Keith Busch
AuthorDate: Mon, 3 Apr 2017 15:25:53 -0400
Committer: Thomas Gleixner
CommitDate: Tue, 4 Apr 2017 11:57:28 +0200
irq/affinity: Fix CPU
Commit-ID: edd14cfebc4404698544d407ecf8eda6e19aa19e
Gitweb: http://git.kernel.org/tip/edd14cfebc4404698544d407ecf8eda6e19aa19e
Author: Keith Busch
AuthorDate: Fri, 17 Jun 2016 16:00:20 -0600
Committer: Thomas Gleixner
CommitDate: Sat, 18 Jun 2016 10:00:55 +0200
genirq: Add untracked
1401 - 1500 of 1501 matches
Mail list logo
