[OpenAFS-devel] [PATCH] fix openafs crashes on linux 2.6.10-2.6.12, and all RHEL4 kernels

[Derrick J Brashear]

On Tue, 8 May 2007, chas williams - CONTRACTOR wrote:

> In message <10F582F31B7CC582D409D2AE@sirius.fac.cs.cmu.edu>,Jeffrey Hutzelman w
> rites:
>> The problem with this is that it requires every caller to know whether the
>> thing it is allocating is "huge" or "not huge", where the distinction
>> depends on the operating system, platform, and perhaps even kernel
>> configuration.  That means we'd be pushing platform-dependent code into
>> every caller of osi_Alloc, which is exactly what the abstraction is
>> intended to prevent.
>
> yet there is precedent for this already: osi_Alloc{Small,Medium,Large}Space.
> i am only asking for 33% more insanity.  perhaps the distinction of huge
> and not huge is not appropriate; pageable versus non-pageable might be
> a better choice.
>
> currently, you have no clear idea (you can guess) what kind of memory you
> might be from the allocator.  this does have an effect on reproducibility
> of certain bugs.

allocate an extra amount of memory for each allocation, making it aligned, 
and put a tag saying how to free it in each allocation, then the 
alloc/free package and not the caller can decide how to allocate.

>>> it would also serve to point out sections of the afs code
>>> that could stand some improvement.
>>
>> No; the size of individual memory allocations is not necessarily an
>> indicator of code quality.
>
> i should have said 'could possibly'.  however, you must admit the
> larger the allocation the more likely it is to fail.  afs doesnt
> typically handle allocation failures well.

you're just saying that because you don't like panics.