svn commit: r306509 - in head/sys: fs/nandfs kern sys ufs/ffs

[Mateusz Guzik]

On Fri, Sep 30, 2016 at 01:36:26PM -0400, Larry Rosenman wrote:
> On 2016-09-30 13:28, Mateusz Guzik wrote:
> >On Fri, Sep 30, 2016 at 01:18:45PM -0400, Shawn Webb wrote:
> >>On Fri, Sep 30, 2016 at 05:11:03PM +0000, Mateusz Guzik wrote:
> >>> Author: mjg
> >>> Date: Fri Sep 30 17:11:03 2016
> >>> New Revision: 306509
> >>> URL: https://svnweb.freebsd.org/changeset/base/306509
> >>>
> >>> Log:
> >>>   vfs: remove the __bo_vnode field from struct vnode
> >>>
> >>>   The pointer can be obtained using __containerof instead.
> >>>
> >>>   Reviewed by:	kib
> >>
> >>Should __FreeBSD_Version be bumped?
> >>
> >
> >Unlikely. It can be in an odd case it turns out there is a module which
> >is using the field.
> 
> Can someone do me a favor and make sure sysutils/lsof still
> compiles/works?
> 
> I'm OOT at the moment, and have a test IPv6 patch on my 12 system.

I just ran lsof and it worked fine at least for the basic case.

Apparently it indeed still goes through kernel memory. Did anyone ask
the author what kind of interfaces would they want to NOT have to do
this?

Also, it looks like it constains some kind of a loop to imitate
closefrom.

On truss I see over 3.7 milion (yes, MILION) calls to close. Like this:
close(3773297)                                   ERR#9 'Bad file descriptor'
close(3773298)                                   ERR#9 'Bad file descriptor'
close(3773299)                                   ERR#9 'Bad file descriptor'
close(3773300)                                   ERR#9 'Bad file descriptor'
close(3773301)                                   ERR#9 'Bad file descriptor'
close(3773302)                                   ERR#9 'Bad file descriptor'
close(3773303)                                   ERR#9 'Bad file descriptor'
[snip]

At least for freebsd this can be patched with the use of closefrom() on
all supported releases.

Arguably this may be a side effect of limits set too high, perhaps linux
sets them sigifnicanly lower and the problem is not that terrible.

-- 
Mateusz Guzik <mjguzik gmail.com>