Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp5689388rwb; Wed, 7 Sep 2022 06:43:16 -0700 (PDT) X-Google-Smtp-Source: AA6agR65hJILQfTScKuavfkRLhWaVeSxvsBQEMCPRo1L70G1CPoI3VJINchZpKvT8bMLftNdUXsk X-Received: by 2002:a17:907:6d8a:b0:73b:d9e4:e628 with SMTP id sb10-20020a1709076d8a00b0073bd9e4e628mr2398558ejc.75.1662558196335; Wed, 07 Sep 2022 06:43:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662558196; cv=none; d=google.com; s=arc-20160816; b=wAuXyHE1LpHqT7vDPB45AuW8oq6v8u2gmHAJXMGXjg30y3kzpL5ljd9OcnYEBXJO14 jDcEKJEY2HMpbr2MQpE/Zu6+aVHdHup1omKdZEaRdN9cY6emgU7sBtRQ8Q55GWUyiYZ1 2aei8RDxNok34VjlZDwZON4Lm3s8PrdcFvGm+d2DTwf49ikjP65zcr2L0BFIeUezzAKX QqL206dskiAFMrFWIHuBuJpjiM7DOJr8NQS08ghu63Y1eWh10fpO/uqTAI30HHTN12is /9XMLdsB/AbTosfq1r+mLlfo3Lx+4wnSjhlo0A1/wAmf4vzS5sWtyG9aKH3Vup80fd2t 0/kw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=eM4prT5L/3P1sS70chtnCux9y+km+1Kv507CLh8Plw8=; b=ShD2rKPFDFx8qh+N0lMIniz+S9xy16t3a0QFCOP17scz8D1k8sE1LgMJ5ccEG++RTh r9/qaMQCnc1oHU2PLRErBbi0kXY/F45fzDBPqCgpEX1PwAAx18YFj3C2i56N2ZA3I2uw 4h7GdyB5PbH8XQQbvStwQQwU3I290VMHOqmtJsWrJsCk6fxLdNHBce9Wrp/mqEsrq10p CNb4UVtg1e4f5+1ZEWOmnITzd2mgbnkdB6PH55NxXyC812LQbtu9ouP5V//g3DCW7dnJ MLxcGi5oI7dQVgnF8ilFSI4MdJZ90SuqLRrSrlGNE4gMgV2YQua6wJV8es6l29boKMWY V49Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e5-20020a17090658c500b0075f013f525esi10846649ejs.739.2022.09.07.06.42.50; Wed, 07 Sep 2022 06:43:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230037AbiIGNkc (ORCPT + 99 others); Wed, 7 Sep 2022 09:40:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230147AbiIGNjb (ORCPT ); Wed, 7 Sep 2022 09:39:31 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 44A869E883 for ; Wed, 7 Sep 2022 06:38:45 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5EAF31042; Wed, 7 Sep 2022 06:38:44 -0700 (PDT) Received: from e121345-lin.cambridge.arm.com (e121345-lin.cambridge.arm.com [10.1.196.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 34BD13F7B4; Wed, 7 Sep 2022 06:38:37 -0700 (PDT) From: Robin Murphy To: hch@infradead.org Cc: m.szyprowski@samsung.com, iommu@lists.linux.dev, dongli.zhang@oracle.com, yuzhao@google.com, linux-kernel@vger.kernel.org Subject: [PATCH] swiotlb: Don't panic! Date: Wed, 7 Sep 2022 14:38:33 +0100 Message-Id: X-Mailer: git-send-email 2.36.1.dirty MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The panics in swiotlb are relics of a bygone era, some of them inadvertently inherited from a memblock refactor, and all of them unnecessary since they are in places that may also fail gracefully anyway. Convert the panics in swiotlb_init_remap() into non-fatal warnings more consistent with the other bail-out paths there and in swiotlb_init_late() (but don't bother trying to roll anything back, since if anything does actually fail that early, the aim is merely to keep going as far as possible to get more diagnostic information out of the inevitably-dying kernel). It's not for SWIOTLB to decide that the system is terminally compromised just because there *might* turn out to be one or more 32-bit devices that might want to make streaming DMA mappings, especially since we already handle the no-buffer case later if it turns out someone did want it. Similarly though, downgrade that panic in swiotlb_tbl_map_single(), since even if we do get to that point it's an overly extreme reaction. It makes little difference to the DMA API caller whether a mapping fails because the buffer is full or because there is no buffer, and once again it's not for SWIOTLB to presume that any particular DMA mapping is so fundamental to the operation of the system that it must be terminal if it could never succeed. Even if the caller handles failure by futilely retrying forever, a single stuck thread is considerably less impactful to the user than a needless panic. Signed-off-by: Robin Murphy --- Based on dma/for-next with the revert already applied kernel/dma/swiotlb.c | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-) diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index 0ef6b12f961d..11579a3be2b5 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -346,22 +346,27 @@ void __init swiotlb_init_remap(bool addressing_limit, unsigned int flags, memblock_free(tlb, PAGE_ALIGN(bytes)); nslabs = ALIGN(nslabs >> 1, IO_TLB_SEGSIZE); - if (nslabs < IO_TLB_MIN_SLABS) - panic("%s: Failed to remap %zu bytes\n", - __func__, bytes); - goto retry; + if (nslabs >= IO_TLB_MIN_SLABS) + goto retry; + + pr_warn("%s: Failed to remap %zu bytes\n", __func__, bytes); + return; } alloc_size = PAGE_ALIGN(array_size(sizeof(*mem->slots), nslabs)); mem->slots = memblock_alloc(alloc_size, PAGE_SIZE); - if (!mem->slots) - panic("%s: Failed to allocate %zu bytes align=0x%lx\n", - __func__, alloc_size, PAGE_SIZE); + if (!mem->slots) { + pr_warn("%s: Failed to allocate %zu bytes align=0x%lx\n", + __func__, alloc_size, PAGE_SIZE); + return; + } mem->areas = memblock_alloc(array_size(sizeof(struct io_tlb_area), default_nareas), SMP_CACHE_BYTES); - if (!mem->areas) - panic("%s: Failed to allocate mem->areas.\n", __func__); + if (!mem->areas) { + pr_warn("%s: Failed to allocate mem->areas.\n", __func__); + return; + } swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, flags, false, default_nareas); @@ -731,8 +736,11 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev, phys_addr_t orig_addr, int index; phys_addr_t tlb_addr; - if (!mem || !mem->nslabs) - panic("Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer"); + if (!mem || !mem->nslabs) { + dev_warn_ratelimited(dev, + "Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer"); + return (phys_addr_t)DMA_MAPPING_ERROR; + } if (cc_platform_has(CC_ATTR_MEM_ENCRYPT)) pr_warn_once("Memory encryption is active and system is using DMA bounce buffers\n"); -- 2.36.1.dirty