linux-kernel - Re: [PATCH RFC 0/6] iio: core: Introduce cleanup.h support for mode locks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251206184645.51099254@jic23-huawei>
Date: Sat, 6 Dec 2025 18:46:45 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Nuno Sá <noname.nuno@...il.com>, Kurt Borja
 <kuurtb@...il.com>, Andy Shevchenko <andriy.shevchenko@...el.com>,
 Lars-Peter Clausen <lars@...afoo.de>, Michael Hennerich
 <Michael.Hennerich@...log.com>, Benson Leung <bleung@...omium.org>, Antoniu
 Miclaus <antoniu.miclaus@...log.com>, Gwendal Grignou
 <gwendal@...omium.org>, Shrikant Raskar <raskar.shree97@...il.com>,
 Per-Daniel Olsson <perdaniel.olsson@...s.com>, David Lechner
 <dlechner@...libre.com>, Nuno Sá <nuno.sa@...log.com>, Andy
 Shevchenko <andy@...nel.org>, Guenter Roeck <groeck@...omium.org>, Jonathan
 Cameron <Jonathan.Cameron@...wei.com>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org, chrome-platform@...ts.linux.dev
Subject: Re: [PATCH RFC 0/6] iio: core: Introduce cleanup.h support for mode
 locks

On Thu, 4 Dec 2025 17:07:28 +0200
Andy Shevchenko <andy.shevchenko@...il.com> wrote:

> On Thu, Dec 4, 2025 at 4:35 PM Nuno Sá <noname.nuno@...il.com> wrote:
> > On Wed, 2025-12-03 at 14:18 -0500, Kurt Borja wrote:  
> > >
> > > In a recent driver review discussion [1], Andy Shevchenko suggested we
> > > add cleanup.h support for the lock API:
> > >
> > >       iio_device_claim_{direct,buffer_mode}().  
> >
> > We already went this patch and then reverted it. I guess before we did not had
> > ACQUIRE() and ACQUIRE_ERR() but I'm not sure that makes it much better. Looking at the
> > last two patches on how we are handling the buffer mode stuff, I'm really not convinced...
> >
> > Also, I have doubts sparse can keep up with the __cleanup stuff so I'm not sure the
> > annotations much make sense if we go down this path. Unless we want to use both
> > approaches which is also questionable.  
> 
> This, indeed, needs a (broader) discussion and I appreciate that Kurt
> sent this RFC. Jonathan, what's your thoughts?

I was pretty heavily involved in discussions around ACQUIRE() and it's use
in CXL and runtime PM (though that's still evolving with Rafael trying
to improve the syntax a little).  As you might guess I did have this use
in mind during those discussions.

As far as I know by avoiding the for loop complexity of the previous
try we made and looking (under the hood) like guard() it should be much
easier and safer to use.  Looking at this was on my list, so I'm very happy
to see this series from Kurt exploring how it would be done.

Sparse wise there is no support for now for any of the cleanup.h magic
other than ignoring it.  That doesn't bother me that much though as these
macros create more or less hidden local variables that are hard to mess
with in incorrect ways.

So in general I'm very much in favour of this for same reasons I jumped
in last time (which turned out to be premature!)

This will be particularly useful in avoiding the need for helper functions
in otherwise simple code flows.

Jonathan