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] [day] [month] [year] [list]
Date:   Mon, 4 May 2020 20:28:03 +0000
From:   "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
To:     David Miller <davem@...emloft.net>,
        "kai.heng.feng@...onical.com" <kai.heng.feng@...onical.com>
CC:     "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] igb: Report speed and duplex as unknown when device is
 runtime suspended

> -----Original Message-----
> From: David Miller <davem@...emloft.net>
> Sent: Monday, May 4, 2020 11:21
> To: kai.heng.feng@...onical.com
> Cc: Kirsher, Jeffrey T <jeffrey.t.kirsher@...el.com>; intel-wired-
> lan@...ts.osuosl.org; netdev@...r.kernel.org; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH] igb: Report speed and duplex as unknown when device is
> runtime suspended
> 
> From: Kai-Heng Feng <kai.heng.feng@...onical.com>
> Date: Tue,  5 May 2020 01:32:18 +0800
> 
> > igb device gets runtime suspended when there's no link partner. We
> > can't get correct speed under that state:
> > $ cat /sys/class/net/enp3s0/speed
> > 1000
> >
> > In addition to that, an error can also be spotted in dmesg:
> > [  385.991957] igb 0000:03:00.0 enp3s0: PCIe link lost
> >
> > Since device can only be runtime suspended when there's no link
> > partner, we can directly report the speed and duplex as unknown.
> >
> > The more generic approach will be wrap get_link_ksettings() with
> > begin() and complete() callbacks. However, for this particular issue,
> > begin() calls igb_runtime_resume() , which tries to rtnl_lock() while
> > the lock is already hold by upper ethtool layer.
> >
> > So let's take this approach until the igb_runtime_resume() no longer
> > needs to hold rtnl_lock.
> >
> > Suggested-by: Alexander Duyck <alexander.duyck@...il.com>
> > Signed-off-by: Kai-Heng Feng <kai.heng.feng@...onical.com>
> 
> I'm assuming I will get this from upstream via Jeff K.
[Kirsher, Jeffrey T] 

Yep, I will be picking this up once Alex's last questions/concerns are addressed.

Powered by blists - more mailing lists