Hello Andrew,
I see dead people... Really i do! After your reply.
> This happens when the driver is missing a resource during probe. It
> returns the error -EPROBE_DEFER, and the linux driver core will try
> the probe again later. Probably the second time all the resources it
> needs will be pre
As explained in the "net: sched: taprio: Avoid division by zero on
invalid link speed" commit, it is legal for the ethtool API to return
zero as a link speed. So guard against it to ensure we don't perform a
division by zero in kernel.
Fixes: e0a7683d30e9 ("net/sched: cbs: fix port_rate miscalcula
The check in taprio_set_picos_per_byte is currently not robust enough
and will trigger this division by zero, due to e.g. PHYLINK not setting
kset->base.speed when there is no PHY connected:
[ 27.109992] Division by zero in kernel.
[ 27.113842] CPU: 1 PID: 198 Comm: tc Not tainted
5.3.0-rc5-0
On Wed, 28 Aug 2019 21:07:24 -0700
Alexei Starovoitov wrote:
> >
> > This won’t make me much more comfortable, since CAP_BPF lets it do an
> > ever-growing set of nasty things. I’d much rather one or both of two things
> > happen:
> >
> > 1. Give it CAP_TRACING only. It can leak my data, but i
Working on an IDS product using libpcap, I stumbled upon a problem
with packet loss statistics: libpcap would report as dropped at the
interface level packets that were actually seen by the product.
Because of that, I noticed it used the rx_dropped stat from
/proc/net/dev, which is wrong, as it cou
bcc uses libbpf repo as a submodule. It brings in libbpf source
code and builds everything together to produce shared libraries.
With latest libbpf, I got the following errors:
/bin/ld: libbcc_bpf.so.0.10.0: version node not found for symbol
xsk_umem__create@LIBBPF_0.0.2
/bin/ld: failed to set
The speed divisor is used in a context expecting an s64, but it is
evaluated using 32-bit arithmetic.
To avoid that happening, instead of multiplying by 1,000,000 in the
first place, simplify the fraction and do a standard 32 bit division
instead.
Fixes: f04b514c0ce2 ("taprio: Set default link sp
From: Navid Emamdoost
In sja1105_static_config_upload, in two cases memory is leaked: when
static_config_buf_prepare_for_upload fails and when sja1105_inhibit_tx
fails. In both cases config_buf should be released.
Fixes: 8aa9ebccae87 ("net: dsa: Introduce driver for NXP SJA1105 5-port L2
switch
Because ptp_qoriq_settime is being called prior to spin_lock_init, the
following stack trace can be seen at driver probe time:
[2.269117] the code is fine but needs lockdep annotation.
[2.274569] turning off the locking correctness validator.
[2.280027] CPU: 1 PID: 1 Comm: swapper/0 No
Currently this stack trace can be seen with CONFIG_DEBUG_ATOMIC_SLEEP=y:
[ 41.568348] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:909
[ 41.576757] in_atomic(): 1, irqs_disabled(): 0, pid: 208, name: ptp4l
[ 41.583212] INFO: lockdep is turned off.
[ 41.5871
Sometimes the PTP synchronization on the switch 'jumps':
ptp4l[11241.155]: rms8 max 16 freq -21732 +/- 11 delay 742 +/- 0
ptp4l[11243.157]: rms7 max 17 freq -21731 +/- 10 delay 744 +/- 0
ptp4l[11245.160]: rms 33592410 max 134217731 freq +192422 +/- 8530253 delay
743
On Sat, Sep 28, 2019 at 10:36 PM Florian Fainelli wrote:
> Do we need to duplicate the same is_vlan_valid() check in both the
> vlan_prepare and vlan_add callbacks?
I'm unsure of the semantics of these calls, the check was in the
OpenWrt driver that I started from.
Is it guaranteed that .vlan_p
On 9/28/2019 1:26 PM, Linus Walleij wrote:
> On Fri, Sep 27, 2019 at 6:40 PM Florian Fainelli wrote:
>> On 9/27/19 9:39 AM, Linus Walleij wrote:
>>> There has been some confusion between the port number and
>>> the VLAN ID in this driver. What we need to check for
>>> validity is the VLAN ID, n
On Fri, Sep 27, 2019 at 6:40 PM Florian Fainelli wrote:
> On 9/27/19 9:39 AM, Linus Walleij wrote:
> > There has been some confusion between the port number and
> > the VLAN ID in this driver. What we need to check for
> > validity is the VLAN ID, nothing else.
> >
> > The current confusion came f
From: Roopa Prabhu
This patch adds support to lookup a bridge fdb entry
using recently added support in the kernel using RTM_GETNEIGH
(and AF_BRIDGE family).
example:
$bridge fdb get 02:02:00:00:00:03 dev test-dummy0 vlan 1002
02:02:00:00:00:03 dev test-dummy0 vlan 1002 master bridge
Signed-off
From: Roopa Prabhu
This series adds iproute2 support to lookup a bridge fdb and
neigh entry.
example:
$bridge fdb get 02:02:00:00:00:03 dev test-dummy0 vlan 1002
02:02:00:00:00:03 dev test-dummy0 vlan 1002 master bridge
$ip neigh get 10.0.2.4 dev test-dummy0
10.0.2.4 dev test-dummy0 lladdr de:ad
From: Roopa Prabhu
This patch adds support to lookup a neigh entry
using recently added support in the kernel using RTM_GETNEIGH
example:
$ip neigh get 10.0.2.4 dev test-dummy0
10.0.2.4 dev test-dummy0 lladdr de:ad:be:ef:13:37 PERMANENT
Signed-off-by: Roopa Prabhu
---
ip/ipneigh.c
On Sat, Sep 28, 2019 at 8:46 AM Stephen Hemminger
wrote:
>
> On Fri, 27 Sep 2019 21:48:23 -0700
> Roopa Prabhu wrote:
>
> Overall, looks good.
>
> > + if (print_fdb(answer, (void *)stdout) < 0) {
>
> Cast to void is not necessary in C (it is in C++)
thats a copy/paste from iproute get code.
On Sat, 28 Sep 2019, Andrii Nakryiko wrote:
> On Sat, Sep 28, 2019 at 4:20 AM Alan Maguire wrote:
> >
> > On Fri, 27 Sep 2019, Andrii Nakryiko wrote:
> >
> > > This patch switches libbpf_num_possible_cpus() from using possible CPU
> > > set to present CPU set. This fixes issues with incorrect aut
On Sat, Sep 28, 2019 at 4:20 AM Alan Maguire wrote:
>
> On Fri, 27 Sep 2019, Andrii Nakryiko wrote:
>
> > This patch switches libbpf_num_possible_cpus() from using possible CPU
> > set to present CPU set. This fixes issues with incorrect auto-sizing of
> > PERF_EVENT_ARRAY map on HOTPLUG-enabled s
On Fri, 27 Sep 2019 21:48:23 -0700
Roopa Prabhu wrote:
Overall, looks good.
> + if (print_fdb(answer, (void *)stdout) < 0) {
Cast to void is not necessary in C (it is in C++)
On Sat, Sep 28, 2019 at 01:00:43AM +0200, Zoran Stojsavljevic wrote:
> Hello Andrew,
>
> > You should not need any kernel patches for switch side RGMII
> > delays. rgmii-id in the DT for the switch CPU port should be enough.
> > Some of the vf610-zii platforms use it.
>
> It should, but it does N
On Fri, 27 Sep 2019, Andrii Nakryiko wrote:
> This patch switches libbpf_num_possible_cpus() from using possible CPU
> set to present CPU set. This fixes issues with incorrect auto-sizing of
> PERF_EVENT_ARRAY map on HOTPLUG-enabled systems.
>
> On HOTPLUG enabled systems, /sys/devices/system/cpu
Hello Dave.
An update from ieee802154 for your *net* tree.
Three driver fixes. Navid Emamdoost fixed a memory leak on an error
path in the ca8210 driver, Johan Hovold fixed a use-after-free found
by syzbot in the atusb driver and Christophe JAILLET makes sure
__skb_put_data is used instead of mem
24 matches
Mail list logo
