musl - Re: Re: [RFC PATCH] x86/vdso/32: Add AT

Follow @Openwall on Twitter for new release announcements and other news

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

Message-ID: <20160312170856.GC1108@gmail.com>
Date: Sat, 12 Mar 2016 18:08:56 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Rich Felker <dalias@...c.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Borislav Petkov <bp@...en8.de>,
	"musl@...ts.openwall.com" <musl@...ts.openwall.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Szabolcs Nagy <nsz@...t70.net>
Subject: Re: Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation
 helpers


(Argh: Mail-Followup-To spam your mailer sets up is nasty!)

* Szabolcs Nagy <nsz@...t70.net> wrote:

> >   4. A calls cancellation point and syscall correctly executes
> >   5. Once A enables cancellation again, the cancellation propagates.
> > 
> > So I still see no problem.
> 
> i think the sticky signal design would work, but more
> complex than what we have and adds some atomic rmw ops
> into common code paths and not backward compatible.

Agreed about complexity, but note that the RMW ops shouldn't really be expensive 
here, as this should be a well-cached flag. Especially compared to:

> not using vsyscalls for cancellation-points sounds easier.

... FYI not using vsyscalls has _far_ higher cost than using well-cached RMW ops.

So ... what do you think about Linus's SA_SYNCHRONOUS approach? I think it can be 
made to work without much fuss.

There will still be different code paths on old and new kernels, but that's 
unavoidable.

Thanks,

	Ingo

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.