linux-kernel - [PATCH 1/2] avoid OPEN_MAX in SCM_MAX

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070313083912.89D891801C5@magilla.sf.frob.com>
Date:	Tue, 13 Mar 2007 01:39:12 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCH 1/2] avoid OPEN_MAX in SCM_MAX_FD

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	255

Using the OPEN_MAX constant here is just confusing and misleading.

Signed-off-by: Roland McGrath <roland@...hat.com>
---
 include/net/scm.h |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/include/net/scm.h b/include/net/scm.h
index 5637d5e..4d37c5e 100644  
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -8,7 +8,7 @@
 /* Well, we should have at least one descriptor open
  * to accept passed FDs 8)
  */
-#define SCM_MAX_FD	(OPEN_MAX-1)
+#define SCM_MAX_FD	(NR_OPEN-1)

 struct scm_fp_list
 {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/