Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4824044imu; Tue, 8 Jan 2019 06:59:48 -0800 (PST) X-Google-Smtp-Source: ALg8bN759yIqelP8VIkEG5M7SYONJx2widM6uKz5hg4+S1KQZ7brIsGzFA2rSTMOJBAm4QkTiKB1 X-Received: by 2002:a63:fb15:: with SMTP id o21mr1792086pgh.211.1546959588924; Tue, 08 Jan 2019 06:59:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546959588; cv=none; d=google.com; s=arc-20160816; b=uRQVHqsNUMXu0FTfz9BAF5Fw3/YNkbVEKn1BDI+LkPtsUJ9X0V+18RduWWe5o1+j4/ tLn91rS7maKTgPFlwkYzUmjmCsfty7aCcUtBXlua7EZ0fUNwyU6Lyf2ClUQ6nT2pw4qm mtQloBEKIBJ/c2e6xEJKWqJ2BJZ7PAf//l7iKbD+PjgJApAeuOgzLkVYntEuNgNVSdHL 7+Rc290CZI03IoAH6Yiqi90vy0PbU+HXNP0T6wv87XKx5FxjQ8J8LTJ0hwVqSHxxNjqe T3btLDMduDyHP9YRnzCvf3HCDM15J2IC/b/eRMohZlMvwohtQL4dvxqt39Oru6lc2drL yObA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=kXQCCb7er3UdNn5bS1+RsgEKUZ8ysiDApzcRkJsUoaU=; b=JZmMcOAz6rNga+8Zo1my9LXv9pv1Vq+mKywIqKA2h/GPr/eGJB9eU/aE7scBK40Q9k 51yVHI5h52ECOu8gZz6xd6XIMUjaIeufuIWPapqY+8200FkUSGnfQH2GHjqqX0wIXJWs zgM+kicQtw0M9mwA7+EC9hSlivg4zC8MysvupI4/VNFG9O75yyApEVwrgTgGZprLSMu6 HwoKTAIwdVJk3GNN7SDnUQtJRmALC1iOHiQk8DAXEjI3V99Wrjul9tJvbYamjvko3i+J Ui29YbCTBCOYBCll7ZZ3cgFloERbYAxJ/e80vSc1Ol/p3jREQEpQWDgNURyc/C7wN4xK 8aTg== 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 s73si22897174pfs.54.2019.01.08.06.59.33; Tue, 08 Jan 2019 06:59:48 -0800 (PST) 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 S1728484AbfAHN5D (ORCPT + 99 others); Tue, 8 Jan 2019 08:57:03 -0500 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:44367 "EHLO mail2-relais-roc.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728112AbfAHN5D (ORCPT ); Tue, 8 Jan 2019 08:57:03 -0500 X-IronPort-AV: E=Sophos;i="5.56,454,1539640800"; d="scan'208";a="363069033" Received: from vaio-julia.rsr.lip6.fr ([132.227.76.33]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2019 14:57:01 +0100 Date: Tue, 8 Jan 2019 14:56:59 +0100 (CET) From: Julia Lawall X-X-Sender: jll@hadrien To: Christoph Hellwig cc: Linus Torvalds , Luis Chamberlain , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: remove dma_zalloc_coherent In-Reply-To: Message-ID: References: <20190108130701.14161-1-hch@lst.de> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 8 Jan 2019, Julia Lawall wrote: > > > On Tue, 8 Jan 2019, Christoph Hellwig wrote: > > > Hi Linus and world, > > > > We've always had a weird situation around dma_zalloc_coherent. To > > safely support mapping the allocations to userspace major architectures > > like x86 and arm have always zeroed allocations from dma_alloc_coherent, > > but a couple other architectures were missing that zeroing either always > > or in corner cases. Then later we grew anothe dma_zalloc_coherent > > interface to explicitly request zeroing, but that just added __GFP_ZERO > > to the allocation flags, which for some allocators that didn't end > > up using the page allocator ended up being a no-op and still not > > zeroing the allocations. > > > > So for this merge window I fixed up all remaining architectures to zero > > the memory in dma_alloc_coherent, and made dma_zalloc_coherent a no-op > > wrapper around dma_alloc_coherent, which fixes all of the above issues. > > > > dma_zalloc_coherent is now pointless and can go away, and Luis helped > > me writing a cocchinelle script and patch series to kill it, which I > > think we should apply now just after -rc1 to finally settle these > > issue. > > > > The script that generated the first patch is included here: > > > > @ replace_dma_zalloc_coherent @ > > expression dev, size, data, handle, flags; > > @@ > > > > -dma_zalloc_coherent(dev, size, handle, flags) > > +dma_alloc_coherent(dev, size, handle, flags) > > Great. We should also update api/alloc/zalloc-simple.cocci. The message > could just say that the z version is no longer needed. Oops, I see that you already took care of it. Thanks! julia