On Mon, Mar 27, 2023 at 12:11:54PM +0300, Adrian Hunter wrote:
> On 25/03/23 16:15, Markus Elfring wrote:
> > Date: Fri, 17 Mar 2023 13:13:14 +0100
> >
> > The label “fail” was used to jump to another pointer check despite of
> > the detail in the implementation of the function “amd_uncore_cpu_up_prepare”
> > that it was determined already that the corresponding variable contained
> > a null pointer (because of a failed function call in two cases).
> >
> > 1. Thus return directly after a call of the function “amd_uncore_alloc”
> > failed in the first if branch.
> >
> > 2. Use more appropriate labels instead.
> >
> > 3. Reorder jump targets at the end.
> >
> > 4. Delete a redundant check and kfree() call.
> >
> > 5. Omit an explicit initialisation for the local variable “uncore_llc”.
> >
> >
> > This issue was detected by using the Coccinelle software.
> >
> > Fixes: 39621c5808f5dda75d03dc4b2d4d2b13a5a1c34b ("perf/x86/amd/uncore: Use dynamic events array")
> > Fixes: 503d3291a937b726757c1f7c45fa02389d2f4324 ("perf/x86/amd: Try to fix some mem allocation failure handling")
>
> Commit should be only the first 12 characters of the hash.
> Refer: https://docs.kernel.org/process/submitting-patches.html
>
> But this is not a fix. Redundant calls to kfree do not break
> anything.
>
> Also avoid using the term "exception" since, in x86, exceptions are
> hardware events. Better to just call it "error handling".
Don't feed the trolls; Markus is a bot or other weird construct that's
been banned from lkml.
