From: "H. Peter Anvin" <hpa@zytor.com>
To: Jiri Slaby <jirislaby@gmail.com>
Cc: Borislav Petkov <bp@amd64.org>, "x86@kernel.org" <x86@kernel.org>,
Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: intel_cacheinfo: potential NULL dereference?
Date: Tue, 22 Jun 2010 10:09:40 -0700 [thread overview]
Message-ID: <4C20EE54.2050506@zytor.com> (raw)
In-Reply-To: <4C20C478.9030505@gmail.com>
On 06/22/2010 07:11 AM, Jiri Slaby wrote:
> On 06/22/2010 03:08 PM, Borislav Petkov wrote:
>> From: Jiri Slaby <jirislaby@gmail.com>
>> Date: Tue, Jun 22, 2010 at 07:20:14AM -0400
>>
>>> On 06/22/2010 01:18 PM, Jiri Slaby wrote:
>>>> Stanse found, that this_leaf->l3 is dereferenced at <<1>>, but checked
>>>> for being NULL at <<2>>. Is the check superfluous or the dev assignment
>>>> should go after the check?
>>>
>>> Oh, and I have another report with same symptoms for show_cache_disable.
>>
>> Right, so I have a patch in tip/x86/cpu
>> (8cc1176e5de534d55cb26ff0cef3fd0d6ad8c3c0) which reorganizes
>> and cleans up that code. With it, all possible checks land in
>> amd_check_l3_disable() and if they have all been passed, the PCI dev is
>> guaranteed to be properly set. So no need for sprinkling additional NULL
>> checks in the code.
>>
>> How's that?
>
> Looks good.
>
Do we need a patch for the existing code to go into -linus and -stable,
though?
-hpa
next prev parent reply other threads:[~2010-06-22 17:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-22 11:18 intel_cacheinfo: potential NULL dereference? Jiri Slaby
2010-06-22 11:20 ` Jiri Slaby
2010-06-22 13:08 ` Borislav Petkov
2010-06-22 14:11 ` Jiri Slaby
2010-06-22 17:09 ` H. Peter Anvin [this message]
2010-06-22 19:19 ` Borislav Petkov
2010-06-22 19:45 ` [PATCH -v2] x86, cacheinfo: Carve out L3 cache slot accessors Borislav Petkov
2010-06-22 15:15 ` intel_cacheinfo: potential NULL dereference? H. Peter Anvin
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=4C20EE54.2050506@zytor.com \
--to=hpa@zytor.com \
--cc=bp@amd64.org \
--cc=jirislaby@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.org \
/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.