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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2065AC433FE for ; Wed, 16 Nov 2022 06:11:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232335AbiKPGLR (ORCPT ); Wed, 16 Nov 2022 01:11:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230417AbiKPGLN (ORCPT ); Wed, 16 Nov 2022 01:11:13 -0500 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E5D963CF; Tue, 15 Nov 2022 22:11:11 -0800 (PST) Received: by verein.lst.de (Postfix, from userid 2407) id CFEBC68AA6; Wed, 16 Nov 2022 07:11:06 +0100 (CET) Date: Wed, 16 Nov 2022 07:11:06 +0100 From: Christoph Hellwig To: Leon Romanovsky Cc: Christoph Hellwig , Dennis Dalessandro , Mauro Carvalho Chehab , Alexandra Winter , Wenjia Zhang , Marek Szyprowski , Jaroslav Kysela , Takashi Iwai , Russell King , Robin Murphy , 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 Subject: Re: [PATCH 7/7] dma-mapping: reject __GFP_COMP in dma_alloc_attrs Message-ID: <20221116061106.GA19118@lst.de> References: <20221113163535.884299-1-hch@lst.de> <20221113163535.884299-8-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Mon, Nov 14, 2022 at 10:11:50AM +0200, Leon Romanovsky wrote: > In RDMA patches, you wrote that GFP_USER is not legal flag either. So it > is better to WARN here for everything that is not allowed. So __GFP_COMP is actually problematic and changes behavior, and I plan to lift an optimization from the arm code to the generic one that only rounds up allocations to the next page size instead of the next power of two, so I need this check now. Other flags including GFP_USER are pretty bogus to, but I actually need to do a full audit before rejecting them, which I've only done for GFP_COMP so far.