This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]