Re: [PATCH] Check for overflow in __alloc_dir

[Rich Felker <dalias at aerifal dot cx>]

On Thu, Oct 11, 2012 at 03:38:59PM -0700, Roland McGrath wrote:
> > The highest reasonable value is about 64k, and that's being generous;
> > I'd cap it at 4k or so, or better yet completely ignore the blksize.
> > That's roughly the point at which the cost of actually processing
> > entries drowns out the syscall cost anyway.
> 
> For now, don't cap it at anything smaller than what actual filesystems
> report today for st_blksize.  Being appropriately conservative means
> setting high enough that it doesn't change the behavior for any
> circumstance other than a thoroughly misbehaving filesystem--in other
> words, only cap amounts that are quite likely to actually lead to an
> allocation failure or excessive memory starvation, so 2M is pretty
> reasonable.

I think it's pretty unreasonable for a small program (e.g. an ftpd)
that might have many instances and otherwise only be using <100k of
memory per instance to suddenly consume ~2M just because it's reading
a directory on an odd filesystem with large blocksize.

The kernel is perfectly capable of handling caching efficiently by
itself. There is no reason userspace should care about block sizes.

Rich