* Re: [GIT] Networking
From: David Miller @ 2017-09-06 23:31 UTC (permalink / raw)
To: torvalds
Cc: johannes.berg, emmanuel.grumbach, luciano.coelho, kvalo, akpm,
netdev, linux-kernel, linuxwifi, linux-wireless
In-Reply-To: <CA+55aFw0KNTKFrRHk5hthDGTGgL9BGt9G=x_m9Tz7m_-pN+NoA@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 6 Sep 2017 16:27:15 -0700
> This pull request completely breaks Intel wireless for me.
>
> This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a).
>
> That remains a very standard Intel machine with absolutely zero odd
> things going on.
>
> The firmware is iwlwifi-8000C-28.ucode from
> iwl7260-firmware-25.30.13.0-75.fc26.noarch, and the kernel reports
...
Johannes and other Intel folks please look into this.
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2017-09-06 23:37 UTC (permalink / raw)
To: David Miller, Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Kalle Valo
Cc: Andrew Morton, Network Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux Wireless List
In-Reply-To: <CA+55aFw0KNTKFrRHk5hthDGTGgL9BGt9G=x_m9Tz7m_-pN+NoA@mail.gmail.com>
On Wed, Sep 6, 2017 at 4:27 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> The firmware is iwlwifi-8000C-28.ucode from
> iwl7260-firmware-25.30.13.0-75.fc26.noarch, and the kernel reports
>
> iwlwifi 0000:3a:00.0: loaded firmware version 27.455470.0 op_mode iwlmvm
And when I said "iwlwifi-8000C-28.ucode" I obviously meant
"iwlwifi-8000C-27.ucode".
At least it was _hopefully_ obvious from that "27" in the actual
version number it reports.
Linus
^ permalink raw reply
* Re: [patch net] net: sched: fix memleak for chain zero
From: Cong Wang @ 2017-09-06 23:37 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
Jakub Kicinski, mlxsw
In-Reply-To: <20170906203323.GA16570@nanopsycho>
On Wed, Sep 6, 2017 at 1:33 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> Wed, Sep 06, 2017 at 07:40:02PM CEST, xiyou.wangcong@gmail.com wrote:
>>On Wed, Sep 6, 2017 at 4:14 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>> From: Jiri Pirko <jiri@mellanox.com>
>>>
>>> There's a memleak happening for chain 0. The thing is, chain 0 needs to
>>> be always present, not created on demand. Therefore tcf_block_get upon
>>> creation of block calls the tcf_chain_create function directly. The
>>> chain is created with refcnt == 1, which is not correct in this case and
>>> causes the memleak. So move the refcnt increment into tcf_chain_get
>>> function even for the case when chain needs to be created.
>>>
>>
>>Your approach could work but you just make the code even
>>uglier than it is now:
>>
>>1. The current code is already ugly for special-casing chain 0:
>>
>> if (--chain->refcnt == 0 && !chain->filter_chain && chain->index != 0)
>> tcf_chain_destroy(chain);
>>
>>2. With your patch, chain 0 has a different _initial_ refcnt with others.
>
> No. Initial refcnt is the same. ! for every action that holds the chain.
> So actually, it returns it back where it should be.
Not all all.
tcf_block_get() calls tcf_chain_create(, 0), after your patch
chain 0 has refcnt==0 initially.
Non-0 chain? They are created via tcf_chain_get(), aka,
refcnt==0 initially.
>
>
>>
>>3. Allowing an object (chain 0) exists with refcnt==0
>
> So? That is for every chain that does not have goto_chain action
> pointing at. Please read the code.
So you are pretending to be GC but you are apparently not.
You create all the troubles by setting yourself to believe chain 0
is special and refcnt==0 is okay. Both are wrong.
Actually the !list_empty() check is totally unnecessary too,
it is yet another place you get it wrong, you hide the race
condition in commit 744a4cf63e52 which makes it harder
to expose.
I understand you don't trust me. Look at DaveM's reaction
to your refcnt==0 madness.
Remember, refcnt can be very simple, you just want to
make it harder by abusing it or attempting to invent a GC.
I am going to update my patch (to remove all your madness)
since this is horribly wrong to me. Sorry.
^ permalink raw reply
* RE: [PATCH v2 rfc 0/8] IGMP snooping for local traffic
From: Woojung.Huh @ 2017-09-06 23:44 UTC (permalink / raw)
To: f.fainelli, andrew; +Cc: roopa, netdev, vivien.didelot, jbe, sean.wang, john
In-Reply-To: <44233399-2cb9-35af-2b93-b0024aac8dc4@gmail.com>
> That being said, I have a feeling that the Marvell switches behave a
> tiny bit differently than others in that they do not flood broadcast by
> default in a given L2 domain.
Florian,
Because some DSA switches from Marvell & Microchip can do IGMP snooping,
can we propose switch layer another flag what to do when HW support it?
- Woojung
^ permalink raw reply
* Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"
From: David Daney @ 2017-09-07 0:10 UTC (permalink / raw)
To: Florian Fainelli, David Daney, Mason
Cc: Marc Gonzalez, netdev, Geert Uytterhoeven, David Miller,
Andrew Lunn, Mans Rullgard
In-Reply-To: <a4b70bf9-ec48-314d-b63d-e44f7cbb4bab@gmail.com>
On 09/06/2017 04:14 PM, Florian Fainelli wrote:
> On 09/06/2017 03:51 PM, David Daney wrote:
[...]
>>
>> Consider instead the case of a Marvell phy with no interrupts connected
>> on a v4.9.43 kernel, single CPU:
>>
>>
>> 0) | phy_disconnect() {
>> 0) | phy_stop_machine() {
>> 0) | cancel_delayed_work_sync() {
>> 0) + 23.986 us | } /* cancel_delayed_work_sync */
>> 0) | phy_state_machine() {
>> 0) | phy_start_aneg_priv() {
>
> Thanks for providing the trace, I think I have an idea of what's going
> on, see below.
>
>> 0) | marvell_config_aneg() {
>> 0) ! 240.538 us | } /* marvell_config_aneg */
>> 0) ! 244.971 us | } /* phy_start_aneg_priv */
>> 0) | queue_delayed_work_on() {
>> 0) + 18.016 us | } /* queue_delayed_work_on */
>> 0) ! 268.184 us | } /* phy_state_machine */
>> 0) ! 297.394 us | } /* phy_stop_machine */
>> 0) | phy_detach() {
>> 0) | phy_suspend() {
>> 0) | phy_ethtool_get_wol() {
>> 0) 0.677 us | } /* phy_ethtool_get_wol */
>> 0) | genphy_suspend() {
>> 0) + 71.250 us | } /* genphy_suspend */
>> 0) + 74.197 us | } /* phy_suspend */
>> 0) + 80.302 us | } /* phy_detach */
>> 0) ! 380.072 us | } /* phy_disconnect */
>> .
>> .
>> .
>> 0) | process_one_work() {
>> 0) | find_worker_executing_work() {
>> 0) 0.688 us | } /* find_worker_executing_work */
>> 0) | set_work_pool_and_clear_pending() {
>> 0) 0.734 us | } /* set_work_pool_and_clear_pending */
>> 0) | phy_state_machine() {
>> 0) | genphy_read_status() {
>> 0) ! 205.721 us | } /* genphy_read_status */
>> 0) | netif_carrier_off() {
>> 0) | do_page_fault() {
>>
>>
>> The do_page_fault() at the end indicates the NULL pointer dereference.
>>
>> That added call to phy_state_machine() turns the polling back on
>> unconditionally for a phy that should be disconnected. How is that
>> correct?
>
> It is not fundamentally correct and I don't think there was any
> objection to that to begin with. In fact there is a bug/inefficiency
> here in that if we have entered the PHY state machine with PHY_HALTED we
> should not re-schedule it period, only applicable to PHY_POLL cases
> *and* properly calling phy_stop() followed by phy_disconnect().
>
> What I now think is happening in your case is the following:
>
> phy_stop() was not called, so nothing does set phydev->state to
> PHY_HALTED in the first place so we have:
>
> phy_disconnect()
> -> phy_stop_machine()
> -> cancel_delayed_work_sync() OK
> phydev->state is probably RUNNING so we have:
> -> phydev->state = PHY_UP
> phy_state_machine() is called synchronously
> -> PHY_UP -> needs_aneg = true
> -> phy_restart_aneg()
> -> queue_delayed_work_sync()
> -> phydev->adjust_link = NULL
> -> phy_deatch() -> boom
>
> Can you confirm whether the driver you are using does call phy_stop()
> prior to phy_disconnect()?
There is no call to phy_stop().
I can add this to the ethernet drivers, but I wonder if it should be
called by the code code when doing phy_disconnect(), if it was not
already stopped.
> If that is the case then this whole theory
> falls apart, if not, then this needs fixing in both the driver and PHYLIB.
>
> Thanks
>
^ permalink raw reply
* [PATCH RFC v1 0/3] Support for tap user-space access with veth interfaces
From: sainath.grandhi @ 2017-09-07 0:34 UTC (permalink / raw)
To: netdev; +Cc: davem, Sainath Grandhi
From: Sainath Grandhi <sainath.grandhi@intel.com>
This patchset adds a tap device driver for veth virtual network interface.
With this implementation, tap character interface can be added only to the
peer veth interface. Adding tap interface to veth is for usecases that forwards
packets between host and VMs. This eliminates the need for an additional
software bridge. This can be extended to create both the peer interfaces as
tap interfaces. These patches are a step in that direction.
Sainath Grandhi (3):
net: Adding API to parse IFLA_LINKINFO attribute
net: Abstracting out common routines from veth for use by vethtap
vethtap: veth based tap driver
drivers/net/Kconfig | 1 +
drivers/net/Makefile | 2 +
drivers/net/{veth.c => veth_main.c} | 80 ++++++++++---
drivers/net/vethtap.c | 216 ++++++++++++++++++++++++++++++++++++
include/linux/if_veth.h | 13 +++
include/net/rtnetlink.h | 3 +
net/core/rtnetlink.c | 8 ++
7 files changed, 308 insertions(+), 15 deletions(-)
rename drivers/net/{veth.c => veth_main.c} (89%)
create mode 100644 drivers/net/vethtap.c
create mode 100644 include/linux/if_veth.h
--
2.7.4
^ permalink raw reply
* [PATCH RFC v1 1/3] net: Adding API to parse IFLA_LINKINFO attribute
From: sainath.grandhi @ 2017-09-07 0:34 UTC (permalink / raw)
To: netdev; +Cc: davem, Sainath Grandhi
In-Reply-To: <1504744467-79590-1-git-send-email-sainath.grandhi@intel.com>
From: Sainath Grandhi <sainath.grandhi@intel.com>
Adding rtnl_nla_parse_ifla_info as an exported symbol in rtnetlink.c helps
other modules to parse IFLA_LINKINFO attribute
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
---
include/net/rtnetlink.h | 3 +++
net/core/rtnetlink.c | 8 ++++++++
2 files changed, 11 insertions(+)
diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
index 21837ca..cb15ddb 100644
--- a/include/net/rtnetlink.h
+++ b/include/net/rtnetlink.h
@@ -170,6 +170,9 @@ int rtnl_configure_link(struct net_device *dev, const struct ifinfomsg *ifm);
int rtnl_nla_parse_ifla(struct nlattr **tb, const struct nlattr *head, int len,
struct netlink_ext_ack *exterr);
+int rtnl_nla_parse_ifla_info(struct nlattr **tb, const struct nlattr *head,
+ int len, struct netlink_ext_ack *exterr);
+
#define MODULE_ALIAS_RTNL_LINK(kind) MODULE_ALIAS("rtnl-link-" kind)
#endif
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index a78fd61..0784b7d 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1688,6 +1688,14 @@ int rtnl_nla_parse_ifla(struct nlattr **tb, const struct nlattr *head, int len,
}
EXPORT_SYMBOL(rtnl_nla_parse_ifla);
+int rtnl_nla_parse_ifla_info(struct nlattr **tb, const struct nlattr *head,
+ int len, struct netlink_ext_ack *exterr)
+{
+ return nla_parse(tb, IFLA_INFO_MAX, head, len, ifla_info_policy,
+ exterr);
+}
+EXPORT_SYMBOL(rtnl_nla_parse_ifla_info);
+
struct net *rtnl_link_get_net(struct net *src_net, struct nlattr *tb[])
{
struct net *net;
--
2.7.4
^ permalink raw reply related
* [PATCH RFC v1 2/3] net: Abstracting out common routines from veth for use by vethtap
From: sainath.grandhi @ 2017-09-07 0:34 UTC (permalink / raw)
To: netdev; +Cc: davem, Sainath Grandhi
In-Reply-To: <1504744467-79590-1-git-send-email-sainath.grandhi@intel.com>
From: Sainath Grandhi <sainath.grandhi@intel.com>
Abstracting out common routines for link operations in veth implementation
for use by vethtap interfaces
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
---
drivers/net/veth.c | 47 +++++++++++++++++++++++++++++++++--------------
include/linux/if_veth.h | 9 +++++++++
2 files changed, 42 insertions(+), 14 deletions(-)
create mode 100644 include/linux/if_veth.h
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index f5438d0..a1b370d 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -18,6 +18,7 @@
#include <net/dst.h>
#include <net/xfrm.h>
#include <linux/veth.h>
+#include <linux/if_veth.h>
#include <linux/module.h>
#define DRV_NAME "veth"
@@ -29,12 +30,6 @@ struct pcpu_vstats {
struct u64_stats_sync syncp;
};
-struct veth_priv {
- struct net_device __rcu *peer;
- atomic64_t dropped;
- unsigned requested_headroom;
-};
-
/*
* ethtool interface
*/
@@ -298,13 +293,12 @@ static const struct net_device_ops veth_netdev_ops = {
NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX | \
NETIF_F_HW_VLAN_STAG_TX | NETIF_F_HW_VLAN_STAG_RX )
-static void veth_setup(struct net_device *dev)
+void veth_common_setup(struct net_device *dev)
{
ether_setup(dev);
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
- dev->priv_flags |= IFF_NO_QUEUE;
dev->priv_flags |= IFF_PHONY_HEADROOM;
dev->netdev_ops = &veth_netdev_ops;
@@ -325,6 +319,12 @@ static void veth_setup(struct net_device *dev)
dev->mpls_features = NETIF_F_HW_CSUM | NETIF_F_GSO_SOFTWARE;
}
+static void veth_setup(struct net_device *dev)
+{
+ veth_common_setup(dev);
+ dev->priv_flags |= IFF_NO_QUEUE;
+}
+
/*
* netlink interface
*/
@@ -465,7 +465,7 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
return err;
}
-static void veth_dellink(struct net_device *dev, struct list_head *head)
+void veth_dellink(struct net_device *dev, struct list_head *head)
{
struct veth_priv *priv;
struct net_device *peer;
@@ -503,21 +503,40 @@ static struct rtnl_link_ops veth_link_ops = {
.kind = DRV_NAME,
.priv_size = sizeof(struct veth_priv),
.setup = veth_setup,
- .validate = veth_validate,
.newlink = veth_newlink,
.dellink = veth_dellink,
- .policy = veth_policy,
- .maxtype = VETH_INFO_MAX,
- .get_link_net = veth_get_link_net,
};
+int veth_link_register(struct rtnl_link_ops *ops)
+{
+ /* common fields */
+ ops->validate = veth_validate;
+ ops->policy = veth_policy;
+ ops->maxtype = VETH_INFO_MAX;
+ ops->get_link_net = veth_get_link_net;
+
+ return rtnl_link_register(ops);
+}
+
+void veth_link_ops_init(struct rtnl_link_ops *ops)
+{
+ /*common fields*/
+ ops->validate = veth_validate;
+ ops->policy = veth_policy;
+ ops->maxtype = VETH_INFO_MAX;
+ ops->get_link_net = veth_get_link_net;
+}
/*
* init/fini
*/
static __init int veth_init(void)
{
- return rtnl_link_register(&veth_link_ops);
+ int err;
+
+ err = veth_link_register(&veth_link_ops);
+
+ return err;
}
static __exit void veth_exit(void)
diff --git a/include/linux/if_veth.h b/include/linux/if_veth.h
new file mode 100644
index 0000000..b007891
--- /dev/null
+++ b/include/linux/if_veth.h
@@ -0,0 +1,9 @@
+struct veth_priv {
+ struct net_device __rcu *peer;
+ atomic64_t dropped;
+ unsigned int requested_headroom;
+};
+
+void veth_common_setup(struct net_device *dev);
+void veth_dellink(struct net_device *dev, struct list_head *head);
+void veth_link_ops_init(struct rtnl_link_ops *ops);
--
2.7.4
^ permalink raw reply related
* [PATCH RFC v1 3/3] vethtap: veth based tap driver
From: sainath.grandhi @ 2017-09-07 0:34 UTC (permalink / raw)
To: netdev; +Cc: davem, Sainath Grandhi
In-Reply-To: <1504744467-79590-1-git-send-email-sainath.grandhi@intel.com>
From: Sainath Grandhi <sainath.grandhi@intel.com>
This patch adds a tap character device driver that is based on the
veth network interface, called vethtap. This patchset allows vethtap device
to be created ONLY as a peer interface to a veth network interface. It can
be created in the following way,
ip link add veth1 type veth peer name veth2 type vethtap
With this packets on veth2 can be accessed using tap user space interface.
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
---
drivers/net/Kconfig | 1 +
drivers/net/Makefile | 2 +
drivers/net/{veth.c => veth_main.c} | 33 +++++-
drivers/net/vethtap.c | 216 ++++++++++++++++++++++++++++++++++++
include/linux/if_veth.h | 4 +
5 files changed, 255 insertions(+), 1 deletion(-)
rename drivers/net/{veth.c => veth_main.c} (94%)
create mode 100644 drivers/net/vethtap.c
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index aba0d65..265853e 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -323,6 +323,7 @@ config TUN_VNET_CROSS_LE
config VETH
tristate "Virtual ethernet pair device"
+ select TAP
---help---
This device is a local ethernet tunnel. Devices are created in pairs.
When one end receives the packet it appears on its pair and vice
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 8dff900..7c63e69 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -32,6 +32,8 @@ obj-$(CONFIG_NLMON) += nlmon.o
obj-$(CONFIG_NET_VRF) += vrf.o
obj-$(CONFIG_VSOCKMON) += vsockmon.o
+veth-objs := veth_main.o vethtap.o
+
#
# Networking Drivers
#
diff --git a/drivers/net/veth.c b/drivers/net/veth_main.c
similarity index 94%
rename from drivers/net/veth.c
rename to drivers/net/veth_main.c
index a1b370d..fc91dd7 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth_main.c
@@ -359,6 +359,9 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
unsigned char name_assign_type;
struct ifinfomsg *ifmp;
struct net *net;
+ struct nlattr *linkinfo[IFLA_INFO_MAX + 1];
+ char peer_type[8];
+ struct rtnl_link_ops *link_ops;
/*
* create and register peer first
@@ -393,17 +396,38 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
name_assign_type = NET_NAME_ENUM;
}
+ link_ops = &veth_link_ops;
+ if (tbp[IFLA_LINKINFO]) {
+ err = rtnl_nla_parse_ifla_info(linkinfo,
+ nla_data(tbp[IFLA_LINKINFO]),
+ nla_len(tbp[IFLA_LINKINFO]),
+ NULL);
+
+ if (err < 0)
+ return err;
+
+ if (linkinfo[IFLA_INFO_KIND]) {
+ nla_strlcpy(peer_type, linkinfo[IFLA_INFO_KIND],
+ sizeof(peer_type));
+ if (!strncmp(peer_type, "vethtap", sizeof(peer_type)))
+ link_ops = &vethtap_link_ops;
+ }
+ }
+
net = rtnl_link_get_net(src_net, tbp);
if (IS_ERR(net))
return PTR_ERR(net);
peer = rtnl_create_link(net, ifname, name_assign_type,
- &veth_link_ops, tbp);
+ link_ops, tbp);
if (IS_ERR(peer)) {
put_net(net);
return PTR_ERR(peer);
}
+ if (!strncmp(peer_type, "vethtap", sizeof(peer_type)))
+ link_ops->newlink(net, peer, tbp, NULL, NULL);
+
if (!ifmp || !tbp[IFLA_ADDRESS])
eth_hw_addr_random(peer);
@@ -536,12 +560,19 @@ static __init int veth_init(void)
err = veth_link_register(&veth_link_ops);
+ if (err)
+ goto out1;
+
+ err = vethtap_init();
+
+out1:
return err;
}
static __exit void veth_exit(void)
{
rtnl_link_unregister(&veth_link_ops);
+ vethtap_exit();
}
module_init(veth_init);
diff --git a/drivers/net/vethtap.c b/drivers/net/vethtap.c
new file mode 100644
index 0000000..922b3ea
--- /dev/null
+++ b/drivers/net/vethtap.c
@@ -0,0 +1,216 @@
+#include <linux/etherdevice.h>
+#include <linux/if_tap.h>
+#include <linux/if_vlan.h>
+#include <linux/if_veth.h>
+#include <linux/interrupt.h>
+#include <linux/nsproxy.h>
+#include <linux/compat.h>
+#include <linux/if_tun.h>
+#include <linux/module.h>
+#include <linux/skbuff.h>
+#include <linux/cache.h>
+#include <linux/sched/signal.h>
+#include <linux/types.h>
+#include <linux/slab.h>
+#include <linux/wait.h>
+#include <linux/cdev.h>
+#include <linux/idr.h>
+#include <linux/fs.h>
+#include <linux/uio.h>
+
+#include <net/net_namespace.h>
+#include <net/rtnetlink.h>
+#include <net/sock.h>
+#include <linux/virtio_net.h>
+#include <linux/skb_array.h>
+
+struct vethtap_dev {
+ struct veth_priv veth;
+ struct tap_dev tap;
+};
+
+/* Variables for dealing with vethtaps device numbers.
+ */
+static dev_t vethtap_major;
+
+static const void *vethtap_net_namespace(struct device *d)
+{
+ struct net_device *dev = to_net_dev(d->parent);
+
+ return dev_net(dev);
+}
+
+static struct class vethtap_class = {
+ .name = "vethtap",
+ .owner = THIS_MODULE,
+ .ns_type = &net_ns_type_operations,
+ .namespace = vethtap_net_namespace,
+};
+
+static struct cdev vethtap_cdev;
+
+#define TUN_OFFLOADS (NETIF_F_HW_CSUM | NETIF_F_TSO_ECN | NETIF_F_TSO | \
+ NETIF_F_TSO6)
+
+static void vethtap_count_tx_dropped(struct tap_dev *tap)
+{
+ struct vethtap_dev *vethtap = container_of(tap, struct vethtap_dev,
+ tap);
+ struct veth_priv *veth = &vethtap->veth;
+
+ atomic64_inc(&veth->dropped);
+}
+
+static int vethtap_newlink(struct net *src_net, struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[],
+ struct netlink_ext_ack *extack)
+{
+ struct vethtap_dev *vethtap = netdev_priv(dev);
+ int err;
+
+ INIT_LIST_HEAD(&vethtap->tap.queue_list);
+
+ /* Since macvlan supports all offloads by default, make
+ * tap support all offloads also.
+ */
+ vethtap->tap.tap_features = TUN_OFFLOADS;
+
+ /* Register callbacks for rx/tx drops accounting and updating
+ * net_device features
+ */
+ vethtap->tap.count_tx_dropped = vethtap_count_tx_dropped;
+ vethtap->tap.count_rx_dropped = NULL;
+ vethtap->tap.update_features = NULL;
+
+ err = netdev_rx_handler_register(dev, tap_handle_frame, &vethtap->tap);
+ if (err)
+ return err;
+
+ vethtap->tap.dev = dev;
+
+ return 0;
+}
+
+static void vethtap_dellink(struct net_device *dev,
+ struct list_head *head)
+{
+ struct vethtap_dev *vethtap = netdev_priv(dev);
+
+ netdev_rx_handler_unregister(dev);
+ tap_del_queues(&vethtap->tap);
+ veth_dellink(dev, head);
+}
+
+static void vethtap_setup(struct net_device *dev)
+{
+ veth_common_setup(dev);
+ dev->tx_queue_len = TUN_READQ_SIZE;
+}
+
+struct rtnl_link_ops vethtap_link_ops __read_mostly = {
+ .kind = "vethtap",
+ .setup = vethtap_setup,
+ .newlink = vethtap_newlink,
+ .dellink = vethtap_dellink,
+ .priv_size = sizeof(struct vethtap_dev),
+};
+
+static int vethtap_device_event(struct notifier_block *unused,
+ unsigned long event, void *ptr)
+{
+ struct net_device *dev = netdev_notifier_info_to_dev(ptr);
+ struct vethtap_dev *vethtap;
+ struct device *classdev;
+ dev_t devt;
+ int err;
+ char tap_name[IFNAMSIZ];
+
+ if (dev->rtnl_link_ops != &vethtap_link_ops)
+ return NOTIFY_DONE;
+
+ snprintf(tap_name, IFNAMSIZ, "tap%d", dev->ifindex);
+ vethtap = netdev_priv(dev);
+
+ switch (event) {
+ case NETDEV_REGISTER:
+ /* Create the device node here after the network device has
+ * been registered but before register_netdevice has
+ * finished running.
+ */
+ err = tap_get_minor(vethtap_major, &vethtap->tap);
+ if (err)
+ return notifier_from_errno(err);
+
+ devt = MKDEV(MAJOR(vethtap_major), vethtap->tap.minor);
+ classdev = device_create(&vethtap_class, &dev->dev, devt,
+ dev, tap_name);
+ if (IS_ERR(classdev)) {
+ tap_free_minor(vethtap_major, &vethtap->tap);
+ return notifier_from_errno(PTR_ERR(classdev));
+ }
+ err = sysfs_create_link(&dev->dev.kobj, &classdev->kobj,
+ tap_name);
+ if (err)
+ return notifier_from_errno(err);
+ break;
+ case NETDEV_UNREGISTER:
+ /* vlan->minor == 0 if NETDEV_REGISTER above failed */
+ if (vethtap->tap.minor == 0)
+ break;
+ sysfs_remove_link(&dev->dev.kobj, tap_name);
+ devt = MKDEV(MAJOR(vethtap_major), vethtap->tap.minor);
+ device_destroy(&vethtap_class, devt);
+ tap_free_minor(vethtap_major, &vethtap->tap);
+ break;
+ case NETDEV_CHANGE_TX_QUEUE_LEN:
+ if (tap_queue_resize(&vethtap->tap))
+ return NOTIFY_BAD;
+ break;
+ }
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block vethtap_notifier_block __read_mostly = {
+ .notifier_call = vethtap_device_event,
+};
+
+int vethtap_init(void)
+{
+ int err;
+
+ err = tap_create_cdev(&vethtap_cdev, &vethtap_major, "vethtap");
+
+ if (err)
+ goto out1;
+
+ err = class_register(&vethtap_class);
+ if (err)
+ goto out2;
+
+ err = register_netdevice_notifier(&vethtap_notifier_block);
+ if (err)
+ goto out3;
+
+ veth_link_ops_init(&vethtap_link_ops);
+ if (err)
+ goto out4;
+
+ return 0;
+
+out4:
+ unregister_netdevice_notifier(&vethtap_notifier_block);
+out3:
+ class_unregister(&vethtap_class);
+out2:
+ tap_destroy_cdev(vethtap_major, &vethtap_cdev);
+out1:
+ return err;
+}
+
+void vethtap_exit(void)
+{
+ unregister_netdevice_notifier(&vethtap_notifier_block);
+ class_unregister(&vethtap_class);
+ tap_destroy_cdev(vethtap_major, &vethtap_cdev);
+}
diff --git a/include/linux/if_veth.h b/include/linux/if_veth.h
index b007891..dbc06c4 100644
--- a/include/linux/if_veth.h
+++ b/include/linux/if_veth.h
@@ -4,6 +4,10 @@ struct veth_priv {
unsigned int requested_headroom;
};
+extern struct rtnl_link_ops vethtap_link_ops;
+
void veth_common_setup(struct net_device *dev);
void veth_dellink(struct net_device *dev, struct list_head *head);
void veth_link_ops_init(struct rtnl_link_ops *ops);
+int vethtap_init(void);
+void vethtap_exit(void);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic
From: Andrew Lunn @ 2017-09-07 0:43 UTC (permalink / raw)
To: Woojung.Huh
Cc: f.fainelli, roopa, netdev, vivien.didelot, jbe, sean.wang, john
In-Reply-To: <9235D6609DB808459E95D78E17F2E43D40B19584@CHN-SV-EXMX02.mchp-main.com>
On Wed, Sep 06, 2017 at 11:44:47PM +0000, Woojung.Huh@microchip.com wrote:
> > That being said, I have a feeling that the Marvell switches behave a
> > tiny bit differently than others in that they do not flood broadcast by
> > default in a given L2 domain.
> Florian,
>
> Because some DSA switches from Marvell & Microchip can do IGMP snooping,
> can we propose switch layer another flag what to do when HW support it?
Hi Woojung
I expect all the current DSA devices should be able to do IGMP
snooping, with some modifications.
Two things are required:
1) The .port_mdb_prepare, .port_mdb_add and .port_mdb_del ops, so that
mdb entries can be added. As you said, only Marvell and Microchip
support these, but i expect the other switch can do this, it just
needs implementing.
2) The switch needs to identify and forward IGMP packets to the host,
even when they would normally be blocked.
And for the implementation, i don't think it actually matters. For
switches which don't implement the port_mdb operations, IGMP packets
will get forwarded to the software bridge. It will attempt to put in
an mdb, but the request will come back with EOPNOTSUPP. The switch
should continue to flood multicast out all ports. No harm done.
Andrew
^ permalink raw reply
* Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic
From: Andrew Lunn @ 2017-09-07 0:47 UTC (permalink / raw)
To: Florian Fainelli
Cc: Roopa Prabhu, netdev, Vivien Didelot, Woojung.Huh, jbe, sean.wang,
john
In-Reply-To: <44233399-2cb9-35af-2b93-b0024aac8dc4@gmail.com>
> At the very least we should probably move the skb->offload_fwd_mark
> setting down into the individual taggers since they should be in a
> better position to set it or not based on the switch device they are
> driving, this should address, on a per-switch basis whether 2) or 3)
> applies to a given switch.
Yes, that could be done.
> That being said, I have a feeling that the Marvell switches behave a
> tiny bit differently than others in that they do not flood broadcast by
> default in a given L2 domain.
It seems like the switch can be configured to flood broadcast. Just at
the moment, it is not.
> On b53/bcm_sf2 there is the ability to disable the reception of
> broadcast frames on the management/CPU port, and while there is the
> ability to configure which ports should be flooded in case of
> unicast/multicast lookup failures, I don't see anything for Broadcast,
> so I am assuming this will get forwarded by default. Will test with your
> patch set later on time permitting.
Please let me know the results of the tests.
If Marvell is being different, it also means that all other switches
today are duplicating broadcasts. We should fix that. In fact, i think
we need to fix this first, before these patches for IGMP snooping on
br0 goes in.
Andrew
^ permalink raw reply
* Re: [PATCH net 2/2] i40e: Avoid some useless variables and initializers in nvm functions
From: Jeff Kirsher @ 2017-09-07 1:13 UTC (permalink / raw)
To: Stefano Brivio, netdev, intel-wired-lan
Cc: David S . Miller, Anjali Singhai Jain
In-Reply-To: <d0881adf53a3f0a546b3e7940b92b4ce938e7e50.1504684488.git.sbrivio@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 571 bytes --]
On Wed, 2017-09-06 at 10:11 +0200, Stefano Brivio wrote:
> Fixes: 09f79fd49d94 ("i40e: avoid NVM acquire deadlock during NVM
> update")
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_nvm.c | 20 +++++++-------------
> 1 file changed, 7 insertions(+), 13 deletions(-)
This is NOT a fix, it is a coding style preference whether or not you
like multiple returns or a single return in functions. I do not mind
picking this up for net-next (4.15 kernel), but this does not qualify
for a fix for Dave's net tree.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net 1/2] i40e: Fix comment about locking for __i40e_read_nvm_word()
From: Jeff Kirsher @ 2017-09-07 1:16 UTC (permalink / raw)
To: Stefano Brivio, netdev, intel-wired-lan
Cc: David S . Miller, Anjali Singhai Jain
In-Reply-To: <4d27bbb33031ac1489fe6d969edd74d44155136c.1504684488.git.sbrivio@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 663 bytes --]
On Wed, 2017-09-06 at 10:11 +0200, Stefano Brivio wrote:
> Caller needs to acquire the lock. Called functions will not.
>
> Fixes: 09f79fd49d94 ("i40e: avoid NVM acquire deadlock during NVM
> update")
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_nvm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Yes, this fixes the function header comment, not sure if it requires
the "Fixes:" tag. If that were the case, wonder why all the other code
comment changes do not have this. :-) I do agree it reads better with
this change, so I do not have an issue queue this up for Dave's net
tree.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* LOAN AVAILABLE @3 %
From: Mr @ 2017-09-07 1:37 UTC (permalink / raw)
To: Recipients
LOAN AVAILABLE @3 % Rely mohammedanisa01@gmail.com
^ permalink raw reply
* Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"
From: Florian Fainelli @ 2017-09-07 1:41 UTC (permalink / raw)
To: David Daney, David Daney, Mason
Cc: Marc Gonzalez, netdev, Geert Uytterhoeven, David Miller,
Andrew Lunn, Mans Rullgard
In-Reply-To: <64800ff2-201b-eb26-304e-1c4c6e0a6d5e@caviumnetworks.com>
On 09/06/2017 05:10 PM, David Daney wrote:
> On 09/06/2017 04:14 PM, Florian Fainelli wrote:
>> On 09/06/2017 03:51 PM, David Daney wrote:
> [...]
>>>
>>> Consider instead the case of a Marvell phy with no interrupts connected
>>> on a v4.9.43 kernel, single CPU:
>>>
>>>
>>> 0) | phy_disconnect() {
>>> 0) | phy_stop_machine() {
>>> 0) | cancel_delayed_work_sync() {
>>> 0) + 23.986 us | } /*
>>> cancel_delayed_work_sync */
>>> 0) | phy_state_machine() {
>>> 0) | phy_start_aneg_priv() {
>>
>> Thanks for providing the trace, I think I have an idea of what's going
>> on, see below.
>>
>>> 0) | marvell_config_aneg() {
>>> 0) ! 240.538 us | } /*
>>> marvell_config_aneg */
>>> 0) ! 244.971 us | } /* phy_start_aneg_priv */
>>> 0) | queue_delayed_work_on() {
>>> 0) + 18.016 us | } /*
>>> queue_delayed_work_on */
>>> 0) ! 268.184 us | } /* phy_state_machine */
>>> 0) ! 297.394 us | } /* phy_stop_machine */
>>> 0) | phy_detach() {
>>> 0) | phy_suspend() {
>>> 0) | phy_ethtool_get_wol() {
>>> 0) 0.677 us | } /* phy_ethtool_get_wol */
>>> 0) | genphy_suspend() {
>>> 0) + 71.250 us | } /* genphy_suspend */
>>> 0) + 74.197 us | } /* phy_suspend */
>>> 0) + 80.302 us | } /* phy_detach */
>>> 0) ! 380.072 us | } /* phy_disconnect */
>>> .
>>> .
>>> .
>>> 0) | process_one_work() {
>>> 0) | find_worker_executing_work() {
>>> 0) 0.688 us | } /* find_worker_executing_work */
>>> 0) | set_work_pool_and_clear_pending() {
>>> 0) 0.734 us | } /* set_work_pool_and_clear_pending */
>>> 0) | phy_state_machine() {
>>> 0) | genphy_read_status() {
>>> 0) ! 205.721 us | } /* genphy_read_status */
>>> 0) | netif_carrier_off() {
>>> 0) | do_page_fault() {
>>>
>>>
>>> The do_page_fault() at the end indicates the NULL pointer dereference.
>>>
>>> That added call to phy_state_machine() turns the polling back on
>>> unconditionally for a phy that should be disconnected. How is that
>>> correct?
>>
>> It is not fundamentally correct and I don't think there was any
>> objection to that to begin with. In fact there is a bug/inefficiency
>> here in that if we have entered the PHY state machine with PHY_HALTED we
>> should not re-schedule it period, only applicable to PHY_POLL cases
>> *and* properly calling phy_stop() followed by phy_disconnect().
>>
>> What I now think is happening in your case is the following:
>>
>> phy_stop() was not called, so nothing does set phydev->state to
>> PHY_HALTED in the first place so we have:
>>
>> phy_disconnect()
>> -> phy_stop_machine()
>> -> cancel_delayed_work_sync() OK
>> phydev->state is probably RUNNING so we have:
>> -> phydev->state = PHY_UP
>> phy_state_machine() is called synchronously
>> -> PHY_UP -> needs_aneg = true
>> -> phy_restart_aneg()
>> -> queue_delayed_work_sync()
>> -> phydev->adjust_link = NULL
>> -> phy_deatch() -> boom
>>
>> Can you confirm whether the driver you are using does call phy_stop()
>> prior to phy_disconnect()?
>
> There is no call to phy_stop().
OK this all makes sense now.
>
> I can add this to the ethernet drivers, but I wonder if it should be
> called by the code code when doing phy_disconnect(), if it was not
> already stopped.
Fixing the driver should be reasonably quick and easy and can be done
independently from fixing PHYLIB, but I agree that PHYLIB should be
safeguarded against such a case.
Of course, now that I looked again at the code, there is really a ton of
unnecessary workqueue scheduling going on, similarly to phy_stop()
making us go from PHY_HALTED to PHY_HALTED, phy_start_machine() does the
same thing with PHY_READY -> PHY_READY, I suppose back when this was
done the assumption was that there is not going to be a tremendous
amount of time being spent between a call to
phy_connect()/phy_start_machine() and phy_start() and respectively
phy_stop() followed by a phy_disconnect(), oh well.
Now that the revert is in 4.13 we can work on a solution that satisfies
everybody on this thread.
Thanks!
--
Florian
^ permalink raw reply
* [PATCH] ipv4: Namespaceify tcp_max_orphans knob
From: Haishuang Yan @ 2017-09-07 3:10 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Eric Dumazet
Cc: netdev, linux-kernel, Haishuang Yan
Different namespace application might require different maximal number
of TCP sockets independently of the host.
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
include/net/netns/ipv4.h | 1 +
include/net/tcp.h | 5 +++--
net/ipv4/sysctl_net_ipv4.c | 14 +++++++-------
net/ipv4/tcp.c | 3 ---
net/ipv4/tcp_input.c | 1 -
net/ipv4/tcp_ipv4.c | 1 +
6 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index 20d061c..305e031 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -127,6 +127,7 @@ struct netns_ipv4 {
int sysctl_tcp_timestamps;
struct inet_timewait_death_row tcp_death_row;
int sysctl_max_syn_backlog;
+ int sysctl_tcp_max_orphans;
#ifdef CONFIG_NET_L3_MASTER_DEV
int sysctl_udp_l3mdev_accept;
diff --git a/include/net/tcp.h b/include/net/tcp.h
index b510f28..ac2d998 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -320,10 +320,11 @@ static inline bool tcp_too_many_orphans(struct sock *sk, int shift)
{
struct percpu_counter *ocp = sk->sk_prot->orphan_count;
int orphans = percpu_counter_read_positive(ocp);
+ int tcp_max_orphans = sock_net(sk)->ipv4.sysctl_tcp_max_orphans;
- if (orphans << shift > sysctl_tcp_max_orphans) {
+ if (orphans << shift > tcp_max_orphans) {
orphans = percpu_counter_sum_positive(ocp);
- if (orphans << shift > sysctl_tcp_max_orphans)
+ if (orphans << shift > tcp_max_orphans)
return true;
}
return false;
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 0d3c038..4f26c8d3 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -394,13 +394,6 @@ static int proc_tcp_available_ulp(struct ctl_table *ctl,
.proc_handler = proc_dointvec
},
{
- .procname = "tcp_max_orphans",
- .data = &sysctl_tcp_max_orphans,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec
- },
- {
.procname = "tcp_fastopen",
.data = &sysctl_tcp_fastopen,
.maxlen = sizeof(int),
@@ -1085,6 +1078,13 @@ static int proc_tcp_available_ulp(struct ctl_table *ctl,
.mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .procname = "tcp_max_orphans",
+ .data = &init_net.ipv4.sysctl_tcp_max_orphans,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
#ifdef CONFIG_IP_ROUTE_MULTIPATH
{
.procname = "fib_multipath_use_neigh",
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 5091402..39187ac 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3522,9 +3522,6 @@ void __init tcp_init(void)
}
- cnt = tcp_hashinfo.ehash_mask + 1;
- sysctl_tcp_max_orphans = cnt / 2;
-
tcp_init_mem();
/* Set per-socket limits to no more than 1/128 the pressure threshold */
limit = nr_free_buffer_pages() << (PAGE_SHIFT - 7);
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index c5d7656..0230509 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -88,7 +88,6 @@
int sysctl_tcp_stdurg __read_mostly;
int sysctl_tcp_rfc1337 __read_mostly;
-int sysctl_tcp_max_orphans __read_mostly = NR_FILE;
int sysctl_tcp_frto __read_mostly = 2;
int sysctl_tcp_min_rtt_wlen __read_mostly = 300;
int sysctl_tcp_moderate_rcvbuf __read_mostly = 1;
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index a63486a..4b17a91 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2468,6 +2468,7 @@ static int __net_init tcp_sk_init(struct net *net)
net->ipv4.tcp_death_row.hashinfo = &tcp_hashinfo;
net->ipv4.sysctl_max_syn_backlog = max(128, cnt / 256);
+ net->ipv4.sysctl_tcp_max_orphans = cnt / 2;
net->ipv4.sysctl_tcp_sack = 1;
net->ipv4.sysctl_tcp_window_scaling = 1;
net->ipv4.sysctl_tcp_timestamps = 1;
--
1.8.3.1
^ permalink raw reply related
* Re: [GIT] Networking
From: Coelho, Luciano @ 2017-09-07 4:11 UTC (permalink / raw)
To: torvalds@linux-foundation.org, davem@davemloft.net,
kvalo@codeaurora.org, Berg, Johannes, Grumbach, Emmanuel
Cc: linuxwifi, netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org, akpm@linux-foundation.org
In-Reply-To: <CA+55aFw0KNTKFrRHk5hthDGTGgL9BGt9G=x_m9Tz7m_-pN+NoA@mail.gmail.com>
On Wed, 2017-09-06 at 16:27 -0700, Linus Torvalds wrote:
> This pull request completely breaks Intel wireless for me.
>
> This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a).
>
> That remains a very standard Intel machine with absolutely zero odd
> things going on.
>
> The firmware is iwlwifi-8000C-28.ucode from
> iwl7260-firmware-25.30.13.0-75.fc26.noarch, and the kernel reports
>
> iwlwifi 0000:3a:00.0: loaded firmware version 27.455470.0 op_mode iwlmvm
>
> the thing starts acting badly with this:
>
> iwlwifi 0000:3a:00.0: FW Error notification: type 0x00000000 cmd_id 0x04
> iwlwifi 0000:3a:00.0: FW Error notification: seq 0x0000 service 0x00000004
> iwlwifi 0000:3a:00.0: FW Error notification: timestamp 0x 5D84
> iwlwifi 0000:3a:00.0: Microcode SW error detected. Restarting 0x2000000.
> iwlwifi 0000:3a:00.0: Start IWL Error Log Dump:
> iwlwifi 0000:3a:00.0: Status: 0x00000100, count: 6
> iwlwifi 0000:3a:00.0: Loaded firmware version: 27.455470.0
> iwlwifi 0000:3a:00.0: 0x00000038 | BAD_COMMAND
> iwlwifi 0000:3a:00.0: 0x00A002F0 | trm_hw_status0
> ...
> iwlwifi 0000:3a:00.0: 0x00000000 | isr status reg
> ieee80211 phy0: Hardware restart was requested
> iwlwifi 0000:3a:00.0: FW error in SYNC CMD MAC_CONTEXT_CMD
This seems to be a problem with backwards-compatibility with FW version
27. We are now in version 31[1] and upgrading will probably fix that.
But obviously the driver should not fail miserably like this with
version 27, because it claims to support it still.
I'm looking into this now and will provide a fix asap.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/iwlwifi-8000C-31.ucode
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] dt-binding: phy: don't confuse with Ethernet phy properties
From: David Miller @ 2017-09-07 4:14 UTC (permalink / raw)
To: baruch; +Cc: kishon, linux-kernel, netdev
In-Reply-To: <0a90f4b3cc903af6f82002e502deba67f374c602.1504449136.git.baruch@tkos.co.il>
From: Baruch Siach <baruch@tkos.co.il>
Date: Sun, 3 Sep 2017 17:32:16 +0300
> The generic PHY 'phys' property sometime appears in the same node with
> the Ethernet PHY 'phy' or 'phy-handle' properties. Add a warning in
> phy-bindings.txt to reduce confusion.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Applied.
^ permalink raw reply
* Re: [PATCH net] netlink: fix an use-after-free issue for nlk groups
From: David Miller @ 2017-09-07 4:24 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, fw, chunwang, syzkaller
In-Reply-To: <1217baf9faf9d034ba8224cb6362b822c51a0eae.1504669632.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Wed, 6 Sep 2017 11:47:12 +0800
> ChunYu found a netlink use-after-free issue by syzkaller:
>
> [28448.842981] BUG: KASAN: use-after-free in __nla_put+0x37/0x40 at addr ffff8807185e2378
> [28448.969918] Call Trace:
> [...]
> [28449.117207] __nla_put+0x37/0x40
> [28449.132027] nla_put+0xf5/0x130
> [28449.146261] sk_diag_fill.isra.4.constprop.5+0x5a0/0x750 [netlink_diag]
> [28449.176608] __netlink_diag_dump+0x25a/0x700 [netlink_diag]
> [28449.202215] netlink_diag_dump+0x176/0x240 [netlink_diag]
> [28449.226834] netlink_dump+0x488/0xbb0
> [28449.298014] __netlink_dump_start+0x4e8/0x760
> [28449.317924] netlink_diag_handler_dump+0x261/0x340 [netlink_diag]
> [28449.413414] sock_diag_rcv_msg+0x207/0x390
> [28449.432409] netlink_rcv_skb+0x149/0x380
> [28449.467647] sock_diag_rcv+0x2d/0x40
> [28449.484362] netlink_unicast+0x562/0x7b0
> [28449.564790] netlink_sendmsg+0xaa8/0xe60
> [28449.661510] sock_sendmsg+0xcf/0x110
> [28449.865631] __sys_sendmsg+0xf3/0x240
> [28450.000964] SyS_sendmsg+0x32/0x50
> [28450.016969] do_syscall_64+0x25c/0x6c0
> [28450.154439] entry_SYSCALL64_slow_path+0x25/0x25
>
> It was caused by no protection between nlk groups' free in netlink_release
> and nlk groups' accessing in sk_diag_dump_groups. The similar issue also
> exists in netlink_seq_show().
>
> This patch is to defer nlk groups' free in deferred_put_nlk_sk.
>
> Reported-by: ChunYu Wang <chunwang@redhat.com>
> Acked-by: Florian Westphal <fw@strlen.de>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] netlink: access nlk groups safely in netlink bind and getname
From: David Miller @ 2017-09-07 4:24 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, fw
In-Reply-To: <cfb5c05d158b278beb2f1441c67a068a8bb27d44.1504670009.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Wed, 6 Sep 2017 11:53:29 +0800
> Now there is no lock protecting nlk ngroups/groups' accessing in
> netlink bind and getname. It's safe from nlk groups' setting in
> netlink_release, but not from netlink_realloc_groups called by
> netlink_setsockopt.
>
> netlink_lock_table is needed in both netlink bind and getname when
> accessing nlk groups.
>
> Acked-by: Florian Westphal <fw@strlen.de>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] tipc: remove unnecessary call to dev_net()
From: David Miller @ 2017-09-07 4:26 UTC (permalink / raw)
To: kleber.souza; +Cc: netdev, jon.maloy, ying.xue
In-Reply-To: <20170906090806.20931-1-kleber.souza@canonical.com>
From: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Date: Wed, 6 Sep 2017 11:08:06 +0200
> The net device is already stored in the 'net' variable, so no need to call
> dev_net() again.
>
> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Applied, thanks.
^ permalink raw reply
* [Patch net v2 1/2] net_sched: get rid of tcfa_rcu
From: Cong Wang @ 2017-09-07 4:26 UTC (permalink / raw)
To: netdev; +Cc: jakub.kicinski, Cong Wang, Jiri Pirko, Eric Dumazet
gen estimator has been rewritten in commit 1c0d32fde5bd
("net_sched: gen_estimator: complete rewrite of rate estimators"),
the caller is no longer needed to wait for a grace period.
So this patch gets rid of it.
This also completely closes a race condition between action free
path and filter chain add/remove path for the following patch.
Because otherwise the nested RCU callback can't be caught by
rcu_barrier().
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
include/net/act_api.h | 2 --
net/sched/act_api.c | 12 +++---------
2 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/include/net/act_api.h b/include/net/act_api.h
index 26ffd8333f50..68218a5f8e72 100644
--- a/include/net/act_api.h
+++ b/include/net/act_api.h
@@ -38,7 +38,6 @@ struct tc_action {
struct gnet_stats_queue tcfa_qstats;
struct net_rate_estimator __rcu *tcfa_rate_est;
spinlock_t tcfa_lock;
- struct rcu_head tcfa_rcu;
struct gnet_stats_basic_cpu __percpu *cpu_bstats;
struct gnet_stats_queue __percpu *cpu_qstats;
struct tc_cookie *act_cookie;
@@ -55,7 +54,6 @@ struct tc_action {
#define tcf_qstats common.tcfa_qstats
#define tcf_rate_est common.tcfa_rate_est
#define tcf_lock common.tcfa_lock
-#define tcf_rcu common.tcfa_rcu
static inline unsigned int tcf_hash(u32 index, unsigned int hmask)
{
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index f2e9ed34a963..fc17d286a6a2 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -53,10 +53,8 @@ static void tcf_action_goto_chain_exec(const struct tc_action *a,
res->goto_tp = rcu_dereference_bh(chain->filter_chain);
}
-static void free_tcf(struct rcu_head *head)
+static void free_tcf(struct tc_action *p)
{
- struct tc_action *p = container_of(head, struct tc_action, tcfa_rcu);
-
free_percpu(p->cpu_bstats);
free_percpu(p->cpu_qstats);
@@ -76,11 +74,7 @@ static void tcf_hash_destroy(struct tcf_hashinfo *hinfo, struct tc_action *p)
hlist_del(&p->tcfa_head);
spin_unlock_bh(&hinfo->lock);
gen_kill_estimator(&p->tcfa_rate_est);
- /*
- * gen_estimator est_timer() might access p->tcfa_lock
- * or bstats, wait a RCU grace period before freeing p
- */
- call_rcu(&p->tcfa_rcu, free_tcf);
+ free_tcf(p);
}
int __tcf_hash_release(struct tc_action *p, bool bind, bool strict)
@@ -271,7 +265,7 @@ void tcf_hash_cleanup(struct tc_action *a, struct nlattr *est)
{
if (est)
gen_kill_estimator(&a->tcfa_rate_est);
- call_rcu(&a->tcfa_rcu, free_tcf);
+ free_tcf(a);
}
EXPORT_SYMBOL(tcf_hash_cleanup);
--
2.13.0
^ permalink raw reply related
* [Patch net v2 2/2] net_sched: fix all the madness of tc filter chain
From: Cong Wang @ 2017-09-07 4:26 UTC (permalink / raw)
To: netdev; +Cc: jakub.kicinski, Cong Wang, Jiri Pirko
In-Reply-To: <20170907042607.24413-1-xiyou.wangcong@gmail.com>
This patch fixes the following madness of tc filter chain:
1) tcf_chain_destroy() is called by both tcf_block_put() and
tcf_chain_put(). tcf_chain_put() is correctly refcnt'ed and paired
with tcf_chain_get(), but tcf_block_put() is not, it should be paired
with tcf_block_get() which means we still need to decrease the refcnt.
Think it in another way: if we call tcf_bock_put() immediately after
tcf_block_get(), could we get effectively a nop? This causes a memory
leak as reported by Jakub.
2) tp proto should hold a refcnt to the chain too. This significantly
simplifies the logic:
2a) Chain 0 is no longer special, it is created and refcnted by tp
like any other chains. All the ugliness in tcf_chain_put() can be
gone!
2b) No need to handle the flushing oddly, because block still holds
chain 0, it can not be released, this guarantees block is the last
user.
2c) The race condition with RCU callbacks is easier to handle with just
a rcu_barrier()! Much easier to understand, nothing to hide! Thanks
to the previous patch. Please see also the comments in code.
2d) Make the code understandable by humans, much less error-prone.
Fixes: 744a4cf63e52 ("net: sched: fix use after free when tcf_chain_destroy is called multiple times")
Fixes: 5bc1701881e3 ("net: sched: introduce multichain support for filters")
Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/sched/cls_api.c | 38 ++++++++++++++++++++++----------------
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index 6c5ea84d2682..e9060dc36519 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -209,21 +209,20 @@ static void tcf_chain_flush(struct tcf_chain *chain)
RCU_INIT_POINTER(*chain->p_filter_chain, NULL);
while ((tp = rtnl_dereference(chain->filter_chain)) != NULL) {
RCU_INIT_POINTER(chain->filter_chain, tp->next);
+ tcf_chain_put(chain);
tcf_proto_destroy(tp);
}
}
static void tcf_chain_destroy(struct tcf_chain *chain)
{
- /* May be already removed from the list by the previous call. */
- if (!list_empty(&chain->list))
- list_del_init(&chain->list);
+ list_del(&chain->list);
+ kfree(chain);
+}
- /* There might still be a reference held when we got here from
- * tcf_block_put. Wait for the user to drop reference before free.
- */
- if (!chain->refcnt)
- kfree(chain);
+static void tcf_chain_hold(struct tcf_chain *chain)
+{
+ ++chain->refcnt;
}
struct tcf_chain *tcf_chain_get(struct tcf_block *block, u32 chain_index,
@@ -233,7 +232,7 @@ struct tcf_chain *tcf_chain_get(struct tcf_block *block, u32 chain_index,
list_for_each_entry(chain, &block->chain_list, list) {
if (chain->index == chain_index) {
- chain->refcnt++;
+ tcf_chain_hold(chain);
return chain;
}
}
@@ -246,10 +245,7 @@ EXPORT_SYMBOL(tcf_chain_get);
void tcf_chain_put(struct tcf_chain *chain)
{
- /* Destroy unused chain, with exception of chain 0, which is the
- * default one and has to be always present.
- */
- if (--chain->refcnt == 0 && !chain->filter_chain && chain->index != 0)
+ if (--chain->refcnt == 0)
tcf_chain_destroy(chain);
}
EXPORT_SYMBOL(tcf_chain_put);
@@ -294,10 +290,18 @@ void tcf_block_put(struct tcf_block *block)
if (!block)
return;
- list_for_each_entry_safe(chain, tmp, &block->chain_list, list) {
+ /* Standalone actions are not allowed to jump to any chain, and
+ * bound actions should be all removed after flushing. However,
+ * filters are destroyed in RCU callbacks, we have to flush and wait
+ * for them before releasing this refcnt, otherwise we race with RCU
+ * callbacks!!!
+ */
+ list_for_each_entry(chain, &block->chain_list, list)
tcf_chain_flush(chain);
- tcf_chain_destroy(chain);
- }
+ rcu_barrier();
+
+ list_for_each_entry_safe(chain, tmp, &block->chain_list, list)
+ tcf_chain_put(chain);
kfree(block);
}
EXPORT_SYMBOL(tcf_block_put);
@@ -375,6 +379,7 @@ static void tcf_chain_tp_insert(struct tcf_chain *chain,
rcu_assign_pointer(*chain->p_filter_chain, tp);
RCU_INIT_POINTER(tp->next, tcf_chain_tp_prev(chain_info));
rcu_assign_pointer(*chain_info->pprev, tp);
+ tcf_chain_hold(chain);
}
static void tcf_chain_tp_remove(struct tcf_chain *chain,
@@ -386,6 +391,7 @@ static void tcf_chain_tp_remove(struct tcf_chain *chain,
if (chain->p_filter_chain && tp == chain->filter_chain)
RCU_INIT_POINTER(*chain->p_filter_chain, next);
RCU_INIT_POINTER(*chain_info->pprev, next);
+ tcf_chain_put(chain);
}
static struct tcf_proto *tcf_chain_tp_find(struct tcf_chain *chain,
--
2.13.0
^ permalink raw reply related
* Re: ipset losing entries on its own
From: Akshat Kakkar @ 2017-09-07 4:48 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev, netdev-owner
In-Reply-To: <c7abf292ac5e6202993a10a66537141e@nuclearcat.com>
I understand that without reproducible scenarios, its hard to debug ...
But the point is, this issue is fully random and of very low frequency.
For the setup, it is CentOS 7.3 upgraded to kernel 4.4.
Whenever a system comes up on the network, he provides his credentials
and after successful authentication, his IP is added in an IPSET which
is having access to certain resources.
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2017-09-07 4:57 UTC (permalink / raw)
To: Coelho, Luciano
Cc: davem@davemloft.net, kvalo@codeaurora.org, Berg, Johannes,
Grumbach, Emmanuel, linuxwifi, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
akpm@linux-foundation.org
In-Reply-To: <1504757495.5400.89.camel@intel.com>
On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano
<luciano.coelho@intel.com> wrote:
>
> This seems to be a problem with backwards-compatibility with FW version
> 27. We are now in version 31[1] and upgrading will probably fix that.
I can confirm that fw version 31 works.
> But obviously the driver should not fail miserably like this with
> version 27, because it claims to support it still.
Not just "claims to support it", but if it's what is shipped with a
fairly recent distro like an up-to-date version of F26, I would really
hope that the driver can still work with it.
> I'm looking into this now and will provide a fix asap.
Thanks,
Linus
^ 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