linux-kernel - [PATCH 0/1] futex: don't spin waiting for PF_EXITING -> PF

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150216201313.GA18246@redhat.com>
Date:	Mon, 16 Feb 2015 21:13:13 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Darren Hart <darren@...art.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>
Cc:	Jerome Marchand <jmarchan@...hat.com>,
	Larry Woodman <lwoodman@...hat.com>,
	Mateusz Guzik <mguzik@...hat.com>,
	linux-kernel@...r.kernel.org,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	Pavel Emelyanov <xemul@...allels.com>
Subject: [PATCH 0/1] futex: don't spin waiting for PF_EXITING ->
	PF_EXITPIDONE transition

On 02/02, Oleg Nesterov wrote:
>
> And another question. Lets forget about this ->mm check. I simply can not
> understand this
>
>	ret = (p->flags & PF_EXITPIDONE) ? -ESRCH : -EAGAIN
>
> logic in attach_to_pi_owner(). First of all, why do we need to retry if
> PF_EXITING is set but PF_EXITPIDONE is not? Why we can not simply ignore
> PF_EXITING and rely on exit_pi_state_list() if PF_EXITPIDONE is not set?
>
> I must have missed something but this looks buggy, I do not see any
> preemption point
  ^^^^^^^^^^

I meant synchronization point, sorry for confusion.

> in this "retry" loop. Suppose that max_cpus=1 and rt_task()
> preempts the non-rt PF_EXITING owner. Looks like futex_lock_pi() can spin
> forever in this case? (OK, ignoring RT throttling).

Finally I forced myself to try to make the 1st patch ;) To remind, we have
more problems with robust+pi futexes, this needs another patch(es). Otherwise
we could (probably) even kill PF_EXITPIDONE.

Peter. I have no idea how to test it (except it obviously fixes the test-
case I sent before). IOW: please review.

And I still fail to understand why this PF_EXITING logic was added in the
first place. So I also have the problem with the changelog, it merely says
"don't do this because this is not needed".

On top of "check PF_KTHREAD rather than !p->mm to filter out kthreads" but
doesn't depend on it.

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/