[OpenAFS] afsd gets unhappy when ThisCell has no root.afs and -dynroot not specified

[Derrick J Brashear]

On Thu, 31 May 2007, Jeffrey Altman wrote:

> Adam Megacz wrote:
>> In case this leaves anybody else scratching their head...
>>
>> I discovered that with OpenAFS 1.4.4 and linux 2.6.20.4, if ThisCell
>> refers to a cell which has no volume called root.afs, and you forget
>> to specify -dynroot, afsd will hang on startup, and attempts to shut
>> it down will cause this:
>>
>>   slab error in kmem_cache_destroy(): cache `afs_inode_cache': Can't free all objects
>>    [<c0159294>] kmem_cache_destroy+0x7c/0xbf
>>    [<f898a656>] cleanup_module+0x1e/0x53 [openafs]
>>    [<c0131986>] sys_delete_module+0x130/0x194
>>    [<c014b8a8>] remove_vma+0x31/0x36
>>    [<c014c256>] do_munmap+0x16e/0x1c1
>>    [<c0102e30>] syscall_call+0x7/0xb
>>    [<c0400033>] rpc_timeout_upcall_queue+0x35/0xc4
>>    =======================
>>
>> I wouldn't call this a bug; it's a gross user configuration error --
>> but the failure mode is wierd enough that I thought I should mention
>> it so that it turns up when people google the error message.
>>
>>   - a
>
> Actually, I do consider this a bug, its just such a low priority bug
> that no one has gotten around to fixing it.
>
> When there is no dynroot, afsd must obtain the root.afs volume in order
> to complete its startup.  It will attempt to mount it forever.
>
> The Windows AFS client will panic if the volume cannot be loaded after
> some period of time and freelance mode is not in use.

Actually, the issue here is we don't note if the kmem cache was actually 
created before destroying it. We should fix it for 1.4.5