Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3382336yba; Tue, 23 Apr 2019 02:51:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqwHck73WbE5WZEc1ObMXGnbrBIM9xuFXTE9gd6+opPqtuvY7tPPB69CidzBjZRcya+dJn46 X-Received: by 2002:a63:5854:: with SMTP id i20mr23561941pgm.171.1556013078370; Tue, 23 Apr 2019 02:51:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556013078; cv=none; d=google.com; s=arc-20160816; b=reys8Zrn5tNcAPZx+0rXw5Fxi0e6oWzHyyDEBO0mYMMBt3vc5ylW91Syhg0m06ELVe QVxvmvu42dmNP62adtCMaAuO/aVxSjvvej9OnAr+safeq9+7wHoAHQtXVNEyaJx4E+N9 5KJskPYfdq3emSKBHusPF0WjHqReSBdufQ3DWvl62mGiNst3emvDsQ9CZ5w4JKtC0zyx Fmgr0OOEtQXqZ06UGCyvMkSK4OR5zlfF99RsBCt38mYaGjIcWlotBOM6qTE4mWz3r2rN 78RSv2vjxeX3syoQvnyAYuaCoM+qEu7YzlDG/8riL3g5UYrjilnt+9JXplaQRT0sQMP8 eshg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:subject:from; bh=NMydbJgGulS1KSxyPbc7qu12FGNBRwUzMcFoJ7+Cs2k=; b=HoQz+DmzmwwbXUdCWrd8qlRVbgIU0h7Wa2HY16NHBCGgBwvo4xmQ1Itf3O/oWmYOCa REYTFmHakIYQl8kOYsn2qSVRSoohLxemm6OEhqeYR7KT/guJlING0Ym69OBc079Y/cxJ 5blD78do0JP8sEXgRTCUhk0GzIp0lQZQ84C5ASqmFN8CZ2dOYURmRfN4T1c5/c0NZiL6 aT0lWKOwTSHXMZiPMC17aKVbi5icaZ6lLIIIJPQpQUXifosgstrvQgMF5Cz7Uq3KfVix W2GriPTMkX5TpxrXm56U7kmgsaGuPZm37yxg3rrJe3bzyBj4pC0dLQSnN4hEEmTib6R3 bHLw== 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 w22si14709011pgj.174.2019.04.23.02.51.02; Tue, 23 Apr 2019 02:51:18 -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 S1727033AbfDWJsx (ORCPT + 99 others); Tue, 23 Apr 2019 05:48:53 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:52806 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726150AbfDWJsx (ORCPT ); Tue, 23 Apr 2019 05:48:53 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4B4C6374; Tue, 23 Apr 2019 02:48:52 -0700 (PDT) Received: from [10.1.196.75] (e110467-lin.cambridge.arm.com [10.1.196.75]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E60913F557; Tue, 23 Apr 2019 02:48:50 -0700 (PDT) From: Robin Murphy Subject: Re: [PATCH 12/21] dma-iommu: factor atomic pool allocations into helpers To: Christoph Hellwig Cc: Joerg Roedel , Catalin Marinas , Will Deacon , Tom Lendacky , iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20190327080448.5500-1-hch@lst.de> <20190327080448.5500-13-hch@lst.de> <20190410061157.GA5278@lst.de> <20190417063358.GA24139@lst.de> <83615173-a8b4-e0eb-bac3-1a58d61ea4ef@arm.com> <20190418163512.GA25347@lst.de> <433dec64-ef15-b31d-ace4-4c72b81d2942@arm.com> <20190419090759.GA22885@lst.de> Message-ID: <290377cd-8cd3-aa7a-0057-36df3d7cd728@arm.com> Date: Tue, 23 Apr 2019 10:48:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190419090759.GA22885@lst.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-04-19 10:07 am, Christoph Hellwig wrote: > On Thu, Apr 18, 2019 at 05:41:00PM +0100, Robin Murphy wrote: >>> From a very high level POV this looks ok, but sometimes a bit to >>> convoluted to me. The major issue why I went with the version I posted >>> is that I can cleanly ifdef out the remap code in just a few sections. >>> In this version it is spread out a lot more, and the use of IS_ENABLED >>> means that we'd need a lot more stubs for functionality that won't >>> ever be called but needs to be compilable. >> >> What functionality do you have planned in that regard? I did do a quick >> build test of my arm64 config with DMA_DIRECT_REMAP hacked out, and >> dma-iommu.o appeared to link OK (although other bits of arm64 and >> dma-direct didn't, as expected). I will try x86 with IOMMU_DMA to make >> sure, though. > > Yeah, this seems to actually work, there just is a huge chunk of > remapping that is hopefully discarded by the compiler even without the > ifdefs. Right, the major point of this approach is that you don't need stubs; indeed, stubs themselves fall into the category of "#ifdefed code I'd prefer to avoid". The preprocessing essentially resolves to: if (0) function_that_doesnt_exist(); so compilation treats it as an external reference, but since constant folding ends up eliding the call, that symbol isn't referenced in the final object, so linking never has to resolve it. All it needs is a declaration to avoid a compiler warning, but that's the same declaration that's needed anyway for when the function does exist. Similarly, static functions like iommu_dma_alloc_remap() still get compiled - so we don't lose coverage - but then get discarded at the link stage (via gc-sections) since they end up unreferenced. It's really pretty neat. Robin.