linux-kernel - Re: [PATCH] skip increamenting nr for TASK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 22 Dec 2013 16:09:18 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Vaibhav Shinde <v.bhav.shinde@...il.com>,
	Ajeet Yadav <ajeet.yadav.77@...il.com>,
	Tejun Heo <tj@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] skip increamenting nr for TASK_UNINTERRUPTIBLE

Vaibhav,

again, I think that everything was explained by Linus, let me
add some details.

> > In coredump case, where thread_1 faults while thread_2 is in
> > TASK_UNINTERRUPTIBLE state, it cannot handle the SIGKILL.
> > Thus the process hangs on event.
> > The coredump routine freezes until the thread state is
> > uninterruptible.

Yes. But why we should even try to "fix" coredump in this case?

> > Solution: Continue for coredump, without waiting for uninterruptible
> >  thread,

This can't work, please see below.

> > as it will get killed as soon as it returns from
> >  uninterruptible state.

Not necessarily. It can play with ->mm before it notices the pending
SIGKILL. And, if nothing else, the coredumping paths do not even take
mmap_sem because we assume that the dumper is the only user.

But even if this doesn't happen,

> >  Therefore do not increament thread count for threads with
> >  TASK_UNINTERRUPTIBLE.

This is very wrong too. This means that we can start the coredump before
the _accounted_ thread exits (because a skipped thread can exit first and
decrement the counter). This also means that coredump_finish() can race
with the unaccounted threads.

> >   sigaddset(&t->pending.signal, SIGKILL);
> >   signal_wake_up(t, 1);
> > - nr++;
> > + if(!(t->state & TASK_UNINTERRUPTIBLE))
> > + nr++;

Again, we can't simply check t->state & TASK_UNINTERRUPTIBLE. This can
be false positive or it can sleep in TASK_UNINTERRUPTIBLE right after
the check. And even "& TASK_UNINTERRUPTIBLE" is wrong, please look at
TASK_KILLABLE.

Oleg.

--
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/