Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Ruhl, Michael J" <michael.j.ruhl@intel.com>
To:     Kees Cook <keescook@chromium.org>
CC:     "Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
        "Nguyen, Anthony L" <anthony.l.nguyen@intel.com>,
        "David S. Miller" <davem@davemloft.net>,
        "Eric Dumazet" <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        "intel-wired-lan@lists.osuosl.org" <intel-wired-lan@lists.osuosl.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-hardening@vger.kernel.org" <linux-hardening@vger.kernel.org>
Subject: RE: [PATCH v3 2/2] igb: Proactively round up to kmalloc bucket size
Thread-Topic: [PATCH v3 2/2] igb: Proactively round up to kmalloc bucket size
Thread-Index: AQHY60UEuvCQ5/6nqkOEi2jDwjCFAa4o+uNAgAGizYCAARDSsA==
Date:   Wed, 2 Nov 2022 14:12:33 +0000
Message-ID: <DM5PR11MB1324EC38950CD47541E69EE1C1399@DM5PR11MB1324.namprd11.prod.outlook.com>
References: <20221018092340.never.556-kees@kernel.org>
 <20221018092526.4035344-2-keescook@chromium.org>
 <202210282013.82F28AE92@keescook>
 <DM5PR11MB1324802F3F2098CB3239CF36C1379@DM5PR11MB1324.namprd11.prod.outlook.com>
 <202211011433.A64BF17F46@keescook>
In-Reply-To: <202211011433.A64BF17F46@keescook>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-reaction: no-action
dlp-version: 11.6.500.17
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?5DRUZsBrwLWpq0POZNu7gUJ/VDIWkmj4U2UT63069JcpRn6Pd08H2QyvtkqL?=
 =?us-ascii?Q?qlWqT3VAzhpWZ2mlIokIuC+qiO2enEqq94uhOCcxmhQjcJpVFmNt8KA1A4Ld?=
 =?us-ascii?Q?jvht6UNYGSqzGH1/7QO+eEgDb0gi/73+SU5GO0PIErnrWHdx/mUv02ouPmmh?=
 =?us-ascii?Q?RxDx5TP4WRu6OH7K5417t2XUGQZcHRprvGZErcxleRd7o5yRwDpZoF26wanS?=
 =?us-ascii?Q?ZjGT3lYkl9jr6RSSmHWfhHEiPtZveFYOeQF29fsKqTrAQPjcJKcS10F931oK?=
 =?us-ascii?Q?Qb1/lhvlSvlBLIod1wgMnU048m+jjzWq49zhF59rf+Y6ttbicoPH7b8JBqLz?=
 =?us-ascii?Q?h9uNxG+ihiYVp8zolayzlfsIndREXngs7fzas9m51Z9MvnP8DrlmuSeCEdtC?=
 =?us-ascii?Q?F2sOHfYY7jiE/nMi/pLQBu6/iM0l4XuLoil9oBDbaG2h34AGkXnP3TBCtS2c?=
 =?us-ascii?Q?AyilW0+fEeK0nmiALEy94Q0wkaQKn2zAggON5tOA0aK9YIVIe+/usOFzCQfB?=
 =?us-ascii?Q?YbNeuNNd84W23ACCqMc7gPXauAzhVsij2k2UQCLHkejeBn2RwaczNzt0ddR6?=
 =?us-ascii?Q?tJO351g0G4JSAcaBAyvLQUNQCZz+Bpog/WKQfBjiFdiZnXwopNl4ZctSDJd7?=
 =?us-ascii?Q?kZTDuq/DkSH5PNKklaJvmw3aeJhUlnowLmBpqkJ39U3C7q5zzFfddZ8uRTfD?=
 =?us-ascii?Q?ctA5CwGQVnljaoeaT5HwjL7nNnAJ5StMdw7h9Gq2JtAqwjsr/XqgTXUa1pEc?=
 =?us-ascii?Q?jUv2m7AmsGbQWtLXlt4pMdgNbcyQb0GtGtNNPHiaB9yx+mowlq+SS8QzWQKo?=
 =?us-ascii?Q?eBWoGJi5hCnuGjHUYX12gv7kdz4RQWqlxYbGI8rfHtFQUaNk+0JUv987TJZl?=
 =?us-ascii?Q?8ixn042MgXW8pkuDcLbGHHCZ2indEHmEV6xZamsZgI8Q3+siO6atyCVVCwJd?=
 =?us-ascii?Q?u0hj2qMJEpBJx77OBDquRe3JQBf0LgC2xksnTpSf7Il/t2y2TLtT02m9QlOB?=
 =?us-ascii?Q?ncqJN06on1NjMyPQMzWXuL0QakeTTheOnZ1qVSGVKk0KgZqmNS5oBpUu0C70?=
 =?us-ascii?Q?3PclfbO8Q9bixZTCRQEkOrI7u01CmqIH0wHpwmTOXqrAHmZegRcNf7G0V7yJ?=
 =?us-ascii?Q?UsYN6I7zOdjNSOLp94J7nQyct6vDuEbuSkFWpiPg7NsPfmklnRGRyeQVKDwm?=
 =?us-ascii?Q?Uq9JkbmvB+AVDPK/exmVKCGpE69QpqT2qG8fJYFpkmT9IAaJ6NhuRAf3lg0b?=
 =?us-ascii?Q?O5f92lW3aUsomftEGj/Lr94aApH3f1dsb5RYxOigjgAMilFvj6UMARyT6qdY?=
 =?us-ascii?Q?ZAHH4xNNHhmJPI0KnFzgQut1XJ6BDoM/f3KXlSjGFor7ti/Znz/dW+qN6zzv?=
 =?us-ascii?Q?rHActq8IwOC9zUvZRlAHP0s2NrRvFCJgujzkrTb8JjC6OTkHWIqUcM73+YZg?=
 =?us-ascii?Q?Ni66Qhf4OZ4AqDSI3C40M3Pp4OxJUEQ0odCZ5grRenWuvqrPEk6/Jrep19x0?=
 =?us-ascii?Q?wKQP4C8hji5TJUsWZMeoBArszbXg/yQxi+hp6UZ9Nga6X0G8cVLlkVZLr83p?=
 =?us-ascii?Q?R4W2T8dbxLtOoxBqfSBiZfCrJNfWDRcipsewv3jp?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM5PR11MB1324.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 82403c92-d89a-40b0-e08d-08dabcdc4988
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2022 14:12:33.8255
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yLsdh5FPRDaD1PP32O+y9N+e7COoiyA1nPBDVyzqmZaF+AnEXHM2YcmThZN4iLgM/Qb27+nqZM2UnCHohn6NrIXMqIrXw8rDx8vOzU5pEfY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5237
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>-----Original Message-----
>From: Kees Cook <keescook@chromium.org>
>Sent: Tuesday, November 1, 2022 5:37 PM
>To: Ruhl, Michael J <michael.j.ruhl@intel.com>
>Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L
><anthony.l.nguyen@intel.com>; David S. Miller <davem@davemloft.net>;
>Eric Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>;
>Paolo Abeni <pabeni@redhat.com>; intel-wired-lan@lists.osuosl.org;
>netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
>hardening@vger.kernel.org
>Subject: Re: [PATCH v3 2/2] igb: Proactively round up to kmalloc bucket si=
ze
>
>On Mon, Oct 31, 2022 at 08:42:36PM +0000, Ruhl, Michael J wrote:
>> Looking at the size usage (from elixir), I see:
>>
>> --
>> 	if (!q_vector) {
>> 		q_vector =3D kzalloc(size, GFP_KERNEL);
>> 	} else if (size > ksize(q_vector)) {
>> 		kfree_rcu(q_vector, rcu);
>> 		q_vector =3D kzalloc(size, GFP_KERNEL);
>> 	} else {
>> 		memset(q_vector, 0, size);
>> 	}
>> --
>>
>> If the size is rounded up, will the (size > ksize()) check ever be true?
>>
>> I.e. have you eliminated this check (and maybe getting rid of the need f=
or
>first patch?)?
>
>Hi!
>
>It looked like igb_alloc_q_vector() was designed to be called multiple
>times on the same q_vector (i.e. to grow its allocation size over time).
>So for that case, yes, the "size > ksize(q_vector)" check is needed. If
>it's only ever called once (which is hard for me to tell), then no. (And
>if "no", why was the alloc/free case even there in the first place?)

Ahh, Ok, I missed the fact that size is based on ring_count.  When I saw
the "struct_size" I assumed that size would be the same every time and
missed this point.

So can vary over time, and this ksize check is needed.

With that in mind these patches look good to me.

Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>

Mike

>-Kees
>
>--
>Kees Cook