On Tuesday, January 17, 2017 8:18 AM, Ingo Molnar wrote:
> Mind sending this as a proper patch, with akpm Cc:-ed?
Not at all, I'll put it together this week.
Thanks,
Lukas
* Odzioba, Lukasz wrote:
> > pr_warn("x86/cpu: Ignoring invalid "clearcpuid=%s' option!\n", arg)
> >
> > Which would save quite a bit of head scratching and frustration when
> > someone has a
> > bad enough day to add silly typos to the kernel cmdline.
>
> Is there any particular reason w
On Thursday, January 5, 2017 8:56 AM, Ingo Molnar wrote:
>
> Good one, queued it up.
Hi Ingo, thanks for picking up the patch.
> When we don't accept the value we should at least inform the user (via a
> printk
> that includes the 'clearcpuid' token in its message) that we totally ignored
> wh
* Borislav Petkov wrote:
> On Wed, Dec 28, 2016 at 02:55:40PM +0100, Lukasz Odzioba wrote:
> > A negative number can be specified in the cmdline which will be used as
> > setup_clear_cpu_cap() argument. With that we can clear/set some bit in
> > memory predceeding boot_cpu_data/cpu_caps_cleared
On Wed, Dec 28, 2016 at 02:55:40PM +0100, Lukasz Odzioba wrote:
> A negative number can be specified in the cmdline which will be used as
> setup_clear_cpu_cap() argument. With that we can clear/set some bit in
> memory predceeding boot_cpu_data/cpu_caps_cleared which may cause kernel
> to misbehav
A negative number can be specified in the cmdline which will be used as
setup_clear_cpu_cap() argument. With that we can clear/set some bit in
memory predceeding boot_cpu_data/cpu_caps_cleared which may cause kernel
to misbehave. This patch adds lower bound check to setup_disablecpuid().
Fixes: ac
6 matches
Mail list logo
