[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4cd700ef-f2fc-2bb5-35d2-0b2194accc45@kernel.dk>
Date: Tue, 17 Sep 2019 12:32:45 -0600
From: Jens Axboe <axboe@...nel.dk>
To: David Rientjes <rientjes@...gle.com>,
Christoph Hellwig <hch@....de>, Keith Busch <kbusch@...nel.org>
Cc: Tom Lendacky <thomas.lendacky@....com>,
Brijesh Singh <brijesh.singh@....com>,
Ming Lei <ming.lei@...hat.com>,
Peter Gonda <pgonda@...gle.com>,
Jianxiong Gao <jxgao@...gle.com>, linux-kernel@...r.kernel.org,
x86@...nel.org, iommu@...ts.linux-foundation.org
Subject: Re: [bug] __blk_mq_run_hw_queue suspicious rcu usage
On 9/17/19 12:23 PM, David Rientjes wrote:
> On Mon, 16 Sep 2019, David Rientjes wrote:
>
>> Brijesh and Tom, we currently hit this any time we boot an SEV enabled
>> Ubuntu 18.04 guest; I assume that guest kernels, especially those of such
>> major distributions, are expected to work with warnings and BUGs when
>> certain drivers are enabled.
>>
>> If the vmap purge lock is to remain a mutex (any other reason that
>> unmapping aliases can block?) then it appears that allocating a dmapool
>> is the only alternative. Is this something that you'll be addressing
>> generically or do we need to get buy-in from the maintainers of this
>> specific driver?
>>
>
> We've found that the following applied on top of 5.2.14 suppresses the
> warnings.
>
> Christoph, Keith, Jens, is this something that we could do for the nvme
> driver? I'll happily propose it formally if it would be acceptable.
No, this is not going to be acceptable, I'm afraid. This tells blk-mq
that the driver always needs blocking context for queueing IO, which
will increase latencies for the cases where we'd otherwise issue IO
directly from the context that queues it.
--
Jens Axboe
Powered by blists - more mailing lists