* Re: [PATCH][V2] net: phy: marvell: make some functions static
From: David Miller @ 2017-06-04 23:55 UTC (permalink / raw)
To: colin.king; +Cc: andrew, f.fainelli, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170602141334.26506-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 2 Jun 2017 15:13:34 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> functions m88e1510_get_temp_critical, m88e1510_set_temp_critical and
> m88e1510_get_temp_alarm can be made static as they not need to be
> in global scope.
>
> Cleans up sparse warnings:
> "symbol 'm88e1510_get_temp_alarm' was not declared. Should it be static?"
> "symbol 'm88e1510_get_temp_critical' was not declared. Should it be
> static?"
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] net: stmmac: ensure jumbo_frm error return is correctly checked for -ve value
From: David Miller @ 2017-06-04 23:58 UTC (permalink / raw)
To: colin.king
Cc: peppe.cavallaro, alexandre.torgue, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20170602145827.21151-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 2 Jun 2017 15:58:27 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The current comparison of entry < 0 will never be true since entry is an
> unsigned integer. Cast entry to an int to ensure -ve error return values
> from the call to jumbo_frm are correctly being caught.
>
> Detected by CoverityScan, CID#1238760 ("Macro compares unsigned to 0")
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Like others have suggested, probably making 'entry' signed is
a better fix.
I was initially worried that STMMAC_GET_ENTRY() might become
more expensive if it was implemented using '%' but it is using
'and' masking instead which doesn't have that kind of problem.
^ permalink raw reply
* Re: [PATCH net-next] dccp: consistently use dccp_write_space()
From: David Miller @ 2017-06-04 23:58 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, gerrit
In-Reply-To: <1496415746.5031.6.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 02 Jun 2017 08:02:26 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> DCCP uses dccp_write_space() for sk->sk_write_space method.
>
> Unfortunately a passive connection (as provided by accept())
> is using the generic sk_stream_write_space() function.
>
> Lets simply inherit sk->sk_write_space from the parent
> instead of forcing the generic one.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH][net-next] rxrpc: remove redundant proc_remove call
From: David Miller @ 2017-06-04 23:59 UTC (permalink / raw)
To: colin.king; +Cc: dhowells, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170602152227.3626-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 2 Jun 2017 16:22:27 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The proc_remove call is dead code as it occurs after a return and
> hence can never be called. Remove it.
>
> Detected by CoverityScan, CID#1437743 ("Logically dead code")
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH] amd-xgbe: use PAGE_ALLOC_COSTLY_ORDER in xgbe_map_rx_buffer
From: David Miller @ 2017-06-05 0:01 UTC (permalink / raw)
To: mhocko; +Cc: thomas.lendacky, netdev, linux-kernel, mhocko
In-Reply-To: <20170602155408.12792-1-mhocko@kernel.org>
From: Michal Hocko <mhocko@kernel.org>
Date: Fri, 2 Jun 2017 17:54:08 +0200
> From: Michal Hocko <mhocko@suse.com>
>
> xgbe_map_rx_buffer is rather confused about what PAGE_ALLOC_COSTLY_ORDER
> means. It uses PAGE_ALLOC_COSTLY_ORDER-1 assuming that
> PAGE_ALLOC_COSTLY_ORDER is the first costly order which is not the case
> actually because orders larger than that are costly. And even that
> applies only to sleeping allocations which is not the case here. We
> simply do not perform any costly operations like reclaim or compaction
> for those. Simplify the code by dropping the order calculation and use
> PAGE_ALLOC_COSTLY_ORDER directly.
>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] sock: reset sk_err when the error queue is empty
From: David Miller @ 2017-06-05 0:02 UTC (permalink / raw)
To: soheil.kdev; +Cc: netdev, chrubis, soheil, edumazet, willemb
In-Reply-To: <20170602163822.67543-1-soheil.kdev@gmail.com>
From: Soheil Hassas Yeganeh <soheil.kdev@gmail.com>
Date: Fri, 2 Jun 2017 12:38:22 -0400
> From: Soheil Hassas Yeganeh <soheil@google.com>
>
> Prior to f5f99309fa74 (sock: do not set sk_err in
> sock_dequeue_err_skb), sk_err was reset to the error of
> the skb on the head of the error queue.
>
> Applications, most notably ping, are relying on this
> behavior to reset sk_err for ICMP packets.
>
> Set sk_err to the ICMP error when there is an ICMP packet
> at the head of the error queue.
>
> Fixes: f5f99309fa74 (sock: do not set sk_err in sock_dequeue_err_skb)
> Reported-by: Cyril Hrubis <chrubis@suse.cz>
> Test-by: Cyril Hrubis <chrubis@suse.cz>
> Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* (unknown),
From: nmckenna @ 2017-06-05 0:03 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 12178296.zip --]
[-- Type: application/zip, Size: 3159 bytes --]
^ permalink raw reply
* Re: [PATCH net] geneve: fix needed_headroom and max_mtu for collect_metadata
From: David Miller @ 2017-06-05 0:04 UTC (permalink / raw)
To: e; +Cc: pshelar, netdev
In-Reply-To: <20170602185410.10971-1-e@erig.me>
From: Eric Garver <e@erig.me>
Date: Fri, 2 Jun 2017 14:54:10 -0400
> Since commit 9b4437a5b870 ("geneve: Unify LWT and netdev handling.")
> when using COLLECT_METADATA geneve devices are created with too small of
> a needed_headroom and too large of a max_mtu. This is because
> ip_tunnel_info_af() is not valid with the device level info when using
> COLLECT_METADATA and we mistakenly fall into the IPv4 case.
>
> For COLLECT_METADATA, always use the worst case of ipv6 since both
> sockets are created.
>
> Fixes: 9b4437a5b870 ("geneve: Unify LWT and netdev handling.")
> Signed-off-by: Eric Garver <e@erig.me>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 0/3] net: dsa: Cleanups before multi-CPU port
From: David Miller @ 2017-06-05 0:06 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, john
In-Reply-To: <20170602193123.23930-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 2 Jun 2017 12:31:20 -0700
> This patch series does a bunch of cleanups before we start adding support
> for multiple CPU ports.
Series applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next 0/5] net: dsa: mv88e6xxx: move registers macros
From: David Miller @ 2017-06-05 0:08 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <20170602210619.26837-1-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Fri, 2 Jun 2017 17:06:14 -0400
> This patchset brings no functional changes.
>
> It is the first step of a cleanup renaming the chip header file and
> moving the Register definitions _as is_ in their proper header files.
>
> A following patchset will prefix them with the appropriate model
> (MV88E6XXX_ or e.g. MV88E6390_) to respect an implicit namespace and
> easily identify model subtleties in registers layout, as correctly done
> in the newly added serdes.h header.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH] ath6kl: fix spelling mistake: "Indicat" -> "Indicate"
From: Steve deRosier @ 2017-06-05 0:47 UTC (permalink / raw)
To: Colin King
Cc: Kalle Valo, linux-wireless, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170604163608.24894-1-colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
On Sun, Jun 4, 2017 at 9:36 AM, Colin King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> wrote:
> From: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
>
> Trivial fix to spelling mistake in ath6kl_dbg debug message
>
> Signed-off-by: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> ---
> drivers/net/wireless/ath/ath6kl/htc_pipe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath6kl/htc_pipe.c b/drivers/net/wireless/ath/ath6kl/htc_pipe.c
> index d127a08d60df..d4fd9e40fffb 100644
> --- a/drivers/net/wireless/ath/ath6kl/htc_pipe.c
> +++ b/drivers/net/wireless/ath/ath6kl/htc_pipe.c
> @@ -383,7 +383,7 @@ static enum htc_send_queue_result htc_try_send(struct htc_target *target,
> list_for_each_entry_safe(packet, tmp_pkt,
> txq, list) {
> ath6kl_dbg(ATH6KL_DBG_HTC,
> - "%s: Indicat overflowed TX pkts: %p\n",
> + "%s: Indicate overflowed TX pkts: %p\n",
> __func__, packet);
> action = ep->ep_cb.tx_full(ep->target, packet);
> if (action == HTC_SEND_FULL_DROP) {
> --
> 2.11.0
>
Looks good to me.
Reviewed-by: Steve deRosier <derosier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
- Steve
^ permalink raw reply
* [PATCH v2] devlink: fix potential memort leak
From: Haishuang Yan @ 2017-06-05 0:57 UTC (permalink / raw)
To: David S. Miller, Arkadi Sharshevsky, Jiri Pirko
Cc: netdev, linux-kernel, Haishuang Yan
We must free allocated skb when genlmsg_put() return fails.
Fixes: 1555d204e743 ("devlink: Support for pipeline debug (dpipe)")
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
Changes in v2:
- Fix same issue in headers_fill.
---
net/core/devlink.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/core/devlink.c b/net/core/devlink.c
index b0b87a2..a0adfc3 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -1680,8 +1680,10 @@ static int devlink_dpipe_tables_fill(struct genl_info *info,
hdr = genlmsg_put(skb, info->snd_portid, info->snd_seq,
&devlink_nl_family, NLM_F_MULTI, cmd);
- if (!hdr)
+ if (!hdr) {
+ nlmsg_free(skb);
return -EMSGSIZE;
+ }
if (devlink_nl_put_handle(skb, devlink))
goto nla_put_failure;
@@ -2098,8 +2100,10 @@ static int devlink_dpipe_headers_fill(struct genl_info *info,
hdr = genlmsg_put(skb, info->snd_portid, info->snd_seq,
&devlink_nl_family, NLM_F_MULTI, cmd);
- if (!hdr)
+ if (!hdr) {
+ nlmsg_free(skb);
return -EMSGSIZE;
+ }
if (devlink_nl_put_handle(skb, devlink))
goto nla_put_failure;
--
1.8.3.1
^ permalink raw reply related
* RE: [net-next] openvswitch: add macro MODULE_ALIAS_VPORT_TYPE for vport type alias
From: 张胜举 @ 2017-06-05 1:10 UTC (permalink / raw)
To: 'David Miller', pshelar; +Cc: pshelar, netdev
In-Reply-To: <20170604.161235.2303882939513535289.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, June 05, 2017 4:13 AM
> To: pshelar@ovn.org
> Cc: zhangshengju@cmss.chinamobile.com; pshelar@nicira.com;
> netdev@vger.kernel.org
> Subject: Re: [net-next] openvswitch: add macro
> MODULE_ALIAS_VPORT_TYPE for vport type alias
>
> From: Pravin Shelar <pshelar@ovn.org>
> Date: Sat, 3 Jun 2017 22:58:22 -0700
>
> > On Sat, Jun 3, 2017 at 6:47 AM, Zhang Shengju
> > <zhangshengju@cmss.chinamobile.com> wrote:
> >> Add a new macro MODULE_ALIAS_VPORT_TYPE to unify and simplify the
> >> declaration of vport type alias, and replace magic numbers with
> >> symbolic constants.
> >>
> >> Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
> >> ---
> >> net/openvswitch/vport-geneve.c | 2 +-
> >> net/openvswitch/vport-gre.c | 2 +-
> >> net/openvswitch/vport-vxlan.c | 2 +-
> >> net/openvswitch/vport.h | 3 +++
> >> 4 files changed, 6 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/net/openvswitch/vport-geneve.c
> >> b/net/openvswitch/vport-geneve.c index 5aaf3ba..1c068d6 100644
> >> --- a/net/openvswitch/vport-geneve.c
> >> +++ b/net/openvswitch/vport-geneve.c
> >> @@ -141,4 +141,4 @@ static void __exit ovs_geneve_tnl_exit(void)
> >>
> >> MODULE_DESCRIPTION("OVS: Geneve switching port");
> >> MODULE_LICENSE("GPL"); -MODULE_ALIAS("vport-type-5");
> >> +MODULE_ALIAS_VPORT_TYPE(OVS_VPORT_TYPE_GENEVE);
> >> diff --git a/net/openvswitch/vport-gre.c
> >> b/net/openvswitch/vport-gre.c index 0e72d95..48a5852 100644
> >> --- a/net/openvswitch/vport-gre.c
> >> +++ b/net/openvswitch/vport-gre.c
> >> @@ -113,4 +113,4 @@ static void __exit ovs_gre_tnl_exit(void)
> >>
> >> MODULE_DESCRIPTION("OVS: GRE switching port");
> >> MODULE_LICENSE("GPL"); -MODULE_ALIAS("vport-type-3");
> >> +MODULE_ALIAS_VPORT_TYPE(OVS_VPORT_TYPE_GRE);
> >
> > This is user visible change. For example this is changing the gre
> > module alias from "vport-type-3" to "vport-type-OVS_VPORT_TYPE_GRE".
> > This could break userspace application.
>
> Agreed, you really can't do this.
Hi David,
Actually this change does not change module alias name. I use '__stringify'
to
address this. Please refer my previous reply.
BRs,
Zhang Shengju
^ permalink raw reply
* Re: [net-next] openvswitch: add macro MODULE_ALIAS_VPORT_TYPE for vport type alias
From: David Miller @ 2017-06-05 1:25 UTC (permalink / raw)
To: zhangshengju; +Cc: pshelar, pshelar, netdev
In-Reply-To: <001601d2dd98$8209e620$861db260$@cmss.chinamobile.com>
From: 张胜举 <zhangshengju@cmss.chinamobile.com>
Date: Mon, 5 Jun 2017 09:10:22 +0800
>> -----Original Message-----
>> From: David Miller [mailto:davem@davemloft.net]
>> Sent: Monday, June 05, 2017 4:13 AM
>> To: pshelar@ovn.org
>> Cc: zhangshengju@cmss.chinamobile.com; pshelar@nicira.com;
>> netdev@vger.kernel.org
>> Subject: Re: [net-next] openvswitch: add macro
>> MODULE_ALIAS_VPORT_TYPE for vport type alias
>>
>> From: Pravin Shelar <pshelar@ovn.org>
>> Date: Sat, 3 Jun 2017 22:58:22 -0700
>>
>> > On Sat, Jun 3, 2017 at 6:47 AM, Zhang Shengju
>> > <zhangshengju@cmss.chinamobile.com> wrote:
>> >> Add a new macro MODULE_ALIAS_VPORT_TYPE to unify and simplify the
>> >> declaration of vport type alias, and replace magic numbers with
>> >> symbolic constants.
>> >>
>> >> Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
>> >> ---
>> >> net/openvswitch/vport-geneve.c | 2 +-
>> >> net/openvswitch/vport-gre.c | 2 +-
>> >> net/openvswitch/vport-vxlan.c | 2 +-
>> >> net/openvswitch/vport.h | 3 +++
>> >> 4 files changed, 6 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/net/openvswitch/vport-geneve.c
>> >> b/net/openvswitch/vport-geneve.c index 5aaf3ba..1c068d6 100644
>> >> --- a/net/openvswitch/vport-geneve.c
>> >> +++ b/net/openvswitch/vport-geneve.c
>> >> @@ -141,4 +141,4 @@ static void __exit ovs_geneve_tnl_exit(void)
>> >>
>> >> MODULE_DESCRIPTION("OVS: Geneve switching port");
>> >> MODULE_LICENSE("GPL"); -MODULE_ALIAS("vport-type-5");
>> >> +MODULE_ALIAS_VPORT_TYPE(OVS_VPORT_TYPE_GENEVE);
>> >> diff --git a/net/openvswitch/vport-gre.c
>> >> b/net/openvswitch/vport-gre.c index 0e72d95..48a5852 100644
>> >> --- a/net/openvswitch/vport-gre.c
>> >> +++ b/net/openvswitch/vport-gre.c
>> >> @@ -113,4 +113,4 @@ static void __exit ovs_gre_tnl_exit(void)
>> >>
>> >> MODULE_DESCRIPTION("OVS: GRE switching port");
>> >> MODULE_LICENSE("GPL"); -MODULE_ALIAS("vport-type-3");
>> >> +MODULE_ALIAS_VPORT_TYPE(OVS_VPORT_TYPE_GRE);
>> >
>> > This is user visible change. For example this is changing the gre
>> > module alias from "vport-type-3" to "vport-type-OVS_VPORT_TYPE_GRE".
>> > This could break userspace application.
>>
>> Agreed, you really can't do this.
>
> Hi David,
> Actually this change does not change module alias name. I use '__stringify'
> to
> address this. Please refer my previous reply.
Yep, I saw that, I waive my objection :-)
^ permalink raw reply
* Re: [PATCH net-next 0/2] Fixes for mv88e6161
From: David Miller @ 2017-06-05 1:35 UTC (permalink / raw)
To: andrew; +Cc: vivien.didelot, cphealy, nikita.yoush, netdev
In-Reply-To: <1496438566-30612-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Fri, 2 Jun 2017 23:22:44 +0200
> Testing a board with an mv88e6161 turned up two issues. The PHYs were
> not found, because the wrong method to access them was used. The
> statistics did not work, because the wrong snapshot method was used
Series applied, thanks Andrew.
^ permalink raw reply
* Re: [PATCHv2 net-next] net: phy: smsc: Implement PHY statistics
From: David Miller @ 2017-06-05 1:36 UTC (permalink / raw)
To: andrew; +Cc: Woojung.Huh, netdev
In-Reply-To: <1496512836-22198-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sat, 3 Jun 2017 20:00:36 +0200
> Most of the PHYs supported by the SMSC driver have a counter of symbol
> errors. This is 16 bit wide and wraps around when it reaches its
> maximum value.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> Reviewed-By: Woojung Huh <Woojung.Huh@microchip.com>
> ---
> v2:
> Align members
> Add Reviewed-by's
Applied.
^ permalink raw reply
* Re: [PATCH V5 net-next] neigh: Really delete an arp/neigh entry on "ip neigh delete" or "arp -d"
From: David Miller @ 2017-06-05 1:37 UTC (permalink / raw)
To: sowmini.varadhan; +Cc: netdev, stephen, ja
In-Reply-To: <1496419309-91478-1-git-send-email-sowmini.varadhan@oracle.com>
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Fri, 2 Jun 2017 09:01:49 -0700
> The command
> # arp -s 62.2.0.1 a:b:c:d:e:f dev eth2
> adds an entry like the following (listed by "arp -an")
> ? (62.2.0.1) at 0a:0b:0c:0d:0e:0f [ether] PERM on eth2
> but the symmetric deletion command
> # arp -i eth2 -d 62.2.0.1
> does not remove the PERM entry from the table, and instead leaves behind
> ? (62.2.0.1) at <incomplete> on eth2
>
> The reason is that there is a refcnt of 1 for the arp_tbl itself
> (neigh_alloc starts off the entry with a refcnt of 1), thus
> the neigh_release() call from arp_invalidate() will (at best) just
> decrement the ref to 1, but will never actually free it from the
> table.
>
> To fix this, we need to do something like neigh_forced_gc: if
> the refcnt is 1 (i.e., on the table's ref), remove the entry from
> the table and free it. This patch refactors and shares common code
> between neigh_forced_gc and the newly added neigh_remove_one.
>
> A similar issue exists for IPv6 Neighbor Cache entries, and is fixed
> in a similar manner by this patch.
>
> Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
> Reviewed-by: Julian Anastasov <ja@ssi.bg>
Applied, thank you.
^ permalink raw reply
* Re: Leak in ipv6_gso_segment()?
From: David Miller @ 2017-06-05 1:41 UTC (permalink / raw)
To: kraigatgoog; +Cc: ben, netdev
In-Reply-To: <CAEfhGiyR-A6yuR8ZJX6WagHTED1McdLqa0eyA3Hg463xSUzSTA@mail.gmail.com>
From: Craig Gallek <kraigatgoog@gmail.com>
Date: Fri, 2 Jun 2017 15:27:41 -0400
> On Fri, Jun 2, 2017 at 2:25 PM, Craig Gallek <kraigatgoog@gmail.com> wrote:
>> On Fri, Jun 2, 2017 at 2:05 PM, David Miller <davem@davemloft.net> wrote:
>>> From: Ben Hutchings <ben@decadent.org.uk>
>>> Date: Wed, 31 May 2017 13:26:02 +0100
>>>
>>>> If I'm not mistaken, ipv6_gso_segment() now leaks segs if
>>>> ip6_find_1stfragopt() fails. I'm not sure whether the fix would be as
>>>> simple as adding a kfree_skb(segs) or whether more complex cleanup is
>>>> needed.
>>>
>>> I think we need to use kfree_skb_list(), like the following.
>> I think this is problematic as well. ipv6_gso_segment could
>> previously return errors, in which case the caller uses kfree_skb (ex
>> validate_xmit_skb() -> skb_gso_segment -> ...
>> callbacks.gso_segment()). Having the kfree_skb_list here would cause
>> a double free if I'm reading this correctly.
>>
>> My first guess was going to be skb_gso_error_unwind(), but I'm still
>> trying to understand that code...
>>
>> Sorry again for the fallout from this bug fix. This is my first time
>> down this code path and I clearly didn't understand it fully :/
>
> Ok, I take it back. I believe your kfree_skb_list suggestion is correct.
>
> I was assuming that skb_segment consumed the original skb upon
> successful segmentation. It does not. This is exactly why
> validate_xmit_skb calls consume_skb when segments are returned.
> Further, there is at least one existing example of kfree_skb_list in a
> similar post-semgent cleanup path (esp6_gso_segment).
Great, thanks for reviewing. I've pushed this into 'net' and
queued it up for -stable.
^ permalink raw reply
* Re: [PATCH v4 net-next 0/3] bpf: Add BPF support to all perf_event
From: David Miller @ 2017-06-05 1:49 UTC (permalink / raw)
To: ast; +Cc: peterz, bgregg, daniel, qinteng, netdev, linux-kernel,
kernel-team
In-Reply-To: <20170603040354.3580555-1-ast@fb.com>
From: Alexei Starovoitov <ast@fb.com>
Date: Fri, 2 Jun 2017 21:03:51 -0700
> v3->v4: one more tweak to reject unsupported events at map
> update time as Peter suggested
>
> v2->v3: more refactoring to address Peter's feedback.
> Now all perf_events are attachable and readable
>
> v1->v2: address Peter's feedback. Refactor patch 1 to allow attaching
> bpf programs to all event types and reading counters from all of them as well
> patch 2 - more tests
> patch 3 - address Dave's feedback and document bpf_perf_event_read()
> and bpf_perf_event_output() properly
Series applied, thanks.
^ permalink raw reply
* Re: BUG: KASAN: use-after-free in free_old_xmit_skbs
From: Michael S. Tsirkin @ 2017-06-05 2:08 UTC (permalink / raw)
To: Jean-Philippe Menil; +Cc: netdev, jasowang, John Fastabend
In-Reply-To: <d2e8cf65-ea3d-7db2-9382-a063daf1168a@gmail.com>
On Mon, Jun 05, 2017 at 12:48:53AM +0200, Jean-Philippe Menil wrote:
> Hi,
>
> while playing with xdp and ebpf, i'm hitting the following:
>
> [ 309.993136]
> ==================================================================
> [ 309.994735] BUG: KASAN: use-after-free in
> free_old_xmit_skbs.isra.29+0x2b7/0x2e0 [virtio_net]
> [ 309.998396] Read of size 8 at addr ffff88006aa64220 by task sshd/323
> [ 310.000650]
> [ 310.002305] CPU: 1 PID: 323 Comm: sshd Not tainted 4.12.0-rc3+ #2
> [ 310.004018] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.10.2-20170228_101828-anatol 04/01/2014
> [ 310.006495] Call Trace:
> [ 310.007610] dump_stack+0xb8/0x14c
> [ 310.008748] ? _atomic_dec_and_lock+0x174/0x174
> [ 310.009998] ? pm_qos_get_value.part.7+0x6/0x6
> [ 310.011203] print_address_description+0x6f/0x280
> [ 310.012416] kasan_report+0x27a/0x370
> [ 310.013573] ? free_old_xmit_skbs.isra.29+0x2b7/0x2e0 [virtio_net]
> [ 310.014900] __asan_report_load8_noabort+0x19/0x20
> [ 310.016136] free_old_xmit_skbs.isra.29+0x2b7/0x2e0 [virtio_net]
> [ 310.017467] ? virtnet_del_vqs+0xe0/0xe0 [virtio_net]
> [ 310.018759] ? packet_rcv+0x20d0/0x20d0
> [ 310.019950] ? dev_queue_xmit_nit+0x5cd/0xaf0
> [ 310.021168] start_xmit+0x1b4/0x1b10 [virtio_net]
> [ 310.022413] ? default_device_exit+0x2d0/0x2d0
> [ 310.023634] ? virtnet_remove+0xf0/0xf0 [virtio_net]
> [ 310.024874] ? update_load_avg+0x1281/0x29f0
> [ 310.026059] dev_hard_start_xmit+0x1ea/0x7f0
> [ 310.027247] ? validate_xmit_skb_list+0x100/0x100
> [ 310.028470] ? validate_xmit_skb+0x7f/0xc10
> [ 310.029731] ? netif_skb_features+0x920/0x920
> [ 310.033469] ? __skb_tx_hash+0x2f0/0x2f0
> [ 310.035615] ? validate_xmit_skb_list+0xa3/0x100
> [ 310.037782] sch_direct_xmit+0x2eb/0x7a0
> [ 310.039842] ? dev_deactivate_queue.constprop.29+0x230/0x230
> [ 310.041980] ? netdev_pick_tx+0x212/0x2b0
> [ 310.043868] __dev_queue_xmit+0x12fa/0x20b0
> [ 310.045564] ? netdev_pick_tx+0x2b0/0x2b0
> [ 310.047210] ? __account_cfs_rq_runtime+0x630/0x630
> [ 310.048301] ? update_stack_state+0x402/0x780
> [ 310.049307] ? account_entity_enqueue+0x730/0x730
> [ 310.050322] ? __rb_erase_color+0x27d0/0x27d0
> [ 310.051286] ? update_curr_fair+0x70/0x70
> [ 310.052206] ? enqueue_entity+0x2450/0x2450
> [ 310.053124] ? entry_SYSCALL64_slow_path+0x25/0x25
> [ 310.054082] ? dequeue_entity+0x27a/0x1520
> [ 310.054967] ? bpf_prog_alloc+0x320/0x320
> [ 310.055822] ? yield_to_task_fair+0x110/0x110
> [ 310.056708] ? set_next_entity+0x2f2/0xa90
> [ 310.057574] ? dequeue_task_fair+0xc09/0x2ec0
> [ 310.058457] dev_queue_xmit+0x10/0x20
> [ 310.059298] ip_finish_output2+0xacf/0x12a0
> [ 310.060160] ? dequeue_entity+0x1520/0x1520
> [ 310.063410] ? ip_fragment.constprop.47+0x220/0x220
> [ 310.065078] ? ring_buffer_set_clock+0x50/0x50
> [ 310.066677] ? __switch_to+0x685/0xda0
> [ 310.068166] ? load_balance+0x38f0/0x38f0
> [ 310.069544] ? compat_start_thread+0x80/0x80
> [ 310.070989] ? trace_find_cmdline+0x60/0x60
> [ 310.072402] ? rt_cpu_seq_show+0x2d0/0x2d0
> [ 310.073579] ip_finish_output+0x407/0x880
> [ 310.074441] ? ip_finish_output+0x407/0x880
> [ 310.075255] ? update_stack_state+0x402/0x780
> [ 310.076076] ip_output+0x1c0/0x640
> [ 310.076843] ? ip_mc_output+0x1350/0x1350
> [ 310.077642] ? __sk_dst_check+0x164/0x370
> [ 310.078441] ? complete_formation.isra.53+0xa30/0xa30
> [ 310.079313] ? __read_once_size_nocheck.constprop.7+0x20/0x20
> [ 310.080265] ? sock_prot_inuse_add+0xa0/0xa0
> [ 310.081097] ? memcpy+0x45/0x50
> [ 310.081850] ? __copy_skb_header+0x1fa/0x280
> [ 310.082676] ip_local_out+0x70/0x90
> [ 310.083448] ip_queue_xmit+0x8a1/0x22a0
> [ 310.084236] ? ip_build_and_send_pkt+0xe80/0xe80
> [ 310.085079] ? tcp_v4_md5_lookup+0x13/0x20
> [ 310.085884] tcp_transmit_skb+0x187a/0x3e00
> [ 310.086696] ? __tcp_select_window+0xaf0/0xaf0
> [ 310.087524] ? sock_sendmsg+0xba/0xf0
> [ 310.088298] ? __vfs_write+0x4e0/0x960
> [ 310.089074] ? vfs_write+0x155/0x4b0
> [ 310.089838] ? SyS_write+0xf7/0x240
> [ 310.090593] ? do_syscall_64+0x235/0x5b0
> [ 310.091372] ? entry_SYSCALL64_slow_path+0x25/0x25
> [ 310.094690] ? sock_sendmsg+0xba/0xf0
> [ 310.096133] ? do_syscall_64+0x235/0x5b0
> [ 310.097593] ? entry_SYSCALL64_slow_path+0x25/0x25
> [ 310.099157] ? tcp_init_tso_segs+0x1e0/0x1e0
> [ 310.100539] ? radix_tree_lookup+0xd/0x10
> [ 310.101894] ? get_work_pool+0xcd/0x150
> [ 310.103216] ? check_flush_dependency+0x330/0x330
> [ 310.104113] tcp_write_xmit+0x498/0x52a0
> [ 310.104905] ? kasan_unpoison_shadow+0x35/0x50
> [ 310.105729] ? kasan_kmalloc+0xad/0xe0
> [ 310.106505] ? tcp_transmit_skb+0x3e00/0x3e00
> [ 310.107331] ? memset+0x31/0x40
> [ 310.108070] ? __check_object_size+0x22e/0x55c
> [ 310.108895] ? skb_pull_rcsum+0x2b0/0x2b0
> [ 310.109690] ? check_stack_object+0x120/0x120
> [ 310.110512] ? tcp_v4_md5_lookup+0x13/0x20
> [ 310.111315] __tcp_push_pending_frames+0x8d/0x2a0
> [ 310.112159] tcp_push+0x47c/0xbd0
> [ 310.112912] ? copy_from_iter_full+0x21e/0xc70
> [ 310.113747] ? sock_warn_obsolete_bsdism+0x70/0x70
> [ 310.114604] ? tcp_splice_data_recv+0x1c0/0x1c0
> [ 310.115436] ? iov_iter_copy_from_user_atomic+0xeb0/0xeb0
> [ 310.116324] tcp_sendmsg+0xd6d/0x43f0
> [ 310.117106] ? tcp_sendpage+0x2170/0x2170
> [ 310.117911] ? set_fd_set.part.1+0x50/0x50
> [ 310.118718] ? remove_wait_queue+0x196/0x3b0
> [ 310.119535] ? set_fd_set.part.1+0x50/0x50
> [ 310.120365] ? add_wait_queue_exclusive+0x290/0x290
> [ 310.121224] ? __wake_up+0x44/0x50
> [ 310.121985] ? n_tty_read+0x9f9/0x19d0
> [ 310.122898] ? __check_object_size+0x22e/0x55c
> [ 310.125380] inet_sendmsg+0x111/0x590
> [ 310.126863] ? inet_recvmsg+0x5e0/0x5e0
> [ 310.128348] ? inet_recvmsg+0x5e0/0x5e0
> [ 310.129817] sock_sendmsg+0xba/0xf0
> [ 310.131110] sock_write_iter+0x2e4/0x6a0
> [ 310.132433] ? core_sys_select+0x47d/0x780
> [ 310.133779] ? sock_sendmsg+0xf0/0xf0
> [ 310.134591] __vfs_write+0x4e0/0x960
> [ 310.135351] ? kvm_clock_get_cycles+0x1e/0x20
> [ 310.136160] ? __vfs_read+0x950/0x950
> [ 310.136931] ? rw_verify_area+0xbd/0x2b0
> [ 310.137711] vfs_write+0x155/0x4b0
> [ 310.138454] SyS_write+0xf7/0x240
> [ 310.139183] ? SyS_read+0x240/0x240
> [ 310.139922] ? SyS_read+0x240/0x240
> [ 310.140649] do_syscall_64+0x235/0x5b0
> [ 310.141390] ? trace_raw_output_sys_exit+0xf0/0xf0
> [ 310.142204] ? syscall_return_slowpath+0x240/0x240
> [ 310.143018] ? trace_do_page_fault+0xc4/0x3a0
> [ 310.143810] ? prepare_exit_to_usermode+0x124/0x160
> [ 310.144634] ? perf_trace_sys_enter+0x1080/0x1080
> [ 310.145447] entry_SYSCALL64_slow_path+0x25/0x25
> [ 310.146257] RIP: 0033:0x7f6f868fb070
> [ 310.146999] RSP: 002b:00007fffed379578 EFLAGS: 00000246 ORIG_RAX:
> 0000000000000001
> [ 310.148507] RAX: ffffffffffffffda RBX: 00000000000002e4 RCX:
> 00007f6f868fb070
> [ 310.149521] RDX: 00000000000002e4 RSI: 000055603b5cfc10 RDI:
> 0000000000000003
> [ 310.150532] RBP: 000055603b5aca60 R08: 0000000000000000 R09:
> 0000000000003000
> [ 310.151530] R10: 0000000000000008 R11: 0000000000000246 R12:
> 0000000000000000
> [ 310.152537] R13: 00007fffed37960f R14: 000055603a832e31 R15:
> 0000000000000003
> [ 310.153578]
> [ 310.156362] Allocated by task 483:
> [ 310.157812] save_stack_trace+0x1b/0x20
> [ 310.159274] save_stack+0x43/0xd0
> [ 310.160663] kasan_kmalloc+0xad/0xe0
> [ 310.161943] __kmalloc+0x105/0x230
> [ 310.163233] __vring_new_virtqueue+0xd1/0xee0
> [ 310.164623] vring_create_virtqueue+0x2e3/0x5e0
> [ 310.165536] setup_vq+0x136/0x620
> [ 310.166286] vp_setup_vq+0x13d/0x6d0
> [ 310.167059] vp_find_vqs_msix+0x46c/0xb50
> [ 310.167855] vp_find_vqs+0x71/0x410
> [ 310.168641] vp_modern_find_vqs+0x21/0x140
> [ 310.169453] init_vqs+0x957/0x1390 [virtio_net]
> [ 310.170306] virtnet_restore_up+0x4a/0x590 [virtio_net]
> [ 310.171214] virtnet_xdp+0x89f/0xdf0 [virtio_net]
> [ 310.172077] dev_change_xdp_fd+0x1ca/0x420
> [ 310.172918] do_setlink+0x2c33/0x3bc0
> [ 310.173703] rtnl_setlink+0x245/0x380
> [ 310.174511] rtnetlink_rcv_msg+0x530/0x9b0
> [ 310.175344] netlink_rcv_skb+0x213/0x450
> [ 310.176166] rtnetlink_rcv+0x28/0x30
> [ 310.176990] netlink_unicast+0x4a0/0x6c0
> [ 310.177807] netlink_sendmsg+0x9ec/0xe50
> [ 310.178646] sock_sendmsg+0xba/0xf0
> [ 310.179435] SYSC_sendto+0x31d/0x620
> [ 310.180229] SyS_sendto+0xe/0x10
> [ 310.181004] do_syscall_64+0x235/0x5b0
> [ 310.181783] return_from_SYSCALL_64+0x0/0x6a
> [ 310.182595]
> [ 310.183217] Freed by task 483:
> [ 310.183934] save_stack_trace+0x1b/0x20
> [ 310.184801] save_stack+0x43/0xd0
> [ 310.187187] kasan_slab_free+0x72/0xc0
> [ 310.188530] kfree+0x94/0x1a0
> [ 310.189797] vring_del_virtqueue+0x19a/0x430
> [ 310.191221] del_vq+0x11c/0x250
> [ 310.192474] vp_del_vqs+0x379/0xc30
> [ 310.193772] virtnet_del_vqs+0xad/0xe0 [virtio_net]
> [ 310.195064] virtnet_xdp+0x836/0xdf0 [virtio_net]
> [ 310.196231] dev_change_xdp_fd+0x37c/0x420
> [ 310.197072] do_setlink+0x2c33/0x3bc0
> [ 310.197804] rtnl_setlink+0x245/0x380
> [ 310.198530] rtnetlink_rcv_msg+0x530/0x9b0
> [ 310.199283] netlink_rcv_skb+0x213/0x450
> [ 310.200036] rtnetlink_rcv+0x28/0x30
> [ 310.200754] netlink_unicast+0x4a0/0x6c0
> [ 310.201496] netlink_sendmsg+0x9ec/0xe50
> [ 310.202236] sock_sendmsg+0xba/0xf0
> [ 310.202947] SYSC_sendto+0x31d/0x620
> [ 310.203660] SyS_sendto+0xe/0x10
> [ 310.204340] do_syscall_64+0x235/0x5b0
> [ 310.205050] return_from_SYSCALL_64+0x0/0x6a
> [ 310.205792]
> [ 310.206350] The buggy address belongs to the object at ffff88006aa64200
> [ 310.206350] which belongs to the cache kmalloc-8192 of size 8192
> [ 310.208149] The buggy address is located 32 bytes inside of
> [ 310.208149] 8192-byte region [ffff88006aa64200, ffff88006aa66200)
> [ 310.209929] The buggy address belongs to the page:
> [ 310.210763] page:ffffea0001aa9800 count:1 mapcount:0 mapping: (null)
> index:0x0 compound_mapcount: 0
> [ 310.212499] flags: 0x1ffff8000008100(slab|head)
> [ 310.213373] raw: 01ffff8000008100 0000000000000000 0000000000000000
> 0000000100030003
> [ 310.214481] raw: dead000000000100 dead000000000200 ffff88006cc02700
> 0000000000000000
> [ 310.215635] page dumped because: kasan: bad access detected
> [ 310.218989]
> [ 310.220398] Memory state around the buggy address:
> [ 310.222141] ffff88006aa64100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> fc fc
> [ 310.223996] ffff88006aa64180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> fc fc
> [ 310.225469] >ffff88006aa64200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> fb fb
> [ 310.227400] ^
> [ 310.228367] ffff88006aa64280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> fb fb
> [ 310.229510] ffff88006aa64300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> fb fb
> [ 310.230639]
> ==================================================================
> [ 310.231788] Disabling lock debugging due to kernel taint
> [ 310.233499] kasan: CONFIG_KASAN_INLINE enabled
> [ 310.236846] kasan: GPF could be caused by NULL-ptr deref or user memory
> access
> [ 310.239138] general protection fault: 0000 [#1] SMP KASAN
> [ 310.240926] Modules linked in: joydev kvm_intel kvm psmouse irqbypass
> i2c_piix4 qemu_fw_cfg ip_tables x_tables autofs4 serio_raw virtio_balloon
> pata_acpi virtio_net virtio_blk
> [ 310.243618] CPU: 0 PID: 352 Comm: sshd Tainted: G B 4.12.0-rc3+ #2
> [ 310.245780] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.10.2-20170228_101828-anatol 04/01/2014
> [ 310.249799] task: ffff880066ca8d80 task.stack: ffff880069e40000
> [ 310.251090] RIP: 0010:free_old_xmit_skbs.isra.29+0x9d/0x2e0 [virtio_net]
> [ 310.252403] RSP: 0018:ffff880069e46540 EFLAGS: 00010202
> [ 310.253631] RAX: 0000000000000000 RBX: 0000000000000000 RCX:
> 0000000000000004
> [ 310.255916] RDX: dffffc0000000000 RSI: 0000000000000008 RDI:
> 0000000000000020
> [ 310.258017] RBP: ffff880069e465e8 R08: ffff880069e45f10 R09:
> ffff880066b3c400
> [ 310.259430] R10: ffff880069e45e98 R11: 1ffff1000cd952f3 R12:
> ffff880066b3c400
> [ 310.260797] R13: ffff880066b3c400 R14: ffff88006afc9156 R15:
> ffff88006afc9001
> [ 310.262139] FS: 00007f3020f26680(0000) GS:ffff88006d000000(0000)
> knlGS:0000000000000000
> [ 310.263564] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 310.264825] CR2: 00007efed4534010 CR3: 000000006986d000 CR4:
> 00000000000006f0
> [ 310.266178] Call Trace:
> [ 310.267231] ? virtnet_del_vqs+0xe0/0xe0 [virtio_net]
> [ 310.268453] ? packet_rcv+0x20d0/0x20d0
> [ 310.269559] start_xmit+0x1b4/0x1b10 [virtio_net]
> [ 310.270762] ? default_device_exit+0x2d0/0x2d0
> [ 310.271910] ? virtnet_remove+0xf0/0xf0 [virtio_net]
> [ 310.273076] ? update_load_avg+0x1281/0x29f0
> [ 310.274189] dev_hard_start_xmit+0x1ea/0x7f0
> [ 310.275295] ? validate_xmit_skb_list+0x100/0x100
> [ 310.276425] ? validate_xmit_skb+0x7f/0xc10
> [ 310.277548] ? rb_insert_color+0x1590/0x1590
> [ 310.280172] ? netif_skb_features+0x920/0x920
> [ 310.281275] ? __skb_tx_hash+0x2f0/0x2f0
> [ 310.282362] ? validate_xmit_skb_list+0xa3/0x100
> [ 310.283494] sch_direct_xmit+0x2eb/0x7a0
> [ 310.284559] ? dev_deactivate_queue.constprop.29+0x230/0x230
> [ 310.286448] ? netdev_pick_tx+0x212/0x2b0
> [ 310.288251] ? __account_cfs_rq_runtime+0x630/0x630
> [ 310.289707] __dev_queue_xmit+0x12fa/0x20b0
> [ 310.290788] ? netdev_pick_tx+0x2b0/0x2b0
> [ 310.291837] ? update_curr+0x1ef/0x750
> [ 310.292826] ? update_stack_state+0x402/0x780
> [ 310.293827] ? account_entity_enqueue+0x730/0x730
> [ 310.294831] ? update_stack_state+0x402/0x780
> [ 310.295818] ? update_curr_fair+0x70/0x70
> [ 310.296737] ? entry_SYSCALL64_slow_path+0x25/0x25
> [ 310.297693] ? dequeue_entity+0x27a/0x1520
> [ 310.298591] ? bpf_prog_alloc+0x320/0x320
> [ 310.299484] ? yield_to_task_fair+0x110/0x110
> [ 310.300385] ? unwind_dump+0x4e0/0x4e0
> [ 310.301246] ? __free_insn_slot+0x600/0x600
> [ 310.302125] ? unwind_dump+0x4e0/0x4e0
> [ 310.302975] ? dequeue_task_fair+0xc09/0x2ec0
> [ 310.303883] dev_queue_xmit+0x10/0x20
> [ 310.304711] ip_finish_output2+0xacf/0x12a0
> [ 310.305558] ? dequeue_entity+0x1520/0x1520
> [ 310.306393] ? ip_fragment.constprop.47+0x220/0x220
> [ 310.307320] ? save_stack_trace+0x1b/0x20
> [ 310.308133] ? save_stack+0x43/0xd0
> [ 310.309081] ? kasan_slab_free+0x72/0xc0
> [ 310.310614] ? kfree_skbmem+0xb6/0x1d0
> [ 310.311406] ? tcp_ack+0x2730/0x7450
> [ 310.312167] ? tcp_rcv_established+0xdbb/0x2db0
> [ 310.312987] ? tcp_v4_do_rcv+0x2bb/0x7a0
> [ 310.313769] ? __release_sock+0x14a/0x2b0
> [ 310.314550] ? release_sock+0xa8/0x270
> [ 310.315330] ? inet_sendmsg+0x111/0x590
> [ 310.316100] ? sock_sendmsg+0xba/0xf0
> [ 310.317403] ? sock_write_iter+0x2e4/0x6a0
> [ 310.318759] ? __rb_erase_color+0x27d0/0x27d0
> [ 310.319949] ? rt_cpu_seq_show+0x2d0/0x2d0
> [ 310.320800] ? update_stack_state+0x402/0x780
> [ 310.321590] ip_finish_output+0x407/0x880
> [ 310.322347] ? ip_finish_output+0x407/0x880
> [ 310.323138] ? update_stack_state+0x402/0x780
> [ 310.323948] ip_output+0x1c0/0x640
> [ 310.324661] ? ip_mc_output+0x1350/0x1350
> [ 310.325415] ? __sk_dst_check+0x164/0x370
> [ 310.326169] ? complete_formation.isra.53+0xa30/0xa30
> [ 310.327013] ? __read_once_size_nocheck.constprop.7+0x20/0x20
> [ 310.327896] ? sock_prot_inuse_add+0xa0/0xa0
> [ 310.328684] ? memcpy+0x45/0x50
> [ 310.329393] ? __copy_skb_header+0x1fa/0x280
> [ 310.330180] ip_local_out+0x70/0x90
> [ 310.330914] ip_queue_xmit+0x8a1/0x22a0
> [ 310.331676] ? ip_build_and_send_pkt+0xe80/0xe80
> [ 310.332517] ? tcp_v4_md5_lookup+0x13/0x20
> [ 310.333298] tcp_transmit_skb+0x187a/0x3e00
> [ 310.334085] ? __tcp_select_window+0xaf0/0xaf0
> [ 310.334887] ? sock_sendmsg+0xba/0xf0
> [ 310.335637] ? __vfs_write+0x4e0/0x960
> [ 310.336391] ? vfs_write+0x155/0x4b0
> [ 310.337135] ? SyS_write+0xf7/0x240
> [ 310.337861] ? do_syscall_64+0x235/0x5b0
> [ 310.338612] ? entry_SYSCALL64_slow_path+0x25/0x25
> [ 310.339443] ? sock_sendmsg+0xba/0xf0
> [ 310.341675] ? do_syscall_64+0x235/0x5b0
> [ 310.342441] ? entry_SYSCALL64_slow_path+0x25/0x25
> [ 310.343298] ? tcp_init_tso_segs+0x1e0/0x1e0
> [ 310.344095] ? radix_tree_lookup+0xd/0x10
> [ 310.344871] ? get_work_pool+0xcd/0x150
> [ 310.345635] ? check_flush_dependency+0x330/0x330
> [ 310.346466] tcp_write_xmit+0x498/0x52a0
> [ 310.347826] ? kasan_unpoison_shadow+0x35/0x50
> [ 310.349243] ? kasan_kmalloc+0xad/0xe0
> [ 310.350156] ? tcp_transmit_skb+0x3e00/0x3e00
> [ 310.351261] ? memset+0x31/0x40
> [ 310.352054] ? __check_object_size+0x22e/0x55c
> [ 310.352881] ? skb_pull_rcsum+0x2b0/0x2b0
> [ 310.353686] ? check_stack_object+0x120/0x120
> [ 310.354506] ? tcp_v4_md5_lookup+0x13/0x20
> [ 310.355327] __tcp_push_pending_frames+0x8d/0x2a0
> [ 310.356174] ? tcp_cwnd_restart+0x169/0x440
> [ 310.357016] tcp_push+0x47c/0xbd0
> [ 310.357777] ? copy_from_iter_full+0x21e/0xc70
> [ 310.358618] ? tcp_splice_data_recv+0x1c0/0x1c0
> [ 310.359463] ? iov_iter_copy_from_user_atomic+0xeb0/0xeb0
> [ 310.360355] ? tcp_send_mss+0x24/0x2b0
> [ 310.361135] tcp_sendmsg+0xd6d/0x43f0
> [ 310.361908] ? select_estimate_accuracy+0x440/0x440
> [ 310.362765] ? tcp_sendpage+0x2170/0x2170
> [ 310.363583] ? set_fd_set.part.1+0x50/0x50
> [ 310.364392] ? remove_wait_queue+0x196/0x3b0
> [ 310.365205] ? set_fd_set.part.1+0x50/0x50
> [ 310.366005] ? add_wait_queue_exclusive+0x290/0x290
> [ 310.366865] ? __wake_up+0x44/0x50
> [ 310.367637] ? n_tty_read+0x9f9/0x19d0
> [ 310.368424] ? update_blocked_averages+0x9a0/0x9a0
> [ 310.369283] ? __check_object_size+0x22e/0x55c
> [ 310.370129] inet_sendmsg+0x111/0x590
> [ 310.371104] ? inet_recvmsg+0x5e0/0x5e0
> [ 310.372571] ? inet_recvmsg+0x5e0/0x5e0
> [ 310.373449] sock_sendmsg+0xba/0xf0
> [ 310.374217] sock_write_iter+0x2e4/0x6a0
> [ 310.375005] ? core_sys_select+0x47d/0x780
> [ 310.375822] ? sock_sendmsg+0xf0/0xf0
> [ 310.376607] __vfs_write+0x4e0/0x960
> [ 310.377463] ? kvm_clock_get_cycles+0x1e/0x20
> [ 310.378864] ? __vfs_read+0x950/0x950
> [ 310.380178] ? rw_verify_area+0xbd/0x2b0
> [ 310.381092] vfs_write+0x155/0x4b0
> [ 310.381877] SyS_write+0xf7/0x240
> [ 310.382616] ? SyS_read+0x240/0x240
> [ 310.383404] ? SyS_read+0x240/0x240
> [ 310.384159] do_syscall_64+0x235/0x5b0
> [ 310.384930] ? trace_raw_output_sys_exit+0xf0/0xf0
> [ 310.385747] ? syscall_return_slowpath+0x240/0x240
> [ 310.386564] ? trace_do_page_fault+0xc4/0x3a0
> [ 310.387424] ? prepare_exit_to_usermode+0x124/0x160
> [ 310.388524] ? perf_trace_sys_enter+0x1080/0x1080
> [ 310.389347] entry_SYSCALL64_slow_path+0x25/0x25
> [ 310.390164] RIP: 0033:0x7f301f83c070
> [ 310.390906] RSP: 002b:00007ffff738fc78 EFLAGS: 00000246 ORIG_RAX:
> 0000000000000001
> [ 310.391943] RAX: ffffffffffffffda RBX: 0000000000000564 RCX:
> 00007f301f83c070
> [ 310.392938] RDX: 0000000000000564 RSI: 000055cf87fb0748 RDI:
> 0000000000000003
> [ 310.393947] RBP: 000055cf87f8f090 R08: 0000000000000000 R09:
> 0000000000003000
> [ 310.394948] R10: 0000000000000008 R11: 0000000000000246 R12:
> 0000000000000000
> [ 310.395967] R13: 00007ffff738fd0f R14: 000055cf873dde31 R15:
> 0000000000000003
> [ 310.396969] Code: 00 00 48 89 5d d0 31 db 80 3c 02 00 0f 85 05 02 00 00
> 49 8b 45 00 48 ba 00 00 00 00 00 fc ff df 48 8d 78 20 48 89 f9 48 c1 e9 03
> <80> 3c 11 00 0f 85 04 02 00 00 48 8b 58 20 48 ba 00 00 00 00 00
> [ 310.399937] RIP: free_old_xmit_skbs.isra.29+0x9d/0x2e0 [virtio_net] RSP:
> ffff880069e46540
> [ 310.401120] ---[ end trace 89c5b0ea3f07debe ]---
> [ 310.403923] Kernel panic - not syncing: Fatal exception in interrupt
> [ 310.405942] Kernel Offset: 0x33200000 from 0xffffffff81000000 (relocation
> range: 0xffffffff80000000-0xffffffffbfffffff)
> [ 310.408133] ---[ end Kernel panic - not syncing: Fatal exception in
> interrupt
>
>
> (gdb) l *(free_old_xmit_skbs+0x2b7)
> 0x22f7 is in free_old_xmit_skbs (drivers/net/virtio_net.c:1051).
> 1046
> 1047 static void free_old_xmit_skbs(struct send_queue *sq)
> 1048 {
> 1049 struct sk_buff *skb;
> 1050 unsigned int len;
> 1051 struct virtnet_info *vi = sq->vq->vdev->priv;
> 1052 struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
> 1053 unsigned int packets = 0;
> 1054 unsigned int bytes = 0;
> 1055
>
> Let me know if i need to provide more informations.
>
> Best regards.
>
> Jean-Philippe
So del_vq done during xdp setup seems to race with regular xmit.
Since commit 680557cf79f82623e2c4fd42733077d60a843513
virtio_net: rework mergeable buffer handling
we no longer must do the resets, we now have enough space
to store a bit saying whether a buffer is xdp one or not.
And that's probably a cleaner way to fix these issues than
try to find and fix the race condition.
John?
--
MST
^ permalink raw reply
* Re: [net-next] openvswitch: add macro MODULE_ALIAS_VPORT_TYPE for vport type alias
From: Pravin Shelar @ 2017-06-05 2:29 UTC (permalink / raw)
To: 张胜举
Cc: Pravin Shelar, Linux Kernel Network Developers, David S. Miller
In-Reply-To: <000a01d2dd0a$57b46fa0$071d4ee0$@cmss.chinamobile.com>
On Sun, Jun 4, 2017 at 1:12 AM, 张胜举 <zhangshengju@cmss.chinamobile.com> wrote:
>> -----Original Message-----
>> From: Pravin Shelar [mailto:pshelar@ovn.org]
>> Sent: Sunday, June 04, 2017 1:58 PM
>> To: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
>> Cc: Pravin Shelar <pshelar@nicira.com>; Linux Kernel Network Developers
>> <netdev@vger.kernel.org>; David S. Miller <davem@davemloft.net>
>> Subject: Re: [net-next] openvswitch: add macro
>> MODULE_ALIAS_VPORT_TYPE for vport type alias
>>
>> On Sat, Jun 3, 2017 at 6:47 AM, Zhang Shengju
>> <zhangshengju@cmss.chinamobile.com> wrote:
>> > Add a new macro MODULE_ALIAS_VPORT_TYPE to unify and simplify the
>> > declaration of vport type alias, and replace magic numbers with
>> > symbolic constants.
>> >
>> > Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
>> > ---
>> > net/openvswitch/vport-geneve.c | 2 +-
>> > net/openvswitch/vport-gre.c | 2 +-
>> > net/openvswitch/vport-vxlan.c | 2 +-
>> > net/openvswitch/vport.h | 3 +++
>> > 4 files changed, 6 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/net/openvswitch/vport-geneve.c
>> > b/net/openvswitch/vport-geneve.c index 5aaf3ba..1c068d6 100644
>> > --- a/net/openvswitch/vport-geneve.c
>> > +++ b/net/openvswitch/vport-geneve.c
>> > @@ -141,4 +141,4 @@ static void __exit ovs_geneve_tnl_exit(void)
>> >
>> > MODULE_DESCRIPTION("OVS: Geneve switching port");
>> > MODULE_LICENSE("GPL"); -MODULE_ALIAS("vport-type-5");
>> > +MODULE_ALIAS_VPORT_TYPE(OVS_VPORT_TYPE_GENEVE);
>> > diff --git a/net/openvswitch/vport-gre.c b/net/openvswitch/vport-gre.c
>> > index 0e72d95..48a5852 100644
>> > --- a/net/openvswitch/vport-gre.c
>> > +++ b/net/openvswitch/vport-gre.c
>> > @@ -113,4 +113,4 @@ static void __exit ovs_gre_tnl_exit(void)
>> >
>> > MODULE_DESCRIPTION("OVS: GRE switching port");
>> > MODULE_LICENSE("GPL"); -MODULE_ALIAS("vport-type-3");
>> > +MODULE_ALIAS_VPORT_TYPE(OVS_VPORT_TYPE_GRE);
>>
>> This is user visible change. For example this is changing the gre
>> module alias from "vport-type-3" to "vport-type-OVS_VPORT_TYPE_GRE".
>> This could break userspace application.
> Hi Shelar,
> Actually this change does not change module alias name. I use '__stringify' to
> address this. Below is my build result:
> ```
> [zhangshengju@promote net-next]$ modinfo net/openvswitch/vport-gre.ko
> filename: /gitlab/net-next/net/openvswitch/vport-gre.ko
> alias: vport-type-3
> ...
> ```
Yes, I expected this. But when I tried modinfo with your patch, I did
not see it. here is modinfo output from my setup.
---8<---
root@ubuntu:/home/pravin/linux/net-next# modinfo net/openvswitch/vport-gre.ko
filename: /home/pravin/linux/net-next/./net/openvswitch/vport-gre.ko
alias: vport-type-OVS_VPORT_TYPE_GRE
license: GPL
description: OVS: GRE switching port
srcversion: AD3B4449820F294E0B5681C
depends: openvswitch
intree: Y
vermagic: 4.12.0-rc2+ SMP mod_unload modversions
^ permalink raw reply
* [PATCH] net: phy: fix kernel-doc warnings
From: Randy Dunlap @ 2017-06-05 2:46 UTC (permalink / raw)
To: netdev@vger.kernel.org, David Miller; +Cc: Andrew Lunn, Florian Fainelli
From: Randy Dunlap <rdunlap@infradead.org>
Fix kernel-doc warnings (typo) in drivers/net/phy/phy.c:
..//drivers/net/phy/phy.c:259: warning: No description found for parameter 'features'
..//drivers/net/phy/phy.c:259: warning: Excess function parameter 'feature' description in 'phy_lookup_setting'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
drivers/net/phy/phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- lnx-412-rc4.orig/drivers/net/phy/phy.c
+++ lnx-412-rc4/drivers/net/phy/phy.c
@@ -241,7 +241,7 @@ static const struct phy_setting settings
* phy_lookup_setting - lookup a PHY setting
* @speed: speed to match
* @duplex: duplex to match
- * @feature: allowed link modes
+ * @features: allowed link modes
* @exact: an exact match is required
*
* Search the settings array for a setting that matches the speed and
^ permalink raw reply
* Re: [PATCH net] net: dsa: Fix stale cpu_switch reference after unbind then bind
From: David Miller @ 2017-06-05 2:57 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, linux-kernel
In-Reply-To: <20170603050523.27014-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 2 Jun 2017 22:05:23 -0700
> Commit 9520ed8fb841 ("net: dsa: use cpu_switch instead of ds[0]")
> replaced the use of dst->ds[0] with dst->cpu_switch since that is
> functionally equivalent, however, we can now run into an use after free
> scenario after unbinding then rebinding the switch driver.
>
> The use after free happens because we do correctly initialize
> dst->cpu_switch the first time we probe in dsa_cpu_parse(), then we
> unbind the driver: dsa_dst_unapply() is called, and we rebind again.
> dst->cpu_switch now points to a freed "ds" structure, and so when we
> finally dereference it in dsa_cpu_port_ethtool_setup(), we oops.
>
> To fix this, simply set dst->cpu_switch to NULL in dsa_dst_unapply()
> which guarantees that we always correctly re-assign dst->cpu_switch in
> dsa_cpu_parse().
>
> Fixes: 9520ed8fb841 ("net: dsa: use cpu_switch instead of ds[0]")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] net: ping: do not abuse udp_poll()
From: David Miller @ 2017-06-05 2:58 UTC (permalink / raw)
To: eric.dumazet
Cc: edumazet, lorenzo, segoon, solar, alexander.levin, pabeni, netdev,
linux-kernel
In-Reply-To: <1496507365.5031.16.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 03 Jun 2017 09:29:25 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Alexander reported various KASAN messages triggered in recent kernels
>
> The problem is that ping sockets should not use udp_poll() in the first
> place, and recent changes in UDP stack finally exposed this old bug.
>
> Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
> Fixes: 6d0bfe226116 ("net: ipv6: Add IPv6 support to the ping socket.")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Sasha Levin <alexander.levin@verizon.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next v10 0/5] Avoiding stack overflow in skb_to_sgvec
From: David Miller @ 2017-06-05 3:03 UTC (permalink / raw)
To: Jason; +Cc: netdev, linux-kernel, kernel-hardening
In-Reply-To: <20170604021626.11968-1-Jason@zx2c4.com>
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: Sun, 4 Jun 2017 04:16:21 +0200
> Changes v9->v10:
> - Spaces to tabs on one line.
> - Added some acked-by, reviewed-by lines.
I wish in the future you would retain the entire change history, and
keep it in it's entirety here in the header postings. That list of
adjustments is important and might be useful to someone in the future
("why didn't they do this, oh they decided to not do that
intentionally I can see that in the Change list").
> The recent bug with macsec and historical one with virtio have
> indicated that letting skb_to_sgvec trounce all over an sglist
> without checking the length is probably a bad idea. And it's not
> necessary either: an sglist already explicitly marks its last
> item, and the initialization functions are diligent in doing so.
> Thus there's a clear way of avoiding future overflows.
>
> So, this patchset, from a high level, makes skb_to_sgvec return
> a potential error code, and then adjusts all callers to check
> for the error code. There are two situations in which skb_to_sgvec
> might return such an error:
>
> 1) When the passed in sglist is too small; and
> 2) When the passed in skbuff is too deeply nested.
>
> So, the first patch in this series handles the issues with
> skb_to_sgvec directly, and the remaining ones then handle the call
> sites.
Applied to net-next.
^ 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