Mon, Oct 01, 2018 at 06:04:08AM CEST, vasundhara-v.vo...@broadcom.com wrote:
>On Sat, Sep 29, 2018 at 6:27 PM Jiri Pirko wrote:
>>
>> Fri, Sep 28, 2018 at 08:28:23AM CEST, vasundhara-v.vo...@broadcom.com wrote:
>> >This patch adds a new file to add information about configuration
>> >parameters
On 10 Aug 2018, at 16:48, Eelco Chaudron wrote:
On 10 Aug 2018, at 16:44, Stephen Hemminger wrote:
On Fri, 10 Aug 2018 07:59:30 -0400
Eelco Chaudron wrote:
+ if (bs.bytes >= bs_hw.bytes && bs.packets >= bs_hw.packets) {
+ print_string(PRINT_FP, NULL,
From: Patrick Ruddy
The code to obtain the correct table for the incoming interface was
missing for IPv6. This has been added along with the table creation
notification to fib rules for the RTNL_FAMILY_IP6MR address family.
Signed-off-by: Patrick Ruddy
Signed-off-by: Mike Manning
---
On 25/09/2018 18:16, David Ahern wrote:
> On 9/25/18 9:26 AM, Mike Manning wrote:
>> On 24/09/2018 23:44, David Ahern wrote:
>>> On 9/24/18 10:13 AM, Mike Manning wrote:
From: Robert Shearman
There is no easy way currently for applications that want to receive
packets in the
From: Haishuang Yan
The pointer 'esph' is defined but is never used hence it is redundant
and canbe removed.
Signed-off-by: Haishuang Yan
Signed-off-by: Steffen Klassert
---
net/ipv4/esp4.c | 7 +++
net/ipv6/esp6.c | 7 +++
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git
From: Wei Yongjun
Fixes the following sparse warning:
net/xfrm/xfrm_interface.c:745:12: warning:
symbol 'xfrmi_get_link_net' was not declared. Should it be static?
Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces")
Signed-off-by: Wei Yongjun
Signed-off-by: Steffen Klassert
---
Hi Andrew,
On Fri, Sep 14, 2018 at 07:27:54PM +0200, Andrew Lunn wrote:
>
> > struct vsc8531_private {
> > int rate_magic;
> > u16 supp_led_modes;
> > @@ -181,6 +354,7 @@ struct vsc8531_private {
> > struct vsc85xx_hw_stat *hw_stats;
> > u64 *stats;
> > int nstats;
> > +
From: Shannon Nelson
If the "offload" attribute is used to create an IPsec SA
and the .xdo_dev_state_add() fails, the SA creation fails.
However, if the "offload" attribute is used on a device that
doesn't offer it, the attribute is quietly ignored and the SA
is created without an offload.
1) Make xfrmi_get_link_net() static to silence a sparse warning.
From Wei Yongjun.
2) Remove a unused esph pointer definition in esp_input().
From Haishuang Yan.
3) Allow the NIC driver to quietly refuse xfrm offload
in case it does not support it, the SA is created
without offload
From: Robert Shearman
It is useful to be able to use the same socket for listening in a
specific VRF, as for sending multicast packets out of a specific
interface. However, the bound device on the socket currently takes
precedence and results in the packets not being sent.
Relax the condition
On Mon, 01 Oct 2018 09:08:32 +0200
"Eelco Chaudron" wrote:
> On 10 Aug 2018, at 16:48, Eelco Chaudron wrote:
>
> > On 10 Aug 2018, at 16:44, Stephen Hemminger wrote:
> >
> >> On Fri, 10 Aug 2018 07:59:30 -0400
> >> Eelco Chaudron wrote:
> >>
> >>> + if (bs.bytes >= bs_hw.bytes &&
On Mon, Oct 1, 2018 at 12:24 PM Jiri Pirko wrote:
>
> Mon, Oct 01, 2018 at 06:04:08AM CEST, vasundhara-v.vo...@broadcom.com wrote:
> >On Sat, Sep 29, 2018 at 6:27 PM Jiri Pirko wrote:
> >>
> >> Fri, Sep 28, 2018 at 08:28:23AM CEST, vasundhara-v.vo...@broadcom.com
> >> wrote:
> >> >This patch
On Sat, 29 Sep 2018 14:28:01 +0300 Ilias Apalodimas
wrote:
> +static void *netsec_alloc_rx_data(struct netsec_priv *priv,
> + dma_addr_t *dma_handle, u16 *desc_len)
> +{
> + size_t len = priv->ndev->mtu + ETH_HLEN + 2 * VLAN_HLEN + NET_SKB_PAD +
> +
Services currently have to be VRF-aware if they are using an unbound
socket. One cannot have multiple service instances running in the
default and other VRFs for services that are not VRF-aware and listen
on an unbound socket. This is because there is no way of isolating
packets received in the
Add a sysctl raw_l3mdev_accept to control raw socket lookup in a manner
similar to use of tcp_l3mdev_accept for stream and of udp_l3mdev_accept
for datagram sockets. Have this default to off as this is what users
expect, given that there is no explicit mechanism to set unmodified
VRF-unaware
From: Dewi Morgan
For bound udp sockets in a vrf, also check the sdif to get the index
for ingress devices enslaved to an l3mdev.
Signed-off-by: Dewi Morgan
Signed-off-by: Mike Manning
---
net/ipv6/udp.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git
From: Duncan Eastoe
When there exist a pair of raw sockets one unbound and one bound
to a VRF but equal in all other respects, when a packet is received
in the VRF context, __raw_v4_lookup() matches on both sockets.
This results in the packet being delivered over both sockets,
instead of only
The commit a04a480d4392 ("net: Require exact match for TCP socket
lookups if dif is l3mdev") only ensures that the correct socket is
selected for packets in a VRF. However, there is no guarantee that
the unbound socket will be selected for packets when not in a VRF.
By checking for a device match
From: Duncan Eastoe
If setsockopt(IP_MULTICAST_IF) or setsockopt(IPV6_MULTICAST_IF) is
called on a socket which is not bound to a VRF then we should ensure
that the output device chosen is also not bound to a VRF master.
This avoids inadvertently sending traffic out of the wrong interface.
This
If the skb for multicast packets marked as enslaved to a VRF are
received, then the secondary device index should be used to obtain
the real device. And verify the multicast address against the
enslaved rather than the l3mdev device.
Signed-off-by: Dewi Morgan
Signed-off-by: Mike Manning
---
Ensure an unbound datagram skt is chosen when not in a VRF. The check
for a device match in compute_score() for UDP must be performed when
there is no device match. For this, a failure is returned when there is
no device match. This ensures that bound sockets are never selected,
even if there is
From: Robert Shearman
There is no easy way currently for applications that want to receive
packets in the default VRF to be isolated from packets arriving in
VRFs, which makes using VRF-unaware applications in a VRF-aware system
a potential security risk.
So change the inet socket lookup to
If link-local packets are marked as enslaved to a VRF, then to allow
ping to the link-local from a vrf, the error handling for IPV6_PKTINFO
needs to be relaxed to also allow the pkt ipi6_ifindex to be that of a
slave device to the vrf.
Note that the real device also needs to be retrieved in
The skb for packets that are multicast or to a link-local address are
not marked as being enslaved to a VRF, if they are received on a socket
bound to the VRF. This is needed for ND and it is preferable for the
kernel not to have to deal with the additional use-cases if ll or mcast
packets are
On Mon, Oct 01, 2018 at 11:26:31AM +0200, Jesper Dangaard Brouer wrote:
>
> On Sat, 29 Sep 2018 14:28:01 +0300 Ilias Apalodimas
> wrote:
>
> > +static void *netsec_alloc_rx_data(struct netsec_priv *priv,
> > + dma_addr_t *dma_handle, u16 *desc_len)
> > +{
> > +
From: Thadeu Lima de Souza Cascardo
After commit d6990976af7c5d8f55903bfb4289b6fb030bf754 ("vti6: fix PMTU caching
and reporting on xmit"), some too big skbs might be potentially passed down to
__xfrm6_output, causing it to fail to transmit but not free the skb, causing a
leak of skb, and
From: Sowmini Varadhan
We only support one offloaded xfrm (we do not have devices that
can handle more than one offload), so reset crypto_done in
xfrm_input() when iterating over multiple transforms in xfrm_input,
so that we can invoke the appropriate x->type->input for the
non-offloaded
Since commit 222d7dbd258d ("net: prevent dst uses after free")
skb_dst_force() might clear the dst_entry attached to the skb.
The xfrm code don't expect this to happen, so we crash with
a NULL pointer dereference in this case. Fix it by checking
skb_dst(skb) for NULL after skb_dst_force() and drop
From: Sowmini Varadhan
A policy may have been set up with multiple transforms (e.g., ESP
and ipcomp). In this situation, the ingress IPsec processing
iterates in xfrm_input() and applies each transform in turn,
processing the nexthdr to find any additional xfrm that may apply.
This patch resets
1) Validate address prefix lengths in the xfrm selector,
otherwise we may hit undefined behaviour in the
address matching functions if the prefix is too
big for the given address family.
2) Fix skb leak on local message size errors.
From Thadeu Lima de Souza Cascardo.
3) We currently
We don't validate the address prefix lengths in the xfrm
selector we got from userspace. This can lead to undefined
behaviour in the address matching functions if the prefix
is too big for the given address family. Fix this by checking
the prefixes and refuse SA/policy insertation when a prefix
is
From: Sean Tranchetti
XFRM mode parameters passed as part of the user templates
in the IP_XFRM_POLICY are never properly validated. Passing
values other than valid XFRM modes can cause stack-out-of-bounds
reads to occur later in the XFRM processing:
[ 140.535608]
team's ndo_add_slave() acquires 'team->lock' and later tries to open the
newly enslaved device via dev_open(). This emits a 'NETDEV_UP' event
that causes the VLAN driver to add VLAN 0 on the team device. team's
ndo_vlan_rx_add_vid() will also try to acquire 'team->lock' and
deadlock.
Fix this by
Hi, TI experts
During work with rapidio and ethernet driver, we have faced ingress
and egress queue descriptors starvation.
Obvious things were to find which queues were under pressure. Existing
interface knav_queue in debugfs can help debug starvation issue by a
periodic process which cat
> > #2: You have allocations on the XDP fast-path.
> >
> > The REAL secret behind the XDP performance is to avoid allocations on
> > the fast-path. While I just told you to use the page-allocator and
> > order-0 pages, this will actually kill performance. Thus, to make this
> > fast, you need a
On 10/1/18 6:44 AM, Mauricio Faria de Oliveira wrote:
>> I suspect rtnl_fdb_dump is forever stuck with the ifinfomsg struct as
>> the header if any kernel side filtering is to be done. [snip]
>
> Why exactly? I understand currently there may be little information
> to distinguish family
On 9/30/18 12:44 AM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski
>
> (the parameter in question is mark)
>
> Signed-off-by: Maciej Żenczykowski
> ---
> include/net/ip6_route.h | 3 +--
> net/ipv6/ndisc.c| 2 +-
> net/ipv6/route.c| 4 +---
> 3 files changed, 3
On 9/30/18 12:44 AM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski
>
> (allows for better compiler optimization)
>
> Signed-off-by: Maciej Żenczykowski
> ---
> net/ipv6/route.c | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
Reviewed-by: David Ahern
On 9/30/18 12:44 AM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski
>
> (allows for better compiler optimization)
>
> Signed-off-by: Maciej Żenczykowski
> ---
> net/ipv6/route.c | 32
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
Reviewed-by:
On Mon, Oct 1, 2018 at 12:01 PM David Ahern wrote:
>
> On 10/1/18 6:44 AM, Mauricio Faria de Oliveira wrote:
> >> I suspect rtnl_fdb_dump is forever stuck with the ifinfomsg struct as
> >> the header if any kernel side filtering is to be done. [snip]
> >
> > Why exactly? I understand currently
On Wed, Sep 26, 2018 at 10:23 AM Roopa Prabhu wrote:
>
> On Tue, Sep 25, 2018 at 2:34 AM, Patrick Ruddy
> wrote:
> > On Wed, 2018-09-19 at 21:47 -0700, David Ahern wrote:
> >> On 9/18/18 6:12 AM, Patrick Ruddy wrote:
> >> >
> >> > I've hit a small snag with adding the new groups. The number of
On Mon, 1 Oct 2018 17:37:06 +0300
Ilias Apalodimas wrote:
> On Mon, Oct 01, 2018 at 03:48:45PM +0200, Jesper Dangaard Brouer wrote:
> > On Mon, 1 Oct 2018 14:20:21 +0300
> > Ilias Apalodimas wrote:
> >
> > > On Mon, Oct 01, 2018 at 01:03:13PM +0200, Jesper Dangaard Brouer wrote:
> > > > On
On Mon, Oct 1, 2018 at 6:40 AM Herbert Xu wrote:
>
> On Mon, Oct 01, 2018 at 06:16:27AM -0700, Eric Dumazet wrote:
> > syszbot found an interesting use-after-free [1] happening
> > while IPv4 fragment rhashtable was destroyed at netns dismantle.
> >
> > While no insertions can possibly happen at
On 9/30/18 12:44 AM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski
>
> (allows for better compiler optimization)
>
> Signed-off-by: Maciej Żenczykowski
> ---
> net/ipv4/route.c | 21 +
> 1 file changed, 9 insertions(+), 12 deletions(-)
>
Reviewed-by: David Ahern
On 9/30/18 12:44 AM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski
>
> (allows for better compiler optimization)
>
> Signed-off-by: Maciej Żenczykowski
> ---
> net/ipv6/route.c | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
Reviewed-by: David Ahern
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Sergei Shtylyov
> Sent: Friday, September 28, 2018 2:02 AM
> To: Kirsher, Jeffrey T ; da...@davemloft.net
> Cc: Keller, Jacob E ; netdev@vger.kernel.org;
> nhor...@redhat.com;
On 10/1/18 4:29 AM, Eelco Chaudron wrote:
>>> Hi Stephen, anything else required for this patch to be accepted?
>>>
>>> FYI the kernel side of this patch has been excepted on net-next.
>>>
>>> Cheers,
>>>
>>> Eelco
>>
>> David Ahern handles net-next see patchwork
>>
On 9/30/18 12:44 AM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski
>
> (allows for better compiler optimization)
>
> Signed-off-by: Maciej Żenczykowski
> ---
> net/ipv6/route.c | 19 +--
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
Reviewed-by: David Ahern
On 9/30/18 12:44 AM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski
>
> Signed-off-by: Maciej Żenczykowski
> ---
> net/ipv6/route.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
Reviewed-by: David Ahern
On 9/30/18 12:44 AM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski
>
> Signed-off-by: Maciej Żenczykowski
> ---
> net/ipv4/route.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
Reviewed-by: David Ahern
On 9/30/18 12:44 AM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski
>
> (allows for better compiler optimization)
>
> Signed-off-by: Maciej Żenczykowski
> ---
> net/ipv6/route.c | 23 ---
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
Reviewed-by: David
On Mon, Oct 1, 2018 at 3:18 PM Yuchung Cheng wrote:
> Hi David: thanks for taking this patch - I didn't notice this earlier
> but it seems patch v1 was applied instead of v2? should I submit a
> v2-v1-diff patch?
Yes, please, send an additional patch.
From: Saeed Mahameed
Date: Mon, 1 Oct 2018 11:56:48 -0700
> The following pull request includes updates to mlx5e ethernet netdevice
> driver, for more information please see tag log below.
>
> Please pull and let me know if there's any problem.
Pulled, thank you.
On 10/1/18 2:41 AM, Mike Manning wrote:
> From: Patrick Ruddy
>
> The code to obtain the correct table for the incoming interface was
> missing for IPv6. This has been added along with the table creation
> notification to fib rules for the RTNL_FAMILY_IP6MR address family.
>
> Signed-off-by:
Currently, rtnl_fdb_dump() assumes the family header is 'struct ifinfomsg',
which is not always true -- 'struct ndmsg' is used by iproute2 ('ip neigh').
The problem is, the function bails out early if nlmsg_parse() fails, which
does occur for iproute2 usage of 'struct ndmsg' because the payload
From: Yuchung Cheng
Date: Mon, 1 Oct 2018 15:42:32 -0700
> Previously receiver buffer auto-tuning starts after receiving
> one advertised window amount of data. After the initial receiver
> buffer was raised by patch a337531b942b ("tcp: up initial rmem to
> 128KB and SYN rwin to around 64KB"),
On 9/28/18, 6:21 PM, "Linux-aspeed on behalf of Vijay Khemka"
wrote:
> On 9/28/18, 6:07 PM, "Vijay Khemka" wrote:
> This patch adds OEM commands and response handling. It also defines OEM
> command and response structure as per NCSI specification along with
On 10/1/18 2:40 AM, Mike Manning wrote:
> From: Robert Shearman
>
> It is useful to be able to use the same socket for listening in a
> specific VRF, as for sending multicast packets out of a specific
> interface. However, the bound device on the socket currently takes
> precedence and results
On Mon, Oct 1, 2018 at 5:58 PM Herbert Xu wrote:
> The walk interface was designed to handle read-only iteration
> through the hash table. While this probably works since the
> actual freeing is delayed by RCU, it seems to be rather fragile.
>
> How about using the dead flag but instead of
From: Eric Dumazet
Date: Mon, 1 Oct 2018 15:02:26 -0700
> In normal SYN processing, packets are handled without listener
> lock and in RCU protected ingress path.
>
> But syzkaller is known to be able to trick us and SYN
> packets might be processed in process context, after being
> queued
Previously receiver buffer auto-tuning starts after receiving
one advertised window amount of data. After the initial receiver
buffer was raised by patch a337531b942b ("tcp: up initial rmem to
128KB and SYN rwin to around 64KB"), the reciver buffer may take
too long to start raising. To address
On Sun, Sep 30, 2018 at 11:41:00AM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 9/30/2018 12:04 AM, Andrew Lunn wrote:
>
> >The macro PHY_GBIT_FEAUTRES needs to change into a bitmap in order to
> >support link_modes. Remove its use from xgde by replacing it with its
> >definition.
> >
>
From: David Ahern
Implement kernel side filtering of routes by table id, egress device index,
protocol, tos, scope, and route type.
Signed-off-by: David Ahern
---
include/net/ip_fib.h| 2 +-
net/ipv4/fib_frontend.c | 13 -
net/ipv4/fib_trie.c | 33
From: David Ahern
Pass extack to dump callbacks by adding extack to netlink_dump_control,
transferring to netlink_callback and adding to the netlink_dump. Update
rtnetlink as the first user. Update netlink_dump to add any message after
the dump_done_errno.
Signed-off-by: David Ahern
---
From: David Ahern
Update inet_netconf_dump_devconf, inet6_netconf_dump_devconf, and
mpls_netconf_dump_devconf to check for NLM_F_DUMP_PROPER_HDR in the
netlink message header. If the flag is set, the dump request is
expected to have an netconfmsg struct as the header. The struct
only has the
From: David Ahern
There are many use cases where a user wants to influence what is
returned in a dump for some rtnetlink command: one is wanting data
for a different namespace than the one the request is received and
another is limiting the amount of data returned in the dump to a
specific set
From: David Ahern
Update br_mdb_dump to check for NLM_F_DUMP_PROPER_HDR in the netlink
message header. If the flag is set, the dump request is expected to have
a br_port_msg struct as the header. All elements of the struct are
expected to be 0 and no attributes can be appended.
Signed-off-by:
From: David Ahern
Update ip6addrlbl_dump to check for NLM_F_DUMP_PROPER_HDR in the netlink
message header. If the flag is set, the dump request is expected to have
an ifaddrlblmsg struct as the header. All elements of the struct are
expected to be 0 and no attributes can be appended.
From: David Ahern
Update rtnl_bridge_getlink to check for NLM_F_DUMP_PROPER_HDR in the netlink
message header. If the flag is set, the dump request is expected to have
an ifinfomsg struct as the header potentially followed by one or more
attributes. Any data passed in the header or as an
From: David Ahern
Update neigh_dump_info to check for NLM_F_DUMP_PROPER_HDR in the netlink
message header. If the flag is set, the dump request is expected to have
an ndmsg struct as the header potentially followed by one or more
attributes. Any data passed in the header or as an attribute is
From: David Ahern
Update inet6_dump_ifinfo to check for NLM_F_DUMP_PROPER_HDR in the netlink
message header. If the flag is set, the dump request is expected to have
an ifinfomsg struct as the header. All elements of the struct are
expected to be 0 and no attributes can be appended.
From: David Ahern
Add a new flag, NLM_F_DUMP_PROPER_HDR, for userspace to indicate to the
kernel that it believes it is sending the right header struct for the
dump message type (ifinfomsg, ifaddrmsg, rtmsg, fib_rule_hdr, ...).
Setting the flag in the netlink message header indicates to the
From: David Ahern
Pull the inet6_fill_args arg up to in6_dump_addrs and move netnsid
into it. Since IFA_TARGET_NETNSID is a kernel side filter add the
NLM_F_DUMP_FILTERED flag so userspace knows the request was honored.
Signed-off-by: David Ahern
Acked-by: Christian Brauner
---
From: David Ahern
Update neightbl_dump_info to check for NLM_F_DUMP_PROPER_HDR in the netlink
message header. If the flag is set, the dump request is expected to have
an ndtmsg struct as the header. All elements of the struct are expected to
be 0 and no attributes can be appended.
From: David Ahern
Update rtnl_stats_dump to check for NLM_F_DUMP_PROPER_HDR in the netlink
message header. If the flag is set, the dump request is expected to have
an if_stats_msg struct as the header. All elements of the struct are
expected to be 0 except filter_mask which must be non-0 (legacy
From: David Ahern
Update inet6_dump_addr to check for NLM_F_DUMP_PROPER_HDR in the netlink
message header. If the flag is set, the dump request is expected to have
an ifaddrmsg struct as the header potentially followed by one or more
attributes. Any data passed in the header or as an attribute
From: David Ahern
Update inet_dump_ifaddr to check for NLM_F_DUMP_PROPER_HDR in the netlink
message header. If the flag is set, the dump request is expected to have
an ifaddrmsg struct as the header potentially followed by one or more
attributes. Any data passed in the header or as an attribute
From: David Ahern
Add struct fib_dump_filter for options on limiting which routes are
dumped. The current list is table id, tos, protocol, scope, route type,
flags and nexthop device index.
This patch adds the struct and argument to ip_valid_fib_dump_req so
that per-protocol patches can be done
From: David Ahern
Update parsing of route dump request to enable kernel side of filtering.
Signed-off-by: David Ahern
---
net/ipv4/fib_frontend.c | 42 ++
1 file changed, 30 insertions(+), 12 deletions(-)
diff --git a/net/ipv4/fib_frontend.c
From: David Ahern
Add helper to check netlink message for route dumps. The dump request
is expected to have an rtmsg struct as the header. All elements of the
struct are expected to be 0 with the exception of rtm_flags (which is
used by both ipv4 and ipv6 dumps) and with no attributes can be
From: David Ahern
Move the attribute parsing from neigh_dump_table to neigh_dump_info, and
pass the filter arguments down to neigh_dump_table in a new struct. Add
the filter option to proxy neigh dumps as well to make the dumps consistent.
Signed-off-by: David Ahern
---
net/core/neighbour.c |
On Mon, Oct 01, 2018 at 10:58:21AM -0700, Eric Dumazet wrote:
>
> void inet_frags_exit_net(struct netns_frags *nf)
> {
> + struct rhashtable_iter hti;
> + struct inet_frag_queue *fq;
> +
> + /* Since we want to cleanup the hashtable, make sure that
> + * we wont trigger an
On Sat, Sep 29, 2018 at 11:23 AM, David Miller wrote:
>
> From: Yuchung Cheng
> Date: Fri, 28 Sep 2018 13:09:02 -0700
>
> > Previously TCP initial receive buffer is ~87KB by default and
> > the initial receive window is ~29KB (20 MSS). This patch changes
> > the two numbers to 128KB and ~64KB
On Mon, Oct 1, 2018 at 3:46 PM, David Miller wrote:
> From: Yuchung Cheng
> Date: Mon, 1 Oct 2018 15:42:32 -0700
>
>> Previously receiver buffer auto-tuning starts after receiving
>> one advertised window amount of data. After the initial receiver
>> buffer was raised by patch a337531b942b
On 9/29/18 8:48 PM, Roopa Prabhu wrote:
> From: Roopa Prabhu
>
> While at it also add missing text for proxy in the man page.
>
> Signed-off-by: Roopa Prabhu
> ---
> ip/ipneigh.c| 1 +
> man/man8/ip-neighbour.8 | 11 ++-
> 2 files changed, 11 insertions(+), 1 deletion(-)
On Fri, 2018-09-28 at 18:06 -0700, Vijay Khemka wrote:
> This patch adds OEM commands and response handling. It also defines OEM
> command and response structure as per NCSI specification along with its
> handlers.
>
> ncsi_cmd_handler_oem: This is a generic command request handler for OEM
>
On Mon, Oct 1, 2018 at 12:38 PM Mauricio Faria de Oliveira
wrote:
> Ok, thanks for your suggestions.
> I'll do some research/learning on them, and give it a try for a v2.
FYI, that is "[PATCH v2 net-next] rtnetlink: fix rtnl_fdb_dump() for
ndmsg header".
BTW, could please advise whether this
In normal SYN processing, packets are handled without listener
lock and in RCU protected ingress path.
But syzkaller is known to be able to trick us and SYN
packets might be processed in process context, after being
queued into socket backlog.
In commit 06f877d613be ("tcp/dccp: fix other lockdep
From: Jeff Kirsher
Date: Mon, 1 Oct 2018 14:14:23 -0700
> This series contains updates to ice driver only.
>
> Anirudh provides several changes to "prep" the driver for upcoming
> features. Specifically, the functions that are used for PF VSI/netdev
> setup will also be used in SR-IOV support
From: David Ahern
Implement kernel side filtering of routes by egress device index and
table id.
Signed-off-by: David Ahern
---
include/linux/mroute_base.h | 5 +++--
net/ipv4/ipmr.c | 2 +-
net/ipv4/ipmr_base.c| 42 +-
From: David Ahern
Update rtnl_dump_ifinfo to check for NLM_F_DUMP_PROPER_HDR in the netlink
message header. If the flag is set, the dump request is expected to have
an ifinfomsg struct as the header potentially followed by one or more
attributes. Any data passed in the header or as an attribute
From: David Ahern
Implement kernel side filtering of routes by egress device index and
protocol. MPLS uses only a single table and route type.
Signed-off-by: David Ahern
---
net/mpls/af_mpls.c | 55 +-
1 file changed, 54 insertions(+), 1
From: David Ahern
Implement kernel side filtering of routes by table id, egress device index,
protocol, and route type. Move the existing route flags check
for prefix only routes to the new filter.
Signed-off-by: David Ahern
---
net/ipv6/ip6_fib.c | 13 +
net/ipv6/route.c | 36
From: David Ahern
Update rtnl_net_dumpid to check for NLM_F_DUMP_PROPER_HDR in the netlink
message header. The dump request is expected to have an rtgenmsg struct
which has the family as the only element. No data may be appended.
Signed-off-by: David Ahern
---
net/core/net_namespace.c | 8
From: David Ahern
Update fib_nl_dumprule to check for NLM_F_DUMP_PROPER_HDR in the netlink
message header. If the flag is set, the dump request is expected to have
fib_rule_hdr struct as the header. All elements of the struct are
expected to be 0 and no attributes can be appended.
From: David Ahern
Update ipmr_rtm_dumplink to check for NLM_F_DUMP_PROPER_HDR in the netlink
message header. If the flag is set, the dump request is expected to have
an ifinfomsg struct as the header. All elements of the struct are
expected to be 0 and no attributes can be appended.
On Mon, Oct 01, 2018 at 08:11:43AM -0500, Mauricio Vasquez wrote:
> > > > +BPF_CALL_3(bpf_map_pop_elem, struct bpf_map *, map, void *,
> > > > value, u32, size)
> > > > +{
> > > > + void *ptr;
> > > > +
> > > > + if (map->value_size != size)
> > > > + return -EINVAL;
> > > > +
> > > >
Some apps may want to have higher MTU on the control vNIC/queue.
Allow them to set the requested MTU at init time.
Signed-off-by: Jakub Kicinski
---
drivers/net/ethernet/netronome/nfp/nfp_app.h | 4
.../net/ethernet/netronome/nfp/nfp_net_common.c| 14 --
2 files
Up until now we only had per-vNIC BPF ABI version capabilities,
which are slightly awkward to use because bulk of the resources
and configuration does not relate to any particular vNIC. Add
a new capability for global ABI version and check the per-vNIC
version are equal to it. Assume the ABI
In current ABI the size of the messages carrying map elements was
statically defined to at most 16 words of key and 16 words of value
(NFP word is 4 bytes). We should not make this assumption and use
the max key and value sizes from the BPF capability instead.
To make sure old kernels don't get
1 - 100 of 199 matches
Mail list logo
