From: Greg Ungerer
Add descriptive entries for the new bindings introduced to support the
MT7530 implementation in the MediaTek MT7621 SoC.
New bindings added for:
mediatek,no-clock-regulator
mediatek,mfc-has-cpuport
Signed-off-by: Greg Ungerer
---
Documentation/devicetree/bindings/net/d
From: Greg Ungerer
At least one device that contains the MediaTek MT7530 switch module
does not need the clock and regulator setup parts of the MT7530 DSA
driver. That setup looks to be very specific to the MT7623.
The MediaTek MT7621 SoC device contains a 7530 switch, but its MIPS CPU
cores and
From: Greg Ungerer
Some versions of the MediaTek MT7530 switch have a CPU port number and
enable bit in their MFC register. The MT7530 instance on the MediaTek
MT7621 SoC is one that does for example. The switch will not work
without these fields being correctly setup on these devices.
Create a
I have been working towards supporting the MT7530 switch as used in the
MediaTek MT7621 SoC. Unlike the MediaTek MT7623 the MT7621 is built around
a dual core MIPS CPU architecture. But underneath it is what appears to
be the same 7530 switch.
The following 3 patches are more of an RFC than anythi
On Friday, 30 November 2018 15:00:02 CET Wen Yang wrote:
> This patch fixes a possible null pointer dereference in
> batadv_gw_election, detected by the semantic patch
> deref_null.cocci, with the following warning:
>
> ./net/batman-adv/gateway_client.c:289:15-24: ERROR: next_gw is NULL but
> der
> > > So it should return at least 18 and not 14.
> >
> > Yes, the function does its best to return at least 18, but it silently
> expects
> > skb_transport_offset to exceed 18. In normal conditions, it will be more
> that
> > 18, because it will be at least 14 + 20. But in my case, when I send a
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, 2018-11-29 at 15:52 -0800, David Miller wrote:
> From: Kees Cook
> Date: Thu, 29 Nov 2018 15:31:25 -0800
>
> > Did you ever solve this?
>
> I think it was fixed by:
>
> commit 45611c61dd503454b2edae00aabe1e429ec49ebe
> Author: Bernd Eckst
This patch fixes a possible null pointer dereference in
batadv_gw_election, detected by the semantic patch
deref_null.cocci, with the following warning:
./net/batman-adv/gateway_client.c:289:15-24: ERROR: next_gw is NULL but
dereferenced.
./net/batman-adv/gateway_client.c:290:15-29: ERROR: next_g
Hi Heiner,
On Fri, 30 Nov 2018 07:20:27 +0100 wrote:
> On 30.11.2018 05:37, Kunihiko Hayashi wrote:
> > Hi Heiner Florian,
> >
> > Thank you for your comments.
> >
> > On Thu, 29 Nov 2018 16:37:48 -0800 wrote:
> >
> >>
> >>
> >> On 11/29/2018 2:47 PM, Heiner Kallweit wrote:
> >>> On 29.11.20
On Thu, Nov 29, 2018 at 11:39 PM Neil Horman wrote:
>
> On Thu, Nov 29, 2018 at 02:42:56PM +0800, Xin Long wrote:
> > Now when using stream reconfig to add out streams, stream->out
> > will get re-allocated, and all old streams' information will
> > be copied to the new ones and the old ones will
On 30.11.2018 05:37, Kunihiko Hayashi wrote:
> Hi Heiner Florian,
>
> Thank you for your comments.
>
> On Thu, 29 Nov 2018 16:37:48 -0800 wrote:
>
>>
>>
>> On 11/29/2018 2:47 PM, Heiner Kallweit wrote:
>>> On 29.11.2018 09:12, Kunihiko Hayashi wrote:
Even though the link is down before ent
On 2018/11/30 11:40, Jason Wang wrote:
> On 2018/11/30 上午10:30, Prashant Bhole wrote:
>> In tun.c skb->len was accessed while doing stats accounting after a
>> call to netif_receive_skb. We can not access skb after this call
>> because buffers may be dropped.
>>
>> The fix for this bug would be to
On Fri, Nov 30, 2018 at 5:52 AM Neil Horman wrote:
>
> On Thu, Nov 29, 2018 at 02:44:07PM +0800, Xin Long wrote:
> > Without holding transport to dereference its asoc, a use after
> > free panic can be caused in sctp_epaddr_lookup_transport. Note
> > that a sock lock can't protect these transports
Hi Heiner Florian,
Thank you for your comments.
On Thu, 29 Nov 2018 16:37:48 -0800 wrote:
>
>
> On 11/29/2018 2:47 PM, Heiner Kallweit wrote:
> > On 29.11.2018 09:12, Kunihiko Hayashi wrote:
> >> Even though the link is down before entering hibernation,
> >> there is an issue that the network
The amount of DMA mappings from Hisilicon HNS ethernet devices is huge,
so it could trigger "DMA-API: debugging out of memory - disabling".
hnae_get_handle [1]
hnae_init_queue
hnae_init_ring
hnae_alloc_buffers [2]
debug_dma_map_page
dma_entry_alloc
[1] for (i = 0; i
Make it set the flag argument to bpf_verify_program() which will relax
the alignment restrictions.
Now all such test cases will go properly through the verifier even on
inefficient unaligned access architectures.
On inefficient unaligned access architectures do not try to run such
programs, ins
Use F_NEEDS_EFFICIENT_UNALIGNED_ACCESS in more tests where the
expected result is REJECT.
Signed-off-by: David S. Miller
---
tools/testing/selftests/bpf/test_verifier.c | 44 +
1 file changed, 44 insertions(+)
diff --git a/tools/testing/selftests/bpf/test_verifier.
If a testcase has alignment problems but is expected to be ACCEPT,
verify it using F_NEEDS_EFFICIENT_UNALIGNED_ACCESS too.
Maybe in the future if we add some architecture specific code to elide
the unaligned memory access warnings during the test, we can execute
these as well.
Signed-off-by: Da
On sparc64 a ton of test cases in test_verifier.c fail because
the memory accesses in the test case are unaligned (or cannot
be proven to be aligned by the verifier).
Perhaps we can eventually try to (carefully) modify each test case
which has this problem to not use unaligned accesses but:
1)
Often we want to write tests cases that check things like bad context
offset accesses. And one way to do this is to use an odd offset on,
for example, a 32-bit load.
This unfortunately triggers the alignment checks first on platforms
that do not set CONFIG_EFFICIENT_UNALIGNED_ACCESS. So the te
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Friday, November 16, 2018 4:19 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; jesus.s.palen...@gmail.com
> Subject: [Intel-wired-lan] [next-queue PATCH v1 2/2] Do
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> Sent: Friday, November 16, 2018 4:19 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: Sanchez-Palencia, Jesus ; Kirsher,
> Jeffrey T ; netdev@vger.kernel.org;
> jesus.s.palen...@gmail.co
On 2018/11/30 上午10:30, Prashant Bhole wrote:
In tun.c skb->len was accessed while doing stats accounting after a
call to netif_receive_skb. We can not access skb after this call
because buffers may be dropped.
The fix for this bug would be to store skb->len in local variable and
then use it af
On 2018/11/30 上午3:28, Jean-Philippe Brucker wrote:
Hi,
On 25/09/2018 13:36,xiangxia.m@gmail.com wrote:
From: Tonghao Zhang
This patch changes the way that lock all vqs
at the same, to lock them one by one. It will
be used for next patch to avoid the deadlock.
Signed-off-by: Tonghao Zha
In tun.c skb->len was accessed while doing stats accounting after a
call to netif_receive_skb. We can not access skb after this call
because buffers may be dropped.
The fix for this bug would be to store skb->len in local variable and
then use it after netif_receive_skb(). IMO using xdp data size
From: Sagi Grimberg
Date: Thu, 29 Nov 2018 17:24:09 -0800
>
>> What is the plan ahead here? I think the nvme code looks pretty
>> reasonable now (I'll do another pass at nitpicking), but we need the
>> networking stuff sorted out with at least ACKs, or a merge through
>> the networking tree and
From: Daniel Borkmann
Date: Fri, 30 Nov 2018 03:01:38 +0100
> The following pull-request contains BPF updates for your *net-next* tree.
>
> (Getting out bit earlier this time to pull in a dependency from bpf.)
>
> The main changes are:
>
> 1) Add libbpf ABI versioning and document API naming c
On Thu, Nov 29, 2018 at 1:46 PM Eric Dumazet wrote:
>
>
>
> On 11/29/2018 01:13 PM, Duyck, Alexander H wrote:
>
> > Instead of just checking for the max it might make more sense to do a
> > check using skb_is_gso, and then if true use gso_segs, otherwise just
> > default to 1.
> >
> > Also your by
Hi David,
The following pull-request contains BPF updates for your *net-next* tree.
(Getting out bit earlier this time to pull in a dependency from bpf.)
The main changes are:
1) Add libbpf ABI versioning and document API naming conventions
as well as ABI versioning process, from Andrey.
2)
On 11/30/2018 12:47 AM, Jakub Kicinski wrote:
> On Thu, 29 Nov 2018 15:31:45 -0800, Yonghong Song wrote:
>> During porting libbpf to bcc, I got some warnings like below:
>> ...
>> [ 2%] Building C object
>> src/cc/CMakeFiles/bpf-shared.dir/libbpf/src/libbpf.c.o
>> /home/yhs/work/bcc2/src/cc
What is the plan ahead here? I think the nvme code looks pretty
reasonable now (I'll do another pass at nitpicking), but we need the
networking stuff sorted out with at least ACKs, or a merge through
the networking tree and then a shared branch we can pull in.
I would think that having Dave
+static inline void nvmet_tcp_put_cmd(struct nvmet_tcp_cmd *cmd)
+{
+ if (unlikely(cmd == &cmd->queue->connect))
+ return;
if you don't return connect cmd to the list please don't add it to it in
the first place (during alloc_cmd). and if you use it once, we might
think of a clean
> From: Eric Dumazet
> On 11/29/2018 01:13 PM, Duyck, Alexander H wrote:
> >
> > Also your bytes are going to be totally messed up as well since the
> > headers are trimmed in the GSO frames. It might be worthwhile to just
> > have a branch based on skb_is_gso that sets the packets and bytes
> > b
On Wed, Nov 28, 2018 at 3:10 AM Maxim Mikityanskiy wrote:
>
> Hi Saeed,
>
> > Can you elaborate more, what NIC? what configuration ? what do you mean
> > by confusion, anyway please see below
>
> ConnectX-4, after running `mlnx_qos -i eth1 --trust dscp`, which sets inline
> mode 2 (MLX5_INLINE_MOD
Fix packet count when using vlan/macvlan drivers with gso. Without this it
is not possible to reconcile packet counts between underlying devices and
these virtual devices. Additionally, the output looks wrong in a standalone
way i.e. device MTU of 1500, 1 packet sent, 31856 bytes sent.
There are m
On Thu, Nov 29, 2018 at 3:52 PM David Miller wrote:
>
> From: Kees Cook
> Date: Thu, 29 Nov 2018 15:31:25 -0800
>
> > Did you ever solve this?
>
> I think it was fixed by:
>
> commit 45611c61dd503454b2edae00aabe1e429ec49ebe
> Author: Bernd Eckstein <3erndeckst...@gmail.com>
> Date: Fri Nov 23 1
On Mon, Nov 26, 2018 at 2:39 PM Saeed Mahameed wrote:
>
> Hi,
>
> This patchset is for mlx5-next shared branch, and will be applied there
> once the review is done.
>
> The main idea of this change is to define a flexible scalable and
> simpler high level mlx5 core APIs to forward device and drive
On 11/29/2018 2:47 PM, Heiner Kallweit wrote:
> On 29.11.2018 09:12, Kunihiko Hayashi wrote:
>> Even though the link is down before entering hibernation,
>> there is an issue that the network interface always links up after resuming
>> from hibernation.
>>
>> The phydev->state is PHY_READY befor
Improve the wording around socket lookup for reuseport sockets, and
ensure that both bpf.h headers are in sync.
Signed-off-by: Joe Stringer
---
include/uapi/linux/bpf.h | 4
tools/include/uapi/linux/bpf.h | 8
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/inc
David Ahern and Nicolas Dichtel report that the handling of the netns id
0 is incorrect for the BPF socket lookup helpers: rather than finding
the netns with id 0, it is resolving to the current netns. This renders
the netns_id 0 inaccessible.
To fix this, adjust the API for the netns to treat all
On Wed, Nov 28, 2018 at 8:09 PM Eric Dumazet wrote:
>
> On Wed, Nov 28, 2018 at 7:53 PM Cong Wang wrote:
> >
> > On Wed, Nov 28, 2018 at 7:50 PM Eric Dumazet wrote:
> > >
> > > On Wed, Nov 28, 2018 at 7:40 PM Cong Wang
> > > wrote:
> > > >
> > > > On Wed, Nov 28, 2018 at 4:07 PM Eric Dumazet
From: Christoph Paasch
Date: Thu, 29 Nov 2018 16:01:04 -0800
> __qdisc_drop_all() accesses skb->prev to get to the tail of the
> segment-list.
>
> With commit 68d2f84a1368 ("net: gro: properly remove skb from list")
> the skb-list handling has been changed to set skb->next to NULL and set
> the
On 11/29/2018 04:01 PM, Christoph Paasch wrote:
> __qdisc_drop_all() accesses skb->prev to get to the tail of the
> segment-list.
>
> With commit 68d2f84a1368 ("net: gro: properly remove skb from list")
> the skb-list handling has been changed to set skb->next to NULL and set
> the list-poison
On Wed, Nov 28, 2018 at 4:05 PM Cong Wang wrote:
>
> On Wed, Nov 28, 2018 at 3:57 PM Cong Wang wrote:
> > But again, I kinda feel the hardware already does the sanity check,
> > otherwise we have much more serious trouble in mlx5e_lro_update_hdr()
> > which parses into TCP header.
> >
>
> While w
__qdisc_drop_all() accesses skb->prev to get to the tail of the
segment-list.
With commit 68d2f84a1368 ("net: gro: properly remove skb from list")
the skb-list handling has been changed to set skb->next to NULL and set
the list-poison on skb->prev.
With that change, __qdisc_drop_all() will panic
From: Pavel Machek
Date: Fri, 30 Nov 2018 00:44:32 +0100
> In -next we have new driver, and it is default-y.
>
> I'm pretty sure that's a no-no.
>
> Can someone please fix it?
Done.
On Thu, Nov 29, 2018 at 3:54 PM David Miller wrote:
>
> From: Eric Dumazet
> Date: Thu, 29 Nov 2018 15:09:18 -0800
>
> > diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
> > index
> > 2c38e3d0792468162ee0dc4137f1400160ab9276..22cd46a600576f286803536d45875cd9d537cdca
> > 100644
> > ---
From: Christoph Paasch
Date: Thu, 29 Nov 2018 15:45:19 -0800
> I can resubmit a patch.
Please do after testing.
On Thu, Nov 29, 2018 at 5:13 AM Tariq Toukan wrote:
>
>
>
> On 29/11/2018 1:04 AM, Cong Wang wrote:
> > IP header is not necessarily located right after struct ethhdr,
> > there could be multiple 802.1Q headers in between, this is why
> > we call __vlan_get_protocol().
> >
> > Fixes: fe1dc069990c
From: Eric Dumazet
Date: Thu, 29 Nov 2018 15:09:18 -0800
> diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
> index
> 2c38e3d0792468162ee0dc4137f1400160ab9276..22cd46a600576f286803536d45875cd9d537cdca
> 100644
> --- a/net/sched/sch_netem.c
> +++ b/net/sched/sch_netem.c
> @@ -431,6 +43
From: Kees Cook
Date: Thu, 29 Nov 2018 15:31:25 -0800
> Did you ever solve this?
I think it was fixed by:
commit 45611c61dd503454b2edae00aabe1e429ec49ebe
Author: Bernd Eckstein <3erndeckst...@gmail.com>
Date: Fri Nov 23 13:51:26 2018 +0100
usbnet: ipheth: fix potential recvmsg bug and re
Hi All,
On 11/28/18 7:22 PM, David Miller wrote:
> From: Andrew Lunn
> Date: Thu, 29 Nov 2018 01:28:35 +0100
>
>> On Wed, Nov 28, 2018 at 04:43:40PM -0600, Grygorii Strashko wrote:
>>> Hi Andrew,
>>>
>>> On 11/28/18 4:02 PM, Andrew Lunn wrote:
> This is dynamic configuration related to ALE V
On Thu, 29 Nov 2018 15:31:45 -0800, Yonghong Song wrote:
> During porting libbpf to bcc, I got some warnings like below:
> ...
> [ 2%] Building C object
> src/cc/CMakeFiles/bpf-shared.dir/libbpf/src/libbpf.c.o
> /home/yhs/work/bcc2/src/cc/libbpf/src/libbpf.c:12:0:
> warning: "_GNU_SOURCE"
On 29/11/18 - 15:09:18, Eric Dumazet wrote:
>
>
> On 11/29/2018 02:55 PM, Christoph Paasch wrote:
> > On 29/11/18 - 14:44:44, Eric Dumazet wrote:
> >>
> >>
> >> On 11/29/2018 02:27 PM, Christoph Paasch wrote:
> >>> There are places in the stack, where we access skb->prev directly and
> >>> modify
Hi!
In -next we have new driver, and it is default-y.
I'm pretty sure that's a no-no.
Can someone please fix it?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.c
During porting libbpf to bcc, I got some warnings like below:
...
[ 2%] Building C object
src/cc/CMakeFiles/bpf-shared.dir/libbpf/src/libbpf.c.o
/home/yhs/work/bcc2/src/cc/libbpf/src/libbpf.c:12:0:
warning: "_GNU_SOURCE" redefined [enabled by default]
#define _GNU_SOURCE
...
[ 3%]
On Wed, Jun 6, 2018 at 1:21 AM Yves-Alexis Perez wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Tue, Jun 05, 2018 at 10:54:51AM +0200, Yves-Alexis Perez wrote:
> > Hi,
> >
> > since some kernels releases (I didn't test thorougly but at least 4.16
> > and 4.17) I have regular f
Some users of rhashtables might need to move an object from one table
to another - this appears to be the reason for the incomplete usage
of NULLS markers.
To support these, we store a unique NULLS_MARKER at the end of
each chain, and when a search fails to find a match, we check
if the NULLS ma
On 11/29/18 1:00 PM, Jakub Kicinski wrote:
> On Thu, 29 Nov 2018 12:38:03 -0800, Yonghong Song wrote:
>> diff --git a/tools/lib/bpf/libbpf_errno.c b/tools/lib/bpf/libbpf_errno.c
>> index d83b17f8435c..286e497c50ec 100644
>> --- a/tools/lib/bpf/libbpf_errno.c
>> +++ b/tools/lib/bpf/libbpf_errno.c
On 11/29/2018 03:00 PM, Paolo Abeni wrote:
> This header define a bunch of helpers that allow avoiding the
> retpoline overhead when calling builtin functions via function pointers.
> It boils down to explicitly comparing the function pointers to
> known builtin functions and eventually invoke d
On 11/29/18 9:26 AM, Ivan Khoronzhuk wrote:
> On Wed, Nov 28, 2018 at 03:15:46PM -0600, Grygorii Strashko wrote:
>>
>>
>> On 11/26/18 2:07 PM, Ivan Khoronzhuk wrote:
>>> On Mon, Nov 26, 2018 at 12:57:20PM -0600, Grygorii Strashko wrote:
On 11/26/18 10:26 AM, Ivan Khoronzhuk wrote:
On Thu, 29 Nov 2018 18:49:26 +
"Edgecombe, Rick P" wrote:
> On Thu, 2018-11-29 at 23:06 +0900, Masami Hiramatsu wrote:
> > On Tue, 27 Nov 2018 16:07:52 -0800
> > Rick Edgecombe wrote:
> >
> > > Sometimes when memory is freed via the module subsystem, an executable
> > > permissioned TLB ent
On 11/29/2018 02:55 PM, Christoph Paasch wrote:
> On 29/11/18 - 14:44:44, Eric Dumazet wrote:
>>
>>
>> On 11/29/2018 02:27 PM, Christoph Paasch wrote:
>>> There are places in the stack, where we access skb->prev directly and
>>> modify it. Namely, __qdisc_drop_all().
>>>
>>> With commit 68d2f84a
This avoids an indirect calls for L3 GRO receive path, both
for ipv4 and ipv6, if the latter is not compiled as a module.
Note that when IPv6 is compiled as buildin, it will be checked first,
so we have a single additional compare for the more common path.
Signed-off-by: Paolo Abeni
---
include
This avoids an indirect call in the receive path for TCP and UDP
packets. TCP takes precedence on UDP, so that we have a single
additional conditional in the common case.
Signed-off-by: Paolo Abeni
---
include/net/inet_common.h | 7 +++
net/ipv4/af_inet.c| 11 +--
net/ipv4/t
This avoids another indirect call for UDP GRO. Again, the test
for the IPv6 variant is performed first.
Signed-off-by: Paolo Abeni
---
net/ipv4/udp.c | 2 ++
net/ipv4/udp_offload.c | 6 --
net/ipv6/udp.c | 2 ++
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/n
This header define a bunch of helpers that allow avoiding the
retpoline overhead when calling builtin functions via function pointers.
It boils down to explicitly comparing the function pointers to
known builtin functions and eventually invoke directly the latter.
The macro defined here implement
The spectre v2 counter-measures, aka retpolines, are a source of measurable
overhead[1]. We can partially address that when the function pointer refers to
a builtin symbol resorting to a list of tests vs well-known builtin function and
direct calls.
This may lead to some uglification around the in
On Thu, Nov 29, 2018 at 2:47 PM Christoph Paasch wrote:
> Indeed, the UDP-stack is not fully 4-tuple ready.
>
>
> What are your thoughts on getting it there?
This would request an additional lookup, and heavy duty servers using
non connected sockets
would pay the price for an extra lookup for ea
On 29/11/18 - 14:44:44, Eric Dumazet wrote:
>
>
> On 11/29/2018 02:27 PM, Christoph Paasch wrote:
> > There are places in the stack, where we access skb->prev directly and
> > modify it. Namely, __qdisc_drop_all().
> >
> > With commit 68d2f84a1368 ("net: gro: properly remove skb from list")
> >
On Thu, 2018-11-29 at 22:19 +, Steve Douthit wrote:
> On 11/29/18 2:03 PM, Jeff Kirsher wrote:
> > On Thu, 2018-11-29 at 18:54 +, Steve Douthit wrote:
> > > Most dsa devices currently expect to get a pointer to a mii_bus from
> > > platform data of device tree information.
> > >
> > > The
Hello,
On 28/11/18 - 19:15:12, Eric Dumazet wrote:
> On Wed, Nov 28, 2018 at 7:09 PM Jana Iyengar wrote:
> >
> >
> > On Wed, Nov 28, 2018 at 6:19 PM Eric Dumazet wrote:
> >>
> >> On Wed, Nov 28, 2018 at 5:57 PM Christoph Paasch wrote:
> >> >
> >> > There are use-cases where a host wants to use
On 29.11.2018 09:12, Kunihiko Hayashi wrote:
> Even though the link is down before entering hibernation,
> there is an issue that the network interface always links up after resuming
> from hibernation.
>
> The phydev->state is PHY_READY before enabling the network interface, so
> the link is down
On 11/29/2018 02:27 PM, Christoph Paasch wrote:
> There are places in the stack, where we access skb->prev directly and
> modify it. Namely, __qdisc_drop_all().
>
> With commit 68d2f84a1368 ("net: gro: properly remove skb from list")
> the skb-list handling has been changed to set skb->next to
On Wed, Nov 28, 2018 at 9:44 AM Davide Caratti wrote:
>
> when users set an invalid control action, kmemleak complains as follows:
...
> change tcf_police_init() to avoid leaking 'new' in case TCA_POLICE_RESULT
> contains TC_ACT_GOTO_CHAIN extended action.
>
> Fixes: c08f5ed5d625 ("net/sched: act_
There are places in the stack, where we access skb->prev directly and
modify it. Namely, __qdisc_drop_all().
With commit 68d2f84a1368 ("net: gro: properly remove skb from list")
the skb-list handling has been changed to set skb->next to NULL and set
the list-poison on skb->prev.
With that change,
From: Martin Schiller
Date: Tue, 27 Nov 2018 09:50:27 +0100
> The length of the called and calling address was not calculated
> correctly (BCD encoding).
>
> Signed-off-by: Martin Schiller
Applied.
From: Martin Schiller
Date: Tue, 27 Nov 2018 09:50:29 +0100
> If a session in X25_STATE_1 (Awaiting Call Accept) receives a call
> request, the session will be closed (x25_disconnect), cause=0x01
> (Number Busy) and diag=0x48 (Call Collision) will be set and a clear
> request will be send.
>
> S
From: Martin Schiller
Date: Tue, 27 Nov 2018 09:50:28 +0100
> o x25_find_listener(): the compare for the null_x25_address was wrong.
>We have to check the x25_addr of the listener socket instead of the
>x25_addr of the incomming call.
>
> o x25_bind(): it was not possible to bind a soc
On 11/29/18 2:03 PM, Jeff Kirsher wrote:
> On Thu, 2018-11-29 at 18:54 +, Steve Douthit wrote:
>> Most dsa devices currently expect to get a pointer to a mii_bus from
>> platform data of device tree information.
>>
>> The first patch exposes a mii_bus for ixgbe devices.
>>
>> Currently the ixgb
On Thu, Nov 29, 2018 at 07:18:50PM -0200, Alacn wrote:
> >From ecc3afc357aeece71842d2d9e3f7ec63e2b4ab67 Mon Sep 17 00:00:00 2001
> From: Anderson Luiz Alves
> Date: Thu, 29 Nov 2018 19:02:03 -0200
> Subject: [PATCH] mv88e6060: disable hardware level MAC learning
>
> Disable hardware level MAC lea
From: Cong Wang
Date: Mon, 26 Nov 2018 09:31:26 -0800
> Cc: Herbert Xu
> Signed-off-by: Cong Wang
Applied, thanks Cong.
On Thu, Nov 29, 2018 at 11:31:23AM -0800, Florian Fainelli wrote:
>
>
> On 11/29/2018 4:49 AM, Baruch Siach wrote:
> > The mvpp2_phylink_validate() relies on the interface field of
> > phylink_link_state to determine valid link modes. However, when called
> > from phylink_sfp_module_insert() this
Hi Cong,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net/master]
url:
https://github.com/0day-ci/linux/commits/Cong-Wang/mlx5-fixup-checksum-for-ethernet-padding/20181130-014928
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 8.
On 11/29/2018 01:13 PM, Duyck, Alexander H wrote:
> Instead of just checking for the max it might make more sense to do a
> check using skb_is_gso, and then if true use gso_segs, otherwise just
> default to 1.
>
> Also your bytes are going to be totally messed up as well since the
> headers ar
On Thu, 2018-11-29 at 15:58 -0500, Debabrata Banerjee wrote:
> Fix packet count when using vlan/macvlan drivers with gso. Without this it
> is not possible to reconcile packet counts between underlying devices and
> these virtual devices. Additionally, the output looks wrong in a standalone
> way i
On Thu, 29 Nov 2018 12:38:03 -0800, Yonghong Song wrote:
> diff --git a/tools/lib/bpf/libbpf_errno.c b/tools/lib/bpf/libbpf_errno.c
> index d83b17f8435c..286e497c50ec 100644
> --- a/tools/lib/bpf/libbpf_errno.c
> +++ b/tools/lib/bpf/libbpf_errno.c
> @@ -40,9 +40,19 @@ int libbpf_strerror(int err, c
Fix packet count when using vlan/macvlan drivers with gso. Without this it
is not possible to reconcile packet counts between underlying devices and
these virtual devices. Additionally, the output looks wrong in a standalone
way i.e. device MTU of 1500, 1 packet sent, 31856 bytes sent.
There are m
On Thu, Nov 29, 2018 at 02:44:07PM +0800, Xin Long wrote:
> Without holding transport to dereference its asoc, a use after
> free panic can be caused in sctp_epaddr_lookup_transport. Note
> that a sock lock can't protect these transports that belong to
> other socks.
>
> A similar fix as Commit ba
On Thu, 29 Nov 2018 03:22:24 +0100, Pablo Neira Ayuso wrote:
> This patch provides the flow_stats structure that acts as container for
> tc_cls_flower_offload, then we can use to restore the statistics on the
> existing TC actions. Hence, tcf_exts_stats_update() is not used from
> drivers anymore.
During porting libbpf to bcc, I got some warnings like below:
...
[ 2%] Building C object
src/cc/CMakeFiles/bpf-shared.dir/libbpf/src/libbpf.c.o
/home/yhs/work/bcc2/src/cc/libbpf/src/libbpf.c:12:0:
warning: "_GNU_SOURCE" redefined [enabled by default]
#define _GNU_SOURCE
...
[ 3%]
On Thu, Nov 29, 2018 at 3:26 PM Willem de Bruijn
wrote:
>
> From: Willem de Bruijn
>
> With MSG_ZEROCOPY, each skb holds a reference to a struct ubuf_info.
> Release of its last reference triggers a completion notification.
>
> The TCP stack in tcp_sendmsg_locked holds an extra ref independent of
On Thu, Nov 29, 2018 at 3:26 PM Willem de Bruijn
wrote:
>
> From: Willem de Bruijn
>
> Extend zerocopy to udp sockets. Allow setting sockopt SO_ZEROCOPY and
> interpret flag MSG_ZEROCOPY.
>
> This patch was previously part of the zerocopy RFC patchsets. Zerocopy
> is not effective at small MTU. W
From: Willem de Bruijn
With MSG_ZEROCOPY, each skb holds a reference to a struct ubuf_info.
Release of its last reference triggers a completion notification.
The TCP stack in tcp_sendmsg_locked holds an extra ref independent of
the skbs, because it can build, send and free skbs within its loop,
From: Willem de Bruijn
Both msg_zerocopy and udpgso_bench have udp zerocopy variants.
Exercise these as part of the standard kselftest run.
With udp, msg_zerocopy has no control channel. Ensure that the
receiver exits after the sender by accounting for the initial
delay in starting them (in msg_
From: Willem de Bruijn
Extend zerocopy to udp sockets. Allow setting sockopt SO_ZEROCOPY and
interpret flag MSG_ZEROCOPY.
This patch was previously part of the zerocopy RFC patchsets. Zerocopy
is not effective at small MTU. With segmentation offload building
larger datagrams, the benefit of page
From: Willem de Bruijn
Enable MSG_ZEROCOPY for udp sockets
Patch 1/3 is the main patch, a rework of RFC patch
http://patchwork.ozlabs.org/patch/899630/
more details in the patch commit message
Patch 2/3 is an optimization to remove a branch from the UDP hot path
and refcount_inc/refcount_
Hi Roopa,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Roopa-Prabhu/vxlan-support-changelink-for-a-few-more-attributes/20181130-030315
config: x86_64-randconfig-x006-201847 (attached as .config)
compiler
Hi Florian,
Florian Fainelli writes:
> On 11/29/2018 4:49 AM, Baruch Siach wrote:
>> The mvpp2_phylink_validate() relies on the interface field of
>> phylink_link_state to determine valid link modes. However, when called
>> from phylink_sfp_module_insert() this field in not initialized. The
>> def
From: Baruch Siach
Date: Thu, 29 Nov 2018 12:00:05 +0200
> SFP standards are now available from the SNIA (Storage Networking
> Industry Association) website.
>
> Cc: Andrew Lunn
> Cc: Florian Fainelli
> Signed-off-by: Baruch Siach
Applied.
1 - 100 of 218 matches
Mail list logo
