From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Cc: "Jorge Lopez" <jorge.lopez2@hp.com>,
"Hans de Goede" <hdegoede@redhat.com>,
"Mark Gross" <markgross@kernel.org>,
"Thomas Weißschuh" <linux@weissschuh.net>,
platform-driver-x86@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
dan.carpenter@linaro.org, kernel-janitors@vger.kernel.org,
error27@gmail.com, vegard.nossum@oracle.com,
darren.kenny@oracle.com, "kernel test robot" <lkp@intel.com>
Subject: Re: [PATCH v2 4/4] platform/x86: hp-bioscfg: Fix error handling in hp_add_other_attributes()
Date: Mon, 13 Nov 2023 15:31:48 +0200 (EET) [thread overview]
Message-ID: <1b58df2d-b444-ddb7-7533-9911d35f8f7@linux.intel.com> (raw)
In-Reply-To: <fb97e3ea-1bee-4d7d-a8d4-dd76107f75ef@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 3318 bytes --]
On Sat, 11 Nov 2023, Harshit Mogalapalli wrote:
> On 10/11/23 8:14 pm, Ilpo Järvinen wrote:
> > On Fri, 10 Nov 2023, Harshit Mogalapalli wrote:
> >
>
> Thanks for the review.
>
> > This changelog needs to be rewritten, it contains multiple errors. I
> > suppose even this patch could be split into two but I'll not be too picky
> > here if you insist on fixing them in the same patch.
> >
>
> Any thoughts on how to split this into two patches ?
>
> I thought of fixing memory leak in separate patch, but that would add more
> code which should be removed when we move kobject_put() to the end.
I meant that in the first patch you fix add the missing kfree(). Then in
the second one, you correct kobject_put() + play with goto labels. There's
no extra code that needs to be added and then removed AFAICT.
That way, you can make the commit messages more to the point too per
patch.
> > > We have two issues:
> > > 1. Memory leak of 'attr_name_kobj' in the error handling path.
> >
> > True, but not specific enough to be useful.
> >
>
> Should I mention something like:
>
> 'attr_name_kobj' is allocated using kzalloc, but on all the error paths we
> don't free it, hence we have a memory leak.
>
> > > 2. When kobject_init_and_add() fails on every subsequent error path call
> > > kobject_put() to cleanup.
> >
> > This makes no sense. The only case when there old code had no issue is
> > "when kobject_init_and_add() fails" but now your wording claims it to be
> > source of problem. Please rephrase this.
> >
>
> Does this look better:
>
> kobject_put() must be called to cleanup memory associated with the object if
> kobject_init_and_add() returns an error , before this patch only the error
> path which is immediately next to kobject_init_and_add() has a kobject_put()
> not any other error paths after it. Fix this by moving the kobject_put() into
> a goto label "err_other_attr_init:" and use that for error paths after
> kobject_init_and_add().
This is easier to understand I think:
kobject_put() must be always called after passing the object to
kobject_init_and_add(). Only the error path which is immediately next
to kobject_init_and_add() calls kobject_put() and not any other error
path after it.
Fix the error handling by moving the kobject_put() into the goto label
err_other_attr_init that is already used by all the error paths after
kobject_init_and_add().
> > > Both of these issues will be fixed when we add kobject_put() in the goto
> > > label, as kfree() is already part of kobject_put().
> >
> > No, you're fixing a problem in the patch which is not covered by moving
> > kobject_put()!
>
> Sure, I will try to rephrase it to:
>
> 1. Add a new label "unlock_drv_mutex"
> 2. Add a kfree() in the default statement of switch before going to
> "unlock_drv_mutex" to free up the memory allocated with kzalloc.
> 2. Move kobject_put() to goto "err_other_attr_init:" and use this goto label
> in every error path after kobject_init_and_add().
>
> Please let me know if you have any comments.
I think none of this is needed for this patch after you move the other fix
into a separate patch. Those two paragraphs I suggest above would explain
the problem and solution (no need to have these numbered bullets or
anything else besides those 2 paragraphs).
--
i.
next prev parent reply other threads:[~2023-11-13 13:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-10 14:29 [PATCH v2 1/4] platform/x86: hp-bioscfg: Remove unused obj in hp_add_other_attributes() Harshit Mogalapalli
2023-11-10 14:29 ` [PATCH v2 2/4] platform/x86: hp-bioscfg: Simplify return check " Harshit Mogalapalli
2023-11-10 14:29 ` [PATCH v2 3/4] platform/x86: hp-bioscfg: move mutex_lock down " Harshit Mogalapalli
2023-11-10 14:35 ` Ilpo Järvinen
2023-11-10 14:29 ` [PATCH v2 4/4] platform/x86: hp-bioscfg: Fix error handling " Harshit Mogalapalli
2023-11-10 14:44 ` Ilpo Järvinen
2023-11-10 19:58 ` Harshit Mogalapalli
2023-11-13 13:31 ` Ilpo Järvinen [this message]
2023-11-13 13:57 ` Harshit Mogalapalli
2023-11-13 14:15 ` Ilpo Järvinen
2023-11-13 16:01 ` Dan Carpenter
2023-11-13 16:44 ` Ilpo Järvinen
2023-11-10 14:31 ` [PATCH v2 1/4] platform/x86: hp-bioscfg: Remove unused obj " Ilpo Järvinen
2023-11-10 14:45 ` Ilpo Järvinen
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=1b58df2d-b444-ddb7-7533-9911d35f8f7@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=dan.carpenter@linaro.org \
--cc=darren.kenny@oracle.com \
--cc=error27@gmail.com \
--cc=harshit.m.mogalapalli@oracle.com \
--cc=hdegoede@redhat.com \
--cc=jorge.lopez2@hp.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=lkp@intel.com \
--cc=markgross@kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=vegard.nossum@oracle.com \
/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