linux-kernel - Re: [RESEND][RFC PATCH v2] waitfd

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:	Wed, 7 Jan 2009 22:50:33 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Davide Libenzi <davidel@...ilserver.org>
Cc:	Roland McGrath <roland@...hat.com>,
	Casey Dahlin <cdahlin@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [RESEND][RFC PATCH v2] waitfd


* Davide Libenzi <davidel@...ilserver.org> wrote:

> On Wed, 7 Jan 2009, Ingo Molnar wrote:
> 
> > 
> > * Roland McGrath <roland@...hat.com> wrote:
> > 
> > > New syscall should have gone to linux-api, I think.
> > > 
> > > Do we really need another one for this?  How about using signalfd plus 
> > > setting the child's exit_signal to a queuing (SIGRTMIN+n) signal instead 
> > > of SIGCHLD?  It's slightly more magical for the userland process to know 
> > > to do that (fork -> clone SIGRTMIN).  But compared to adding a syscall 
> > > we don't really have to add, maybe better.
> > 
> > hm, i think it's cleaner conceptually than trying to wrap this into 
> > signalfd. Since we already have:
> > 
> >   #define __NR_signalfd           321
> >   #define __NR_timerfd_create     322
> >   #define __NR_timerfd_settime    325
> >   #define __NR_timerfd_gettime    326
> >   #define __NR_signalfd4          327
> > 
> > is one more really such an issue?
> 
> And what did eventfd do to you? :)

:)

> I partially agree with Roland (and I stated this during Casey's first 
> post), this can be achieved in a not too troublesome way already. A new 
> dedicated interface is easier for the challenged userspace coder, but I 
> dunno if it's worth the new code (although it does have little 
> footprint). Both ways are fine from my POV.

i think we should be defensive and generous and do a clean separate 
syscall for this - we have a pretty bad track record in syscall interface 
cleanliness, today's borderline hack is tomorrow's limitation causing 
headaches. We never know what that extra flexibility that will buy us in 
the future.

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