linux-kernel - Re: [PATCH 0/9] gpib: Unify *allocate

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] [day] [month] [year] [list]

Message-ID: <2OjrGFXCpqmsmtnBumGHXqrOAd07ZoXToot9HgqnNZPFuvPZ-Loj4jPkpj54QOVKoaNLAIaLgl6WYVpGQh6DsBg67LKXLKwAtSbKf0_LRXw=@protonmail.com>
Date: Tue, 20 Jan 2026 16:12:57 +0000
From: Dominik Karol Piątkowski <dominik.karol.piatkowski@...tonmail.com>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: Dave Penkler <dpenkler@...il.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Michael Rubin <matchstick@...erthere.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/9] gpib: Unify *allocate_private

Hi Dan,

On Monday, January 19th, 2026 at 08:34, Dan Carpenter <dan.carpenter@...aro.org> wrote:

> 
> 
> On Tue, Jan 13, 2026 at 07:08:37PM +0000, Dominik Karol Piątkowski wrote:
> 
> > Recently, gpib driver got out of staging area. There is still a bit of work that
> > can be done to improve it.
> > 
> > Return values for *allocate_private functions as well as calling code in
> > gpib driver are all over the place. Unify them by returning -errno if
> > something fails, zero otherwise. Use the returned value as early return
> > value in case of error.
> > 
> > Untouched gpib files already use the proposed convention.
> > 
> > Signed-off-by: Dominik Karol Piątkowski dominik.karol.piatkowski@...tonmail.com
> 
> 
> I don't see the point of the allocate_private() functions. Why not
> just open code it?

In most cases, *allocate_private() functions are used just once, in the
*attach() functions. The exception is tnt4882_gpib.c, that has 3 *attach()
functions, so it makes sense to keep it at least there. From what I noticed,
*allocate_private sometimes just allocates memory for private_data (for example,
in agilent_82350b.c), but sometimes it also does a bit of other stuff (like
initializing private_data mutexes in agilent_82357a.c).

And tnt4882_gpib.c falls into the "also does a bit of other stuff" category.

If I were to open code it, I would have to leave tnt4882_gpib.c as-is, drop the
`Unify *allocate_private usage` patches and introduce patches that move the
*allocate_private() to *attach() functions. I think v3 has a cleaner approach.

What do you think about that?

Thanks,
Dominik Karol

> 
> regards,
> dan carpenter