On Thu, Jul 19, 2018 at 07:07:47PM -0700, Nathan Harold wrote:
> Allow attaching an SA to an xfrm interface id after
> the creation of the SA, so that tasks such as keying
> which must be done as the SA is created, can remain
> separate from the decision on how to route traffic
> from an SA. This p
On Thu, Jul 19, 2018 at 10:50:44AM -0700, Benedict Wong wrote:
> In order to remove performance impact of having the extra u32 in every
> single flowi, this change removes the flowi_xfrm struct, prefering to
> take the if_id as a method parameter where needed.
>
> In the inbound direction, if_id i
On Tue, Jun 26, 2018 at 02:19:10PM -0700, Shannon Nelson wrote:
> The offload_handle should be an opaque data cookie for the driver
> to use, much like the data cookie for a timer or alarm callback.
> Thus, the XFRM stack should not be checking for non-zero, because
> the driver might use that to s
On Sun, Jul 22, 2018 at 9:43 PM Eric Dumazet wrote:
>
>
>
> On 07/22/2018 05:43 PM, Willem de Bruijn wrote:
> > From: Willem de Bruijn
> >
> > Syzbot reported a read beyond the end of the skb head when returning
> > IPV6_ORIGDSTADDR:
> >
> > BUG: KMSAN: kernel-infoleak in put_cmsg+0x5ef/0x860 n
On 07/22/2018 05:43 PM, Willem de Bruijn wrote:
> From: Willem de Bruijn
>
> Syzbot reported a read beyond the end of the skb head when returning
> IPV6_ORIGDSTADDR:
>
> BUG: KMSAN: kernel-infoleak in put_cmsg+0x5ef/0x860 net/core/scm.c:242
> CPU: 0 PID: 4501 Comm: syz-executor128 Not tai
From: Willem de Bruijn
Syzbot reported a read beyond the end of the skb head when returning
IPV6_ORIGDSTADDR:
BUG: KMSAN: kernel-infoleak in put_cmsg+0x5ef/0x860 net/core/scm.c:242
CPU: 0 PID: 4501 Comm: syz-executor128 Not tainted 4.17.0+ #9
Hardware name: Google Google Compute Engine/Goo
On Sun, Jul 22, 2018 at 01:04:11PM -0700, David Miller wrote:
> From: Uwe Kleine-König
> Date: Sun, 22 Jul 2018 21:00:35 +0200
>
> > On Sat, Jul 21, 2018 at 10:44:09PM -0700, David Miller wrote:
> >> From: Uwe Kleine-König
> >> Date: Fri, 20 Jul 2018 11:53:15 +0200
> >>
> >> > free_irq() waits
From: Uwe Kleine-König
Date: Sun, 22 Jul 2018 21:00:35 +0200
> On Sat, Jul 21, 2018 at 10:44:09PM -0700, David Miller wrote:
>> From: Uwe Kleine-König
>> Date: Fri, 20 Jul 2018 11:53:15 +0200
>>
>> > free_irq() waits until all handlers for this IRQ have completed. As the
>> > relevant handler (
Hello,
On Sat, Jul 21, 2018 at 10:44:09PM -0700, David Miller wrote:
> From: Uwe Kleine-König
> Date: Fri, 20 Jul 2018 11:53:15 +0200
>
> > free_irq() waits until all handlers for this IRQ have completed. As the
> > relevant handler (mv88e6xxx_g1_irq_thread_fn()) takes the chip's reg_lock
> > it
Hi Dear, my name is Jack and i am seeking for a relationship in which i will
feel loved after a series of failed relationships.
I am hoping that you would be interested and we could possibly get to know each
other more if you do not mind. I am open to answering questions from you as i
think my
I think you can combine these two patches into one.
Thank you.
From: Jakub Kicinski
Date: Fri, 20 Jul 2018 21:14:38 -0700
> Now that we have offload replay infrastructure added by
> commit 326367427cc0 ("net: sched: call reoffload op on block callback reg")
> and flows are guaranteed to be removed correctly, we can revert
> commit 951a8ee6def3 ("nfp: reject
From: Jakub Kicinski
Date: Fri, 20 Jul 2018 21:14:39 -0700
> After device is stopped we reset the rings by moving all free buffers
> to positions [0, cnt - 2], and clear the position cnt - 1 in the ring.
> We then proceed to clear the read/write pointers. This means that if
> we try to reset the
From: Jakub Kicinski
Date: Fri, 20 Jul 2018 21:07:54 -0700
> From: John Hurley
>
> Previously only the neighbour state was checked to decide if an offloaded
> entry should be removed. However, there can be situations when the entry
> is dead but still marked as valid. This can lead to dead entr
From: Roopa Prabhu
Date: Fri, 20 Jul 2018 13:21:00 -0700
> From: Roopa Prabhu
>
> Problem:
> In vxlan_newlink, a default fdb entry is added before register_netdev.
> The default fdb creation function notifies user-space of the
> fdb entry on the vxlan device which user-space does not know about
From: Florian Westphal
Date: Fri, 20 Jul 2018 19:30:57 +0200
> Got crash report with following backtrace:
> BUG: unable to handle kernel paging request at 8801869daffe
> RIP: 0010:[] []
> ip6_finish_output2+0x394/0x4c0
> RSP: 0018:880186c83a98 EFLAGS: 00010283
> RAX: 8801869db00e .
From: Nikolay Aleksandrov
Date: Sun, 22 Jul 2018 11:37:31 +0300
> As was recently discussed [1], let's avoid casting the const buf in
> bonding_sysfs_store_option and use kstrndup/kfree instead.
>
> [1] http://lists.openwall.net/netdev/2018/07/22/25
>
> Signed-off-by: Nikolay Aleksandrov
Appl
From: Toshiaki Makita
This allows further redirection of xdp_frames like
NIC -> veth--veth -> veth--veth
(XDP) (XDP) (XDP)
The intermediate XDP, redirecting packets from NIC to the other veth,
reuses xdp_mem_info from NIC so that page recycling of the NIC works on
the desti
From: Toshiaki Makita
This is preparation for XDP TX and ndo_xdp_xmit.
This allows napi handler to handle xdp_frames through xdp ring as well
as sk_buff.
v3:
- Revert v2 change around rings and use a flag to differentiate skb and
xdp_frame, since bulk skb xmit makes little performance differen
From: Toshiaki Makita
This allows NIC's XDP to redirect packets to veth. The destination veth
device enqueues redirected packets to the napi ring of its peer, then
they are processed by XDP on its peer veth device.
This can be thought as calling another XDP program by XDP program using
REDIRECT,
From: Toshiaki Makita
This patch set introduces driver XDP for veth.
Basically this is used in conjunction with redirect action of another XDP
program.
NIC ---> veth===veth
(XDP) (redirect)(XDP)
In this case xdp_frame can be forwarded to the peer veth without
modification, so
From: Toshiaki Makita
This is the basic implementation of veth driver XDP.
Incoming packets are sent from the peer veth device in the form of skb,
so this is generally doing the same thing as generic XDP.
This itself is not so useful, but a starting point to implement other
useful veth XDP feat
From: Toshiaki Makita
All oversized packets including GSO packets are dropped if XDP is
enabled on receiver side, so don't send such packets from peer.
Drop TSO and SCTP fragmentation features so that veth devices themselves
segment packets with XDP enabled. Also cap MTU accordingly.
Signed-off
From: Toshiaki Makita
We need some mechanism to disable napi_direct on calling
xdp_return_frame_rx_napi() from some context.
When veth gets support of XDP_REDIRECT, it will redirects packets which
are redirected from other devices. On redirection veth will reuse
xdp_mem_info of the redirection so
From: Toshiaki Makita
This is needed for veth XDP which does skb_copy_expand()-like operation.
v2:
- Drop skb_copy_header part because it has already been exported now.
Signed-off-by: Toshiaki Makita
---
include/linux/skbuff.h | 1 +
net/core/skbuff.c | 3 ++-
2 files changed, 3 insertio
From: Toshiaki Makita
Move XDP and napi related fields in veth_priv to newly created veth_rq
structure.
When xdp_frames are enqueued from ndo_xdp_xmit and XDP_TX, rxq is
selected by current cpu.
When skbs are enqueued from the peer device, rxq is one to one mapping
of its peer txq. This way we
On Sat, 2018-07-21 at 16:29 -0700, David Miller wrote:
> From: Paolo Abeni
> Date: Thu, 19 Jul 2018 15:02:29 +0200
>
> > kernel openswitch datapath.
> ^^
>
> "openvswitch"
Oops, typo!
Thank you for the feedback! I do hope this is your major concern ;)
I will address it v3.
T
Hi
The kernel based TLS record layer allows the user space world to use a
decoupled TLS implementation.
The applications need not be linked with TLS stack.
The TLS handshake can be done by a TLS daemon on the behalf of applications.
Presently, as soon as the handshake process derives keys, it p
Extend VFs statistics by receive and transmit violation counters.
Example: "ip -s link show dev enp5s0f0"
6: enp5s0f0: mtu 1500 qdisc mq state UP mode
DEFAULT group default qlen 1000
link/ether 24:8a:07:a5:28:f0 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
On 07/22/2018 05:17 AM, David Miller wrote:
> From: Hauke Mehrtens
> Date: Sat, 21 Jul 2018 21:13:58 +0200
>
>> +// start the table access:
>
> Please stick to C-style comments, except perhaps in the SPDX
> identifiers.
>
> Thank you.
>
Sorry that I missed that, it is fixed now.
As was recently discussed [1], let's avoid casting the const buf in
bonding_sysfs_store_option and use kstrndup/kfree instead.
[1] http://lists.openwall.net/netdev/2018/07/22/25
Signed-off-by: Nikolay Aleksandrov
---
drivers/net/bonding/bond_sysfs.c | 7 ++-
1 file changed, 6 insertions(+),
On 19/07/2018 8:25 PM, Cong Wang wrote:
On Thu, Jul 19, 2018 at 7:34 AM Tariq Toukan wrote:
Fix dev_change_tx_queue_len so it rolls back original value
upon a failure in dev_qdisc_change_tx_queue_len.
This is already done for notifirers' failures, share the code.
The revert of changes in d
On 19/07/2018 8:21 PM, Cong Wang wrote:
On Thu, Jul 19, 2018 at 7:50 AM Tariq Toukan wrote:
--- a/net/core/dev_ioctl.c
+++ b/net/core/dev_ioctl.c
@@ -282,14 +282,7 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr,
unsigned int cmd)
return dev_mc_del_global(dev, i
33 matches
Mail list logo
