---
- branch: MAIN
  date: Mon Mar 21 00:22:02 UTC 2011
  files:
  - new: '1.109'
    old: '1.108'
    path: pkgsrc/sysutils/lsof/Makefile
    pathrev: pkgsrc/sysutils/lsof/Makefile@1.109
    type: modified
  - new: '1.80'
    old: '1.79'
    path: pkgsrc/sysutils/lsof/distinfo
    pathrev: pkgsrc/sysutils/lsof/distinfo@1.80
    type: modified
  - new: '1.5'
    old: '1.4'
    path: pkgsrc/sysutils/lsof/patches/patch-ah
    pathrev: pkgsrc/sysutils/lsof/patches/patch-ah@1.5
    type: modified
  id: 20110321T002202Z.c840ff0f3214621aee12b3e97a991b7e3f0cb4f8
  log: |
    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.
  module: pkgsrc
  subject: 'CVS commit: pkgsrc/sysutils/lsof'
  unixtime: '1300666922'
  user: jym