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: <20211125154349.ozf6jfq5kmzoou4j@x230>
Date:   Thu, 25 Nov 2021 16:43:49 +0100
From:   Stefan Assmann <sassmann@...hat.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Tony Nguyen <anthony.l.nguyen@...el.com>, davem@...emloft.net,
        Jedrzej Jagielski <jedrzej.jagielski@...el.com>,
        netdev@...r.kernel.org,
        Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>,
        Konrad Jankowski <konrad0.jankowski@...el.com>
Subject: Re: [PATCH net-next 06/12] iavf: Add trace while removing device

On 2021-11-25 07:13, Jakub Kicinski wrote:
> On Thu, 25 Nov 2021 07:50:49 +0100 Stefan Assmann wrote:
> > On 2021-11-24 15:48, Jakub Kicinski wrote:
> > > On Wed, 24 Nov 2021 09:16:46 -0800 Tony Nguyen wrote:  
> > > > Add kernel trace that device was removed.
> > > > Currently there is no such information.
> > > > I.e. Host admin removes a PCI device from a VM,
> > > > than on VM shall be info about the event.
> > > > 
> > > > This patch adds info log to iavf_remove function.  
> > > 
> > > Why is this an important thing to print to logs about?
> > > If it is why is PCI core not doing the printing?
> > 
> > From personal experience I'd say this piece of information has value,
> > especially when debugging it can be interesting to know exactly when
> > the driver was removed.
> 
> But there isn't anything specific to iavf here, right? If it really 
> is important then core should be doing the printing for all drivers.
> 
> Actually, I can't come up with any uses for this print on the spot.
> What debugging scenarios do you have in mind?

There was a lot of trouble with iavf in terms of device reset, device
unbinding (DPDK), stress testing of driver load/unload issues. When
looking through the crash logs it was not always easy to determine if
the driver was still loaded.
Especially on problems that weren't easy to reproduce.

So for iavf having that information would have been valuable. Not sure
if that justifies a PCI core message or if others might find that too
verbose.

  Stefan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ