Re: [patch 7/8] fdmap v2 - implement sys_socket2

[Al Viro]

On Sat, Jun 09, 2007 at 01:21:24PM -0700, Linus Torvalds wrote:
> Which is why you'd like to do the *initial* operation with a flag that 
> says "please set the FD_CLOEXEC flag on the file descriptor", so that you 
> *atomically* install the file file descriptor and set the FD_CLOEXEC bit.
> 
> It's trivial to do for open(), but there are about a million ways to get a 
> file descriptor, and open() is just about the *only* one of those that 
> actually takes a "flags" field that can be used to tell the kernel.

Eww...  Idea of pipe(2) taking flags as argument...

BTW, you also need that for recvmsg() (SCM_RIGHTS) and fsckloads of
syscalls we've got duplicating open() for no good reason (and no, "BSD
folks did it for sockets, so we'll do it for tons of new subsystems" doesn't
really qualify ;-/).

I don't know if your indirect is a good idea in that respect, actually.
AFAICS, you are suggesting per-syscall meanings of the flags, so it really
smells like YAMultiplexor, free for abuse.
 
> (And dammit, that _is_ a *real*issue*. No races necessary, no NR_OPEN 
> iterations, no even *halfway* suspect code. It's perfectly fine to do
> 
> 	close(0);
> 	close(1);
> 	close(2);
> 	.. generate filenames, whatever ..
> 	if (open(..) < 0 || open(..) < 0 || open(..) < 0)
> 		die("Couldn't redirect stdin/stdout/stderr");
> 
> and there's absolutely nothing wrong with this kind of setup, even if you 
> could obviously have done it other ways too (ie by using "dup2()" instead 
> of "close + open"),

Yeah, well - I wouldn't call that perfectly fine, but it's probably too
widespread to kill.  Just as use of 0 for NULL ;-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/