linux-kernel - Re: [PATCH v5 6/8] iio: buffer-dma: Enable support for DMABUFs

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: <20231226153037.1a2052f3@jic23-huawei>
Date: Tue, 26 Dec 2023 15:30:37 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Nuno Sá <noname.nuno@...il.com>
Cc: Paul Cercueil <paul@...pouillou.net>, Lars-Peter Clausen
 <lars@...afoo.de>, Sumit Semwal <sumit.semwal@...aro.org>, Christian
 König <christian.koenig@....com>, Vinod Koul
 <vkoul@...nel.org>, Jonathan Corbet <corbet@....net>,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 dmaengine@...r.kernel.org, linux-iio@...r.kernel.org,
 linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 linaro-mm-sig@...ts.linaro.org, Michael Hennerich
 <Michael.Hennerich@...log.com>
Subject: Re: [PATCH v5 6/8] iio: buffer-dma: Enable support for DMABUFs


> > > +struct iio_dma_buffer_block *
> > > +iio_dma_buffer_attach_dmabuf(struct iio_buffer *buffer,
> > > +                            struct dma_buf_attachment *attach)
> > > +{
> > > +       struct iio_dma_buffer_queue *queue = iio_buffer_to_queue(buffer);
> > > +       struct iio_dma_buffer_block *block;
> > > +       int err;
> > > +
> > > +       mutex_lock(&queue->lock);  
> > 
> >         guard(mutex)(&queue->lock);  
> 
> I'm also a big fan of this new stuff but shouldn't we have a prep patch making the
> transition to that? Otherwise we'll end up with a mix of styles. I'm happy to clean
> up stuff with follow up patches (even some coding style could be improved IIRC) but
> typically that's not how we handle things like this I believe...

Ideally yes, I think a prep patch would make sense - but I'm not that fussed
about it and follow up patches would be fine here. 

There are cases for using this that are much easier to justify than
others, so I don't really mind if simple

mutex_lock();
do_something
mutex_unlock();

cases are left for ever not using guard(), though I also don't mind if people want to use
scoped_guard() or guard for these just to be consistent.  Either way is pretty
easy to read.  We'll probably also continue to gain new uses of this logic such
as the conditional guard stuff that is queued up for the next merge window and
whilst that is going on we are going to have a bit of mixed style.

Jonathan


> 
> - Nuno Sá
> >   
>