This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Check for overflow in __alloc_dir
> 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.
Of course, use a usefully-named internal macro for the particular value of
the cap. We can consider a change for optimization later, and you can put
a comment at the macro definition site saying we should consider tuning
this later. The change you're making right now is for sanity-checking, and
the criteria for that are different than those for a tuning change.
Thanks,
Roland