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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 F0521C433FE for ; Wed, 16 Nov 2022 15:17:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fcW43gxb93rCQtPTY4RuK2aJDdLR+DuS87iVMs6fYbQ=; b=o07rD3C7HvV/24 9oyDtU2sLW4G7bsqFS56WGlry7t4qpZu4vyPJp2vjIvV5+TloUNmjWIsZcEDXJv67spgPM+cot1+g qte8a94p4lv74G1NH+AbAEwnxJ9AmxTwp4xFSjKPlrCkKPFUaAJs1A+zMq3HswOAab9BHRtytdnAC shNn1OKPj3i6c7BzHzHSwPMQ39T5TTbJHb3bkDQ9uamZUIJf89M0fYIdemJRuiZ7v7rsz2Xpwvi5G zash6BlUwr3gqyNRXbmT5RgFhIvIBo/yPBp6Mfjm4kXDchzpauk52ajapG06ezSAYAsQ5Unvt5qg7 tmQZkNbEurLQSgfKc1Ig==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ovK8c-00549s-Sn; Wed, 16 Nov 2022 15:15:42 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ovK8X-00543r-3f for linux-arm-kernel@lists.infradead.org; Wed, 16 Nov 2022 15:15:41 +0000 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 BDFAE150C; Wed, 16 Nov 2022 07:15:36 -0800 (PST) Received: from [10.57.70.190] (unknown [10.57.70.190]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A3E913F587; Wed, 16 Nov 2022 07:15:26 -0800 (PST) Message-ID: Date: Wed, 16 Nov 2022 15:15:10 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH 2/7] RDMA/hfi1: don't pass bogus GFP_ flags to dma_alloc_coherent Content-Language: en-GB To: Dean Luick , Christoph Hellwig , Dennis Dalessandro , Mauro Carvalho Chehab , Alexandra Winter , Wenjia Zhang , Marek Szyprowski , Jaroslav Kysela , Takashi Iwai , Russell King Cc: linux-arm-kernel@lists.infradead.org, linux-rdma@vger.kernel.org, iommu@lists.linux.dev, linux-media@vger.kernel.org, netdev@vger.kernel.org, linux-s390@vger.kernel.org, alsa-devel@alsa-project.org References: <20221113163535.884299-1-hch@lst.de> <20221113163535.884299-3-hch@lst.de> From: Robin Murphy In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221116_071537_567964_E4EE8AA0 X-CRM114-Status: GOOD ( 16.04 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2022-11-16 14:40, Dean Luick wrote: > On 11/13/2022 10:35 AM, Christoph Hellwig wrote: >> dma_alloc_coherent is an opaque allocator that only uses the GFP_ flags >> for allocation context control. Don't pass GFP_USER which doesn't make >> sense for a kernel DMA allocation or __GFP_COMP which makes no sense >> for an allocation that can't in any way be converted to a page pointer. >> >> Signed-off-by: Christoph Hellwig >> --- >> drivers/infiniband/hw/hfi1/init.c | 21 +++------------------ >> 1 file changed, 3 insertions(+), 18 deletions(-) >> >> diff --git a/drivers/infiniband/hw/hfi1/init.c b/drivers/infiniband/hw/hfi1/init.c >> index 436372b314312..24c0f0d257fc9 100644 >> --- a/drivers/infiniband/hw/hfi1/init.c >> +++ b/drivers/infiniband/hw/hfi1/init.c >> @@ -1761,17 +1761,11 @@ int hfi1_create_rcvhdrq(struct hfi1_devdata *dd, struct hfi1_ctxtdata *rcd) >> unsigned amt; >> >> if (!rcd->rcvhdrq) { >> - gfp_t gfp_flags; >> - >> amt = rcvhdrq_size(rcd); >> >> - if (rcd->ctxt < dd->first_dyn_alloc_ctxt || rcd->is_vnic) >> - gfp_flags = GFP_KERNEL; >> - else >> - gfp_flags = GFP_USER; >> rcd->rcvhdrq = dma_alloc_coherent(&dd->pcidev->dev, amt, >> &rcd->rcvhdrq_dma, >> - gfp_flags | __GFP_COMP); >> + GFP_KERNEL); > > A user context receive header queue may be mapped into user space. Is that not the use case for GFP_USER? The above conditional is what decides. > > Why do you think GFP_USER should be removed here? Coherent DMA buffers are allocated by a kernel driver or subsystem for the use of a device managed by that driver or subsystem, and thus they fundamentally belong to the kernel as proxy for the device. Any coherent DMA buffer may be mapped to userspace with the dma_mmap_*() interfaces, but they're never a "userspace allocation" in that sense. Thanks, Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel