Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1325831
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Crashes with 874bbfe600a6 in 3.18.25 |
| Date | 2016-02-03 19:50 +0100 |
| Message-ID | <qYaF4-5Ec-23@gated-at.bofh.it> (permalink) |
| References | (6 earlier) <qV9Pc-3ib-33@gated-at.bofh.it> <qVbHj-4Dq-1@gated-at.bofh.it> <qY24O-aO-3@gated-at.bofh.it> <qY4Jl-1TE-19@gated-at.bofh.it> <qY8tA-4kE-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Wed, 3 Feb 2016, Tejun Heo wrote:
> On Wed, Feb 03, 2016 at 01:28:56PM +0100, Michal Hocko wrote:
> > > The CPU was 168, and that one was offlined in the meantime. So
> > > __queue_work fails at:
> > > if (!(wq->flags & WQ_UNBOUND))
> > > pwq = per_cpu_ptr(wq->cpu_pwqs, cpu);
> > > else
> > > pwq = unbound_pwq_by_node(wq, cpu_to_node(cpu));
> > > ^^^ ^^^^ NODE is -1
> > > \ pwq is NULL
> > >
> > > if (last_pool && last_pool != pwq->pool) { <--- BOOM
>
> So, the proper fix here is keeping cpu <-> node mapping stable across
> cpu on/offlining which has been being worked on for a long time now.
> The patchst is pending and it fixes other issues too.
>
> > So I think 874bbfe600a6 is really bogus. It should be reverted. We
> > already have a proper fix for vmstat 176bed1de5bf ("vmstat: explicitly
> > schedule per-cpu work on the CPU we need it to run on"). This which
> > should be used for the stable trees as a replacement.
>
> It's not bogus. We can't flip a property that has been guaranteed
> without any provision for verification. Why do you think vmstat blow
> up in the first place? vmstat would be the canary case as it runs
> frequently on all systems. It's exactly the sign that we can't break
> this guarantee willy-nilly.
You're in complete failure denial mode once again.
Fact is:
That patch breaks stuff because there is no stable cpu -> node mapping
accross cpu on/offlining. As a result this selects unbound_pwq_by_node() on
node -1.
The reason why you need to do that work->cpu assignment might be legitimate,
but that does not justify that you expose systems to a lurking out of bounds
access which results in a NULL pointer dereference.
As long as cpu_to_node(cpu) can return -1, we need a sanity check there. And
we need that now and not at some point in the future when the patches
establishing a stable cpu -> node mapping are finished.
Stop arguing around a bug which really exists and was exposed by this patch.
Thanks,
tglx
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Crashes with 874bbfe600a6 in 3.18.25 Jiri Slaby <jslaby@suse.cz> - 2016-02-03 10:40 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Thomas Gleixner <tglx@linutronix.de> - 2016-02-03 11:50 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Michal Hocko <mhocko@kernel.org> - 2016-02-03 13:30 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Tejun Heo <tj@kernel.org> - 2016-02-03 17:30 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Michal Hocko <mhocko@kernel.org> - 2016-02-03 17:50 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Tejun Heo <tj@kernel.org> - 2016-02-03 18:10 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Michal Hocko <mhocko@kernel.org> - 2016-02-04 07:40 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Michal Hocko <mhocko@kernel.org> - 2016-02-04 08:50 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-02-03 18:10 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Tejun Heo <tj@kernel.org> - 2016-02-03 18:10 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Tejun Heo <tj@kernel.org> - 2016-02-03 18:20 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-02-03 18:20 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-02-04 03:10 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Tejun Heo <tj@kernel.org> - 2016-02-05 17:50 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-02-05 21:50 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Tejun Heo <tj@kernel.org> - 2016-02-05 22:00 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Tejun Heo <tj@kernel.org> - 2016-02-05 22:10 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Henrique de Moraes Holschuh <hmh@hmh.eng.br> - 2016-02-06 14:10 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-02-07 06:30 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-02-07 07:10 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-02-05 22:10 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-02-04 11:10 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Thomas Gleixner <tglx@linutronix.de> - 2016-02-04 11:50 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-02-04 12:10 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Jan Kara <jack@suse.cz> - 2016-02-04 12:30 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Daniel Bilik <daniel.bilik@neosystem.cz> - 2016-02-04 18:00 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-02-05 03:50 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Daniel Bilik <daniel.bilik@neosystem.cz> - 2016-02-05 09:20 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-02-05 09:40 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Thomas Gleixner <tglx@linutronix.de> - 2016-02-03 19:50 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Thomas Gleixner <tglx@linutronix.de> - 2016-02-03 20:10 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Tejun Heo <tj@kernel.org> - 2016-02-03 20:20 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Tejun Heo <tj@kernel.org> - 2016-02-03 20:10 +0100
Re: Crashes with 874bbfe600a6 in 3.18.25 Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-02-05 06:50 +0100
csiph-web