> Date: Tue, 28 Sep 1999 11:52:16 -0400 (EDT)
> From: Chuck Lever <cel@monkey.org>
>
> it may have made sense a while ago to create an inode for each
> socket before there were dentries, and before you could create more
> than 4K sockets per system. nowadays i think it is wasteful and
> introduces DoS and system instability where one might expect normal
> behavior. administrators need to be aware of how to set their fd
> and socket maximums, and what can happen if they don't set them
> appropriately -- this is now a security issue.
>
> You make some valid points, certainly, but here is some food
> for thought:
>
> 1) Some sockets do need a bonafide inode attached to them,
> for example UNIX domain sockets bound to a name in the filesystem
> space.
So? You have the following can of worms:
1. AF_UNIX socket's dentry.
2. AF_UNIX socket's inode.
3. AF_UNIX socket's struct socket (embedded into inode)
4. AF_UNIX struct's sock.
5. dentry for fs object.
6. inode (say it, ext2) for it.
You have two inodes in that game. The latter is completely real, it may be
chmoded, etc. - normal ext2 inode. The former has no business being
anywhere near icache.
> 2) In my experiments over a year ago, I do recall one statistic, that
> even with all of this overhead the kernel could manage ~40,000
> full sockets with ~64MB of ram. This was on a 64-bit system.
If the memory consumption is a problem (rather than cache pollution) we
might take the fs-specific part out of struct inode and let the filesystem
deal with it. I've done that in my tree back in January and had _no_
problems. The only icky part was separating the pipe stuff and it had been
in the main tree since 2.3.1. ->u.generic_ip-> instead of ->u.foosfs_i. +
allocate upon foofs_new_inode/foofs_read_inode + free upon
foofs_clear_inode. That's it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/