kvm_getfiles is badly broken

[John Baldwin]

On Saturday 29 December 2007 06:44:50 pm Jeff Roberson wrote:
> >From kvm_getfiles(3):
> 
>       The number of files found is returned in the reference parameter cnt.
>       The files are returned as a contiguous array of file structures, 
> preceded
>       by the address of the first file entry in the kernel.
> 
> sysctl kern.file is used if the kernel is live.  This code assumes the 
> kernel copies out a struct filelist before any files.  It does not.  I can 
> not find any consumers of this interface however.  I also don't understand 
> why it supplies the address of the first file and what this would be used 
> for.
> 
> There are other users of sysctl kern.file which assume it does not prepend 
> this address so it would be wrong to change that.  Would it also be wrong 
> to change kvm to supply null as the first address?
> 
> Other inconsistencies include live kernels returning strcut xfile and dead 
> kernels returning struct file.  The interface in kvm_getfiles() claims to 
> return struct files.  I can't imagine any code actually relies on this 
> routine.
> 
> Any opinions on what we should do with this?  It has been broken since 
> 2002 at least.  I'm committing changes for my lockless struct file work. 
> As part of that I'll commit a broken but compiling implementation that 
> matches current bugs but causes the code to fail whenever it is called.

As long as fstat(1) still works on coredumps I'm happy. :)  Actually, it looks 
like fstat(1) doesn't use sysctl at all, but always uses kvm, even on live 
kernels.  It would probably be nice to provide a kvm_getfiles(3) that 
exports 'struct xfile' objects by using the sysctl on live systems and by 
simulating the syscall on crashdumps to generate 'struct xfile' objects.  You 
could then fix fstat(1) to use that instead of what it does now.  Note that 
fstat(1) actually works now by walking each process' fdp table rather than by 
walking the global filelist.

-- 
John Baldwin