Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1551551 > unrolled thread

[PATCH] x86/microcode/intel: Fix allocation size of struct ucode_patch

Started byJunichi Nomura <j-nomura@ce.jp.nec.com>
First post2017-01-05 02:50 +0100
Last post2017-01-09 23:20 +0100
Articles 8 — 4 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH] x86/microcode/intel: Fix allocation size of struct  ucode_patch Junichi Nomura <j-nomura@ce.jp.nec.com> - 2017-01-05 02:50 +0100
    Re: [PATCH] x86/microcode/intel: Fix allocation size of struct  ucode_patch Borislav Petkov <bp@alien8.de> - 2017-01-05 11:30 +0100
    Re: [PATCH] x86/microcode/intel: Fix allocation size of struct ucode_patch Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-01-05 18:50 +0100
      Re: [PATCH] x86/microcode/intel: Fix allocation size of struct  ucode_patch Junichi Nomura <j-nomura@ce.jp.nec.com> - 2017-01-06 01:00 +0100
        Re: [PATCH] x86/microcode/intel: Fix allocation size of struct  ucode_patch Borislav Petkov <bp@alien8.de> - 2017-01-06 01:10 +0100
          Re: [PATCH] x86/microcode/intel: Fix allocation size of struct  ucode_patch Junichi Nomura <j-nomura@ce.jp.nec.com> - 2017-01-06 01:20 +0100
            Re: [PATCH] x86/microcode/intel: Fix allocation size of struct  ucode_patch Borislav Petkov <bp@alien8.de> - 2017-01-06 12:00 +0100
    [tip:x86/urgent] x86/microcode/intel: Fix allocation size of struct  ucode_patch tip-bot for Junichi Nomura <tipbot@zytor.com> - 2017-01-09 23:20 +0100

#1551551 — [PATCH] x86/microcode/intel: Fix allocation size of struct ucode_patch

FromJunichi Nomura <j-nomura@ce.jp.nec.com>
Date2017-01-05 02:50 +0100
Subject[PATCH] x86/microcode/intel: Fix allocation size of struct ucode_patch
Message-ID<sW5lL-4mv-3@gated-at.bofh.it>
We allocate struct ucode_patch here.

"size" is a size of microcode data and used for kmemdup() later
in this function.

Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading")

diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index aee3cb5..042f329 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -150,7 +150,7 @@ static struct ucode_patch *__alloc_microcode_buf(void *data, unsigned int size)
 {
 	struct ucode_patch *p;
 
-	p = kzalloc(size, GFP_KERNEL);
+	p = kzalloc(sizeof(struct ucode_patch), GFP_KERNEL);
 	if (!p)
 		return ERR_PTR(-ENOMEM);
 
-- 
Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.

[toc] | [next] | [standalone]

#1551861

FromBorislav Petkov <bp@alien8.de>
Date2017-01-05 11:30 +0100
Message-ID<sWdt0-1EN-23@gated-at.bofh.it>
In reply to#1551551
On Thu, Jan 05, 2017 at 01:03:51AM +0000, Junichi Nomura wrote:
> We allocate struct ucode_patch here.
> 
> "size" is a size of microcode data and used for kmemdup() later
> in this function.
> 
> Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
> Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading")
> 
> diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
> index aee3cb5..042f329 100644
> --- a/arch/x86/kernel/cpu/microcode/intel.c
> +++ b/arch/x86/kernel/cpu/microcode/intel.c
> @@ -150,7 +150,7 @@ static struct ucode_patch *__alloc_microcode_buf(void *data, unsigned int size)
>  {
>  	struct ucode_patch *p;
>  
> -	p = kzalloc(size, GFP_KERNEL);
> +	p = kzalloc(sizeof(struct ucode_patch), GFP_KERNEL);
>  	if (!p)
>  		return ERR_PTR(-ENOMEM);
>  
> -- 

Applied, thanks.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [prev] | [next] | [standalone]

#1552175 — Re: [PATCH] x86/microcode/intel: Fix allocation size of struct ucode_patch

FromAndy Shevchenko <andy.shevchenko@gmail.com>
Date2017-01-05 18:50 +0100
SubjectRe: [PATCH] x86/microcode/intel: Fix allocation size of struct ucode_patch
Message-ID<sWkkO-6b3-25@gated-at.bofh.it>
In reply to#1551551
On Thu, Jan 5, 2017 at 3:03 AM, Junichi Nomura <j-nomura@ce.jp.nec.com> wrote:
> We allocate struct ucode_patch here.
>
> "size" is a size of microcode data and used for kmemdup() later
> in this function.
>
> Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
> Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading")
>
> diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
> index aee3cb5..042f329 100644
> --- a/arch/x86/kernel/cpu/microcode/intel.c
> +++ b/arch/x86/kernel/cpu/microcode/intel.c
> @@ -150,7 +150,7 @@ static struct ucode_patch *__alloc_microcode_buf(void *data, unsigned int size)
>  {
>         struct ucode_patch *p;
>
> -       p = kzalloc(size, GFP_KERNEL);
> +       p = kzalloc(sizeof(struct ucode_patch), GFP_KERNEL);

Perhaps sizeof(*p) ?

>         if (!p)
>                 return ERR_PTR(-ENOMEM);

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1552411

FromJunichi Nomura <j-nomura@ce.jp.nec.com>
Date2017-01-06 01:00 +0100
Message-ID<sWq6R-1FB-19@gated-at.bofh.it>
In reply to#1552175
On 01/06/17 02:44, Andy Shevchenko wrote:
> On Thu, Jan 5, 2017 at 3:03 AM, Junichi Nomura <j-nomura@ce.jp.nec.com> wrote:
>> We allocate struct ucode_patch here.
>>
>> "size" is a size of microcode data and used for kmemdup() later
>> in this function.
>>
>> Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
>> Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading")
>>
>> diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
>> index aee3cb5..042f329 100644
>> --- a/arch/x86/kernel/cpu/microcode/intel.c
>> +++ b/arch/x86/kernel/cpu/microcode/intel.c
>> @@ -150,7 +150,7 @@ static struct ucode_patch *__alloc_microcode_buf(void *data, unsigned int size)
>>  {
>>         struct ucode_patch *p;
>>
>> -       p = kzalloc(size, GFP_KERNEL);
>> +       p = kzalloc(sizeof(struct ucode_patch), GFP_KERNEL);
> 
> Perhaps sizeof(*p) ?

Yeah, that might be preferred.

>>         if (!p)
>>                 return ERR_PTR(-ENOMEM);

-- 
Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.

[toc] | [prev] | [next] | [standalone]

#1552414

FromBorislav Petkov <bp@alien8.de>
Date2017-01-06 01:10 +0100
Message-ID<sWqgy-217-27@gated-at.bofh.it>
In reply to#1552411
On Thu, Jan 05, 2017 at 11:52:07PM +0000, Junichi Nomura wrote:
> >> +       p = kzalloc(sizeof(struct ucode_patch), GFP_KERNEL);
> > 
> > Perhaps sizeof(*p) ?
> 
> Yeah, that might be preferred.

No, those things are never preferred because

	sizeof(struct <type>)

tells you exactly the size of what kind of object you're getting vs

	sizeof(*p)

which tells you you're getting the size of what p points to.

Now you have to go look at p and what type it is. In the current case, p
is defined not far away from the use site but in a larger function, you
most likely need to eyeball up to its type when reading the code. Which
makes the whole thing less readable.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [prev] | [next] | [standalone]

#1552422

FromJunichi Nomura <j-nomura@ce.jp.nec.com>
Date2017-01-06 01:20 +0100
Message-ID<sWqqe-25X-9@gated-at.bofh.it>
In reply to#1552414
On 01/06/17 09:02, Borislav Petkov wrote:
> On Thu, Jan 05, 2017 at 11:52:07PM +0000, Junichi Nomura wrote:
>>>> +       p = kzalloc(sizeof(struct ucode_patch), GFP_KERNEL);
>>>
>>> Perhaps sizeof(*p) ?
>>
>> Yeah, that might be preferred.
> 
> No, those things are never preferred because
> 
> 	sizeof(struct <type>)
> 
> tells you exactly the size of what kind of object you're getting vs
> 
> 	sizeof(*p)
> 
> which tells you you're getting the size of what p points to.
> 
> Now you have to go look at p and what type it is. In the current case, p
> is defined not far away from the use site but in a larger function, you
> most likely need to eyeball up to its type when reading the code. Which
> makes the whole thing less readable.

Personally I have same opinion as yours. :)

But according to Documentation/process/coding-style.rst, it seems
"sizeof(*p)" is preferred style and the reason there makes some
sense.

Quote from coding-style.rst:
  > The preferred form for passing a size of a struct is the following:
  > 
  >         p = kmalloc(sizeof(*p), ...);
  > 
  > The alternative form where struct name is spelled out hurts readability and
  > introduces an opportunity for a bug when the pointer variable type is changed
  > but the corresponding sizeof that is passed to a memory allocator is not.

I'm fine with either way.

-- 
Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.

[toc] | [prev] | [next] | [standalone]

#1552686

FromBorislav Petkov <bp@alien8.de>
Date2017-01-06 12:00 +0100
Message-ID<sWApz-zS-1@gated-at.bofh.it>
In reply to#1552422
On Fri, Jan 06, 2017 at 12:14:13AM +0000, Junichi Nomura wrote:
> Personally I have same opinion as yours. :)
> 
> But according to Documentation/process/coding-style.rst, it seems
> "sizeof(*p)" is preferred style and the reason there makes some
> sense.
> 
> Quote from coding-style.rst:
>   > The preferred form for passing a size of a struct is the following:
>   > 
>   >         p = kmalloc(sizeof(*p), ...);
>   > 
>   > The alternative form where struct name is spelled out hurts readability and
							^^^^^^^^^^^^^^^^^^^^^

Yeah, right. Change is from 2005 (af4e5a218e18a). Pekka didn't know better then. :-P

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [prev] | [next] | [standalone]

#1554751 — [tip:x86/urgent] x86/microcode/intel: Fix allocation size of struct ucode_patch

Fromtip-bot for Junichi Nomura <tipbot@zytor.com>
Date2017-01-09 23:20 +0100
Subject[tip:x86/urgent] x86/microcode/intel: Fix allocation size of struct ucode_patch
Message-ID<sXQsi-1ot-9@gated-at.bofh.it>
In reply to#1551551
Commit-ID:  9fcf5ba2ef908af916e9002891fbbca20ce4dc98
Gitweb:     http://git.kernel.org/tip/9fcf5ba2ef908af916e9002891fbbca20ce4dc98
Author:     Junichi Nomura <j-nomura@ce.jp.nec.com>
AuthorDate: Mon, 9 Jan 2017 12:41:46 +0100
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Mon, 9 Jan 2017 23:11:14 +0100

x86/microcode/intel: Fix allocation size of struct ucode_patch

We allocate struct ucode_patch here. @size is the size of microcode data
and used for kmemdup() later in this function.

Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading")
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: http://lkml.kernel.org/r/7a730dc9-ac17-35c4-fe76-dfc94e5ecd95@ce.jp.nec.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

---
 arch/x86/kernel/cpu/microcode/intel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index faec8fa..9434865 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -150,7 +150,7 @@ static struct ucode_patch *__alloc_microcode_buf(void *data, unsigned int size)
 {
 	struct ucode_patch *p;
 
-	p = kzalloc(size, GFP_KERNEL);
+	p = kzalloc(sizeof(struct ucode_patch), GFP_KERNEL);
 	if (!p)
 		return ERR_PTR(-ENOMEM);

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web