linux-kernel - Re: sched: memory corruption on completing completions

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]

Date:	Thu, 5 Feb 2015 14:57:17 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Davidlohr Bueso <dave@...olabs.net>
Cc:	Sasha Levin <sasha.levin@...cle.com>,
	Waiman Long <Waiman.Long@...com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andrey Ryabinin <a.ryabinin@...sung.com>,
	Dave Jones <davej@...emonkey.org.uk>,
	LKML <linux-kernel@...r.kernel.org>,
	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
Subject: Re: sched: memory corruption on completing completions

On Thu, Feb 5, 2015 at 2:37 PM, Davidlohr Bueso <dave@...olabs.net> wrote:
>>
>> It is possible that the paravirt spinlocks could be saved by:
>>
>>  - moving the clearing of TICKET_SLOWPATH_FLAG into the fastpath locking code.
>
> Ouch, to avoid deadlocks they explicitly need the unlock to occur before
> the slowpath tail flag is read.

Well, just make the unlock do the actual real unlock operation
("fastpath"), leaving the TICKET_SLOWPATH_FLAG alone. The unlock path
can *test* the flag and do whatever kicking it needs to get people
started again, but not clear it again.

Then, the clearing could be done by the lockers. That way the unlock
path at least doesn't change the spinlock any more - sicne the
spinlock might have been free'd at any time after the actual unlock.

Or something. I'm handwaving. I really dislike all the paravirt crap
we do. It tends to be really ugly, and I'm not just talking about
spinlocks. TLB flushing etc tends to get interesting too.

> Yeah, you just cannot have a slowpath without reads or writes :D

Well, you *could* do the slow-path while holding the lock, and making
the actual ock release be the last part of the operation (and do the
final unlock with a "cmpxchg" that fails and re-does the slowpath if
something changed). Then the slowpath can read and write the lock all
it wants.

But people generally want to avoid that, since it makes the hold times
longer. So the "drop the lock, *then* test if we should do some slow
path fixup" tends to be the preferred model, it's just that that model
is broken due to the lifetime rules. Making it read-only would at
least make it a lot less broken..

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