From: Dave Penkler <dpenkler@gmail.com>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: gregkh@linuxfoundation.org, linux-staging@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] staging: gpib: Agilent usb code cleanup
Date: Mon, 20 Jan 2025 16:15:18 +0100 [thread overview]
Message-ID: <Z45ohsfgCSN44rAC@egonzo> (raw)
In-Reply-To: <3a31262b-6bed-4f74-b00e-a124a9486e07@stanley.mountain>
On Mon, Jan 20, 2025 at 10:15:55AM +0300, Dan Carpenter wrote:
> This patch does too many things... It should be split up. People
> complain about this requirement a lot, but eventually it will become
> instinctive. I use `git citool` so I can highlight and click to add
> lines to a commit. In this code there were some dev_info() changes
> mixed into the unwind code in ->attach() that were hard to separate out
> into their own commit but it wasn't too complicated.
>
> On Sat, Jan 18, 2025 at 03:50:46PM +0100, Dave Penkler wrote:
> > Remove useless #ifdef RESET_USB_CONFIG code.
> >
>
> patch 1.
>
> > Change kalloc / memset to kzalloc
> >
>
> patch 2.
>
> > The attach function was not freeing the private data on error
> > returns. Separate the releasing of urbs and private data and
> > add a common error exit for attach failure.
> >
> > Set the board private data pointer to NULL after freeing
> > the private data.
>
> By setting the private data, this patch actually does fix the
> double free that I mentioned earlier. It changes the ->detach into
> a no-op if ->attach fails. Needs a Fixes tag. ;)
>
> But I still hope my blog will convince you that the error handling can be
> re-written in a better way. It shouldn't matter if ->private_data is
> NULL or non-NULL because the caller should only have to handle success
> or failure. The caller shouldn't have to handle a dozen different
> failure modes:
>
> 1) Failure but the ->private_data is NULL
> 2) Failure but the foo->frob pointer is an error pointer
> 3) Failure but the foo->frob pointer needs to be freed.
> 4) Failure but the foo->frob pointer contains other pointers which
> need to be freed.
> 5) ...
>
> It should just be
>
> 1) Success: Everything is allocated
> 2) Failure: Everything is cleaned up and any accesses are probably a
> use after free.
>
> >
> > Reduce console spam by emitting only one attach message.
> >
> > Change last pr_err in attach to dev_err
> >
>
> These last two can probably be combined into one patch?
>
> > @@ -1388,11 +1367,19 @@ static int agilent_82357a_attach(gpib_board_t *board, const gpib_board_config_t
> > retval = agilent_82357a_init(board);
> >
> > if (retval < 0) {
> > - mutex_unlock(&agilent_82357a_hotplug_lock);
> > - return retval;
> > + agilent_82357a_cleanup_urbs(a_priv);
> > + agilent_82357a_release_urbs(a_priv);
> > + goto attach_fail;
> > }
>
> In my blog talk about how every allocation function should have a
> matching free() function. These two functions match
> agilent_82357a_setup_urbs() so we should have a single function to
> release the urbs.
Hi,
I fully agree with you and this is the direction we are pursuing in
the gpib driver code base. We have very long way to go still and
I apologize for not splitting up the changes into multiple patches.
Thanks for the pointer to git citool.
-dave
>
> regards,
> dan carpenter
>
prev parent reply other threads:[~2025-01-20 15:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-18 14:50 [PATCH 0/2] staging: gpib: Fix NULL deref and code cleanup Dave Penkler
2025-01-18 14:50 ` [PATCH 1/2] staging: gpib: Fix NULL pointer dereference in detach Dave Penkler
2025-01-18 15:36 ` Greg KH
2025-01-18 17:30 ` Dave Penkler
2025-01-20 6:42 ` Dan Carpenter
2025-01-18 14:50 ` [PATCH 2/2] staging: gpib: Agilent usb code cleanup Dave Penkler
2025-01-20 7:15 ` Dan Carpenter
2025-01-20 15:15 ` Dave Penkler [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z45ohsfgCSN44rAC@egonzo \
--to=dpenkler@gmail.com \
--cc=dan.carpenter@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox