Mon, Aug 12, 2019 at 06:01:59PM CEST, dsah...@gmail.com wrote:
>On 8/12/19 2:31 AM, Jiri Pirko wrote:
>> Mon, Aug 12, 2019 at 03:37:26AM CEST, dsah...@gmail.com wrote:
>>> On 8/11/19 7:34 PM, David Ahern wrote:
On 8/10/19 12:30 AM, Jiri Pirko wrote:
> Could you please write me an example m
Mon, Aug 12, 2019 at 05:40:39PM CEST, step...@networkplumber.org wrote:
>On Mon, 12 Aug 2019 10:31:39 +0200
>Jiri Pirko wrote:
>
>> Mon, Aug 12, 2019 at 03:37:26AM CEST, dsah...@gmail.com wrote:
>> >On 8/11/19 7:34 PM, David Ahern wrote:
>> >> On 8/10/19 12:30 AM, Jiri Pirko wrote:
>> >>> Coul
Tue, Aug 13, 2019 at 02:29:13AM CEST, dsah...@gmail.com wrote:
>On 8/12/19 3:43 PM, Jakub Kicinski wrote:
>> Is not adding commands better because it's easier to deal with the
>> RTM_NEWLINK notification? I must say it's unclear from the thread why
>> muxing the op through RTM_SETLINK is preferable
Mon, Aug 12, 2019 at 05:13:39PM CEST, ro...@cumulusnetworks.com wrote:
>On Mon, Aug 12, 2019 at 1:31 AM Jiri Pirko wrote:
>>
>> Mon, Aug 12, 2019 at 03:37:26AM CEST, dsah...@gmail.com wrote:
>> >On 8/11/19 7:34 PM, David Ahern wrote:
>> >> On 8/10/19 12:30 AM, Jiri Pirko wrote:
>> >>> Could you pl
The 08/13/2019 08:16, Allan W . Nielsen wrote:
> The 08/13/2019 10:52, Yangbo Lu wrote:
> > The trap action should be copying the frame to CPU and
> > dropping it for forwarding, but current setting was just
> > copying frame to CPU.
> >
> > Signed-off-by: Yangbo Lu
> > ---
> > Changes for v2:
>
The 08/13/2019 10:52, Yangbo Lu wrote:
> All the PTP messages over Ethernet have etype 0x88f7 on them.
> Use etype as the key to trap PTP messages.
>
> Signed-off-by: Yangbo Lu
> ---
> Changes for v2:
> - Added this patch.
> ---
> drivers/net/ethernet/mscc/ocelot.c | 28 +++
The 08/13/2019 10:52, Yangbo Lu wrote:
> The trap action should be copying the frame to CPU and
> dropping it for forwarding, but current setting was just
> copying frame to CPU.
>
> Signed-off-by: Yangbo Lu
> ---
> Changes for v2:
> - None.
> ---
> drivers/net/ethernet/mscc/ocelot_ace.c |
The 08/13/2019 02:12, Y.b. Lu wrote:
> > -Original Message-
> > From: Allan W. Nielsen
> > Sent: Monday, August 12, 2019 8:32 PM
> > To: Y.b. Lu
> > Cc: netdev@vger.kernel.org; David S . Miller ;
> > Alexandre Belloni ; Microchip Linux Driver
> > Support
> > Subject: Re: [PATCH 3/3] ocel
Tue, Aug 13, 2019 at 03:21:22AM CEST, jakub.kicin...@netronome.com wrote:
>On Mon, 12 Aug 2019 15:47:49 +0200, Jiri Pirko wrote:
>> @@ -6953,9 +7089,33 @@ int devlink_compat_switch_id_get(struct net_device
>> *dev,
>> return 0;
>> }
>>
>> +static void __net_exit devlink_pernet_exit(struct
Realtek provided information on how the new NIC-integrated PHY's
expose whether they support 2.5G/5G/10G. This allows to automatically
differentiate 1Gbps and 2.5Gbps PHY's, and therefore allows to
remove the fake PHY ID mechanism for RTL8125.
So far RTL8125 supports 2.5Gbps only, but register layo
Tue, Aug 13, 2019 at 02:24:41AM CEST, dsah...@gmail.com wrote:
>On 8/12/19 7:47 AM, Jiri Pirko wrote:
>> From: Jiri Pirko
>>
>> Devlink from the beginning counts with network namespaces, but the
>> instances has been fixed to init_net. The first patch allows user
>> to move existing devlink insta
Tue, Aug 13, 2019 at 03:11:00AM CEST, jakub.kicin...@netronome.com wrote:
>On Mon, 12 Aug 2019 18:24:41 -0600, David Ahern wrote:
>> On 8/12/19 7:47 AM, Jiri Pirko wrote:
>> > From: Jiri Pirko
>> >
>> > Devlink from the beginning counts with network namespaces, but the
>> > instances has been fix
On 08/13, Martin Lau wrote:
> On Fri, Aug 09, 2019 at 09:10:36AM -0700, Stanislav Fomichev wrote:
> > Add new helper bpf_sk_storage_clone which optionally clones sk storage
> > and call it from sk_clone_lock.
> Thanks for v2. Sorry for the delay. I am traveling.
No worries, take your time, if you
The ingress ports setting of rule should support covering all ports.
This patch is to use u16 ingress_port for ingress port mask setting
for ace rule. One bit corresponds one port.
Signed-off-by: Yangbo Lu
---
Changes for v2:
- None.
---
drivers/net/ethernet/mscc/ocelot_ace.c| 2 +-
All the PTP messages over Ethernet have etype 0x88f7 on them.
Use etype as the key to trap PTP messages.
Signed-off-by: Yangbo Lu
---
Changes for v2:
- Added this patch.
---
drivers/net/ethernet/mscc/ocelot.c | 28
1 file changed, 28 insertions(+)
diff --git
The trap action should be copying the frame to CPU and
dropping it for forwarding, but current setting was just
copying frame to CPU.
Signed-off-by: Yangbo Lu
---
Changes for v2:
- None.
---
drivers/net/ethernet/mscc/ocelot_ace.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-
The ocelot_ace_rule is not port specific. We don't need a member port
in ocelot_ace_rule structure. Drop it and use member ocelot instead.
Signed-off-by: Yangbo Lu
---
Changes for v2:
- None.
---
drivers/net/ethernet/mscc/ocelot_ace.c| 12 ++--
drivers/net/ethernet/mscc/ocelo
This patch-set is to support PTP Ethernet frames trapping.
Before that, fix some issues and improve the ocelot_ace driver
for using.
---
Changes for v2:
- Added PTP Ethernet frames trapping support patch.
Yangbo Lu (4):
ocelot_ace: drop member port from ocelot_ace_rule structure
ocelo
This commit adds bash-completion for new "net attach/detach"
subcommand for attaching XDP program on interface.
Signed-off-by: Daniel T. Lee
---
tools/bpf/bpftool/bash-completion/bpftool | 65 +++
1 file changed, 55 insertions(+), 10 deletions(-)
diff --git a/tools/bpf/bpfto
Since, new sub-command 'net attach/detach' has been added for
attaching XDP program on interface,
this commit documents usage and sample output of `net attach/detach`.
Signed-off-by: Daniel T. Lee
---
.../bpf/bpftool/Documentation/bpftool-net.rst | 57 ++-
1 file changed, 54 inse
By this commit, using `bpftool net attach`, user can attach XDP prog on
interface. New type of enum 'net_attach_type' has been made, as stat ted at
cover-letter, the meaning of 'attach' is, prog will be attached on interface.
With 'overwrite' option at argument, attached XDP program could be repla
By this commit, using `bpftool net detach`, the attached XDP prog can
be detached. Detaching the BPF prog will be done through libbpf
'bpf_set_link_xdp_fd' with the progfd set to -1.
Acked-by: Yonghong Song
Signed-off-by: Daniel T. Lee
---
tools/bpf/bpftool/net.c | 42 ++
Currently, bpftool net only supports dumping progs attached on the
interface. To attach XDP prog on interface, user must use other tool
(eg. iproute2). By this patch, with `bpftool net attach/detach`, user
can attach/detach XDP prog on interface.
# bpftool prog
16: xdp name xdp_prog1
On Mon, Aug 12, 2019 at 9:27 AM Y Song wrote:
>
> On Fri, Aug 9, 2019 at 6:35 AM Daniel T. Lee wrote:
> >
> > By this commit, using `bpftool net attach`, user can attach XDP prog on
> > interface. New type of enum 'net_attach_type' has been made, as stated at
> > cover-letter, the meaning of 'att
Hi Allan,
> -Original Message-
> From: Allan W. Nielsen
> Sent: Monday, August 12, 2019 8:38 PM
> To: Y.b. Lu
> Cc: netdev@vger.kernel.org; David S . Miller ;
> Alexandre Belloni ; Microchip Linux Driver
> Support
> Subject: Re: [PATCH 2/3] ocelot_ace: fix ingress ports setting for rule
Hi Allan,
> -Original Message-
> From: Allan W. Nielsen
> Sent: Monday, August 12, 2019 8:32 PM
> To: Y.b. Lu
> Cc: netdev@vger.kernel.org; David S . Miller ;
> Alexandre Belloni ; Microchip Linux Driver
> Support
> Subject: Re: [PATCH 3/3] ocelot_ace: fix action of trap
>
> The 08/12/
On Fri, Aug 09, 2019 at 09:10:36AM -0700, Stanislav Fomichev wrote:
> Add new helper bpf_sk_storage_clone which optionally clones sk storage
> and call it from sk_clone_lock.
Thanks for v2. Sorry for the delay. I am traveling.
>
> Cc: Martin KaFai Lau
> Cc: Yonghong Song
> Signed-off-by: Stan
On 8/12/19 7:11 PM, Jakub Kicinski wrote:
> If the devlink instance just disappeared - that'd be a very very strange
> thing. Only software objects disappear with the namespace.
> Netdevices without ->rtnl_link_ops go back to init_net.
netdevsim still has rtnl_link_ops:
static struct rtnl_link_o
On Mon, 12 Aug 2019 15:47:49 +0200, Jiri Pirko wrote:
> @@ -6953,9 +7089,33 @@ int devlink_compat_switch_id_get(struct net_device
> *dev,
> return 0;
> }
>
> +static void __net_exit devlink_pernet_exit(struct net *net)
> +{
> + struct devlink *devlink;
> +
> + mutex_lock(&devlink_
On Mon, 12 Aug 2019 13:17:06 +0300
Ido Schimmel wrote:
> From: Ido Schimmel
>
> Commit e991c04d64c0 ("Revert "tc: Add batchsize feature for filter and
> actions"") reverted more than it should and broke shared block
> functionality. Fix this by restoring the original functionality.
>
> To repr
Hi Jiri,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Jiri-Pirko/netdevsim-implement-support-for-devlink-region-and-snapshots/20190813-002135
If you fix the issue, kindly add following tag
Reporte
From: kbuild test robot
drivers/net/netdevsim/dev.c:297:1-3: WARNING: PTR_ERR_OR_ZERO can be used
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Generated by: scripts/coccinelle/api/ptr_ret.cocci
Fixes: e9cf98183f96 ("netdevsim: implement support for devlink region and
snapshots"
On Mon, 12 Aug 2019 18:24:41 -0600, David Ahern wrote:
> On 8/12/19 7:47 AM, Jiri Pirko wrote:
> > From: Jiri Pirko
> >
> > Devlink from the beginning counts with network namespaces, but the
> > instances has been fixed to init_net. The first patch allows user
> > to move existing devlink instanc
On Mon, 12 Aug 2019 12:16:20 +0200, Jiri Pirko wrote:
> From: Jiri Pirko
>
> Implement dummy region of size 32K and allow user to create snapshots
> or random data using debugfs file trigger.
>
> Signed-off-by: Jiri Pirko
I'm nacking all the netdevsim patches unless the selftest
is posted at
On Tue, 13 Aug 2019 01:38:33 +0100, Peter Wu wrote:
> bpftool requires libelf, and zlib for decompressing /proc/config.gz.
> zlib is a transitive dependency via libelf, and became mandatory since
> elfutils 0.165 (Jan 2016). The feature check of libelf is already done
> in the elfdep target of tool
bpftool requires libelf, and zlib for decompressing /proc/config.gz.
zlib is a transitive dependency via libelf, and became mandatory since
elfutils 0.165 (Jan 2016). The feature check of libelf is already done
in the elfdep target of tools/lib/bpf/Makefile, pulled in by bpftool via
a dependency on
bpftool requires libelf, and zlib for decompressing /proc/config.gz.
zlib is a transitive dependency via libelf, and became mandatory since
elfutils 0.165 (Jan 2016). The feature check of libelf is already done
in the elfdep target of tools/lib/bpf/Makefile, pulled in by bpftool via
a dependency on
On 8/12/19 3:43 PM, Jakub Kicinski wrote:
> Is not adding commands better because it's easier to deal with the
> RTM_NEWLINK notification? I must say it's unclear from the thread why
> muxing the op through RTM_SETLINK is preferable. IMHO new op is
> cleaner, do we have precedent for such IFLA_.*_O
On 8/12/19 7:47 AM, Jiri Pirko wrote:
> From: Jiri Pirko
>
> Devlink from the beginning counts with network namespaces, but the
> instances has been fixed to init_net. The first patch allows user
> to move existing devlink instances into namespaces:
>
> $ devlink dev
> netdevsim/netdevsim1
> $ i
On 8/12/19 4:58 PM, Stefano Brivio wrote:
> How so, actually? I don't see how that would happen. On the forwarding
> path, 'iif' is set (not to loopback interface), so that's not affected.
>
> Is there any other route lookup possibility I'm missing?
Use case is saddr is set and FLOWI_FLAG_ANYSRC
From: Petar Penkov
Since the "last_dissection" map holds only the flow keys for the most
recent packet, there is a small race in the skb-less flow dissector
tests if a new packet comes between transmitting the test packet, and
reading its keys from the map. If this happens, the test packet keys
w
On Tue, Aug 13, 2019 at 12:46:01AM +0200, Stefano Brivio wrote:
> Commit ba5ea614622d ("bridge: simplify ip_mc_check_igmp() and
> ipv6_mc_check_mld() calls") replaces direct calls to pskb_may_pull()
> in br_ipv6_multicast_mld2_report() with calls to ipv6_mc_may_pull(),
> that returns -EINVAL on buf
On Wed, Aug 07, 2019 at 12:30:07AM +, Linux Kernel wrote:
> Commit: 4b663366246be1d1d4b1b8b01245b2e88ad9e706
> Parent: 16b2084a8afa1432d14ba72b7c97d7908e178178
> Web:
> https://git.kernel.org/torvalds/c/4b663366246be1d1d4b1b8b01245b2e88ad9e706
> Author: Alexis Bauvin
On Sun, 11 Aug 2019 20:49:18 -0700 (PDT)
David Miller wrote:
> From: David Ahern
> Date: Thu, 1 Aug 2019 22:16:00 -0600
>
> > On 8/1/19 10:13 PM, Hangbin Liu wrote:
> >> On Thu, Aug 01, 2019 at 01:51:25PM -0600, David Ahern wrote:
> >>> On 8/1/19 2:29 AM, Hangbin Liu wrote:
> Jianlin
Commit ba5ea614622d ("bridge: simplify ip_mc_check_igmp() and
ipv6_mc_check_mld() calls") replaces direct calls to pskb_may_pull()
in br_ipv6_multicast_mld2_report() with calls to ipv6_mc_may_pull(),
that returns -EINVAL on buffers too short to be valid IPv6 packets,
while maintaining the previous
On Mon, 12 Aug 2019 15:07:09 +, Nguyen, Anthony L wrote:
> On Fri, 2019-08-09 at 14:15 -0700, Jakub Kicinski wrote:
> > On Fri, 9 Aug 2019 11:31:25 -0700, Jeff Kirsher wrote:
> > > From: Henry Tieman
> > >
> > > Add code to query and set the number of queues on the primary
> > > VSI for a
GCC unescapes escaped string section names while Clang does not. Because
__section uses the `#` stringification operator for the section name, it
doesn't need to be escaped.
This fixes an Oops observed in distro's that use systemd and not
net.core.bpf_jit_enable=1, when their kernels are compiled
The antipattern described can be found with:
$ grep -e __section\(\" -r -e __section__\(\"
Link: https://bugs.llvm.org/show_bug.cgi?id=42950
Signed-off-by: Nick Desaulniers
---
include/linux/compiler_attributes.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/compi
Link: https://github.com/ClangBuiltLinux/linux/issues/619
Reported-by: Sedat Dilek
Suggested-by: Josh Poimboeuf
Signed-off-by: Nick Desaulniers
---
include/linux/cache.h | 6 +++---
include/linux/compiler.h| 8
include/linux/cpu.h | 2 +-
include/linux/export.h |
This macro is not used throughout the kernel. Delete it rather than
update the __section to be a fully spelled out
__attribute__((__section__())) to avoid
https://bugs.llvm.org/show_bug.cgi?id=42950.
Signed-off-by: Nick Desaulniers
---
include/linux/compiler.h | 23 ---
1 fil
We will need the functionality of __set_linkmode_max_speed also for
linkmode bitmaps other than phydev->supported. Therefore split it.
v2:
- remove unused parameter from __set_linkmode_max_speed
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/phy-core.c | 9 +++--
1 file changed, 7 inser
So far phy_speed_down/up can be used up to 1Gbps only. Remove this
restriction by using new helper __phy_speed_down. New member adv_old
in struct phy_device is used by phy_speed_up to restore the advertised
modes before calling phy_speed_down. Don't simply advertise what is
supported because a user
phy_speed_down_core provides most of the functionality for
phy_speed_down. It makes use of new helper phy_resolve_min_speed that is
based on the sorting of the settings[] array. In certain cases it may be
helpful to be able to exclude legacy half duplex modes, therefore
prepare phy_resolve_min_spee
So far phy_speed_down/up can be used up to 1Gbps only. Remove this
restriction and add needed helpers to phy-core.c
v2:
- remove unused parameter in patch 1
- rename __phy_speed_down to phy_speed_down_core in patch 2
Heiner Kallweit (3):
net: phy: add __set_linkmode_max_speed
net: phy: add ph
On Mon, 12 Aug 2019 08:13:39 -0700, Roopa Prabhu wrote:
> On Mon, Aug 12, 2019 at 1:31 AM Jiri Pirko wrote:
> > Mon, Aug 12, 2019 at 03:37:26AM CEST, dsah...@gmail.com wrote:
> > >On 8/11/19 7:34 PM, David Ahern wrote:
> > >> On 8/10/19 12:30 AM, Jiri Pirko wrote:
> > >>> Could you please wr
On Mon, Aug 12, 2019 at 11:20:51PM +0200, Heiner Kallweit wrote:
> So far phy_speed_down/up can be used up to 1Gbps only. Remove this
> restriction by using new helper __phy_speed_down. New member adv_old
> in struct phy_device is used by phy_speed_up to restore the advertised
> modes before callin
> +int __phy_speed_down(struct phy_device *phydev)
> +{
> + int min_common_speed = phy_resolve_min_speed(phydev, true);
> +
> + if (min_common_speed == SPEED_UNKNOWN)
> + return -EINVAL;
> +
> + return __set_linkmode_max_speed(phydev, min_common_speed,
> +
On 12.08.2019 23:27, Andrew Lunn wrote:
> On Mon, Aug 12, 2019 at 11:19:31PM +0200, Heiner Kallweit wrote:
>> We will need the functionality of __set_linkmode_max_speed also for
>> linkmode bitmaps other than phydev->supported. Therefore split it.
>>
>> Signed-off-by: Heiner Kallweit
>> ---
>> dr
On Mon, Aug 12, 2019 at 11:19:31PM +0200, Heiner Kallweit wrote:
> We will need the functionality of __set_linkmode_max_speed also for
> linkmode bitmaps other than phydev->supported. Therefore split it.
>
> Signed-off-by: Heiner Kallweit
> ---
> drivers/net/phy/phy-core.c | 10 --
> 1 f
Todd Seidelmann wrote:
> The ordering of arguments to the x_tables ADD_COUNTER macro
> appears to be wrong in ebtables (cf. ip_tables.c, ip6_tables.c,
> and arp_tables.c).
>
> This causes data corruption in the ebtables userspace tools
> because they get incorrect packet & byte counts from the ke
So far phy_speed_down/up can be used up to 1Gbps only. Remove this
restriction by using new helper __phy_speed_down. New member adv_old
in struct phy_device is used by phy_speed_up to restore the advertised
modes before calling phy_speed_down. Don't simply advertise what is
supported because a user
We will need the functionality of __set_linkmode_max_speed also for
linkmode bitmaps other than phydev->supported. Therefore split it.
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/phy-core.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy-
__phy_speed_down provides most of the functionality for phy_speed_down.
It makes use of new helper phy_resolve_min_speed that is based on the
sorting of the settings[] array.
In certain cases it may be helpful to be able to exclude legacy half
duplex modes, therefore prepare phy_resolve_min_speed()
The ordering of arguments to the x_tables ADD_COUNTER macro
appears to be wrong in ebtables (cf. ip_tables.c, ip6_tables.c,
and arp_tables.c).
This causes data corruption in the ebtables userspace tools
because they get incorrect packet & byte counts from the kernel.
---
net/bridge/netfilter/ebt
So far phy_speed_down/up can be used up to 1Gbps only. Remove this
restriction and add needed helpers to phy-core.c
Heiner Kallweit (3):
net: phy: add __set_linkmode_max_speed
net: phy: add __phy_speed_down and phy_resolve_min_speed
net: phy: let phy_speed_down/up support speeds >1Gbps
dri
The ibm,mac-address-filters property defines the maximum number of
addresses the hypervisor's multicast filter list can support. It is
encoded as a big-endian integer in the OF device tree, but the virtual
ethernet driver does not convert it for use by little-endian systems.
As a result, the driver
Thanks for the answer, I really appreciate it. I tried omitting
"cgroup/skb" to let libbpf guess the attach type, but I got the same
error. Really interesting, because I got the error
> libbpf: failed to load program 'cgroup_skb/egress'
wich is weird because it shows that libbpf guess the program t
On Mon, Aug 12, 2019 at 09:20:02PM +0200, Heiner Kallweit wrote:
> After configuring and restarting aneg we immediately try to read the
> link status. On some systems the PHY may not yet have cleared the
> "aneg complete" and "link up" bits, resulting in a false link-up
> signal. See [0] for a repo
From: David Ahern
Eric reported a syzbot warning:
BUG: KMSAN: uninit-value in nh_valid_get_del_req+0x6f1/0x8c0
net/ipv4/nexthop.c:1510
CPU: 0 PID: 11812 Comm: syz-executor444 Not tainted 5.3.0-rc3+ #17
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Ca
On Mon, Aug 12, 2019 at 12:44:36PM -0700, Nick Desaulniers wrote:
> On Mon, Aug 12, 2019 at 12:01 PM Greg Kroah-Hartman
> wrote:
> >
> > On Mon, Aug 12, 2019 at 10:55:51AM -0700, Nick Desaulniers wrote:
> > > On Sat, Aug 10, 2019 at 3:17 AM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > When cal
On Mon, Aug 12, 2019 at 12:01 PM Greg Kroah-Hartman
wrote:
>
> On Mon, Aug 12, 2019 at 10:55:51AM -0700, Nick Desaulniers wrote:
> > On Sat, Aug 10, 2019 at 3:17 AM Greg Kroah-Hartman
> > wrote:
> > >
> > > When calling debugfs functions, there is no need to ever check the
> > > return value. Th
After configuring and restarting aneg we immediately try to read the
link status. On some systems the PHY may not yet have cleared the
"aneg complete" and "link up" bits, resulting in a false link-up
signal. See [0] for a report.
Clause 22 and 45 both require the PHY to keep the AN_RESTART
bit set
On Mon, Aug 12, 2019 at 10:55:51AM -0700, Nick Desaulniers wrote:
> On Sat, Aug 10, 2019 at 3:17 AM Greg Kroah-Hartman
> wrote:
> >
> > When calling debugfs functions, there is no need to ever check the
> > return value. The function can work or not, but the code logic should
> > never do somethi
Holger reported sporadic transmit timeouts and it turned out that one
path misses ringing the doorbell. Fix was suggested by Eric.
Fixes: ef14358546b1 ("r8169: make use of xmit_more")
Suggested-by: Eric Dumazet
Tested-by: Holger Hoffstätte
Signed-off-by: Heiner Kallweit
---
drivers/net/etherne
The ibm,mac-address-filters property defines the maximum number of
addresses the hypervisor's multicast filter list can support. It is
encoded as a big-endian integer in the OF device tree, but the virtual
ethernet driver does not convert it for use by little-endian systems.
As a result, the driver
Make .BTF section allocated and expose its contents through sysfs.
/sys/kernel/btf directory is created to contain all the BTFs present
inside kernel. Currently there is only kernel's main BTF, represented as
/sys/kernel/btf/kernel file. Once kernel modules' BTFs are supported,
each module will ex
On 12.08.2019 11:59, Holger Hoffstätte wrote:
> On 8/9/19 10:52 AM, Holger Hoffstätte wrote:
>> On 8/9/19 10:25 AM, Eric Dumazet wrote:
>> (snip)
So that didn't take long - got another timeout this morning during some
random light usage, despite sg/tso being disabled this time.
On Mon, Aug 12, 2019 at 1:59 AM Fejes Ferenc wrote:
>
> Greetings!
>
> I found a strange error when I tried to load a BPF_CGROUP_INET_EGRESS
> prog with bpftool. Loading the same program from C code with
> bpf_prog_load_xattr works without problem.
>
> The error message I got:
> bpftool prog loada
From: Thomas Falcon
Date: Mon, 12 Aug 2019 10:56:39 -0500
> Hi, thanks for reporting this. I was able to recreate this on my own
> system. The virtual ethernet's multicast filter list size is limited,
> and the driver will check that there is available space before adding
> entries. The problem
On 8/12/19 7:51 PM, Ioana Ciocoi Radulescu wrote:
>> -Original Message-
>> From: Edward Cree
>> Sent: Friday, August 9, 2019 8:32 PM
>> To: Ioana Ciocoi Radulescu
>> Cc: David Miller ; netdev ;
>> Eric Dumazet ; linux-net-driv...@solarflare.com
>> Subject: Re: [PATCH v3 net-next 0/3] n
On 8/9/19 6:18 PM, Donald Sharp wrote:
> When displaying a nexthop group made up of other nexthops, the display
> line shows this when you have additional data at the end:
>
> id 42 group
> 43/44/45/46/47/48/49/50/51/52/53/54/55/56/57/58/59/60/61/62/63/64/65/66/67/68/69/70/71/72/73/74proto
> zeb
On 8/12/19 12:49 PM, Joe Perches wrote:
On Mon, 2019-08-12 at 12:43 -0500, Thomas Falcon wrote:
The ibm,mac-address-filters property defines the maximum number of
addresses the hypervisor's multicast filter list can support. It is
encoded as a big-endian integer in the OF device tree, but the
On Sat, Aug 10, 2019 at 3:17 AM Greg Kroah-Hartman
wrote:
>
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Maybe adding this recommendation to the comment b
> -Original Message-
> From: Edward Cree
> Sent: Friday, August 9, 2019 8:32 PM
> To: Ioana Ciocoi Radulescu
> Cc: David Miller ; netdev ;
> Eric Dumazet ; linux-net-driv...@solarflare.com
> Subject: Re: [PATCH v3 net-next 0/3] net: batched receive in GRO path
>
> On 09/08/2019 18:14, Io
On 08/12, Daniel Borkmann wrote:
> On 8/9/19 6:10 PM, Stanislav Fomichev wrote:
> > Add new helper bpf_sk_storage_clone which optionally clones sk storage
> > and call it from sk_clone_lock.
> >
> > Cc: Martin KaFai Lau
> > Cc: Yonghong Song
> > Signed-off-by: Stanislav Fomichev
> [...]
> > +in
On 09/07/2019 21:55, Pablo Neira Ayuso wrote:
> This patch updates flow_block_cb_setup_simple() to use the flow block API.
> Several drivers are also adjusted to use it.
>
> This patch introduces the per-driver list of flow blocks to account for
> blocks that are already in use.
>
> Remove tc_block
On Mon, 2019-08-12 at 12:43 -0500, Thomas Falcon wrote:
> The ibm,mac-address-filters property defines the maximum number of
> addresses the hypervisor's multicast filter list can support. It is
> encoded as a big-endian integer in the OF device tree, but the virtual
> ethernet driver does not conv
On Mon, 12 Aug 2019 at 14:28, Daniel Borkmann wrote:
>
[...]
> > diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> > index 59b57d708697..c3447bad608a 100644
> > --- a/net/xdp/xsk.c
> > +++ b/net/xdp/xsk.c
> > @@ -362,6 +362,50 @@ static void xsk_unbind_dev(struct xdp_sock *xs)
> > dev_put(dev);
>
On 8/12/19 5:36 AM, Eric Dumazet wrote:
> David missed that commit 8cb081746c03 ("netlink: make validation
> more configurable for future strictness") has renamed nlmsg_parse()
I think the root cause is nlmsg_parse() calling __nla_parse and not
__nlmsg_parse. Users of nlmsg_parse are missing the h
It is enough for caller of devlink_compat_switch_id_get() to hold the net
device to guarantee that devlink port is not destroyed concurrently. Remove
rtnl lock assertion and modify comment to warn user that they must hold
either rtnl lock or reference to net device. This is necessary to
accommodate
On Mon, Aug 12, 2019 at 8:40 AM Stephen Hemminger
wrote:
>
> On Mon, 12 Aug 2019 10:31:39 +0200
> Jiri Pirko wrote:
>
> > Mon, Aug 12, 2019 at 03:37:26AM CEST, dsah...@gmail.com wrote:
> > >On 8/11/19 7:34 PM, David Ahern wrote:
> > >> On 8/10/19 12:30 AM, Jiri Pirko wrote:
> > >>> Could you plea
On Sun, Aug 11, 2019 at 3:46 AM Paul Blakey wrote:
>
>
> On 8/8/2019 11:53 PM, Pravin Shelar wrote:
> > On Wed, Aug 7, 2019 at 5:08 AM Paul Blakey wrote:
> >> Offloaded OvS datapath rules are translated one to one to tc rules,
> >> for example the following simplified OvS rule:
> >>
> >> recirc_i
On 8/12/19 5:03 PM, Ilya Leoshkevich wrote:
"masking, test in bounds 3" fails on s390, because
BPF_ALU64_IMM(BPF_NEG, BPF_REG_2, 0) ignores the top 32 bits of
BPF_REG_2. The reason is that JIT emits lcgfr instead of lcgr.
The associated comment indicates that the code was intended to emit lcgr
in
On 8/12/19 2:31 AM, Jiri Pirko wrote:
> Mon, Aug 12, 2019 at 03:37:26AM CEST, dsah...@gmail.com wrote:
>> On 8/11/19 7:34 PM, David Ahern wrote:
>>> On 8/10/19 12:30 AM, Jiri Pirko wrote:
Could you please write me an example message of add/remove?
>>>
>>> altnames are for existing netdevs, yes
On 8/12/19 2:37 AM, Hangbin Liu wrote:
On Sun, Aug 11, 2019 at 09:08:20PM -0700, David Miller wrote:
From: Hangbin Liu
Date: Fri, 9 Aug 2019 08:29:39 +0800
ibmveth 3003 env3: h_multicast_ctrl rc=4 when adding an entry to the filter
table
error when add more thann 256 memberships in on
On Sat, 2019-08-10 at 12:17 +0200, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic
> should
> never do something different based on this.
>
> Cc: Jeff Kirsher
> Cc: "David S. Miller"
On Sat, 2019-08-10 at 12:17 +0200, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic
> should
> never do something different based on this.
>
> Cc: Jeff Kirsher
> Cc: "David S. Miller"
On Sat, 2019-08-10 at 12:17 +0200, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic
> should
> never do something different based on this.
>
> Cc: Jeff Kirsher
> Cc: "David S. Miller"
On Mon, Aug 12, 2019 at 05:03:32PM +0200, Ilya Leoshkevich wrote:
> "masking, test in bounds 3" fails on s390, because
> BPF_ALU64_IMM(BPF_NEG, BPF_REG_2, 0) ignores the top 32 bits of
> BPF_REG_2. The reason is that JIT emits lcgfr instead of lcgr.
> The associated comment indicates that the code
1 - 100 of 157 matches
Mail list logo
