When we moved from fd_ofiles to a struct fdtab, the fd_ofiles became
authorjym <jym>
Mon, 21 Mar 2011 00:22:02 +0000 (00:22 +0000)
committerjym <jym>
Mon, 21 Mar 2011 00:22:02 +0000 (00:22 +0000)
commitcf9f9440f1be1ba1168d95309a95893c257c2d0c
tree1ff87839e21d2721b14a217a8fc09db6c99d9ddb
parent54f3f27bd646aed3ad5d2e38a5f14f4b8472311f
When we moved from fd_ofiles to a struct fdtab, the fd_ofiles became
an array of pointer (in struct fdtab) rather than a pointer of pointers.

Sadly for us, no, arrays and pointers are not equivalent from a memory
perspective: while pointers from/to another address space can
be consumed by kvm(3) to query for data in kernel space, arrays
are more tricky, especially when their content is copied in userland:
they are part of the copied struct.

Address of array members are only valid in their own address space,
in our case userland, which is (fortunately?) different from kernel space.
This breaks the various kvm_read() calls that query for file descriptor
information. Consequence: lsof(1) cannot print filedescriptor information
(starting from 5.99.14), and silently ignores the errors, as using
the userland fdtab (``dt'' variable) is not valid for kernel.

Fix that by using the ``fd_dt'' member of struct filedes, which stores
the address of the fdtab struct in kernel address space. Took a few hours
to understand what was going on with lsof(1), hmmm.

Luckily, fstat(1) uses the proper model (checked about 5min ago). Why
lsof(1) decided not to log an error on kvm_read() is... a good question.

Bump rev.
sysutils/lsof/Makefile
sysutils/lsof/distinfo
sysutils/lsof/patches/patch-ah