From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S969217AbdAFASV (ORCPT ); Thu, 5 Jan 2017 19:18:21 -0500 Received: from TYO200.gate.nec.co.jp ([210.143.35.50]:50076 "EHLO tyo200.gate.nec.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754291AbdAFASL (ORCPT ); Thu, 5 Jan 2017 19:18:11 -0500 From: Junichi Nomura To: Borislav Petkov CC: Andy Shevchenko , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "hpa@zytor.com" Subject: Re: [PATCH] x86/microcode/intel: Fix allocation size of struct ucode_patch Thread-Topic: [PATCH] x86/microcode/intel: Fix allocation size of struct ucode_patch Thread-Index: AQHSZu+U/l1IZb2FmEOpgrKPMNh7baEpkfGAgABmwYCAAALvgIAAAz6A Date: Fri, 6 Jan 2017 00:14:13 +0000 Message-ID: <8d24ed6b-9c81-74e3-848d-47ff72b752b4@ce.jp.nec.com> References: <7a730dc9-ac17-35c4-fe76-dfc94e5ecd95@ce.jp.nec.com> <06089643-a36b-93b2-1d26-0336c4d0583c@ce.jp.nec.com> <20170106000237.5dybkvr35sbba2yx@pd.tnic> In-Reply-To: <20170106000237.5dybkvr35sbba2yx@pd.tnic> Accept-Language: en-US, ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.125.85] Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v060IPbC031695 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 ) > > 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.