From patchwork Mon Nov 6 14:59:40 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mikulas Patocka X-Patchwork-Id: 13447104 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 lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7886CC4332F for ; Mon, 6 Nov 2023 15:27:48 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.628130.979325 (Exim 4.92) (envelope-from ) id 1r01Vl-00010Q-A0; Mon, 06 Nov 2023 15:27:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 628130.979325; Mon, 06 Nov 2023 15:27:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1r01Vl-00010J-6q; Mon, 06 Nov 2023 15:27:33 +0000 Received: by outflank-mailman (input) for mailman id 628130; Mon, 06 Nov 2023 14:59:55 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1r0151-0006Yn-FH for xen-devel@lists.xenproject.org; Mon, 06 Nov 2023 14:59:55 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 23499a33-7cb5-11ee-9b0e-b553b5be7939; Mon, 06 Nov 2023 15:59:52 +0100 (CET) Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-587-wo667hKyNIaLrPo-Wqz7rg-1; Mon, 06 Nov 2023 09:59:42 -0500 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (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 4D89F811001; Mon, 6 Nov 2023 14:59:40 +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 270FE492BFA; Mon, 6 Nov 2023 14:59:40 +0000 (UTC) Received: by file1-rdu.file-001.prod.rdu2.dc.redhat.com (Postfix, from userid 12668) id 0FFB830C72A7; Mon, 6 Nov 2023 14:59:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by file1-rdu.file-001.prod.rdu2.dc.redhat.com (Postfix) with ESMTP id 0CADB3FD16; Mon, 6 Nov 2023 15:59:40 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 23499a33-7cb5-11ee-9b0e-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1699282791; 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=MvbDfj8UoB/iWWxf+0USaZxvp1nymUg9UUSbnVJnGJg=; b=RKdRArT3Saf3AaU17gzFv74+A9RcK7n3BSSdSbIr60XSQRVsO6GTlEQQEK011teO+5Y1Lx CwWF7JMg5vbhR5rC7udmRjlG7Oh+imVHfOD8H7BTmdBD8LWuebo7c0kdy/8FzVg79CMOD/ sVQ//DD7opEhCdlHIuTCddx1D1v/6Aw= X-MC-Unique: wo667hKyNIaLrPo-Wqz7rg-1 Date: Mon, 6 Nov 2023 15:59:40 +0100 (CET) From: Mikulas Patocka To: Christoph Hellwig , Juergen Gross , Stefano Stabellini , xen-devel@lists.xenproject.org, iommu@lists.linux.dev cc: Keith Busch , 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 , Mike Snitzer , dm-devel@lists.linux.dev, linux-mm@kvack.org Subject: [PATCH] swiotlb-xen: provide the "max_mapping_size" method In-Reply-To: <20231106071008.GB17022@lst.de> Message-ID: <928b5df7-fada-cf2f-6f6a-257a84547c3@redhat.com> References: <3cb4133c-b6db-9187-a678-11ed8c9456e@redhat.com> <11a9886d-316c-edcd-d6da-24ad0b9a2b4@redhat.com> <20231106071008.GB17022@lst.de> MIME-Version: 1.0 Content-ID: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.10 There's a bug that when using the XEN hypervisor with dm-crypt 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. [1] https://lore.kernel.org/stable/ZTNH0qtmint%2FzLJZ@mail-itl/ Signed-off-by: Mikulas Patocka Reported-by: Marek Marczykowski-Górecki Tested-by: Marek Marczykowski-Górecki Suggested-by: Keith Busch Suggested-by: Christoph Hellwig Cc: stable@vger.kernel.org --- 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, };