[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5990f0a0-eca2-7715-8d10-ce170686a133@suse.com>
Date: Mon, 20 Mar 2023 16:49:27 +0100
From: Juergen Gross <jgross@...e.com>
To: Dave Hansen <dave.hansen@...el.com>,
"Huang, Kai" <kai.huang@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>
Cc: "tglx@...utronix.de" <tglx@...utronix.de>,
"hpa@...or.com" <hpa@...or.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH v4 07/12] x86/mtrr: allocate mtrr_value array dynamically
On 20.03.23 16:31, Dave Hansen wrote:
> On 3/20/23 06:49, Juergen Gross wrote:
>>>>
>>>> @@ -750,6 +750,7 @@ static int __init mtrr_init_finialize(void)
>>>> * TBD: is there any system with such CPU which supports
>>>> * suspend/resume? If no, we should remove the code.
>>>> */
>>>> + mtrr_value = kcalloc(num_var_ranges, sizeof(*mtrr_value),
>>>> GFP_KERNEL);
>>>
>>> Theoretically dynamic allocation can fail, although it should not
>>> happen as this
>>> happens during kernel boot and the size is small. Maybe a WARN()?
>>
>> Fine with me.
>
> What *actually* happens if the system is running out of memory and this
> is the _first_ failure? Does a WARN_ON() here help someone debug what
> is going on?
Good question. Especially as we don't set __GFP_NOWARN here.
Juergen
Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3099 bytes)
Download attachment "OpenPGP_signature" of type "application/pgp-signature" (496 bytes)
Powered by blists - more mailing lists