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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jun 09, 2007, at 01:41:42, Paul Mackerras wrote:
Davide Libenzi writes:

The only reason we use a floating base, is because Uli preferred to have non-exactly predictable fd allocations. There no reason of re-doing the same POSIX mistake all over again:

Why must everything that makes things a bit simpler and more predictable for application programmers be called a "mistake"?

1) Linear FD allocation makes it IMPOSSIBLE for libraries to reliably use persistent FDs behind an application's back. For example, this code sequence should almost always be OK: (except when calling into a library specifically to open a file or socket)

close(0);
some_library_function();
fd = open("some_file", O_RDWR);
/* fd == 0 here */

2)  Another common code example which causes problems:

int i;
for (i = 0; i < NR_OPEN; i++)
	if (!fd_is_special_to_us(i))
		close(i);

Note that this is conceptually buggy, but occurs in several major C programming books, most of the major shells, and a lot of other software to boot.

3) In order to allocate new FDs, the kernel has to scan over a (potentially very large) bitmap. A process with 100,000 fds (not terribly uncommon) would have 12.5kbyte of FD bitmap and would trash the cache every time it tried to allocate an FD.

You can't even hope to use persistent library FDs with these problems, and they even cause problems with servers using lots of FDs. Introducing another linear FD space will just make this sort of stuff happen ALL OVER AGAIN.

If you want to make things reproducible, you could have an option where the "random" algorithm is just pseudo-linearly allocated FDs (no bitmap search) XORed with a boot-time constant either randomly- generated or set in the boot args. That way the people interested in maximum security or stress testing can use completely randomized numbers and the people who need reproducibility can get that too, *without* having the same linear FD allocation problems all over again. The fundamental problem is that a series of numbers increasing linearly from X (especially where X == 0) are used as meaningful data by lazy programmers, instead of just as a cookie. By nonlinearizing the data, even just a little, that becomes unlikely to occur. It also forces programmers to use FDs correctly and prevents problems like this in the future.

Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux