Re: [PATCH 1/2] avoid OPEN_MAX in SCM_MAX_FD

On Tue, Mar 13, 2007 at 01:39:12AM -0700, Roland McGrath wrote:

The OPEN_MAX constant is an arbitrary number with no useful relation to
anything.  Nothing should be using it.  This patch changes SCM_MAX_FD to
use NR_OPEN instead of OPEN_MAX.  This increases the size of the struct
scm_fp_list type fourfold, to make it big enough to contain as many file
descriptors as could be asked of it.  This size increase may not be very
worthwhile, but at any rate if an arbitrary limit unrelated to anything
else is being defined it should be done explicitly here with:

-#define SCM_MAX_FD	(OPEN_MAX-1)
+#define SCM_MAX_FD	(NR_OPEN-1)

This is a bad idea.  From linux/fs.h:

#undef NR_OPEN
#define NR_OPEN (1024*1024)     /* Absolute upper limit on fd num */

There isn't anything I can see guaranteeing that net/scm.h is included 
before fs.h.  This affects networking and should really be Cc'd to 
netdev@vger.kernel.org, which will raise the issue that if SCM_MAX_FD is 
raised, the resulting simple kmalloc() must be changed.  That said, I 
doubt SCM_MAX_FD really needs to be raised, as applications using many 
file descriptors are unlikely to try to send their entire file table to 
another process in one go -- they have to handle the limits imposed by 
SCM_MAX_FD anyways.

		-ben
-- 
"Time is of no importance, Mr. President, only life is important."
Don't Email: [off-list ref].