From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05AFCC4332F for ; Mon, 6 Nov 2023 17:13:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229974AbjKFRNU (ORCPT ); Mon, 6 Nov 2023 12:13:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229715AbjKFRNT (ORCPT ); Mon, 6 Nov 2023 12:13:19 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ADF0C125 for ; Mon, 6 Nov 2023 09:12:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1699290754; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xtsXGyrCZBmUJfCxzrPKMMdVxxHur1sL8JecsuLgwa0=; b=MjyQwaT6a3cTSI3RiDIca8cG8RAfMpf7JF8iskBIFkxXRO3tV2jqixAbJq6PiFgfnpuozu dFtDo3YUysqq6LMjjTSR2Ho4Lis21izpLicOtX39Q17YL0wzC50tJERtjZsV8rFAXO3vRW KywBHrtL/rSy6xqEuJkQWLKYa3SyLdo= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-632-_45CrAGuNjOuxKLbB7FT_Q-1; Mon, 06 Nov 2023 12:12:31 -0500 X-MC-Unique: _45CrAGuNjOuxKLbB7FT_Q-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 674ED3821568; Mon, 6 Nov 2023 17:12:30 +0000 (UTC) Received: from file1-rdu.file-001.prod.rdu2.dc.redhat.com (unknown [10.11.5.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 47C5D1121308; Mon, 6 Nov 2023 17:12:30 +0000 (UTC) Received: by file1-rdu.file-001.prod.rdu2.dc.redhat.com (Postfix, from userid 12668) id 3227530C72A7; Mon, 6 Nov 2023 17:12:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by file1-rdu.file-001.prod.rdu2.dc.redhat.com (Postfix) with ESMTP id 2E33F3FD16; Mon, 6 Nov 2023 18:12:30 +0100 (CET) Date: Mon, 6 Nov 2023 18:12:30 +0100 (CET) From: Mikulas Patocka To: Mike Snitzer cc: Keith Busch , Christoph Hellwig , Juergen Gross , Stefano Stabellini , xen-devel@lists.xenproject.org, iommu@lists.linux.dev, Marek Marczykowski-G'orecki , Jens Axboe , Sagi Grimberg , Jan Kara , Vlastimil Babka , Andrew Morton , Matthew Wilcox , Michal Hocko , stable@vger.kernel.org, regressions@lists.linux.dev, Alasdair Kergon , dm-devel@lists.linux.dev, linux-mm@kvack.org Subject: [PATCH v2] swiotlb-xen: provide the "max_mapping_size" method In-Reply-To: Message-ID: <151bef41-e817-aea9-675-a35fdac4ed@redhat.com> References: <3cb4133c-b6db-9187-a678-11ed8c9456e@redhat.com> <11a9886d-316c-edcd-d6da-24ad0b9a2b4@redhat.com> <20231106071008.GB17022@lst.de> <928b5df7-fada-cf2f-6f6a-257a84547c3@redhat.com> MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="185210117-1837111149-1699290694=:1497320" Content-ID: <478c056-3a19-eb50-34da-911cf13fc558@redhat.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --185210117-1837111149-1699290694=:1497320 Content-Type: text/plain; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-ID: <4468b751-727c-3ffb-15cc-683422283a27@redhat.com> From: Keith Busch There's a bug that when using the XEN hypervisor with bios with large multi-page bio vectors on NVMe, the kernel deadlocks [1]. The deadlocks are caused by inability to map a large bio vector - dma_map_sgtable always returns an error, this gets propagated to the block layer as BLK_STS_RESOURCE and the block layer retries the request indefinitely. XEN uses the swiotlb framework to map discontiguous pages into contiguous runs that are submitted to the PCIe device. The swiotlb framework has a limitation on the length of a mapping - this needs to be announced with the max_mapping_size method to make sure that the hardware drivers do not create larger mappings. Without max_mapping_size, the NVMe block driver would create large mappings that overrun the maximum mapping size. Reported-by: Marek Marczykowski-Górecki Link: https://lore.kernel.org/stable/ZTNH0qtmint%2FzLJZ@mail-itl/ [1] Tested-by: Marek Marczykowski-Górecki Suggested-by: Christoph Hellwig Cc: stable@vger.kernel.org Signed-off-by: Keith Busch Signed-off-by: Mikulas Patocka --- drivers/xen/swiotlb-xen.c | 1 + 1 file changed, 1 insertion(+) Index: linux-stable/drivers/xen/swiotlb-xen.c =================================================================== --- linux-stable.orig/drivers/xen/swiotlb-xen.c 2023-11-03 17:57:18.000000000 +0100 +++ linux-stable/drivers/xen/swiotlb-xen.c 2023-11-06 15:30:59.000000000 +0100 @@ -405,4 +405,5 @@ const struct dma_map_ops xen_swiotlb_dma .get_sgtable = dma_common_get_sgtable, .alloc_pages = dma_common_alloc_pages, .free_pages = dma_common_free_pages, + .max_mapping_size = swiotlb_max_mapping_size, }; --185210117-1837111149-1699290694=:1497320--