Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 4 Feb 2021 15:53:55 -0400
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     John Hubbard <jhubbard@nvidia.com>
CC:     Joao Martins <joao.m.martins@oracle.com>, <linux-mm@kvack.org>,
        <linux-kernel@vger.kernel.org>, <linux-rdma@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Doug Ledford <dledford@redhat.com>,
        "Matthew Wilcox" <willy@infradead.org>
Subject: Re: [PATCH 1/4] mm/gup: add compound page list iterator
Message-ID: <20210204195355.GO4247@nvidia.com>
References: <20210203220025.8568-1-joao.m.martins@oracle.com>
 <20210203220025.8568-2-joao.m.martins@oracle.com>
 <955dbe68-7302-a8bc-f0b5-e9032d7f190e@nvidia.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <955dbe68-7302-a8bc-f0b5-e9032d7f190e@nvidia.com>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from mlx.ziepe.ca (142.162.115.133) by MN2PR15CA0016.namprd15.prod.outlook.com (2603:10b6:208:1b4::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.20 via Frontend Transport; Thu, 4 Feb 2021 19:53:57 +0000
Received: from jgg by mlx with local (Exim 4.94)        (envelope-from <jgg@nvidia.com>)        id 1l7khP-003afx-Qh; Thu, 04 Feb 2021 15:53:55 -0400
X-Header: ProcessedBy-CMR-outbound
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1;
        t=1612468443; bh=Vog3C+ozn5IGqHkEIcJj0R/cWKg/4JFMiLXZ4zVvRvE=;
        h=ARC-Seal:ARC-Message-Signature:ARC-Authentication-Results:Date:
         From:To:CC:Subject:Message-ID:References:Content-Type:
         Content-Disposition:In-Reply-To:X-ClientProxiedBy:MIME-Version:
         X-MS-Exchange-MessageSentRepresentingType:X-Header;
        b=ma3XZqsc73QwreG+4FOlgjiY0b1YNeIh4n8vf3yMdSH4yo+dXNHG9zX8gegWxcwBU
         Jki0TaQWGMC5JkA5bjMku5A/WaQa/Zmbh1+u7YxsDZJspz8xZpjpKf0NAI3nr4DCZJ
         xBpQmFvOPgMj4eknXD9tG9xDDgGJSrdQFKvFJEeeiSa++T0hIb2s+4egbrYlq1pPFW
         7c0eMTDrW9ojgC55zEetqYlz1c8HrDh3JqTf6l+j+uy8XLpKIWxD1cNog1Bm2FlII8
         eshWRSZIvq0/jVGdj8TSOWIBxGXY060lE3JJP9x/71HKHRgh9XmndkDE0m4oYdVnd3
         SVTASjO0R83bw==
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Feb 03, 2021 at 03:00:01PM -0800, John Hubbard wrote:
> > +static inline void compound_next(unsigned long i, unsigned long npages,
> > +				 struct page **list, struct page **head,
> > +				 unsigned int *ntails)
> > +{
> > +	if (i >= npages)
> > +		return;
> > +
> > +	*ntails = count_ntails(list + i, npages - i);
> > +	*head = compound_head(list[i]);
> > +}
> > +
> > +#define for_each_compound_head(i, list, npages, head, ntails) \
> 
> When using macros, which are dangerous in general, you have to worry about
> things like name collisions. I really dislike that C has forced this unsafe
> pattern upon us, but of course we are stuck with it, for iterator helpers.
> 
> Given that we're stuck, you should probably use names such as __i, __list, etc,
> in the the above #define. Otherwise you could stomp on existing variables.

Not this macro, it after cpp gets through with it all the macro names
vanish, it can't collide with variables.

The usual worry is you might collide with other #defines, but we don't
seem to worry about that in the kernel

Jason