IMHO I would have thought that 32bits would be enough...
To get a reference count to 2^32 requires 4x10^9 objects referencing
that one item.  This is an implausible number of any 'real' item to have,
they would take up a ridiculous amount of memory/swap - especially if it
is a 'real' workload of some type.

I presume you've seem the 16bit counter wrap - with obvious devistating
results...

On the other hand it is more or less impossible to wrap a 64bit counter.
(count at 1GHz for 600 years).

However the extra 8 bytes per 'file' is probably a higher cost in kvm.

    David


----- Original Message ----- 
From: <jaromir.dolecek@artisys.cz>
To: <tech-kern@netbsd.org>
Sent: Friday, December 14, 2001 9:34 AM
Subject: struct file reference counts


> Hi,
> I'd like to bump the f_count and f_msgcount members of struct file
> to 'u_long', so that they can't be overflowed easily (it's possible
> now, since they are just 'short' and overflow is not checked anywhere).
> 
> I wonder if any DIAGNOSTIC/DEBUG checks need to be added too
> for f_count/f_msgcount. I believe it's not necessary, see below.
> 
> Since 'maxfiles' is an 'int', number of descriptors (and thus
> references to appropriate struct file) could not be bigger than 2
> ** (sizeof(int) * 8 - 1). Theoretically, the amount of all of
> references might be temporarily higher than maxfiles if descriptor
> passing is used. In that case, number of references might be as
> high as (maxfiles + unp_rights), where both 'maxfiles' and 'unp_rights'
> are 'int'.
> 
> On 32bit archs, the overflow can't actually happen - 2 * 2 **
> (sizeof(int) * 8 - 1) references means there exist that number of
> pointers to the struct, which would consume 4GB of physical &
> virtual kernel memory, which is unfeasible even with Intel's PSE36
> extension support.  On LP64 archs, it is theoretically possible
> for kernel to have 4GB memory just for the the file descriptor
> pointers.  However, (2 * 2 ** (sizeof(int) * 8 - 1)) still fits
> into 'long' on LP64, so we are covered. Of course, unp_internalize()
> should be changed to check for 'unp_rights' overflow and return
> error if that would happen.
> 
> I'm appending the patch to fix this issue.
> 
> Opinions?
> 
> Jarda
> -- 
> Jaromir Dolecek <jaromir.dolecek@artisys.cz>
> ARTISYS, s.r.o., Stursova 71, 61600 Brno, Czech Republic
> phone: +420-5-41224836 / fax: +420-5-41224870 / http://www.artisys.cz
>