[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140415060411.GB29649@gmail.com>
Date: Tue, 15 Apr 2014 08:04:11 +0200
From: Ingo Molnar <mingo@...nel.org>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Igor Mammedov <imammedo@...hat.com>, linux-kernel@...r.kernel.org,
tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
x86@...nel.org, bp@...e.de, paul.gortmaker@...driver.com,
JBeulich@...e.com, prarit@...hat.com, drjones@...hat.com,
toshi.kani@...com, riel@...hat.com, gong.chen@...ux.intel.com,
andi@...stfloor.org, lenb@...nel.org, linux-acpi@...r.kernel.org
Subject: Re: [PATCH v4 3/5] acpi_processor: do not mark present at boot but
not onlined CPU as onlined
* Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> On Monday, April 14, 2014 05:11:15 PM Igor Mammedov wrote:
> > acpi_processor_add() assumes that present at boot CPUs
> > are always onlined, it is not so if a CPU failed to become
> > onlined. As result acpi_processor_add() will mark such CPU
> > device as onlined in sysfs and following attempts to
> > online/offline it using /sys/device/system/cpu/cpuX/online
> > attribute will fail.
> >
> > Do not poke into device internals in acpi_processor_add()
> > and touch "struct device { .offline }" attribute, since
> > for CPUs onlined at boot it's set by:
> > topology_init() -> arch_register_cpu() -> register_cpu()
> > before ACPI device tree is parsed, and for hotplugged
> > CPUs it's set when userspace onlines CPU via sysfs.
> >
> > Signed-off-by: Igor Mammedov <imammedo@...hat.com>
> > ---
> > v2:
> > - fix regression in v1 leading to NULL pointer dereference
> > on CPU unplug, do not remove "pr->dev = dev;"
>
> Yeah.
>
> Does this patch depend on any other patches in the series?
>
> I don't think so, but just asking.
>
> If it doesn't, why is it part of this series at all?
I suspect because Igor was rigorously stress-testing CPU hotplug, and
was fixing all the bugs he saw, before adding the one feature he is
interested in.
The feature cannot be guaranteed to be correct, without having a
stable base to work on.
As such this series makes sense, as long as the fixes precede the
feature, and as long as the fixes are correct.
Consider it work in progress, with you being one of the reviewers who
makes sure the fixes are correct.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists