From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Johan Hovold <johan+linaro@kernel.org>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v1 1/1] irqdomain: Refactor error path in __irq_domain_alloc_fwnode()
Date: Fri, 4 Aug 2023 23:12:11 +0300 [thread overview]
Message-ID: <ZM1bm2+/lyb+IH86@smile.fi.intel.com> (raw)
In-Reply-To: <84f2ea9ee0c08c8826c0f26c4a6291c9@kernel.org>
On Fri, Aug 04, 2023 at 06:33:07PM +0100, Marc Zyngier wrote:
> On 2023-08-04 17:49, Andy Shevchenko wrote:
> > First of all, there is no need to call kasprintf() if the previous
> > allocation failed. Second, there is no need to call for kfree()
> > when we know that its parameter is NULL. Refactor the code accordingly.
...
> > n = kasprintf(GFP_KERNEL, "irqchip@%pa", pa);
> > break;
> > }
> > -
> > - if (!fwid || !n) {
> > + if (!n) {
> > kfree(fwid);
> > - kfree(n);
> > return NULL;
> > }
>
> What are you trying to fix?
I'm not trying to fix anything (there is no such statement from me),
but I would think of some micro-optimization (speedup boot for
unnoticeable time? Dunno.).
> We have a common error handling path, which makes it easy to
> track the memory management. I don't think this sort of bike
> shedding adds much to the maintainability of this code.
Your call, of course, but I not often see in the kernel two or three attempts
to allocate some memory and have grouped check for the failure.
> Now if you have spotted an actual bug, I'm all ears.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2023-08-04 20:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-04 16:49 [PATCH v1 1/1] irqdomain: Refactor error path in __irq_domain_alloc_fwnode() Andy Shevchenko
2023-08-04 17:33 ` Marc Zyngier
2023-08-04 20:12 ` Andy Shevchenko [this message]
2023-08-04 22:24 ` Marc Zyngier
2023-08-07 15:06 ` Andy Shevchenko
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=ZM1bm2+/lyb+IH86@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=johan+linaro@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.