netdev - Re: [net-next 04/14] i40e: dump VF information in debugfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170420113942.GD1886@nanopsycho.orion>
Date:   Thu, 20 Apr 2017 13:39:42 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     "Mintz, Yuval" <Yuval.Mintz@...ium.com>
Cc:     Or Gerlitz <gerlitz.or@...il.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        Mitch Williams <mitch.a.williams@...el.com>,
        David Miller <davem@...emloft.net>,
        Linux Netdev List <netdev@...r.kernel.org>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        "jogreene@...hat.com" <jogreene@...hat.com>
Subject: Re: [net-next 04/14] i40e: dump VF information in debugfs

Thu, Apr 20, 2017 at 12:09:28PM CEST, Yuval.Mintz@...ium.com wrote:
>> > Dump some internal state about VFs through debugfs. This provides
>> > information not available with 'ip link show'.
>> 
>> such as?
>> 
>> donnwantobethedebugfspolice, but still, in the 2-3 times we tried to push
>> debugfs to MLNX NIC drivers, Dave disallowed that, and lately the switch
>> team even went further and deleted that portion of the mlxsw driver -- all to
>> all,  I don't see much point for these type of changes, thoughts?
>
>Don't want to hikjack your thread, but continuing this topic -
>Is there some flat-out disapproval for debugfs in net-next now?

It was mentioned by DaveM on the list multiple times.


>
>We're currently internally engaged with adding qed support for register dumps
>[~equivalents for `ethtool -d' outputs] through debugfs, on behalf of storage
>drivers [qedi/qedf] lacking the API for doing that.

That sounds wrong. Either introduce a generic infra to expose the info you
need or you don't do that. For your inhouse debugging, you should have
oot patch to expose whatever you need.