Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp6632415ybe; Wed, 18 Sep 2019 06:43:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqz3L56oZLMPYAF1orOF3eCJ3Bxo5DfNpZEjWNdWs38eC8zluzFmZJmGMvEo9lgDydLgmO/A X-Received: by 2002:a50:fd01:: with SMTP id i1mr9559745eds.184.1568814188376; Wed, 18 Sep 2019 06:43:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568814188; cv=none; d=google.com; s=arc-20160816; b=YIHYDt388ZzhWZAVxPkrFy+YMMt7PVKq8IVx/9tmUtZVpJGTlJ/Cms0L5L9fjaDMCa 9GvQvZGf2bDWwnSmuK1T50VHXjaSCMBVkTsdunGJcfby9npUR8iWoD8zM/AJgRqlnYN0 Ui/sd6W/Cus7ifGs9TPmjKl1arBtYROK5aCGw4z4EOMNg804hDIMwm4NfrFY0r4odyOv rr/LP7Nd5kxIl5HBHotBN8K7T0YFVcVGLq+c80XgFlT/q3pOnoj37xknG55n/rnse2a/ 2qqmFHxUEt5kv/Fqu6uCKpJbWjQiCmmoOgKO93CIsjeEbQenEQfxmy4/1rRWYw76DBKD wH/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=sxeWhB1FUHpN0piXjAPbjHMxuKBWNdwNUCyY2yXM+/s=; b=O56S6BAzllOM5MQbzfliFKuKOWJqbFz8IFozm81D3QA9nkYL1fSNlLyrh6ESd4Ndig IvTH/vCajVg4yzzvaMaQwpRn95KDofEEAmc+B+8WnzPCxjsf6heFmj4bCuQgXcPjudi8 eDL8hunZDcNIQD4PSGikmk2ogputLdUlZQt4Wlq2kXq5Jm+dfNcQhc52xsoKBZrwctVk tktuVWZGZP65DEvdJEycp47wtGDHafvvBe6NYblZDsaLyMJSd8qLzCcQwvdNPb9lvZoR sWqSRKropk0TsR0QiSmOhGD9GXBv8wtdKzdDzOt+MHQ9/SlUjXDr0wZ1e2Cc+/lvq1c2 tZ0w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f2si2817435ejw.335.2019.09.18.06.42.44; Wed, 18 Sep 2019 06:43:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727267AbfIRNWq (ORCPT + 99 others); Wed, 18 Sep 2019 09:22:46 -0400 Received: from verein.lst.de ([213.95.11.211]:33283 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726545AbfIRNWq (ORCPT ); Wed, 18 Sep 2019 09:22:46 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id CC48268B05; Wed, 18 Sep 2019 15:22:42 +0200 (CEST) Date: Wed, 18 Sep 2019 15:22:42 +0200 From: Christoph Hellwig To: "Lendacky, Thomas" Cc: David Rientjes , Christoph Hellwig , Keith Busch , Jens Axboe , "Singh, Brijesh" , Ming Lei , Peter Gonda , Jianxiong Gao , "linux-kernel@vger.kernel.org" , "x86@kernel.org" , "iommu@lists.linux-foundation.org" Subject: Re: [bug] __blk_mq_run_hw_queue suspicious rcu usage Message-ID: <20190918132242.GA16133@lst.de> References: <20190905060627.GA1753@lst.de> <1d74607e-37f7-56ca-aba3-5a3bd7a68561@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1d74607e-37f7-56ca-aba3-5a3bd7a68561@amd.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 17, 2019 at 06:41:02PM +0000, Lendacky, Thomas wrote: > > diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c > > --- a/drivers/nvme/host/pci.c > > +++ b/drivers/nvme/host/pci.c > > @@ -1613,7 +1613,8 @@ static int nvme_alloc_admin_tags(struct nvme_dev *dev) > > dev->admin_tagset.timeout = ADMIN_TIMEOUT; > > dev->admin_tagset.numa_node = dev_to_node(dev->dev); > > dev->admin_tagset.cmd_size = sizeof(struct nvme_iod); > > - dev->admin_tagset.flags = BLK_MQ_F_NO_SCHED; > > + dev->admin_tagset.flags = BLK_MQ_F_NO_SCHED | > > + BLK_MQ_F_BLOCKING; > > I think you want to only set the BLK_MQ_F_BLOCKING if the DMA is required > to be unencrypted. Unfortunately, force_dma_unencrypted() can't be called > from a module. Is there a DMA API that could be called to get that info? The DMA API must support non-blocking calls, and various drivers rely on that. So we need to provide that even for the SEV case. If the actual blocking can't be made to work we'll need to wire up the DMA pool in kernel/dma/remap.c for it (and probably move it to separate file).