On Mon, Dec 08, 2014 at 08:30:18PM +0100, David Hildenbrand wrote:
> > > active_writer is cleared while holding cpuhp_lock, so this should be safe,
> > > right?
> >
> > You lost me on that one. Don't we get to that piece of code precisely
> > because we don't hold any of the CPU-hotplug locks?
> > active_writer is cleared while holding cpuhp_lock, so this should be safe,
> > right?
>
> You lost me on that one. Don't we get to that piece of code precisely
> because we don't hold any of the CPU-hotplug locks? If so, the
> writer might well hold all the locks it needs, and might well
On Mon, Dec 08, 2014 at 07:58:14PM +0100, David Hildenbrand wrote:
> > On Mon, Dec 08, 2014 at 07:13:03PM +0100, David Hildenbrand wrote:
> > > Commit b2c4623dcd07 ("rcu: More on deadlock between CPU hotplug and
> > > expedited
> > > grace periods") introduced another problem that can easily be
> On Mon, Dec 08, 2014 at 07:13:03PM +0100, David Hildenbrand wrote:
> > Commit b2c4623dcd07 ("rcu: More on deadlock between CPU hotplug and
> > expedited
> > grace periods") introduced another problem that can easily be reproduced by
> > starting/stopping cpus in a loop.
> >
> > E.g.:
> > for
On Mon, Dec 08, 2014 at 07:13:03PM +0100, David Hildenbrand wrote:
> Commit b2c4623dcd07 ("rcu: More on deadlock between CPU hotplug and expedited
> grace periods") introduced another problem that can easily be reproduced by
> starting/stopping cpus in a loop.
>
> E.g.:
> for i in `seq 5000`;
The title should of course say active_writer ... grml
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Commit b2c4623dcd07 ("rcu: More on deadlock between CPU hotplug and expedited
grace periods") introduced another problem that can easily be reproduced by
starting/stopping cpus in a loop.
E.g.:
for i in `seq 5000`; do
echo 1 > /sys/devices/system/cpu/cpu1/online
echo 0 >
Commit b2c4623dcd07 (rcu: More on deadlock between CPU hotplug and expedited
grace periods) introduced another problem that can easily be reproduced by
starting/stopping cpus in a loop.
E.g.:
for i in `seq 5000`; do
echo 1 /sys/devices/system/cpu/cpu1/online
echo 0
The title should of course say active_writer ... grml
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
On Mon, Dec 08, 2014 at 07:13:03PM +0100, David Hildenbrand wrote:
Commit b2c4623dcd07 (rcu: More on deadlock between CPU hotplug and expedited
grace periods) introduced another problem that can easily be reproduced by
starting/stopping cpus in a loop.
E.g.:
for i in `seq 5000`; do
On Mon, Dec 08, 2014 at 07:13:03PM +0100, David Hildenbrand wrote:
Commit b2c4623dcd07 (rcu: More on deadlock between CPU hotplug and
expedited
grace periods) introduced another problem that can easily be reproduced by
starting/stopping cpus in a loop.
E.g.:
for i in `seq 5000`;
On Mon, Dec 08, 2014 at 07:58:14PM +0100, David Hildenbrand wrote:
On Mon, Dec 08, 2014 at 07:13:03PM +0100, David Hildenbrand wrote:
Commit b2c4623dcd07 (rcu: More on deadlock between CPU hotplug and
expedited
grace periods) introduced another problem that can easily be reproduced
active_writer is cleared while holding cpuhp_lock, so this should be safe,
right?
You lost me on that one. Don't we get to that piece of code precisely
because we don't hold any of the CPU-hotplug locks? If so, the
writer might well hold all the locks it needs, and might well change
On Mon, Dec 08, 2014 at 08:30:18PM +0100, David Hildenbrand wrote:
active_writer is cleared while holding cpuhp_lock, so this should be safe,
right?
You lost me on that one. Don't we get to that piece of code precisely
because we don't hold any of the CPU-hotplug locks? If so, the
14 matches
Mail list logo
