Received-SPF: pass (google.com: domain of linux-kernel+bounces-66624-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Thu, 15 Feb 2024 10:26:42 +0000
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Fabio M. De Francesco" <fabio.maria.de.francesco@linux.intel.com>
CC: Peter Zijlstra <peterz@infradead.org>, Dan Williams
	<dan.j.williams@intel.com>, <linux-kernel@vger.kernel.org>,
	<linux-cxl@vger.kernel.org>, Ingo Molnar <mingo@kernel.org>, Dave Jiang
	<dave.jiang@intel.com>, Ira Weiny <ira.weiny@intel.com>
Subject: Re: [PATCH 1/2 v4] cleanup: Add cond_guard() to conditional guards
Message-ID: <20240215102642.000067c5@Huawei.com>
In-Reply-To: <20240214180452.00000974@Huawei.com>
References: <20240208130424.59568-1-fabio.maria.de.francesco@linux.intel.com>
	<20240208130424.59568-2-fabio.maria.de.francesco@linux.intel.com>
	<3917370.kQq0lBPeGt@fdefranc-mobl3>
	<20240214180452.00000974@Huawei.com>
Organization: Huawei Technologies Research and Development (UK) Ltd.
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

On Wed, 14 Feb 2024 18:04:52 +0000
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:

> On Tue, 13 Feb 2024 17:51:26 +0100
> "Fabio M. De Francesco" <fabio.maria.de.francesco@linux.intel.com> wrote:
> 
> > On Thursday, 8 February 2024 14:04:23 CET Fabio M. De Francesco wrote:  
> > > Add cond_guard() macro to conditional guards.
> > > 
> > > cond_guard() is a guard to be used with the conditional variants of locks,
> > > like down_read_trylock() or mutex_lock_interruptible().
> > > 
> > > It takes a statement (or statement-expression) that is passed as its
> > > second argument. That statement (or statement-expression) is executed if
> > > waiting for a lock is interrupted or if a _trylock() fails in case of
> > > contention.
> > > 
> > > Usage example:
> > > 
> > > 	cond_guard(mutex_intr, return -EINTR, &mutex);
> > > 
> > > Consistent with other usage of _guard(), locks are unlocked at the exit of
> > > the scope where cond_guard() is called.
> > >     
> > [snip]  
> > > 
> > > +#define cond_guard(_name, _fail, args...) \
> > > +	CLASS(_name, scope)(args); \
> > > +	if (!__guard_ptr(_name)(&scope)) _fail; \
> > > +	else { }
> > > +    
> > 
> > I have converted and tested several functions in drivers/cxl and found that 
> > there are cases where this macro needs to be called twice in the same scope.
> > 
> > The current implementation fails to compile because any subsequent call to 
> > cond_guard() redefines "scope".
> > 
> > I have a solution for this, which is to instantiate a differently named 
> > variable each time cond_guard() is used:
> > 
> > #define __UNIQUE_LINE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__)
> > #define cond_guard(_name, _fail, args...) \
> >         CLASS(_name, __UNIQUE_LINE_ID(scope))(args); \
> >         if (!__guard_ptr(_name)(&__UNIQUE_LINE_ID(scope))) _fail; \
> >         else { }
> > 
> > But, before sending v5, I think it's best to wait for comments from those with 
> > more experience than me.  
> 
> Ah. So you can't use __UNIQUE_ID as guard does because we need it to be stable
> across the two uses.  What you have looks fine to me.
> We might end up with someone putting multiple calls in a macro but in my
> view anyone doing that level of complexity in a macro is shooting themselves
> in the foot.

Thought more on this whilst cycling home.  Can you use another level
of macros in combination with __UNIQUE_ID that guard uses?
My skills with macros are very limited so I'm sure I got something wrong,
but along the lines of.

#define __cond_class(__unique, _name, _fail, args...) \
   CLASS(_name, __unique)(args); \
         if (!__guard_ptr(_name)(&__unique)) _fail; \
         else { }
#define cond_class(_name, _fail, args... ) \
    __cond_class(__UNIQUE_ID(guard), _name, _fail, args...

?

> 
> Jonathan
> 
> 
> > 
> > Fabio
> > 
> > 
> > 
> >   
> 
>