[Crash-utility] Re: [RFC] Patch for fixing 'files' command: TAKE 4

[Dave Anderson]

Dave Anderson wrote:


>
> This patch-to-your-patch seems to fix it:
>
> RCS file: /nfs/projects/cvs/crash/filesys.c,v
> retrieving revision 1.45
> diff -r1.45 filesys.c
> 2015c2015,2016
> <       ulong files_struct_addr, fdtable_addr;
> ---
> >       ulong files_struct_addr;
> >       ulong fdtable_addr = 0;
> 2153c2154,2155
> <       if (!fdtable_addr || !files_struct_addr || max_fdset == 0 || max_fds == 0) {
> ---
> >       if ((VALID_MEMBER(files_struct_fdt) && !fdtable_addr) ||
> >           !files_struct_addr || max_fdset == 0 || max_fds == 0) {
>
> With fdtable_addr uninitialized, it only gets past the "if" statement
> above on a pre-2.6.14 kernel if there were non-zero garbage left there
> on the stack.  If there happened to be a zero there, the "if" path is
> taken inadvertently, and it just prints "No open files".
>
> But do you agree with my logic of the enclosed checking of the validity first
> and then the fdtable_addr?  Seems right.
>
> Dave

Hi Rachita,

AFAICT, if we're running 2.6.14 with fdtables, it doesn't appear
that there's any possibility of fdtable_addr ever being zero?
It begins life in alloc_files() pointing to the embedded fdtable
in the files_struct, and potentially can be reassigned to a
replacement fdtable allocated from expand_fdtable().  But I don't
see anywhere that it could be cleared.

For that matter, my original check for a NULL files_struct_addr
also looks to be impossible, even in the case of kernel threads.
Maybe back in the 2.2 timeframe it could be NULL -- I just don't
remember...

In any case, I prefer to leave the code as it is above -- just to
be absolutely safe.

Dave


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20060103/65b43eae/attachment.htm>