From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030380AbXCMOSG (ORCPT ); Tue, 13 Mar 2007 10:18:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030377AbXCMOSF (ORCPT ); Tue, 13 Mar 2007 10:18:05 -0400 Received: from kanga.kvack.org ([66.96.29.28]:33873 "EHLO kanga.kvack.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030368AbXCMOSE (ORCPT ); Tue, 13 Mar 2007 10:18:04 -0400 Date: Tue, 13 Mar 2007 10:17:50 -0400 From: Benjamin LaHaise To: Roland McGrath Cc: Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH 1/2] avoid OPEN_MAX in SCM_MAX_FD Message-ID: <20070313141750.GH6209@kvack.org> References: <20070313083912.89D891801C5@magilla.sf.frob.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070313083912.89D891801C5@magilla.sf.frob.com> User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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: .