minor bug in sysctl doc (and potential /proc problem in fs/file_table.c)

Mitch Trachtenberg (mjt@northcoast.com)
Fri, 22 Oct 1999 15:55:24 -0700


This is a multi-part message in MIME format.
--------------82BB5C72362CE2AA6FD9DB45
Content-Type: multipart/alternative;
boundary="------------AF00C68A2DCC7BA850891C30"

--------------AF00C68A2DCC7BA850891C30
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

In Linux kernel versions through 2.2.13, files
Documentation/sysctl/fs.txt and Documentation/proc.txt both state that
/proc/sys/fs/file-nr's second number represents the number of used file
handles, when it appears to actually indicate the number of allocated
but unused file handles. This is corrected in the first two hunks of
the attached diff.

There is a separate issue in that kernel/sysctl.c treats the variable
nr_files as if it were the address of an array of three integers,
despite nr_files being a single integer defined in fs/file_table.c (and
followed by the definitions of nr_free_files and max_files). The
remainder of the attached patch, messily, puts the three variables in a
structure and then separately defines max_files because it is exported
to modules. I've provided this for completeness, but an alternate, and
probably more appropriate, patch would be to simply put a warning line
at the definition of nr_files in fs/file_table.c: "CAUTION:
kernel/sysctl.c depends on the following three integers being defined in
the current order".

I do not subscribe to this list and would appreciate being cc'd on any
replies. Apologies in advance if this post is ill-advised or
misaddressed. I couldn't locate an entry in the MAINTAINERS file for
sysctl or /proc.

--
Mitch Trachtenberg
mjt@northcoast.com
707.677.0762

--------------AF00C68A2DCC7BA850891C30 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">  
In Linux kernel versions through 2.2.13, files Documentation/sysctl/fs.txt and Documentation/proc.txt both state that /proc/sys/fs/file-nr's second number represents the number of used file handles, when it appears to actually indicate the number of allocated but unused file handles.  This is corrected in the first two hunks of the attached diff.

There is a separate issue in that kernel/sysctl.c treats the variable nr_files as if it were the address of an array of three integers, despite nr_files being a single integer defined in fs/file_table.c (and followed by the definitions of nr_free_files and max_files).  The remainder of the attached patch, messily, puts the three variables in a structure and then separately defines max_files because it is exported to modules.  I've provided this for completeness, but an alternate, and probably more appropriate, patch would be to simply put a warning line at the definition of nr_files in fs/file_table.c:  "CAUTION: kernel/sysctl.c depends on the following three integers being defined in the current order".

I do not subscribe to this list and would appreciate being cc'd on any replies.  Apologies in advance if this post is ill-advised or misaddressed.  I couldn't locate an entry  in the MAINTAINERS file for sysctl or /proc.

-- 
Mitch Trachtenberg
mjt@northcoast.com
707.677.0762
 

 
 
 
  --------------AF00C68A2DCC7BA850891C30-- --------------82BB5C72362CE2AA6FD9DB45 Content-Type: text/plain; charset=us-ascii; name="diff4sysctl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diff4sysctl" diff -ur linux2213/Documentation/proc.txt linux/Documentation/proc.txt --- linux2213/Documentation/proc.txt Sat Feb 6 12:46:20 1999 +++ linux/Documentation/proc.txt Fri Oct 22 13:07:30 1999 @@ -453,9 +453,10 @@ file. The three values in file-nr denote the number of allocated file - handles, the number of used file handles, and the maximum number of - file handles. When the allocated file handles come close to the - maximum, but the number of actually used ones is far behind, you've + handles, the number of allocated but unused file handles, + and the maximum number of file handles. + When the allocated file handles come close to the + maximum, but the number of unused ones is not near zero, you've encountered a peak in your usage of file handles and you don't need to increase the maximum. diff -ur linux2213/Documentation/sysctl/fs.txt linux/Documentation/sysctl/fs.txt --- linux2213/Documentation/sysctl/fs.txt Mon Aug 9 12:04:38 1999 +++ linux/Documentation/sysctl/fs.txt Fri Oct 22 13:08:35 1999 @@ -80,10 +80,10 @@ want to increase this limit. The three values in file-nr denote the number of allocated -file handles, the number of used file handles and the maximum -number of file handles. When the allocated file handles come -close to the maximum, but the number of actually used ones is -far behind, you've encountered a peak in your usage of file +file handles, the number of allocated but unused file handles +and the maximum number of file handles. When the allocated +file handles come close to the maximum, but the number of unused ones +is not near zero, you've encountered a peak in your usage of file handles and you don't need to increase the maximum. ============================================================== diff -ur linux2213/fs/file_table.c linux/fs/file_table.c --- linux2213/fs/file_table.c Tue Feb 23 15:30:59 1999 +++ linux/fs/file_table.c Fri Oct 22 14:58:09 1999 @@ -7,15 +7,21 @@ #include #include +#include #include /* SLAB cache for filp's. */ static kmem_cache_t *filp_cache; /* sysctl tunables... */ -int nr_files = 0; /* read only */ -int nr_free_files = 0; /* read only */ +Filps_stats filps_stats = {0,0,NR_FILE}; +int max_files = NR_FILE;/* kept because exported to modules */ +/* above structure enforces order of variables below, for sysctl access */ +#if 0 +int nr_files = 0; /* read only */ +int nr_free_files = 0; /* read only */ int max_files = NR_FILE;/* tunable */ +#endif /* Free list management, if you are here you must have f_count == 0 */ static struct file * free_filps = NULL; @@ -26,7 +32,7 @@ free_filps->f_pprev = &file->f_next; free_filps = file; file->f_pprev = &free_filps; - nr_free_files++; + filps_stats.nr_free_files++; } /* The list of in-use filp's must be exported (ugh...) */ @@ -72,11 +78,11 @@ static int old_max = 0; struct file * f; - if (nr_free_files > NR_RESERVED_FILES) { + if (filps_stats.nr_free_files > NR_RESERVED_FILES) { used_one: f = free_filps; remove_filp(f); - nr_free_files--; + filps_stats.nr_free_files--; new_one: memset(f, 0, sizeof(*f)); f->f_count = 1; @@ -89,23 +95,23 @@ /* * Use a reserved one if we're the superuser */ - if (nr_free_files && !current->euid) + if (filps_stats.nr_free_files && !current->euid) goto used_one; /* * Allocate a new one if we're below the limit. */ - if (nr_files < max_files) { + if (filps_stats.nr_files < filps_stats.max_files) { f = kmem_cache_alloc(filp_cache, SLAB_KERNEL); if (f) { - nr_files++; + filps_stats.nr_files++; goto new_one; } /* Big problems... */ printk("VFS: filp allocation failed\n"); - } else if (max_files > old_max) { - printk("VFS: file-max limit %d reached\n", max_files); - old_max = max_files; + } else if (filps_stats.max_files > old_max) { + printk("VFS: file-max limit %d reached\n", filps_stats.max_files); + old_max = filps_stats.max_files; } return NULL; } diff -ur linux2213/include/linux/fs.h linux/include/linux/fs.h --- linux2213/include/linux/fs.h Tue Oct 19 17:14:02 1999 +++ linux/include/linux/fs.h Fri Oct 22 15:28:22 1999 @@ -47,7 +47,16 @@ /* And dynamically-tunable limits and defaults: */ extern int max_inodes; -extern int max_files, nr_files, nr_free_files; + +typedef struct { + int nr_files; + int nr_free_files; + int max_files; +} Filps_stats; +extern Filps_stats filps_stats; +extern int max_files; +/*extern int max_files, nr_files, nr_free_files;*/ + extern int max_super_blocks, nr_super_blocks; #define NR_FILE 4096 /* this can well be larger on a larger system */ diff -ur linux2213/kernel/sysctl.c linux/kernel/sysctl.c --- linux2213/kernel/sysctl.c Tue Oct 19 17:14:02 1999 +++ linux/kernel/sysctl.c Fri Oct 22 12:57:27 1999 @@ -261,9 +261,9 @@ 0444, NULL, &proc_dointvec}, {FS_MAXINODE, "inode-max", &max_inodes, sizeof(int), 0644, NULL, &proc_dointvec}, - {FS_NRFILE, "file-nr", &nr_files, 3*sizeof(int), + {FS_NRFILE, "file-nr", &filps_stats, 3*sizeof(int), 0444, NULL, &proc_dointvec}, - {FS_MAXFILE, "file-max", &max_files, sizeof(int), + {FS_MAXFILE, "file-max", &filps_stats.max_files, sizeof(int), 0644, NULL, &proc_dointvec}, {FS_NRSUPER, "super-nr", &nr_super_blocks, sizeof(int), 0444, NULL, &proc_dointvec}, --------------82BB5C72362CE2AA6FD9DB45-- - 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/