* [net] udp: enable UDP checksum offload for ESP
From: Jacek Kalwas @ 2018-04-12 19:03 UTC (permalink / raw)
To: davem; +Cc: Jacek Kalwas, netdev, intel-wired-lan
In case NIC has support for ESP TX CSUM offload skb->ip_summed is not
set to CHECKSUM_PARTIAL which results in checksum calculated by SW.
Fix enables ESP TX CSUM for UDP by extending condition with check for
NETIF_F_HW_ESP_TX_CSUM.
Signed-off-by: Jacek Kalwas <jacek.kalwas@intel.com>
---
net/ipv4/ip_output.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 4c11b810a447..a2dfb5a9ba76 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -907,7 +907,7 @@ static int __ip_append_data(struct sock *sk,
length + fragheaderlen <= mtu &&
rt->dst.dev->features & (NETIF_F_HW_CSUM | NETIF_F_IP_CSUM) &&
!(flags & MSG_MORE) &&
- !exthdrlen)
+ (!exthdrlen || (rt->dst.dev->features & NETIF_F_HW_ESP_TX_CSUM)))
csummode = CHECKSUM_PARTIAL;
cork->length += length;
--
2.14.3
--------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.
^ permalink raw reply related
* [net] xfrm: allow to release xfrm_state with flush
From: Jacek Kalwas @ 2018-04-12 19:03 UTC (permalink / raw)
To: davem; +Cc: Jacek Kalwas, netdev, intel-wired-lan
In-Reply-To: <20180412190315.3102-1-jacek.kalwas@intel.com>
Call to flush SAs doesn't release xfrm_state in case there was a
traffic associated with that state and state was already deleted.
Given patch calls xfrm_policy_cache_flush despite of actual states
deleted in xfrm_state_flush function.
Signed-off-by: Jacek Kalwas <jacek.kalwas@intel.com>
---
net/xfrm/xfrm_state.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index f9d2f2233f09..7d3d6a12a14f 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -734,10 +734,10 @@ int xfrm_state_flush(struct net *net, u8 proto, bool task_valid)
}
out:
spin_unlock_bh(&net->xfrm.xfrm_state_lock);
- if (cnt) {
+ if (cnt)
err = 0;
- xfrm_policy_cache_flush();
- }
+
+ xfrm_policy_cache_flush();
return err;
}
EXPORT_SYMBOL(xfrm_state_flush);
--
2.14.3
--------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.
^ permalink raw reply related
* [net] xfrm: cover crypto status in xfrm_input
From: Jacek Kalwas @ 2018-04-12 19:03 UTC (permalink / raw)
To: davem; +Cc: Jacek Kalwas, netdev, intel-wired-lan
In-Reply-To: <20180412190315.3102-1-jacek.kalwas@intel.com>
Status checking in xfrm_input doesn't cover CRYPTO_GENERIC_ERROR and
CRYPTO_INVALID_PACKET_SYNTAX.
Given patch adds additional check for CRYPTO_INVALID_PACKET_SYNTAX and
treats CRYPTO_GENERIC_ERROR as status matching LINUX_MIB_XFRMINERROR.
Signed-off-by: Jacek Kalwas <jacek.kalwas@intel.com>
---
net/xfrm/xfrm_input.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index 352abca2605f..08d70ea774f9 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -285,7 +285,12 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
goto drop;
}
- XFRM_INC_STATS(net, LINUX_MIB_XFRMINBUFFERERROR);
+ if (xo->status & CRYPTO_INVALID_PACKET_SYNTAX) {
+ XFRM_INC_STATS(net, LINUX_MIB_XFRMINBUFFERERROR);
+ goto drop;
+ }
+
+ XFRM_INC_STATS(net, LINUX_MIB_XFRMINERROR);
goto drop;
}
--
2.14.3
--------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.
^ permalink raw reply related
* Re: [RFC net-next 1/2] net: net-porcfs: Reduce rcu lock critical section
From: Saeed Mahameed @ 2018-04-12 19:12 UTC (permalink / raw)
To: eric.dumazet@gmail.com, davem@davemloft.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <3e0f5494-3d5c-06e8-a5b2-12b735390629@gmail.com>
On Wed, 2018-04-11 at 19:59 -0700, Eric Dumazet wrote:
>
> On 04/11/2018 04:47 PM, Saeed Mahameed wrote:
> >
> > Well if we allow devices to access HW counters via FW command
> > interfaces in ndo_get_stats and by testing mlx5 where we query up
> > to 5
> > hw registers, it could take 100us, still this is way smaller than
> > 10sec
> > :) and it is really a nice rate to fetch HW stats on demand.
>
> If hardware stats are slower than software ones, maybe it is time to
> use software stats,
> instead of changing the whole stack ?
>
We already have SW stats for [rx/tx]_[packets/bytes] but for
[rx/tx]_[error/drop] etc .. they can only be grabbed from HW.
We don't want to report only partial counters to get_stats ndo just to
avoid sleeping.
> There are very few devices drivers having issues like that.
>
^ permalink raw reply
* [PATCH net-next] ipv6: provide Kconfig switch to disable accept_ra by default
From: Matthias Schiffer @ 2018-04-12 19:32 UTC (permalink / raw)
To: netdev; +Cc: davem, kuznet, yoshfuji, linux-kernel
Many distributions and users prefer to handle router advertisements in
userspace; one example is OpenWrt, which includes a combined RA and DHCPv6
client. For such configurations, accept_ra should not be enabled by
default.
As setting net.ipv6.conf.default.accept_ra via sysctl.conf or similar
facilities may be too late to catch all interfaces and common sysctl.conf
tools do not allow setting an option for all existing interfaces, this
patch provides a Kconfig option to control the default value of
default.accept_ra.
Using default.accept_ra is preferable to all.accept_ra for our usecase,
as disabling all.accept_ra would preclude users from explicitly enabling
accept_ra on individual interfaces.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
---
net/ipv6/Kconfig | 12 ++++++++++++
net/ipv6/addrconf.c | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/Kconfig b/net/ipv6/Kconfig
index 6794ddf0547c..0f453110f288 100644
--- a/net/ipv6/Kconfig
+++ b/net/ipv6/Kconfig
@@ -20,6 +20,18 @@ menuconfig IPV6
if IPV6
+config IPV6_ACCEPT_RA_DEFAULT
+ bool "IPv6: Accept router advertisements by default"
+ default y
+ help
+ The kernel can internally handle IPv6 router advertisements for
+ stateless address autoconfiguration (SLAAC) and route configuration,
+ which can be configured in detail and per-interface using a number of
+ sysctl options. This option controls the default value of
+ net.ipv6.conf.default.accept_ra.
+
+ If unsure, say Y.
+
config IPV6_ROUTER_PREF
bool "IPv6: Router Preference (RFC 4191) support"
---help---
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 78cef00c9596..ec066cd742db 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -245,7 +245,7 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
.forwarding = 0,
.hop_limit = IPV6_DEFAULT_HOPLIMIT,
.mtu6 = IPV6_MIN_MTU,
- .accept_ra = 1,
+ .accept_ra = IS_ENABLED(CONFIG_IPV6_ACCEPT_RA_DEFAULT),
.accept_redirects = 1,
.autoconf = 1,
.force_mld_version = 0,
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net-next] Per interface IPv4 stats (CONFIG_IP_IFSTATS_TABLE)
From: Julian Anastasov @ 2018-04-12 19:48 UTC (permalink / raw)
To: Stephen Suryaputra; +Cc: netdev
In-Reply-To: <CAHapkUg=XpRqL3y5nMAv+bR_dpCVgLY1Nj28Z1v86j=oM0y2mA@mail.gmail.com>
Hello,
On Thu, 12 Apr 2018, Stephen Suryaputra wrote:
> Thanks for the feedbacks. Please see the detail below:
>
> On Wed, Apr 11, 2018 at 3:37 PM, Julian Anastasov <ja@ssi.bg> wrote:
> [snip]
> >> - __IP_INC_STATS(net, IPSTATS_MIB_INHDRERRORS);
> >> + __IP_INC_STATS(net, skb_dst(skb)->dev, IPSTATS_MIB_INHDRERRORS);
> >
> > May be skb->dev if we want to account it to the
> > input device.
> >
> Yes. I'm about to make change it but see the next one.
>
> [snip]
> >> diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c
> >> index 4527921..32bd3af 100644
> >> --- a/net/netfilter/ipvs/ip_vs_xmit.c
> >> +++ b/net/netfilter/ipvs/ip_vs_xmit.c
> >> @@ -286,7 +286,7 @@ static inline bool decrement_ttl(struct netns_ipvs *ipvs,
> >> {
> >> if (ip_hdr(skb)->ttl <= 1) {
> >> /* Tell the sender its packet died... */
> >> - __IP_INC_STATS(net, IPSTATS_MIB_INHDRERRORS);
> >> + __IP_INC_STATS(net, skb_dst(skb)->dev, IPSTATS_MIB_INHDRERRORS);
> >
> > At this point, skb_dst(skb) can be:
> >
> > - input route at LOCAL_IN => dst->dev is "lo", skb->dev = input_device
> > - output route at LOCAL_OUT => dst->dev is output_device, skb->dev = NULL
> >
> > We should see this error on LOCAL_IN but better to be
> > safe: use 'skb->dev ? : skb_dst(skb)->dev' instead of just
> > 'skb_dst(skb)->dev'.
> >
> This follows v6 implementation in the same function:
>
> #ifdef CONFIG_IP_VS_IPV6
> if (skb_af == AF_INET6) {
> struct dst_entry *dst = skb_dst(skb);
>
> /* check and decrement ttl */
> if (ipv6_hdr(skb)->hop_limit <= 1) {
> /* Force OUTPUT device used as source address */
It looks like IPVS copied it from ip6_forward() but in
IPVS context it has its reason: we want ICMP to exit with
saddr=Virtual_IP. And we are at LOCAL_IN where there is no
output device like in ip6_forward(FORWARD) to use its source
address.
So, IPVS is special (both input and output path) and needs:
IPv4: skb->dev ? : skb_dst(skb)->dev
IPv6 needs fix for IPVS stats in decrement_ttl:
idev = skb->dev ? __in6_dev_get(skb->dev) : ip6_dst_idev(dst);
...
__IP6_INC_STATS(net, idev, IPSTATS_MIB_INHDRERRORS);
Otherwise, stats will go to "lo" if ip6_dst_idev
is used for local input route.
So, for accounting on input IPv4 path skb->dev should be
used, while for IPv6 some sites may prefer to feed icmpv6_send()
with output dst->dev as device containing the source address (skb->dev).
But this is unrelated to the stats.
> skb->dev = dst->dev;
> icmpv6_send(skb, ICMPV6_TIME_EXCEED,
> ICMPV6_EXC_HOPLIMIT, 0);
> __IP6_INC_STATS(net, ip6_dst_idev(dst),
> IPSTATS_MIB_INHDRERRORS);
>
> return false;
> }
>
> /* don't propagate ttl change to cloned packets */
> if (!skb_make_writable(skb, sizeof(struct ipv6hdr)))
> return false;
>
> ipv6_hdr(skb)->hop_limit--;
> } else
> #endif
>
> [snip]
> >
> > The patch probably has other errors, for example,
> > using rt->dst.dev (lo) when rt->dst.error != 0 in ip_error,
> > may be 'dev' should be used instead...
>
> Same also here. Examples are ip6_forward and ip6_pkt_drop.
>
> I think it's better be counted in the input device for them also. Thoughts?
I think so. ipv6_rcv() works with idev = __in6_dev_get(skb->dev)
but I don't know IPv6 well and whether ip6_dst_idev(skb_dst(skb))
is correct usage for input path. It should be correct for output
path, though.
Regards
^ permalink raw reply
* Re: [PATCH] net: ethernet: ti: cpsw: fix tx vlan priority mapping
From: Grygorii Strashko @ 2018-04-12 20:15 UTC (permalink / raw)
To: Ivan Khoronzhuk; +Cc: davem, linux-omap, netdev, linux-kernel
In-Reply-To: <1523543140-20747-1-git-send-email-ivan.khoronzhuk@linaro.org>
On 04/12/2018 09:25 AM, Ivan Khoronzhuk wrote:
> The CPDMA_TX_PRIORITY_MAP in real is vlan pcp field priority mapping
> register and basically replaces vlan pcp field for tagged packets.
> So, set it to be 1:1 mapping.
"Otherwise, it will cause unexpected change of egress vlan tagged packets,
like prio 2 -> prio 5"
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> ---
> Based on net/master
Fixes: e05 107 e6b 747 ("net: ethernet: ti: cpsw: add multi queue support")
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
>
> drivers/net/ethernet/ti/cpsw.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index 3037127..74f8284 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -129,7 +129,7 @@ do { \
>
> #define RX_PRIORITY_MAPPING 0x76543210
> #define TX_PRIORITY_MAPPING 0x33221100
> -#define CPDMA_TX_PRIORITY_MAP 0x01234567
> +#define CPDMA_TX_PRIORITY_MAP 0x76543210
>
> #define CPSW_VLAN_AWARE BIT(1)
> #define CPSW_RX_VLAN_ENCAP BIT(2)
>
--
regards,
-grygorii
^ permalink raw reply
* Re: SRIOV switchdev mode BoF minutes
From: Or Gerlitz @ 2018-04-12 20:20 UTC (permalink / raw)
To: Samudrala, Sridhar
Cc: David Miller, Anjali Singhai Jain, Andy Gospodarek, Michael Chan,
Simon Horman, Jakub Kicinski, John Fastabend, Saeed Mahameed,
Jiri Pirko, Rony Efraim, Linux Netdev List
In-Reply-To: <64cca3cd-5592-8210-54c4-ed28c284ae5d@intel.com>
On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar
<sridhar.samudrala@intel.com> wrote:
> On 11/12/2017 11:49 AM, Or Gerlitz wrote:
>>
>> Hi Dave and all,
>>
>> During and after the BoF on SRIOV switchdev mode, we came into a
>> consensus among the developers from four different HW vendors (CC
>> audience) that a correct thing to do would be to disallow any new
>> extensions to the legacy mode.
>>
>> The idea is to put focus on the new mode and not add new UAPIs and
>> kernel code which was turned to be a wrong design which does not allow
>> for properly offloading a kernel switching SW model to e-switch HW.
>>
>> We also had a good session the day after regarding alignment for the
>> representation model of the uplink (physical port) and PF/s.
>>
>> The VF representor netdevs exist for all drivers that support the new
>> mode but the representation for the uplink and PF wasn't the same for
>> all. The decision was to represent the uplink and PFs vports in the
>> same manner done for VFs, using rep netdevs. This alignment would
>> provide a more strict and clear view of the kernel model for e-switch
>> to users and upper layer control plane SW.
>>
> I don't see any changes in the Mellanox/other drivers to move to this new
> model to enable the uplink and PF port representors, any updates?
Yeah, I am worked on that but didn't get to finalize the upstreaming
so far. I have resumed
the work and plan uplink rep in mlx5 to replace the PF being uplink rep for 4.18
> It would be really nice to highlight the pros and cons of the old versus the
> new model.
>
> We are looking into adding switchdev support for our new 100Gb ice driver
> and could use some feedback on the direction we should be taking.
good news.
The uplink rep is clear cut that needs to be a rep device representing
the uplink just like vf
rep represents the vport toward the vf - please just do it correct
from the begining
I can spare
^ permalink raw reply
* Re: SRIOV switchdev mode BoF minutes
From: Samudrala, Sridhar @ 2018-04-12 20:33 UTC (permalink / raw)
To: Or Gerlitz
Cc: David Miller, Anjali Singhai Jain, Andy Gospodarek, Michael Chan,
Simon Horman, Jakub Kicinski, John Fastabend, Saeed Mahameed,
Jiri Pirko, Rony Efraim, Linux Netdev List
In-Reply-To: <CAJ3xEMiP2my8gP+VsvGAFv9Zj=qk2iTr+BYbd=VEtRFwrG_2JA@mail.gmail.com>
On 4/12/2018 1:20 PM, Or Gerlitz wrote:
> On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar
> <sridhar.samudrala@intel.com> wrote:
>> On 11/12/2017 11:49 AM, Or Gerlitz wrote:
>>> Hi Dave and all,
>>>
>>> During and after the BoF on SRIOV switchdev mode, we came into a
>>> consensus among the developers from four different HW vendors (CC
>>> audience) that a correct thing to do would be to disallow any new
>>> extensions to the legacy mode.
>>>
>>> The idea is to put focus on the new mode and not add new UAPIs and
>>> kernel code which was turned to be a wrong design which does not allow
>>> for properly offloading a kernel switching SW model to e-switch HW.
>>>
>>> We also had a good session the day after regarding alignment for the
>>> representation model of the uplink (physical port) and PF/s.
>>>
>>> The VF representor netdevs exist for all drivers that support the new
>>> mode but the representation for the uplink and PF wasn't the same for
>>> all. The decision was to represent the uplink and PFs vports in the
>>> same manner done for VFs, using rep netdevs. This alignment would
>>> provide a more strict and clear view of the kernel model for e-switch
>>> to users and upper layer control plane SW.
>>>
>> I don't see any changes in the Mellanox/other drivers to move to this new
>> model to enable the uplink and PF port representors, any updates?
> Yeah, I am worked on that but didn't get to finalize the upstreaming
> so far. I have resumed
> the work and plan uplink rep in mlx5 to replace the PF being uplink rep for 4.18
>
>> It would be really nice to highlight the pros and cons of the old versus the
>> new model.
>>
>> We are looking into adding switchdev support for our new 100Gb ice driver
>> and could use some feedback on the direction we should be taking.
> good news.
>
> The uplink rep is clear cut that needs to be a rep device representing
> the uplink just like vf
> rep represents the vport toward the vf - please just do it correct
> from the begining
>
Having an uplink rep will definitely help implement the slow path with flat/vlan network
scenarios by not having to add PF to the bridge.
But how do they help with a vxlan overlay scenario? In case of overlays, the slow path
has to go via vxlan -> ip stack -> pf?
What about pf-rep?
^ permalink raw reply
* Re: linux-next on x60: network manager often complains "network is disabled" after resume
From: Pavel Machek @ 2018-04-12 21:09 UTC (permalink / raw)
To: Dan Williams
Cc: Woody Suwalski, Rafael J. Wysocki, kernel list,
Linux-pm mailing list, Netdev list
In-Reply-To: <20180319173356.GA28462@amd>
[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]
On Mon 2018-03-19 18:33:56, Pavel Machek wrote:
> On Mon 2018-03-19 10:40:08, Dan Williams wrote:
> > On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:
> > > On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
> > > > Pavel Machek wrote:
> > > > > Hi!
> > > > >
> > > > > With recent linux-next, after resume networkmanager often claims
> > > > > that
> > > > > "network is disabled". Sometimes suspend/resume clears that.
> > > > >
> > > > > Any ideas? Does it work for you?
> > > > >
> > > > > Pavel
> > > >
> > > > Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
> > >
> > > Thanks for testing... but yes, 4.16 should be ok. If not fixed,
> > > problem will appear in 4.17-rc1.
> >
> > Where does the complaint occur? In the GUI, or with nmcli, or
> > somewhere else? Also, what's the output of "nmcli dev" after resume?
>
> In the GUI. I click in place where I'd select access point, and menu
> does not show up, telling me that "network is disabled".
Ouch and the bug now crept to mainline.. and it happens on X220,
too. With ethernet, bug is harder to see, because "network is
disabled" and "no network" icon is there, but ethernet still works.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] net/mlx5: remove some extraneous spaces in indentations
From: Saeed Mahameed @ 2018-04-12 22:39 UTC (permalink / raw)
To: colin.king@canonical.com, Matan Barak, linux-rdma@vger.kernel.org,
netdev@vger.kernel.org, leon@kernel.org
Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <20180409124336.29274-1-colin.king@canonical.com>
On Mon, 2018-04-09 at 13:43 +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There are several lines where there is an extraneous space causing
> indentation misalignment. Remove them.
>
> Cleans up Cocconelle warnings:
>
> ./drivers/net/ethernet/mellanox/mlx5/core/qp.c:409:3-18: code aligned
> with following code on line 410
> ./drivers/net/ethernet/mellanox/mlx5/core/qp.c:415:3-18: code aligned
> with following code on line 416
> ./drivers/net/ethernet/mellanox/mlx5/core/qp.c:421:3-18: code aligned
> with following code on line 422
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>
Applied to mlx5-next, Thanks Colin!
^ permalink raw reply
* [PATCH ipsec-next] selftests: add xfrm state-policy-monitor to rtnetlink.sh
From: Shannon Nelson @ 2018-04-12 22:59 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev
Add a simple set of tests for the IPsec xfrm commands.
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
---
tools/testing/selftests/net/rtnetlink.sh | 103 +++++++++++++++++++++++++++++++
1 file changed, 103 insertions(+)
diff --git a/tools/testing/selftests/net/rtnetlink.sh b/tools/testing/selftests/net/rtnetlink.sh
index e6f4852..760faef 100755
--- a/tools/testing/selftests/net/rtnetlink.sh
+++ b/tools/testing/selftests/net/rtnetlink.sh
@@ -502,6 +502,108 @@ kci_test_macsec()
echo "PASS: macsec"
}
+#-------------------------------------------------------------------
+# Example commands
+# ip x s add proto esp src 14.0.0.52 dst 14.0.0.70 \
+# spi 0x07 mode transport reqid 0x07 replay-window 32 \
+# aead 'rfc4106(gcm(aes))' 1234567890123456dcba 128 \
+# sel src 14.0.0.52/24 dst 14.0.0.70/24
+# ip x p add dir out src 14.0.0.52/24 dst 14.0.0.70/24 \
+# tmpl proto esp src 14.0.0.52 dst 14.0.0.70 \
+# spi 0x07 mode transport reqid 0x07
+#
+# Subcommands not tested
+# ip x s update
+# ip x s allocspi
+# ip x s deleteall
+# ip x p update
+# ip x p deleteall
+# ip x p set
+#-------------------------------------------------------------------
+kci_test_ipsec()
+{
+ srcip="14.0.0.52"
+ dstip="14.0.0.70"
+ algo="aead rfc4106(gcm(aes)) 0x3132333435363738393031323334353664636261 128"
+
+ # flush to be sure there's nothing configured
+ ip x s flush ; ip x p flush
+ check_err $?
+
+ # start the monitor in the background
+ tmpfile=`mktemp ipsectestXXX`
+ ip x m > $tmpfile &
+ mpid=$!
+ sleep 0.2
+
+ ipsecid="proto esp src $srcip dst $dstip spi 0x07"
+ ip x s add $ipsecid \
+ mode transport reqid 0x07 replay-window 32 \
+ $algo sel src $srcip/24 dst $dstip/24
+ check_err $?
+
+ lines=`ip x s list | grep $srcip | grep $dstip | wc -l`
+ test $lines -eq 2
+ check_err $?
+
+ ip x s count | grep -q "SAD count 1"
+ check_err $?
+
+ lines=`ip x s get $ipsecid | grep $srcip | grep $dstip | wc -l`
+ test $lines -eq 2
+ check_err $?
+
+ ip x s delete $ipsecid
+ check_err $?
+
+ lines=`ip x s list | wc -l`
+ test $lines -eq 0
+ check_err $?
+
+ ipsecsel="dir out src $srcip/24 dst $dstip/24"
+ ip x p add $ipsecsel \
+ tmpl proto esp src $srcip dst $dstip \
+ spi 0x07 mode transport reqid 0x07
+ check_err $?
+
+ lines=`ip x p list | grep $srcip | grep $dstip | wc -l`
+ test $lines -eq 2
+ check_err $?
+
+ ip x p count | grep -q "SPD IN 0 OUT 1 FWD 0"
+ check_err $?
+
+ lines=`ip x p get $ipsecsel | grep $srcip | grep $dstip | wc -l`
+ test $lines -eq 2
+ check_err $?
+
+ ip x p delete $ipsecsel
+ check_err $?
+
+ lines=`ip x p list | wc -l`
+ test $lines -eq 0
+ check_err $?
+
+ # check the monitor results
+ kill $mpid
+ lines=`wc -l $tmpfile | cut "-d " -f1`
+ test $lines -eq 20
+ check_err $?
+ rm -rf $tmpfile
+
+ # clean up any leftovers
+ ip x s flush
+ check_err $?
+ ip x p flush
+ check_err $?
+
+ if [ $ret -ne 0 ]; then
+ echo "FAIL: ipsec"
+ return 1
+ fi
+ echo "PASS: ipsec"
+}
+
kci_test_gretap()
{
testns="testns"
@@ -755,6 +857,7 @@ kci_test_rtnl()
kci_test_vrf
kci_test_encap
kci_test_macsec
+ kci_test_ipsec
kci_del_dummy
}
--
2.7.4
^ permalink raw reply related
* Re: [RFC bpf-next v2 4/8] bpf: add documentation for eBPF helpers (23-32)
From: Alexei Starovoitov @ 2018-04-13 0:28 UTC (permalink / raw)
To: Quentin Monnet; +Cc: daniel, ast, netdev, oss-drivers, linux-doc, linux-man
In-Reply-To: <20180410144157.4831-5-quentin.monnet@netronome.com>
On Tue, Apr 10, 2018 at 03:41:53PM +0100, Quentin Monnet wrote:
> Add documentation for eBPF helper functions to bpf.h user header file.
> This documentation can be parsed with the Python script provided in
> another commit of the patch series, in order to provide a RST document
> that can later be converted into a man page.
>
> The objective is to make the documentation easily understandable and
> accessible to all eBPF developers, including beginners.
>
> This patch contains descriptions for the following helper functions, all
> written by Daniel:
>
> - bpf_get_prandom_u32()
> - bpf_get_smp_processor_id()
> - bpf_get_cgroup_classid()
> - bpf_get_route_realm()
> - bpf_skb_load_bytes()
> - bpf_csum_diff()
> - bpf_skb_get_tunnel_opt()
> - bpf_skb_set_tunnel_opt()
> - bpf_skb_change_proto()
> - bpf_skb_change_type()
>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
> ---
> include/uapi/linux/bpf.h | 125 +++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 125 insertions(+)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index f3ea8824efbc..d147d9dd6a83 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -473,6 +473,14 @@ union bpf_attr {
> * The number of bytes written to the buffer, or a negative error
> * in case of failure.
> *
> + * u32 bpf_prandom_u32(void)
> + * Return
> + * A random 32-bit unsigned value.
there is no such helper.
It's called bpf_get_prandom_u32().
I'd also add a note that it's using its own random state and cannot be
used to infer seed of other random functions in the kernel.
> + *
> + * u32 bpf_get_smp_processor_id(void)
> + * Return
> + * The SMP (Symmetric multiprocessing) processor id.
probably worth adding a note to explain that all bpf programs run
with preemption disabled, so processor id is stable for the run of the program.
> + *
> * int bpf_skb_store_bytes(struct sk_buff *skb, u32 offset, const void *from, u32 len, u64 flags)
> * Description
> * Store *len* bytes from address *from* into the packet
> @@ -604,6 +612,13 @@ union bpf_attr {
> * Return
> * 0 on success, or a negative error in case of failure.
> *
> + * u32 bpf_get_cgroup_classid(struct sk_buff *skb)
> + * Description
> + * Retrieve the classid for the current task, i.e. for the
> + * net_cls (network classifier) cgroup to which *skb* belongs.
please add that kernel should be configured with CONFIG_NET_CLS_CGROUP=y|m
and mention Documentation/cgroup-v1/net_cls.txt
Otherwise 'network classifier' is way too generic.
I'd also mention that placing a task into net_cls controller
disables all of cgroup-bpf.
> + * Return
> + * The classid, or 0 for the default unconfigured classid.
> + *
> * int bpf_skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci)
> * Description
> * Push a *vlan_tci* (VLAN tag control information) of protocol
> @@ -703,6 +718,14 @@ union bpf_attr {
> * are **TC_ACT_REDIRECT** on success or **TC_ACT_SHOT** on
> * error.
> *
> + * u32 bpf_get_route_realm(struct sk_buff *skb)
> + * Description
> + * Retrieve the realm or the route, that is to say the
> + * **tclassid** field of the destination for the *skb*.
Similarly this only works if CONFIG_IP_ROUTE_CLASSID is on.
> + * Return
> + * The realm of the route for the packet associated to *sdb*, or 0
> + * if none was found.
> + *
> * int bpf_perf_event_output(struct pt_reg *ctx, struct bpf_map *map, u64 flags, void *data, u64 size)
> * Description
> * Write perf raw sample into a perf event held by *map* of type
> @@ -779,6 +802,21 @@ union bpf_attr {
> * Return
> * 0 on success, or a negative error in case of failure.
> *
> + * int bpf_skb_load_bytes(const struct sk_buff *skb, u32 offset, void *to, u32 len)
> + * Description
> + * This helper was provided as an easy way to load data from a
> + * packet. It can be used to load *len* bytes from *offset* from
> + * the packet associated to *skb*, into the buffer pointed by
> + * *to*.
> + *
> + * Since Linux 4.7, this helper is deprecated in favor of
> + * "direct packet access", enabling packet data to be manipulated
> + * with *skb*\ **->data** and *skb*\ **->data_end** pointing
> + * respectively to the first byte of packet data and to the byte
> + * after the last byte of packet data.
I wouldn't call it deprecated.
It's still useful when programmer wants to read large quantities of
data from the packet
> + * Return
> + * 0 on success, or a negative error in case of failure.
> + *
> * int bpf_get_stackid(struct pt_reg *ctx, struct bpf_map *map, u64 flags)
> * Description
> * Walk a user or a kernel stack and return its id. To achieve
> @@ -814,6 +852,93 @@ union bpf_attr {
> * The positive or null stack id on success, or a negative error
> * in case of failure.
> *
> + * s64 bpf_csum_diff(__be32 *from, u32 from_size, __be32 *to, u32 to_size, __wsum seed)
> + * Description
> + * Compute a checksum difference, from the raw buffer pointed by
> + * *from*, of length *from_size* (that must be a multiple of 4),
> + * towards the raw buffer pointed by *to*, of size *to_size*
> + * (same remark). An optional *seed* can be added to the value.
> + *
> + * This is flexible enough to be used in several ways:
> + *
> + * * With *from_size* == 0, *to_size* > 0 and *seed* set to
> + * checksum, it can be used when pushing new data.
> + * * With *from_size* > 0, *to_size* == 0 and *seed* set to
> + * checksum, it can be used when removing data from a packet.
> + * * With *from_size* > 0, *to_size* > 0 and *seed* set to 0, it
> + * can be used to compute a diff. Note that *from_size* and
> + * *to_size* do not need to be equal.
> + * Return
> + * The checksum result, or a negative error code in case of
> + * failure.
> + *
> + * int bpf_skb_get_tunnel_opt(struct sk_buff *skb, u8 *opt, u32 size)
> + * Description
> + * Retrieve tunnel options metadata for the packet associated to
> + * *skb*, and store the raw tunnel option data to the buffer *opt*
> + * of *size*.
> + * Return
> + * The size of the option data retrieved.
> + *
> + * int bpf_skb_set_tunnel_opt(struct sk_buff *skb, u8 *opt, u32 size)
> + * Description
> + * Set tunnel options metadata for the packet associated to *skb*
> + * to the option data contained in the raw buffer *opt* of *size*.
> + * Return
> + * 0 on success, or a negative error in case of failure.
> + *
> + * int bpf_skb_change_proto(struct sk_buff *skb, __be16 proto, u64 flags)
> + * Description
> + * Change the protocol of the *skb* to *proto*. Currently
> + * supported are transition from IPv4 to IPv6, and from IPv6 to
> + * IPv4. The helper takes care of the groundwork for the
> + * transition, including resizing the socket buffer. The eBPF
> + * program is expected to fill the new headers, if any, via
> + * **skb_store_bytes**\ () and to recompute the checksums with
> + * **bpf_l3_csum_replace**\ () and **bpf_l4_csum_replace**\
> + * ().
> + *
> + * Internally, the GSO type is marked as dodgy so that headers are
> + * checked and segments are recalculated by the GSO/GRO engine.
> + * The size for GSO target is adapted as well.
> + *
> + * All values for *flags* are reserved for future usage, and must
> + * be left at zero.
> + *
> + * A call to this helper is susceptible to change data from the
> + * packet. Therefore, at load time, all checks on pointers
> + * previously done by the verifier are invalidated and must be
> + * performed again.
> + * Return
> + * 0 on success, or a negative error in case of failure.
> + *
> + * int bpf_skb_change_type(struct sk_buff *skb, u32 type)
> + * Description
> + * Change the packet type for the packet associated to *skb*. This
> + * comes down to setting *skb*\ **->pkt_type** to *type*, except
> + * the eBPF program does not have a write access to *skb*\
> + * **->pkt_type** beside this helper. Using a helper here allows
> + * for graceful handling of errors.
> + *
> + * The major use case is to change incoming *skb*s to
> + * **PACKET_HOST** in a programmatic way instead of having to
> + * recirculate via **redirect**\ (..., **BPF_F_INGRESS**), for
> + * example.
> + *
> + * Note that *type* only allows certain values. At this time, they
> + * are:
> + *
> + * **PACKET_HOST**
> + * Packet is for us.
> + * **PACKET_BROADCAST**
> + * Send packet to all.
> + * **PACKET_MULTICAST**
> + * Send packet to group.
> + * **PACKET_OTHERHOST**
> + * Send packet to someone else.
> + * Return
> + * 0 on success, or a negative error in case of failure.
> + *
> * u64 bpf_get_current_task(void)
> * Return
> * A pointer to the current task struct.
> --
> 2.14.1
>
^ permalink raw reply
* Re: [bpf PATCH 0/3] BPF, a couple sockmap fixes
From: Daniel Borkmann @ 2018-04-13 1:11 UTC (permalink / raw)
To: John Fastabend, ast; +Cc: netdev
In-Reply-To: <20180411235230.19135.63857.stgit@john-Precision-Tower-5810>
On 04/12/2018 01:56 AM, John Fastabend wrote:
> While testing sockmap with more programs (besides our test programs)
> I found a couple issues.
>
> The attached series fixes an issue where pinned maps were not
> working correctly, blocking sockets returned zero, and an error
> path that when the sock hit an out of memory case resulted in a
> double page_put() while doing ingress redirects.
>
> See individual patches for more details.
Applied to bpf tree, thanks John!
^ permalink raw reply
* Re: [PATCH] net/tls: Remove VLA usage
From: David Miller @ 2018-04-13 1:47 UTC (permalink / raw)
To: keescook; +Cc: davejwatson, linux-kernel, netdev, ilyal, aviadye
In-Reply-To: <20180411005234.GA39848@beast>
From: Kees Cook <keescook@chromium.org>
Date: Tue, 10 Apr 2018 17:52:34 -0700
> In the quest to remove VLAs from the kernel[1], this replaces the VLA
> size with the only possible size used in the code, and adds a mechanism
> to double-check future IV sizes.
>
> [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
Applied.
^ permalink raw reply
* Re: [PATCHv2] mISDN: Remove VLAs
From: David Miller @ 2018-04-13 1:48 UTC (permalink / raw)
To: labbott; +Cc: isdn, keescook, netdev, linux-kernel, kernel-hardening
In-Reply-To: <20180411010429.18074-1-labbott@redhat.com>
From: Laura Abbott <labbott@redhat.com>
Date: Tue, 10 Apr 2018 18:04:29 -0700
> There's an ongoing effort to remove VLAs[1] from the kernel to eventually
> turn on -Wvla. Remove the VLAs from the mISDN code by switching to using
> kstrdup in one place and using an upper bound in another.
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> v2: Switch to a tighter upper bound so we are allocating a more
> reasonable amount on the stack (300). This is based on previous checks
> against this value.
Applied.
^ permalink raw reply
* Re: [PATCH v2 net] lan78xx: PHY DSP registers initialization to address EEE link drop issues with long cables
From: David Miller @ 2018-04-13 1:48 UTC (permalink / raw)
To: raghuramchary.jallipalli; +Cc: netdev, unglinuxdriver, woojung.huh
In-Reply-To: <20180411150636.6933-1-raghuramchary.jallipalli@microchip.com>
From: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
Date: Wed, 11 Apr 2018 20:36:36 +0530
> The patch is to configure DSP registers of PHY device
> to handle Gbe-EEE failures with >40m cable length.
>
> Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
> Signed-off-by: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: stmmac: fix missing support for 802.1AD tag on reception
From: David Miller @ 2018-04-13 1:48 UTC (permalink / raw)
To: EladN; +Cc: netdev
In-Reply-To: <DB5PR07MB15447E832914A7FD15E06A5FA0BD0@DB5PR07MB1544.eurprd07.prod.outlook.com>
From: Elad Nachman <EladN@gilat.com>
Date: Wed, 11 Apr 2018 15:07:40 +0000
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c2018-04-11 17:04:00.586057300 +0300
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c2018-04-11 17:05:33.601992400 +0300
> @@ -3293,17 +3293,19 @@ dma_map_err:
>
> static void stmmac_rx_vlan(struct net_device *dev, struct sk_buff *skb)
> {
> -struct ethhdr *ehdr;
> +struct vlan_ethhdr *veth;
> u16 vlanid;
> +__be16 vlan_proto;
This patch has been mangled by your email client.
^ permalink raw reply
* Re: [net 1/1] tipc: fix unbalanced reference counter
From: David Miller @ 2018-04-13 1:49 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen,
hoang.h.le, canh.d.luu, ying.xue, tipc-discussion
In-Reply-To: <1523479929-28161-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Wed, 11 Apr 2018 22:52:09 +0200
> When a topology subscription is created, we may encounter (or KASAN
> may provoke) a failure to create a corresponding service instance in
> the binding table. Instead of letting the tipc_nametbl_subscribe()
> report the failure back to the caller, the function just makes a warning
> printout and returns, without incrementing the subscription reference
> counter as expected by the caller.
>
> This makes the caller believe that the subscription was successful, so
> it will at a later moment try to unsubscribe the item. This involves
> a sub_put() call. Since the reference counter never was incremented
> in the first place, we get a premature delete of the subscription item,
> followed by a "use-after-free" warning.
>
> We fix this by adding a return value to tipc_nametbl_subscribe() and
> make the caller aware of the failure to subscribe.
>
> This bug seems to always have been around, but this fix only applies
> back to the commit shown below. Given the low risk of this happening
> we believe this to be sufficient.
>
> Fixes: commit 218527fe27ad ("tipc: replace name table service range
> array with rb tree")
> Reported-by: syzbot+aa245f26d42b8305d157@syzkaller.appspotmail.com
>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] tcp: md5: reject TCP_MD5SIG or TCP_MD5SIG_EXT on established sockets
From: David Miller @ 2018-04-13 1:50 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <20180411213628.194344-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Wed, 11 Apr 2018 14:36:28 -0700
> syzbot/KMSAN reported an uninit-value in tcp_parse_options() [1]
>
> I believe this was caused by a TCP_MD5SIG being set on live
> flow.
>
> This is highly unexpected, since TCP option space is limited.
>
> For instance, presence of TCP MD5 option automatically disables
> TCP TimeStamp option at SYN/SYNACK time, which we can not do
> once flow has been established.
>
> Really, adding/deleting an MD5 key only makes sense on sockets
> in CLOSE or LISTEN state.
...
> Fixes: cfb6eeb4c860 ("[TCP]: MD5 Signature Option (RFC2385) support.")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] net: validate attribute sizes in neigh_dump_table()
From: David Miller @ 2018-04-13 1:50 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, dsa
In-Reply-To: <20180411214600.203361-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Wed, 11 Apr 2018 14:46:00 -0700
> Since neigh_dump_table() calls nlmsg_parse() without giving policy
> constraints, attributes can have arbirary size that we must validate
>
> Reported by syzbot/KMSAN :
...
> Fixes: 21fdd092acc7 ("net: Add support for filtering neigh dump by master device")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: David Ahern <dsa@cumulusnetworks.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v2 net 0/2] ibmvnic: Fix parameter change request handling
From: David Miller @ 2018-04-13 1:52 UTC (permalink / raw)
To: nfont; +Cc: netdev, jallen, tlfalcon
In-Reply-To: <152345930946.41899.8546547036273488202.stgit@ltcalpine2-lp14.aus.stglabs.ibm.com>
From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Date: Wed, 11 Apr 2018 10:09:26 -0500
> When updating parameters for the ibmvnic driver there is a possibility
> of entering an infinite loop if a return value other that a partial
> success is received from sending the login CRQ.
>
> Also, a deadlock can occur on the rtnl lock if netdev_notify_peers()
> is called during driver reset for a parameter change reset.
>
> This patch set corrects both of these issues by updating the return
> code handling in ibmvnic_login() nand gaurding against calling
> netdev_notify_peers() for parameter change requests.
>
> -Nathan
>
> Updates for V2: Correct spelling mistakes in commit messages.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] selftests: net: add in_netns.sh to TEST_PROGS
From: David Miller @ 2018-04-13 1:53 UTC (permalink / raw)
To: anders.roxell; +Cc: shuah, netdev, linux-kselftest, linux-kernel
In-Reply-To: <20180411151734.15507-1-anders.roxell@linaro.org>
From: Anders Roxell <anders.roxell@linaro.org>
Date: Wed, 11 Apr 2018 17:17:34 +0200
> Script in_netns.sh isn't installed.
> --------------------
> running psock_fanout test
> --------------------
> ./run_afpackettests: line 12: ./in_netns.sh: No such file or directory
> [FAIL]
> --------------------
> running psock_tpacket test
> --------------------
> ./run_afpackettests: line 22: ./in_netns.sh: No such file or directory
> [FAIL]
>
> In current code added in_netns.sh to be installed.
>
> Fixes: cc30c93fa020 ("selftests/net: ignore background traffic in psock_fanout")
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] strparser: Fix incorrect strp->need_bytes value.
From: David Miller @ 2018-04-13 1:56 UTC (permalink / raw)
To: doronrk; +Cc: netdev
In-Reply-To: <20180411220516.3062277-1-doronrk@fb.com>
From: Doron Roberts-Kedes <doronrk@fb.com>
Date: Wed, 11 Apr 2018 15:05:16 -0700
> strp_data_ready resets strp->need_bytes to 0 if strp_peek_len indicates
> that the remainder of the message has been received. However,
> do_strp_work does not reset strp->need_bytes to 0. If do_strp_work
> completes a partial message, the value of strp->need_bytes will continue
> to reflect the needed bytes of the previous message, causing
> future invocations of strp_data_ready to return early if
> strp->need_bytes is less than strp_peek_len. Resetting strp->need_bytes
> to 0 in __strp_recv on handing a full message to the upper layer solves
> this problem.
>
> __strp_recv also calculates strp->need_bytes using stm->accum_len before
> stm->accum_len has been incremented by cand_len. This can cause
> strp->need_bytes to be equal to the full length of the message instead
> of the full length minus the accumulated length. This, in turn, causes
> strp_data_ready to return early, even when there is sufficient data to
> complete the partial message. Incrementing stm->accum_len before using
> it to calculate strp->need_bytes solves this problem.
>
> Found while testing net/tls_sw recv path.
>
> Fixes: 43a0c6751a322847 ("strparser: Stream parser for messages")
> Signed-off-by: Doron Roberts-Kedes <doronrk@fb.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [net 1/1] tipc: fix missing initializer in tipc_sendmsg()
From: David Miller @ 2018-04-13 1:56 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen,
hoang.h.le, canh.d.luu, ying.xue, tipc-discussion
In-Reply-To: <1523488548-28520-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Thu, 12 Apr 2018 01:15:48 +0200
> The stack variable 'dnode' in __tipc_sendmsg() may theoretically
> end up tipc_node_get_mtu() as an unitilalized variable.
>
> We fix this by intializing the variable at declaration. We also add
> a default else clause to the two conditional ones already there, so
> that we never end up in the named function if the given address
> type is illegal.
>
> Reported-by: syzbot+b0975ce9355b347c1546@syzkaller.appspotmail.com
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied, thanks Jon.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox