* Re: [PATCH] netconsole: Remove duplicate "netconsole: " logging prefix
From: David Miller @ 2017-06-13 17:01 UTC (permalink / raw)
To: joe; +Cc: linux-kernel, netdev
In-Reply-To: <a61deabca48ccbbfb1b0d077881d114ad0c5bc75.1497310740.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Mon, 12 Jun 2017 16:39:51 -0700
> It's already added by pr_fmt so remove the explicit use.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] net: phy: Fix MDIO_THUNDER dependencies
From: David Miller @ 2017-06-13 17:01 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, rdunlap, arnd, andrew, linux-kernel
In-Reply-To: <20170613001852.10073-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 12 Jun 2017 17:18:51 -0700
> After commit 90eff9096c01 ("net: phy: Allow splitting MDIO
> bus/device support from PHYs") we could create a configuration where
> MDIO_DEVICE=y and PHYLIB=m which leads to the following undefined
> references:
>
> drivers/built-in.o: In function `thunder_mdiobus_pci_remove':
>>> mdio-thunder.c:(.text+0x2a212f): undefined reference to
>>> `mdiobus_unregister'
>>> mdio-thunder.c:(.text+0x2a2138): undefined reference to
>>> `mdiobus_free'
> drivers/built-in.o: In function `thunder_mdiobus_pci_probe':
> mdio-thunder.c:(.text+0x2a22e7): undefined reference to
> `devm_mdiobus_alloc_size'
> mdio-thunder.c:(.text+0x2a236f): undefined reference to
> `of_mdiobus_register'
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Fixes: 90eff9096c01 ("net: phy: Allow splitting MDIO bus/device support from PHYs")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] r8152: adjust runtime suspend/resume
From: David Miller @ 2017-06-13 17:01 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-275-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Tue, 13 Jun 2017 15:14:38 +0800
> v2:
> For #1, replace GFP_KERNEL with GFP_NOIO for usb_submit_urb().
>
> v1:
> Improve the flow about runtime suspend/resume and make the code
> easy to read.
Series applied.
^ permalink raw reply
* RE: [PATCH net-next 1/9] net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC
From: Salil Mehta @ 2017-06-13 17:08 UTC (permalink / raw)
To: Mintz, Yuval, davem@davemloft.net
Cc: Zhuangyuzeng (Yisen), huangdaode, lipeng (Y),
mehta.salil.lnk@gmail.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Linuxarm
In-Reply-To: <BY2PR0701MB2005075560E4EA9F455049988DCF0@BY2PR0701MB2005.namprd07.prod.outlook.com>
Hi Yuval
> -----Original Message-----
> From: Mintz, Yuval [mailto:Yuval.Mintz@cavium.com]
> Sent: Saturday, June 10, 2017 1:43 PM
> To: Salil Mehta; davem@davemloft.net
> Cc: Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil.lnk@gmail.com; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; Linuxarm
> Subject: RE: [PATCH net-next 1/9] net: hns3: Add support of HNS3
> Ethernet Driver for hip08 SoC
>
> > +static void hns3_nic_net_down(struct net_device *ndev) {
> > + struct hns3_nic_priv *priv = netdev_priv(ndev);
> > + struct hnae3_ae_ops *ops;
> > + int i;
> > +
> > + netif_tx_stop_all_queues(ndev);
> > + netif_carrier_off(ndev);
> > + netif_tx_disable(ndev);
> > +
> > + ops = priv->ae_handle->ae_algo->ops;
> > +
> > + if (ops->stop)
> > + ops->stop(priv->ae_handle);
> > +
> > + netif_tx_stop_all_queues(ndev);
>
> Looks a bit excessive. Why do you need all these
> netif_tx_stop_all_queues()?
If we are disabling the netdev. We need to stop scheduling
the queues associated with that netdev for TX, so we need
this code. Why do you think it is excessive?
Thanks
Salil
>
> > +int hns3_nic_net_xmit_hw(struct net_device *ndev,
> ...
> > +out_map_frag_fail:
> > +
> > + while (ring->next_to_use != next_to_use) {
> > + if (ring->next_to_use != next_to_use)
> > + dma_unmap_page(dev,
> > + ring->desc_cb[ring->next_to_use].dma,
> > + ring->desc_cb[ring->next_to_use].length,
> > + DMA_TO_DEVICE);
> > + else
> > + dma_unmap_single(dev,
> > + ring->desc_cb[next_to_use].dma,
> > + ring->desc_cb[next_to_use].length,
> > + DMA_TO_DEVICE);
> > + }
>
> Something looks completely broken in this error-handling 'loop'.
This looks bad indeed. I will clean this logic.
Thanks
Salil
>
> > +static int hns3_setup_tc(struct net_device *ndev, u8 tc) {
> ...
> > + /* Assign UP2TC map for the VSI */
> > + for (i = 0; i < HNAE3_MAX_TC; i++) {
> > + netdev_set_prio_tc_map(ndev,
> > + kinfo->tc_info[i].up,
> > + kinfo->tc_info[i].tc);
> > + }
> ...
> > +static int hns3_nic_setup_tc(struct net_device *dev, u32 handle,
> > + u32 chain_index, __be16 protocol,
> > + struct tc_to_netdev *tc)
> > +{
> > + if (handle != TC_H_ROOT || tc->type != TC_SETUP_MQPRIO)
> > + return -EINVAL;
> > +
> > + return hns3_setup_tc(dev, tc->mqprio->num_tc); }
>
> Isn't mqprio going to override your priority2tc mapping with the one
> provided
> by user?
I guess you are referring to below code in the mqprio_init() - right?
static int mqprio_init(struct Qdisc *sch, struct nlattr *opt)
{
[...]
/* Always use supplied priority mappings */
for (i = 0; i < TC_BITMASK + 1; i++)
netdev_set_prio_tc_map(dev, i, qopt->prio_tc_map[i]);
[...]
}
In this case yes, you are right below code seems to be redundant:
+ /* Assign UP2TC map for the VSI */
+ for (i = 0; i < HNAE3_MAX_TC; i++) {
+ netdev_set_prio_tc_map(ndev,
+ kinfo->tc_info[i].up,
+ kinfo->tc_info[i].tc);
Hope I am not missing anything here?
Thanks
Salil
>
> > +
> > +static int hns3_handle_rx_bd(struct hns3_enet_ring *ring,
> > + struct sk_buff **out_skb, int *out_bnum) {
> ...
> > + /* Prefetch first cache line of first page */
> > + prefetch(va);
> > +#if L1_CACHE_BYTES < 128
> > + prefetch(va + L1_CACHE_BYTES);
> > +#endif
>
> Might be better to comment what you're actually fetching
Idea is to cache few bytes of the header of the packet. Our L1
Cache line size is 64B so need to prefetch twice to make it
128B. But in actual we can have greater size of caches with
128B Level 1 cache lines. In such a case, single fetch would
suffice to cache in the relevant part of the header.
Will provide a comment over it - no problem.
Thanks
Salil
>
>
^ permalink raw reply
* [PATCH net-next 0/3] ipmr/ip6mr: add Netlink notifications on cache reports
From: Julien Gomes @ 2017-06-13 17:08 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, nikolay, Julien Gomes
Currently, all ipmr/ip6mr cache reports are sent through the
mroute/mroute6 socket only.
This forces the use of a single socket for mroute programming, cache
reports and, regarding ipmr, IGMP messages without Router Alert option
reception.
The present patches are aiming to send Netlink notifications in addition
to the existing igmpmsg/mrt6msg to give user programs a way to handle
cache reports in parallel with multiple sockets other than the
mroute/mroute6 socket.
Julien Gomes (3):
rtnetlink: add NEWCACHEREPORT message type
ipmr: add netlink notifications on igmpmsg cache reports
ip6mr: add netlink notifications on mrt6msg cache reports
include/uapi/linux/mroute.h | 11 ++++++++
include/uapi/linux/mroute6.h | 11 ++++++++
include/uapi/linux/rtnetlink.h | 3 ++
net/ipv4/ipmr.c | 63 ++++++++++++++++++++++++++++++++++++++++--
net/ipv6/ip6mr.c | 63 ++++++++++++++++++++++++++++++++++++++++--
security/selinux/nlmsgtab.c | 3 +-
6 files changed, 149 insertions(+), 5 deletions(-)
--
2.13.1
^ permalink raw reply
* [PATCH net-next 2/3] ipmr: add netlink notifications on igmpmsg cache reports
From: Julien Gomes @ 2017-06-13 17:08 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, nikolay, Julien Gomes
In-Reply-To: <20170613170822.16310-1-julien@arista.com>
Add Netlink notifications on cache reports in ipmr, in addition to the
existing igmpmsg sent to mroute_sk.
Send RTM_NEWCACHEREPORT notifications to RTNLGRP_IPV4_MROUTE.
MSGTYPE, VIF_ID, SRC_ADDR and DST_ADDR Netlink attributes contain the
same data as their equivalent fields in the igmpmsg header.
PKT attribute is the packet sent to mroute_sk, without the added igmpmsg
header.
Suggested-by: Ryan Halbrook <halbrook@arista.com>
Signed-off-by: Julien Gomes <julien@arista.com>
---
include/uapi/linux/mroute.h | 11 ++++++++
net/ipv4/ipmr.c | 63 +++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/mroute.h b/include/uapi/linux/mroute.h
index f904367c0cee..f6f9e01ee734 100644
--- a/include/uapi/linux/mroute.h
+++ b/include/uapi/linux/mroute.h
@@ -152,6 +152,17 @@ enum {
};
#define IPMRA_VIFA_MAX (__IPMRA_VIFA_MAX - 1)
+/* ipmr netlink cache report attributes */
+enum {
+ IPMRA_CACHEREPORTA_MSGTYPE,
+ IPMRA_CACHEREPORTA_VIF_ID,
+ IPMRA_CACHEREPORTA_SRC_ADDR,
+ IPMRA_CACHEREPORTA_DST_ADDR,
+ IPMRA_CACHEREPORTA_PKT,
+ __IPMRA_CACHEREPORTA_MAX
+};
+#define IPMRA_CACHEREPORTA_MAX (__IPMRA_CACHEREPORTA_MAX - 1)
+
/* That's all usermode folks */
#define MFC_ASSERT_THRESH (3*HZ) /* Maximal freq. of asserts */
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 9374b99c7c17..6d1f4fae3749 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -109,6 +109,7 @@ static int __ipmr_fill_mroute(struct mr_table *mrt, struct sk_buff *skb,
struct mfc_cache *c, struct rtmsg *rtm);
static void mroute_netlink_event(struct mr_table *mrt, struct mfc_cache *mfc,
int cmd);
+static void igmpmsg_netlink_event(struct mr_table *mrt, struct sk_buff *pkt);
static void mroute_clean_tables(struct mr_table *mrt, bool all);
static void ipmr_expire_process(unsigned long arg);
@@ -993,8 +994,7 @@ static void ipmr_cache_resolve(struct net *net, struct mr_table *mrt,
}
}
-/* Bounce a cache query up to mrouted. We could use netlink for this but mrouted
- * expects the following bizarre scheme.
+/* Bounce a cache query up to mrouted and netlink.
*
* Called under mrt_lock.
*/
@@ -1060,6 +1060,8 @@ static int ipmr_cache_report(struct mr_table *mrt,
return -EINVAL;
}
+ igmpmsg_netlink_event(mrt, skb);
+
/* Deliver to mrouted */
ret = sock_queue_rcv_skb(mroute_sk, skb);
rcu_read_unlock();
@@ -2341,6 +2343,63 @@ static void mroute_netlink_event(struct mr_table *mrt, struct mfc_cache *mfc,
rtnl_set_sk_err(net, RTNLGRP_IPV4_MROUTE, err);
}
+static void igmpmsg_netlink_event(struct mr_table *mrt, struct sk_buff *pkt)
+{
+ struct net *net = read_pnet(&mrt->net);
+ struct nlmsghdr *nlh;
+ struct rtgenmsg *rtgenm;
+ struct igmpmsg *msg;
+ struct sk_buff *skb;
+ int payloadlen;
+ int msgsize;
+
+ payloadlen = pkt->len - sizeof(struct igmpmsg);
+ msg = (struct igmpmsg *)skb_network_header(pkt);
+ msgsize = NLMSG_ALIGN(sizeof(struct rtgenmsg))
+ + nla_total_size(1)
+ /* IPMRA_CACHEREPORTA_MSGTYPE */
+ + nla_total_size(1)
+ /* IPMRA_CACHEREPORTA_VIF_ID */
+ + nla_total_size(4)
+ /* IPMRA_CACHEREPORTA_SRC_ADDR */
+ + nla_total_size(4)
+ /* IPMRA_CACHEREPORTA_DST_ADDR */
+ + nla_total_size(payloadlen)
+ /* IPMRA_CACHEREPORTA_PKT */
+ ;
+
+ skb = nlmsg_new(msgsize, GFP_ATOMIC);
+ if (!skb)
+ goto errout;
+
+ nlh = nlmsg_put(skb, 0, 0, RTM_NEWCACHEREPORT,
+ sizeof(struct rtgenmsg), 0);
+ if (!nlh)
+ goto errout;
+ rtgenm = nlmsg_data(nlh);
+ rtgenm->rtgen_family = RTNL_FAMILY_IPMR;
+ if (nla_put_u8(skb, IPMRA_CACHEREPORTA_MSGTYPE, msg->im_msgtype) ||
+ nla_put_u8(skb, IPMRA_CACHEREPORTA_VIF_ID, msg->im_vif) ||
+ nla_put_in_addr(skb, IPMRA_CACHEREPORTA_SRC_ADDR,
+ msg->im_src.s_addr) ||
+ nla_put_in_addr(skb, IPMRA_CACHEREPORTA_DST_ADDR,
+ msg->im_dst.s_addr) ||
+ nla_put(skb, IPMRA_CACHEREPORTA_PKT, payloadlen,
+ pkt->data + sizeof(struct igmpmsg)))
+ goto nla_put_failure;
+
+ nlmsg_end(skb, nlh);
+
+ rtnl_notify(skb, net, 0, RTNLGRP_IPV4_MROUTE, NULL, GFP_ATOMIC);
+ return;
+
+nla_put_failure:
+ nlmsg_cancel(skb, nlh);
+errout:
+ kfree_skb(skb);
+ rtnl_set_sk_err(net, RTNLGRP_IPV4_MROUTE, -ENOBUFS);
+}
+
static int ipmr_rtm_dumproute(struct sk_buff *skb, struct netlink_callback *cb)
{
struct net *net = sock_net(skb->sk);
--
2.13.1
^ permalink raw reply related
* [PATCH net-next 3/3] ip6mr: add netlink notifications on mrt6msg cache reports
From: Julien Gomes @ 2017-06-13 17:08 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, nikolay, Julien Gomes
In-Reply-To: <20170613170822.16310-1-julien@arista.com>
Add Netlink notifications on cache reports in ip6mr, in addition to the
existing mrt6msg sent to mroute6_sk.
Send RTM_NEWCACHEREPORT notifications to RTNLGRP_IPV6_MROUTE.
MSGTYPE, MIF_ID, SRC_ADDR and DST_ADDR Netlink attributes contain the
same data as their equivalent fields in the mrt6msg header.
PKT attribute is the packet sent to mroute6_sk, without the added
mrt6msg header.
Suggested-by: Ryan Halbrook <halbrook@arista.com>
Signed-off-by: Julien Gomes <julien@arista.com>
---
include/uapi/linux/mroute6.h | 11 ++++++++
net/ipv6/ip6mr.c | 63 ++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/mroute6.h b/include/uapi/linux/mroute6.h
index ed5721148768..8e3c2d2c170e 100644
--- a/include/uapi/linux/mroute6.h
+++ b/include/uapi/linux/mroute6.h
@@ -133,4 +133,15 @@ struct mrt6msg {
struct in6_addr im6_src, im6_dst;
};
+/* ip6mr netlink cache report attributes */
+enum {
+ IP6MRA_CACHEREPORTA_MSGTYPE,
+ IP6MRA_CACHEREPORTA_MIF_ID,
+ IP6MRA_CACHEREPORTA_SRC_ADDR,
+ IP6MRA_CACHEREPORTA_DST_ADDR,
+ IP6MRA_CACHEREPORTA_PKT,
+ __IP6MRA_CACHEREPORTA_MAX
+};
+#define IP6MRA_CACHEREPORTA_MAX (__IP6MRA_CACHEREPORTA_MAX - 1)
+
#endif /* _UAPI__LINUX_MROUTE6_H */
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 374997d26488..8667256b4343 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -116,6 +116,7 @@ static int __ip6mr_fill_mroute(struct mr6_table *mrt, struct sk_buff *skb,
struct mfc6_cache *c, struct rtmsg *rtm);
static void mr6_netlink_event(struct mr6_table *mrt, struct mfc6_cache *mfc,
int cmd);
+static void mrt6msg_netlink_event(struct mr6_table *mrt, struct sk_buff *pkt);
static int ip6mr_rtm_dumproute(struct sk_buff *skb,
struct netlink_callback *cb);
static void mroute_clean_tables(struct mr6_table *mrt, bool all);
@@ -1123,8 +1124,7 @@ static void ip6mr_cache_resolve(struct net *net, struct mr6_table *mrt,
}
/*
- * Bounce a cache query up to pim6sd. We could use netlink for this but pim6sd
- * expects the following bizarre scheme.
+ * Bounce a cache query up to pim6sd and netlink.
*
* Called under mrt_lock.
*/
@@ -1206,6 +1206,8 @@ static int ip6mr_cache_report(struct mr6_table *mrt, struct sk_buff *pkt,
return -EINVAL;
}
+ mrt6msg_netlink_event(mrt, skb);
+
/*
* Deliver to user space multicast routing algorithms
*/
@@ -2455,6 +2457,63 @@ static void mr6_netlink_event(struct mr6_table *mrt, struct mfc6_cache *mfc,
rtnl_set_sk_err(net, RTNLGRP_IPV6_MROUTE, err);
}
+static void mrt6msg_netlink_event(struct mr6_table *mrt, struct sk_buff *pkt)
+{
+ struct net *net = read_pnet(&mrt->net);
+ struct nlmsghdr *nlh;
+ struct rtgenmsg *rtgenm;
+ struct mrt6msg *msg;
+ struct sk_buff *skb;
+ int payloadlen;
+ int msgsize;
+
+ payloadlen = pkt->len - sizeof(struct mrt6msg);
+ msg = (struct mrt6msg *)skb_transport_header(pkt);
+ msgsize = NLMSG_ALIGN(sizeof(struct rtgenmsg))
+ + nla_total_size(1)
+ /* IP6MRA_CACHEREPORTA_MSGTYPE */
+ + nla_total_size(2)
+ /* IP6MRA_CACHEREPORTA_MIF_ID */
+ + nla_total_size(sizeof(struct in6_addr))
+ /* IP6MRA_CACHEREPORTA_SRC_ADDR */
+ + nla_total_size(sizeof(struct in6_addr))
+ /* IP6MRA_CACHEREPORTA_DST_ADDR */
+ + nla_total_size(payloadlen)
+ /* IP6MRA_CACHEREPORTA_PKT */
+ ;
+
+ skb = nlmsg_new(msgsize, GFP_ATOMIC);
+ if (!skb)
+ goto errout;
+
+ nlh = nlmsg_put(skb, 0, 0, RTM_NEWCACHEREPORT,
+ sizeof(struct rtgenmsg), 0);
+ if (!nlh)
+ goto errout;
+ rtgenm = nlmsg_data(nlh);
+ rtgenm->rtgen_family = RTNL_FAMILY_IP6MR;
+ if (nla_put_u8(skb, IP6MRA_CACHEREPORTA_MSGTYPE, msg->im6_msgtype) ||
+ nla_put_u16(skb, IP6MRA_CACHEREPORTA_MIF_ID, msg->im6_mif) ||
+ nla_put_in6_addr(skb, IP6MRA_CACHEREPORTA_SRC_ADDR,
+ &msg->im6_src) ||
+ nla_put_in6_addr(skb, IP6MRA_CACHEREPORTA_DST_ADDR,
+ &msg->im6_dst) ||
+ nla_put(skb, IP6MRA_CACHEREPORTA_PKT, payloadlen,
+ pkt->data + sizeof(struct mrt6msg)))
+ goto nla_put_failure;
+
+ nlmsg_end(skb, nlh);
+
+ rtnl_notify(skb, net, 0, RTNLGRP_IPV6_MROUTE, NULL, GFP_ATOMIC);
+ return;
+
+nla_put_failure:
+ nlmsg_cancel(skb, nlh);
+errout:
+ kfree_skb(skb);
+ rtnl_set_sk_err(net, RTNLGRP_IPV6_MROUTE, -ENOBUFS);
+}
+
static int ip6mr_rtm_dumproute(struct sk_buff *skb, struct netlink_callback *cb)
{
struct net *net = sock_net(skb->sk);
--
2.13.1
^ permalink raw reply related
* [PATCH net,stable] qmi_wwan: new Telewell and Sierra device IDs
From: Bjørn Mork @ 2017-06-13 17:10 UTC (permalink / raw)
To: netdev
Cc: linux-usb, Johan Hovold, Lars Melin, Dan Williams, Daniele Palmas,
Petr Kloc, Teemu Likonen, Bjørn Mork
A new Sierra Wireless EM7305 device ID used in a Toshiba laptop,
and two Longcheer device IDs entries used by Telewell TW-3G HSPA+
branded modems.
Reported-by: Petr Kloc <petr_kloc@yahoo.com>
Reported-by: Teemu Likonen <tlikonen@iki.fi>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
The following patch should be backported to v4.9 and later stable kernels to
make this one apply cleanly:
14cf4a771b30 ("drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201")
drivers/net/usb/qmi_wwan.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 949671ce4039..32a22f4e8356 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1192,6 +1192,8 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x9056, 8)}, /* Sierra Wireless Modem */
{QMI_FIXED_INTF(0x1199, 0x9057, 8)},
{QMI_FIXED_INTF(0x1199, 0x9061, 8)}, /* Sierra Wireless Modem */
+ {QMI_FIXED_INTF(0x1199, 0x9063, 8)}, /* Sierra Wireless EM7305 */
+ {QMI_FIXED_INTF(0x1199, 0x9063, 10)}, /* Sierra Wireless EM7305 */
{QMI_FIXED_INTF(0x1199, 0x9071, 8)}, /* Sierra Wireless MC74xx */
{QMI_FIXED_INTF(0x1199, 0x9071, 10)}, /* Sierra Wireless MC74xx */
{QMI_FIXED_INTF(0x1199, 0x9079, 8)}, /* Sierra Wireless EM74xx */
@@ -1206,6 +1208,8 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1bc7, 0x1100, 3)}, /* Telit ME910 */
{QMI_FIXED_INTF(0x1bc7, 0x1200, 5)}, /* Telit LE920 */
{QMI_QUIRK_SET_DTR(0x1bc7, 0x1201, 2)}, /* Telit LE920, LE920A4 */
+ {QMI_FIXED_INTF(0x1c9e, 0x9801, 3)}, /* Telewell TW-3G HSPA+ */
+ {QMI_FIXED_INTF(0x1c9e, 0x9803, 4)}, /* Telewell TW-3G HSPA+ */
{QMI_FIXED_INTF(0x1c9e, 0x9b01, 3)}, /* XS Stick W100-2 from 4G Systems */
{QMI_FIXED_INTF(0x0b3c, 0xc000, 4)}, /* Olivetti Olicard 100 */
{QMI_FIXED_INTF(0x0b3c, 0xc001, 4)}, /* Olivetti Olicard 120 */
--
2.11.0
^ permalink raw reply related
* Re: [Patch net] igmp: acquire pmc lock for ip_mc_clear_src()
From: David Miller @ 2017-06-13 17:00 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, andreyknvl, edumazet, lucien.xin
In-Reply-To: <1497286346-26888-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 12 Jun 2017 09:52:26 -0700
> Andrey reported a use-after-free in add_grec():
>
> for (psf = *psf_list; psf; psf = psf_next) {
> ...
> psf_next = psf->sf_next;
>
> where the struct ip_sf_list's were already freed by:
>
> kfree+0xe8/0x2b0 mm/slub.c:3882
> ip_mc_clear_src+0x69/0x1c0 net/ipv4/igmp.c:2078
> ip_mc_dec_group+0x19a/0x470 net/ipv4/igmp.c:1618
> ip_mc_drop_socket+0x145/0x230 net/ipv4/igmp.c:2609
> inet_release+0x4e/0x1c0 net/ipv4/af_inet.c:411
> sock_release+0x8d/0x1e0 net/socket.c:597
> sock_close+0x16/0x20 net/socket.c:1072
>
> This happens because we don't hold pmc->lock in ip_mc_clear_src()
> and a parallel mr_ifc_timer timer could jump in and access them.
>
> The RCU lock is there but it is merely for pmc itself, this
> spinlock could actually ensure we don't access them in parallel.
>
> Thanks to Eric and Long for discussion on this bug.
>
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Xin Long <lucien.xin@gmail.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* RE: [PATCH net-next 8/9] net: hns3: Add support of debugfs interface to HNS3 driver
From: Salil Mehta @ 2017-06-13 17:14 UTC (permalink / raw)
To: Mintz, Yuval, davem@davemloft.net
Cc: Zhuangyuzeng (Yisen), huangdaode, lipeng (Y),
mehta.salil.lnk@gmail.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Linuxarm
In-Reply-To: <BY2PR0701MB2005750A49D78C63B4B4A6B18DCF0@BY2PR0701MB2005.namprd07.prod.outlook.com>
HI Yuval,
> -----Original Message-----
> From: Mintz, Yuval [mailto:Yuval.Mintz@cavium.com]
> Sent: Saturday, June 10, 2017 1:52 PM
> To: Salil Mehta; davem@davemloft.net
> Cc: Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil.lnk@gmail.com; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; Linuxarm
> Subject: RE: [PATCH net-next 8/9] net: hns3: Add support of debugfs
> interface to HNS3 driver
>
> > This adds the support of the debugfs interface to the driver for
> debugging
> > purposes.
>
> > +const struct hclge_support_cmd support_cmd[] = {
> > + {"send cmd", 8, hclge_dbg_send,
> > + "opcode flag data0 data1 data2 data3 data4 data5"},
> > + {"help", 4, hclge_dbg_usage, "no option"}, };
>
> Is there an actual description of what this does? Or is it simply a
> huge backdoor?
Yes, I understand it has been coded in haste to assist in debugging
of the driver. Yes, there is a format to it but needs bit of work
I guess, otherwise it will be like opening pandoras box. For now, I will drop
this debugfs patch and later will push with proper explanation of its
need and interface.
Thanks
Salil
^ permalink raw reply
* RE: [PATCH net-next 8/9] net: hns3: Add support of debugfs interface to HNS3 driver
From: Salil Mehta @ 2017-06-13 17:16 UTC (permalink / raw)
To: Andrew Lunn, Mintz, Yuval
Cc: davem@davemloft.net, Zhuangyuzeng (Yisen), huangdaode, lipeng (Y),
mehta.salil.lnk@gmail.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Linuxarm
In-Reply-To: <20170610163535.GC26740@lunn.ch>
Hi Andrew,
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Saturday, June 10, 2017 5:36 PM
> To: Mintz, Yuval
> Cc: Salil Mehta; davem@davemloft.net; Zhuangyuzeng (Yisen); huangdaode;
> lipeng (Y); mehta.salil.lnk@gmail.com; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; Linuxarm
> Subject: Re: [PATCH net-next 8/9] net: hns3: Add support of debugfs
> interface to HNS3 driver
>
> On Sat, Jun 10, 2017 at 12:51:57PM +0000, Mintz, Yuval wrote:
> > > This adds the support of the debugfs interface to the driver for
> debugging
> > > purposes.
> >
> > > +const struct hclge_support_cmd support_cmd[] = {
> > > + {"send cmd", 8, hclge_dbg_send,
> > > + "opcode flag data0 data1 data2 data3 data4 data5"},
> > > + {"help", 4, hclge_dbg_usage, "no option"}, };
> >
> > Is there an actual description of what this does? Or is it simply a
> huge backdoor?
>
> It looks like a huge backdoor to the chip.
>
> It is O.K. to have such a patch internally for your own development
> work, but it should not be submitted for mainline.
>
> NACK
>
> Andrew
I will drop this debugfs patch for now.
Thanks
Salil
^ permalink raw reply
* [PATCH net-next 1/3] rtnetlink: add NEWCACHEREPORT message type
From: Julien Gomes @ 2017-06-13 17:08 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, nikolay, Julien Gomes
In-Reply-To: <20170613170822.16310-1-julien@arista.com>
New NEWCACHEREPORT message type to be used for cache reports sent
via Netlink, effectively allowing splitting cache report reception from
mroute programming.
Suggested-by: Ryan Halbrook <halbrook@arista.com>
Signed-off-by: Julien Gomes <julien@arista.com>
---
include/uapi/linux/rtnetlink.h | 3 +++
security/selinux/nlmsgtab.c | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index 564790e854f7..cd1afb900929 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -146,6 +146,9 @@ enum {
RTM_GETSTATS = 94,
#define RTM_GETSTATS RTM_GETSTATS
+ RTM_NEWCACHEREPORT = 96,
+#define RTM_NEWCACHEREPORT RTM_NEWCACHEREPORT
+
__RTM_MAX,
#define RTM_MAX (((__RTM_MAX + 3) & ~3) - 1)
};
diff --git a/security/selinux/nlmsgtab.c b/security/selinux/nlmsgtab.c
index 5aeaf30b7a13..7b7433a1a34c 100644
--- a/security/selinux/nlmsgtab.c
+++ b/security/selinux/nlmsgtab.c
@@ -79,6 +79,7 @@ static const struct nlmsg_perm nlmsg_route_perms[] =
{ RTM_GETNSID, NETLINK_ROUTE_SOCKET__NLMSG_READ },
{ RTM_NEWSTATS, NETLINK_ROUTE_SOCKET__NLMSG_READ },
{ RTM_GETSTATS, NETLINK_ROUTE_SOCKET__NLMSG_READ },
+ { RTM_NEWCACHEREPORT, NETLINK_ROUTE_SOCKET__NLMSG_READ },
};
static const struct nlmsg_perm nlmsg_tcpdiag_perms[] =
@@ -158,7 +159,7 @@ int selinux_nlmsg_lookup(u16 sclass, u16 nlmsg_type, u32 *perm)
switch (sclass) {
case SECCLASS_NETLINK_ROUTE_SOCKET:
/* RTM_MAX always point to RTM_SETxxxx, ie RTM_NEWxxx + 3 */
- BUILD_BUG_ON(RTM_MAX != (RTM_NEWSTATS + 3));
+ BUILD_BUG_ON(RTM_MAX != (RTM_NEWCACHEREPORT + 3));
err = nlmsg_perm(nlmsg_type, perm, nlmsg_route_perms,
sizeof(nlmsg_route_perms));
break;
--
2.13.1
^ permalink raw reply related
* [PATCH] via-rhine: add support for changing MTU
From: Magnus Damm @ 2017-06-13 17:18 UTC (permalink / raw)
To: netdev; +Cc: Magnus Damm, linux-kernel, davem
From: Magnus Damm <damm+renesas@opensource.se>
Allow adjusting the MTU for via-rhine devices in case of no TX alignment
buffer is used.
Lightly tested on ALIX2D13 hardware by making use of VXLAN with MTU set
to 1500 on top of via-rhine devices with 1550 MTU. Without this patch
the VXLAN MTU is limited to less than 1500.
Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---
Developed on top of next-20170613
drivers/net/ethernet/via/via-rhine.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
--- 0001/drivers/net/ethernet/via/via-rhine.c
+++ work/drivers/net/ethernet/via/via-rhine.c 2017-06-14 02:05:25.410607110 +0900
@@ -518,6 +518,7 @@ static void rhine_get_stats64(struct net
static int netdev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
static const struct ethtool_ops netdev_ethtool_ops;
static int rhine_close(struct net_device *dev);
+static int rhine_change_mtu(struct net_device *dev, int new_mtu);
static int rhine_vlan_rx_add_vid(struct net_device *dev,
__be16 proto, u16 vid);
static int rhine_vlan_rx_kill_vid(struct net_device *dev,
@@ -894,6 +895,7 @@ static const struct net_device_ops rhine
.ndo_set_mac_address = eth_mac_addr,
.ndo_do_ioctl = netdev_ioctl,
.ndo_tx_timeout = rhine_tx_timeout,
+ .ndo_change_mtu = rhine_change_mtu,
.ndo_vlan_rx_add_vid = rhine_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid = rhine_vlan_rx_kill_vid,
#ifdef CONFIG_NET_POLL_CONTROLLER
@@ -981,6 +983,14 @@ static int rhine_init_one_common(struct
NETIF_F_HW_VLAN_CTAG_RX |
NETIF_F_HW_VLAN_CTAG_FILTER;
+ /* Allow MTU configuration as long as TX alignment buffer is unused */
+ if (!(rp->quirks & rqRhineI)) {
+ /* Packets less than 64 octets will raise RDES0.RUNT. */
+ dev->min_mtu = ETH_ZLEN - ETH_HLEN;
+ /* Hardware has 11 bits of RDES0.Rx_Length including FCS. */
+ dev->max_mtu = 0x1fff - ETH_HLEN - ETH_FCS_LEN;
+ }
+
/* dev->name not defined before register_netdev()! */
rc = register_netdev(dev);
if (rc)
@@ -1399,6 +1409,15 @@ static void rhine_set_carrier(struct mii
mii->force_media, netif_carrier_ok(dev));
}
+static int rhine_change_mtu(struct net_device *dev, int new_mtu)
+{
+ if (dev->flags & IFF_UP)
+ return -EBUSY;
+
+ dev->mtu = new_mtu;
+ return 0;
+}
+
/**
* rhine_set_cam - set CAM multicast filters
* @ioaddr: register block of this Rhine
^ permalink raw reply
* Re: [PATCH net,stable] qmi_wwan: new Telewell and Sierra device IDs
From: David Miller @ 2017-06-13 17:21 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
johan-DgEjT+Ai2ygdnm+yROfE0A, larsm17-Re5JQEeQqe8AvxtiuMwx3w,
dcbw-H+wXaHxf7aLQT0dZR+AlfA, dnlplm-Re5JQEeQqe8AvxtiuMwx3w,
petr_kloc-/E1597aS9LQAvxtiuMwx3w, tlikonen-X3B1VOXEql0
In-Reply-To: <20170613171018.31526-1-bjorn-yOkvZcmFvRU@public.gmane.org>
From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Tue, 13 Jun 2017 19:10:18 +0200
> A new Sierra Wireless EM7305 device ID used in a Toshiba laptop,
> and two Longcheer device IDs entries used by Telewell TW-3G HSPA+
> branded modems.
>
> Reported-by: Petr Kloc <petr_kloc-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
> Reported-by: Teemu Likonen <tlikonen-X3B1VOXEql0@public.gmane.org>
> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> ---
> The following patch should be backported to v4.9 and later stable kernels to
> make this one apply cleanly:
>
> 14cf4a771b30 ("drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201")
Ok, applied and queued up for -stable, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Lockdep splat with tc filter on 4.11
From: Laura Abbott @ 2017-06-13 17:28 UTC (permalink / raw)
To: Jamal Hadi Salim, David S. Miller
Cc: netdev, Linux Kernel Mailing List, nicholashuber
Hi,
Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1459626
of a hang on 4.11.3 with lockdep splat:
[ 129.100206] BUG: sleeping function called from invalid context at mm/slab.h:432
[ 129.100237] in_atomic(): 1, irqs_disabled(): 0, pid: 1793, name: tc
[ 129.100239] 2 locks held by tc/1793:
[ 129.100241] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff8c826217>] rtnl_lock+0x17/0x20
[ 129.100250] #1: (&(&p->tcfa_lock)->rlock){+...+.}, at: [<ffffffffc08ba22d>] tcf_act_police_init+0x22d/0x580 [act_police]
[ 129.100259] CPU: 2 PID: 1793 Comm: tc Not tainted 4.11.3-202.fc25.x86_64+debug #1
[ 129.100261] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.fc25 04/01/2014
[ 129.100262] Call Trace:
[ 129.100270] dump_stack+0x86/0xc3
[ 129.100274] ___might_sleep+0x17d/0x250
[ 129.100277] __might_sleep+0x4a/0x80
[ 129.100280] kmem_cache_alloc_trace+0x1e6/0x2d0
[ 129.100284] ? gen_new_estimator+0x76/0x1d0
[ 129.100288] gen_new_estimator+0x76/0x1d0
[ 129.100293] gen_replace_estimator+0xe/0x10
[ 129.100296] tcf_act_police_init+0x255/0x580 [act_police]
[ 129.100304] tcf_action_init_1+0xb9/0x340
[ 129.100316] tcf_exts_validate+0x52/0x110
[ 129.100320] fw_change_attrs+0xbb/0x2b0 [cls_fw]
[ 129.100324] ? rcu_read_lock_sched_held+0x4a/0x80
[ 129.100329] fw_change+0x3ad/0x4bb [cls_fw]
[ 129.100338] tc_ctl_tfilter+0x470/0xa80
[ 129.100350] rtnetlink_rcv_msg+0xe6/0x210
[ 129.100354] ? sched_clock+0x9/0x10
[ 129.100358] ? sched_clock_cpu+0x11/0xc0
[ 129.100360] ? netlink_unicast+0x1cd/0x2f0
[ 129.100363] ? rtnl_newlink+0x8e0/0x8e0
[ 129.100366] netlink_rcv_skb+0xa4/0xc0
[ 129.100369] rtnetlink_rcv+0x2a/0x40
[ 129.100371] netlink_unicast+0x1f5/0x2f0
[ 129.100375] netlink_sendmsg+0x302/0x3c0
[ 129.100382] sock_sendmsg+0x38/0x50
[ 129.100385] ___sys_sendmsg+0x2f6/0x310
[ 129.100392] ? _raw_spin_unlock+0x27/0x40
[ 129.100396] ? __handle_mm_fault+0x539/0x1170
[ 129.100401] ? __do_page_fault+0x28e/0x520
[ 129.100405] ? kvm_sched_clock_read+0x25/0x40
[ 129.100407] ? sched_clock+0x9/0x10
[ 129.100409] ? sched_clock_cpu+0x11/0xc0
[ 129.100411] ? __do_page_fault+0x28e/0x520
[ 129.100420] __sys_sendmsg+0x54/0x90
[ 129.100422] ? __sys_sendmsg+0x54/0x90
[ 129.100430] SyS_sendmsg+0x12/0x20
[ 129.100432] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 129.100434] RIP: 0033:0x7f50dffca037
[ 129.100436] RSP: 002b:00007ffe99d12698 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[ 129.100438] RAX: ffffffffffffffda RBX: 00007ffe99d1e7e0 RCX: 00007f50dffca037
[ 129.100439] RDX: 0000000000000000 RSI: 00007ffe99d126e0 RDI: 0000000000000003
[ 129.100441] RBP: 00007ffe99d126e0 R08: 0000000000000001 R09: 0000000000000000
[ 129.100442] R10: 00000000000005eb R11: 0000000000000246 R12: 00007ffe99d12720
[ 129.100443] R13: 0000000000668060 R14: 00007ffe99d1a7b0 R15: 0000000000000000
[ 129.100454] =============================================
[ 129.100455] [ INFO: possible recursive locking detected ]
[ 129.100456] 4.11.3-202.fc25.x86_64+debug #1 Tainted: G W
[ 129.100456] ---------------------------------------------
[ 129.100457] tc/1793 is trying to acquire lock:
[ 129.100457] (&(&p->tcfa_lock)->rlock){+...+.}, at: [<ffffffff8c802d93>] est_fetch_counters+0x23/0x50
[ 129.100460]
but task is already holding lock:
[ 129.100460] (&(&p->tcfa_lock)->rlock){+...+.}, at: [<ffffffffc08ba22d>] tcf_act_police_init+0x22d/0x580 [act_police]
[ 129.100463]
other info that might help us debug this:
[ 129.100463] Possible unsafe locking scenario:
[ 129.100464] CPU0
[ 129.100465] ----
[ 129.100465] lock(&(&p->tcfa_lock)->rlock);
[ 129.100466] lock(&(&p->tcfa_lock)->rlock);
[ 129.100467]
*** DEADLOCK ***
[ 129.100468] May be due to missing lock nesting notation
[ 129.100469] 2 locks held by tc/1793:
[ 129.100470] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff8c826217>] rtnl_lock+0x17/0x20
[ 129.100472] #1: (&(&p->tcfa_lock)->rlock){+...+.}, at: [<ffffffffc08ba22d>] tcf_act_police_init+0x22d/0x580 [act_police]
[ 129.100474]
stack backtrace:
[ 129.100475] CPU: 2 PID: 1793 Comm: tc Tainted: G W 4.11.3-202.fc25.x86_64+debug #1
[ 129.100476] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.fc25 04/01/2014
[ 129.100477] Call Trace:
[ 129.100478] dump_stack+0x86/0xc3
[ 129.100480] __lock_acquire+0x858/0x1450
[ 129.100481] ? ___slab_alloc+0x2a9/0x5f0
[ 129.100483] lock_acquire+0xe3/0x1d0
[ 129.100484] ? gen_new_estimator+0x76/0x1d0
[ 129.100486] ? lock_acquire+0xe3/0x1d0
[ 129.100487] ? est_fetch_counters+0x23/0x50
[ 129.100488] _raw_spin_lock+0x34/0x70
[ 129.100489] ? est_fetch_counters+0x23/0x50
[ 129.100491] est_fetch_counters+0x23/0x50
[ 129.100492] gen_new_estimator+0xdf/0x1d0
[ 129.100493] gen_replace_estimator+0xe/0x10
[ 129.100495] tcf_act_police_init+0x255/0x580 [act_police]
[ 129.100496] tcf_action_init_1+0xb9/0x340
[ 129.100499] tcf_exts_validate+0x52/0x110
[ 129.100537] fw_change_attrs+0xbb/0x2b0 [cls_fw]
[ 129.100539] ? rcu_read_lock_sched_held+0x4a/0x80
[ 129.100540] fw_change+0x3ad/0x4bb [cls_fw]
[ 129.100543] tc_ctl_tfilter+0x470/0xa80
[ 129.100545] rtnetlink_rcv_msg+0xe6/0x210
[ 129.100547] ? sched_clock+0x9/0x10
[ 129.100548] ? sched_clock_cpu+0x11/0xc0
[ 129.100549] ? netlink_unicast+0x1cd/0x2f0
[ 129.100551] ? rtnl_newlink+0x8e0/0x8e0
[ 129.100552] netlink_rcv_skb+0xa4/0xc0
[ 129.100553] rtnetlink_rcv+0x2a/0x40
[ 129.100554] netlink_unicast+0x1f5/0x2f0
[ 129.100556] netlink_sendmsg+0x302/0x3c0
[ 129.100557] sock_sendmsg+0x38/0x50
[ 129.100558] ___sys_sendmsg+0x2f6/0x310
[ 129.100560] ? _raw_spin_unlock+0x27/0x40
[ 129.100562] ? __handle_mm_fault+0x539/0x1170
[ 129.100564] ? __do_page_fault+0x28e/0x520
[ 129.100565] ? kvm_sched_clock_read+0x25/0x40
[ 129.100566] ? sched_clock+0x9/0x10
[ 129.100568] ? sched_clock_cpu+0x11/0xc0
[ 129.100569] ? __do_page_fault+0x28e/0x520
[ 129.100571] __sys_sendmsg+0x54/0x90
[ 129.100572] ? __sys_sendmsg+0x54/0x90
[ 129.100574] SyS_sendmsg+0x12/0x20
[ 129.100575] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 129.100576] RIP: 0033:0x7f50dffca037
[ 129.100578] RSP: 002b:00007ffe99d12698 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[ 129.100579] RAX: ffffffffffffffda RBX: 00007ffe99d1e7e0 RCX: 00007f50dffca037
[ 129.100580] RDX: 0000000000000000 RSI: 00007ffe99d126e0 RDI: 0000000000000003
[ 129.100581] RBP: 00007ffe99d126e0 R08: 0000000000000001 R09: 0000000000000000
[ 129.100581] R10: 00000000000005eb R11: 0000000000000246 R12: 00007ffe99d12720
[ 129.100582] R13: 0000000000668060 R14: 00007ffe99d1a7b0 R15: 0000000000000000
[ 155.156414] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [tc:1793]
[ 155.156418] Modules linked in: act_police cls_fw sch_htb uinput ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables sunrpc snd_hda_codec_generic snd_hda_intel crct10dif_pclmul crc32_pclmul snd_hda_codec snd_hda_core snd_hwdep ghash_clmulni_intel snd_seq snd_seq_device ppdev snd_pcm joydev snd_timer snd virtio_balloon soundcore i2c_piix4 parport_pc parport acpi_cpufreq tpm_tis tpm_tis_core qemu_fw_cfg tpm xfs libcrc32c virtio_rng virtio_console virtio_blk
virtio_net
[ 155.156465] crc32c_intel qxl drm_kms_helper ttm serio_raw drm virtio_pci virtio_ring virtio ata_generic pata_acpi
[ 155.156474] irq event stamp: 3596
[ 155.156477] hardirqs last enabled at (3596): [<ffffffff8c296dee>] __slab_alloc+0x5e/0x90
[ 155.156479] hardirqs last disabled at (3595): [<ffffffff8c296dcc>] __slab_alloc+0x3c/0x90
[ 155.156482] softirqs last enabled at (3508): [<ffffffff8c84db6c>] tcf_hash_lookup+0x6c/0x80
[ 155.156485] softirqs last disabled at (3510): [<ffffffffc08ba22d>] tcf_act_police_init+0x22d/0x580 [act_police]
[ 155.156487] CPU: 2 PID: 1793 Comm: tc Tainted: G W 4.11.3-202.fc25.x86_64+debug #1
[ 155.156488] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.fc25 04/01/2014
[ 155.156489] task: ffff98a803f5b240 task.stack: ffffb21b41b24000
[ 155.156492] RIP: 0010:queued_spin_lock_slowpath+0x25/0x1a0
[ 155.156493] RSP: 0018:ffffb21b41b27720 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff10
[ 155.156495] RAX: 0000000000000001 RBX: ffff98a83a7a4298 RCX: 0000000000000002
[ 155.156496] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff98a83a7a4298
[ 155.156498] RBP: ffffb21b41b27720 R08: 000000345deae54f R09: 0000000000000000
[ 155.156499] R10: ffffb21b41b276d0 R11: 0000000000000000 R12: ffff98a83a7a4298
[ 155.156500] R13: ffff98a8395da474 R14: ffff98a82789c200 R15: ffff98a83a7a4270
[ 155.156501] FS: 00007f50e0bbd500(0000) GS:ffff98a83d400000(0000) knlGS:0000000000000000
[ 155.156502] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 155.156504] CR2: 00007ffe99d18000 CR3: 000000003c549000 CR4: 00000000001406e0
[ 155.156507] Call Trace:
[ 155.156510] do_raw_spin_lock+0xb2/0xc0
[ 155.156513] _raw_spin_lock+0x55/0x70
[ 155.156515] est_fetch_counters+0x23/0x50
[ 155.156517] gen_new_estimator+0xdf/0x1d0
[ 155.156520] gen_replace_estimator+0xe/0x10
[ 155.156522] tcf_act_police_init+0x255/0x580 [act_police]
[ 155.156525] tcf_action_init_1+0xb9/0x340
[ 155.156530] tcf_exts_validate+0x52/0x110
[ 155.156532] fw_change_attrs+0xbb/0x2b0 [cls_fw]
[ 155.156535] ? rcu_read_lock_sched_held+0x4a/0x80
[ 155.156537] fw_change+0x3ad/0x4bb [cls_fw]
[ 155.156541] tc_ctl_tfilter+0x470/0xa80
[ 155.156546] rtnetlink_rcv_msg+0xe6/0x210
[ 155.156549] ? sched_clock+0x9/0x10
[ 155.156551] ? sched_clock_cpu+0x11/0xc0
[ 155.156553] ? netlink_unicast+0x1cd/0x2f0
[ 155.156555] ? rtnl_newlink+0x8e0/0x8e0
[ 155.156557] netlink_rcv_skb+0xa4/0xc0
[ 155.156559] rtnetlink_rcv+0x2a/0x40
[ 155.156560] netlink_unicast+0x1f5/0x2f0
[ 155.156563] netlink_sendmsg+0x302/0x3c0
[ 155.156566] sock_sendmsg+0x38/0x50
[ 155.156568] ___sys_sendmsg+0x2f6/0x310
[ 155.156571] ? _raw_spin_unlock+0x27/0x40
[ 155.156573] ? __handle_mm_fault+0x539/0x1170
[ 155.156576] ? __do_page_fault+0x28e/0x520
[ 155.156578] ? kvm_sched_clock_read+0x25/0x40
[ 155.156580] ? sched_clock+0x9/0x10
[ 155.156581] ? sched_clock_cpu+0x11/0xc0
[ 155.156583] ? __do_page_fault+0x28e/0x520
[ 155.156587] __sys_sendmsg+0x54/0x90
[ 155.156588] ? __sys_sendmsg+0x54/0x90
[ 155.156592] SyS_sendmsg+0x12/0x20
[ 155.156594] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 155.156595] RIP: 0033:0x7f50dffca037
[ 155.156596] RSP: 002b:00007ffe99d12698 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[ 155.156598] RAX: ffffffffffffffda RBX: 00007ffe99d1e7e0 RCX: 00007f50dffca037
[ 155.156599] RDX: 0000000000000000 RSI: 00007ffe99d126e0 RDI: 0000000000000003
[ 155.156600] RBP: 00007ffe99d126e0 R08: 0000000000000001 R09: 0000000000000000
[ 155.156601] R10: 00000000000005eb R11: 0000000000000246 R12: 00007ffe99d12720
[ 155.156602] R13: 0000000000668060 R14: 00007ffe99d1a7b0 R15: 0000000000000000
[ 155.156606] Code: 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 0f 1f 44 00 00 ba 01 00 00 00 8b 07 85 c0 75 0a f0 0f b1 17 85 c0 75 f2 5d c3 f3 90 <eb> ec 81 fe 00 01 00 00 0f 84 9a 00 00 00 41 b8 01 01 00 00 b9
I haven't seen anything queued up for this yet.
Thanks,
Laura
^ permalink raw reply
* Re: [PATCH net] qed: fix dump of context data
From: David Miller @ 2017-06-13 17:33 UTC (permalink / raw)
To: Tomer.Tayar; +Cc: netdev, yuval.mintz
In-Reply-To: <1497345359-2193-1-git-send-email-Tomer.Tayar@cavium.com>
From: Tomer Tayar <Tomer.Tayar@cavium.com>
Date: Tue, 13 Jun 2017 12:15:59 +0300
> Currently when dumping a context data only word number '1' is read for the
> entire context.
>
> Fixes: c965db444629 ("qed: Add support for debug data collection")
>
> Signed-off-by: Tomer Tayar <Tomer.Tayar@cavium.com>
Applied.
^ permalink raw reply
* Re: pull-request: mac80211 2017-06-13
From: David Miller @ 2017-06-13 17:34 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170613094409.12965-1-johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date: Tue, 13 Jun 2017 11:44:08 +0200
> Here are some more fixes for the current cycle. Nothing really
> big, though my own patches look bigger than they are due to some
> code moving. The commit logs are far longer than the changes :-)
>
> Please pull and let me know if there's any problem.
Pulled, thanks Johannes.
^ permalink raw reply
* [PATCH] af_iucv: Move sockaddr length checks to before accessing sa_family in bind and connect handlers
From: Mateusz Jurczyk @ 2017-06-13 17:42 UTC (permalink / raw)
To: Julian Wiedmann, Ursula Braun, David S. Miller, linux-s390,
netdev, linux-kernel
Verify that the caller-provided sockaddr structure is large enough to
contain the sa_family field, before accessing it in bind() and connect()
handlers of the AF_IUCV socket. Since neither syscall enforces a minimum
size of the corresponding memory region, very short sockaddrs (zero or
one byte long) result in operating on uninitialized memory while
referencing .sa_family.
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
---
net/iucv/af_iucv.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/iucv/af_iucv.c b/net/iucv/af_iucv.c
index 84de7b6326dc..1f63e704ab50 100644
--- a/net/iucv/af_iucv.c
+++ b/net/iucv/af_iucv.c
@@ -716,10 +716,8 @@ static int iucv_sock_bind(struct socket *sock, struct sockaddr *addr,
char uid[9];
/* Verify the input sockaddr */
- if (!addr || addr->sa_family != AF_IUCV)
- return -EINVAL;
-
- if (addr_len < sizeof(struct sockaddr_iucv))
+ if (!addr || addr_len < sizeof(struct sockaddr_iucv) ||
+ addr->sa_family != AF_IUCV)
return -EINVAL;
lock_sock(sk);
@@ -863,7 +861,7 @@ static int iucv_sock_connect(struct socket *sock, struct sockaddr *addr,
struct iucv_sock *iucv = iucv_sk(sk);
int err;
- if (addr->sa_family != AF_IUCV || alen < sizeof(struct sockaddr_iucv))
+ if (alen < sizeof(struct sockaddr_iucv) || addr->sa_family != AF_IUCV)
return -EINVAL;
if (sk->sk_state != IUCV_OPEN && sk->sk_state != IUCV_BOUND)
--
2.13.1.508.gb3defc5cc-goog
^ permalink raw reply related
* Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock
From: Arun Parameswaran @ 2017-06-13 17:46 UTC (permalink / raw)
To: Richard Cochran
Cc: Rob Herring, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w
In-Reply-To: <20170613050947.GA1684-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
Hi Richard,
On 17-06-12 10:09 PM, Richard Cochran wrote:
> On Mon, Jun 12, 2017 at 01:26:00PM -0700, Arun Parameswaran wrote:
>> +Example:
>> +
>> +ptp_dte: ptp_dte@180af650 {
>> + compatible = "brcm,ptp-dte";
>> + reg = <0x180af650 0x10>;
>> + status = "okay";
>> +};
> This patch set looks okay, as far as it goes, but how does one
> actually use the clock?
>
> How does one connect this node to an Ethernet MAC, for example?
In some of the SoC's, the DTE's NCO is synced in hardware with the Ethernet's
1588 Shim NCO (used for time-stamping the packets). We are working on getting
all the future SoC's synced this way (for Ethernet).
In other scenarios, we use an user-space app to perform the sync based on
time-stamps from external hardware sources like the Wi-Fi.
> Thanks,
> Richard
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/2] pull request for net: batman-adv 2017-06-13
From: David Miller @ 2017-06-13 17:46 UTC (permalink / raw)
To: sw; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20170613111531.29082-1-sw@simonwunderlich.de>
From: Simon Wunderlich <sw@simonwunderlich.de>
Date: Tue, 13 Jun 2017 13:15:29 +0200
> here are two batman-adv bugfixes for net.
>
> Please pull or let me know of any problem!
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH RFC net-next 3/4] net/mlx5: Separate between eswitch and MPFS l2 table logic
From: Saeed Mahameed @ 2017-06-13 17:49 UTC (permalink / raw)
To: Jes Sorensen
Cc: Saeed Mahameed, Linux Netdev List, Kernel Team, Or Gerlitz,
Tzahi Oved
In-Reply-To: <d205ed47-0275-ade7-1fdc-d82001b1dda5@fb.com>
On Mon, Jun 12, 2017 at 8:52 PM, Jes Sorensen <jsorensen@fb.com> wrote:
> On 06/07/2017 07:42 PM, Saeed Mahameed wrote:
>>
>> Multi-Physical Function Switch (MPFs) is required for when multi-PF
>> configuration is enabled to allow passing user configured unicast MAC
>> addresses to the requesting PF.
>>
>> Before this patch eswitch.c used to manage the HW MPFS l2 table,
>> eswitch always enabled vport(0) (NIC PF) vport's contexts update on
>> unicast
>> mac address list changes, to populate the PF's MPFS L2 table accordingly,
>> even if SRIOV was not enabled.
>>
>> In downstream patch we would like to allow compiling the driver without
>> eswitch functionalities, for that we move MPFS l2 table logic out
>> of eswitch.c into its own file, and provide Kconfig flag (MLX5_MPFS) to
>> allow compiling out MPFS for those who don't want Multi-PF support
>>
>> NIC PF netdevice will now directly update MPFS l2 table via the new MPFS
>> API. VF netdevice has no access to MPFS L2 table, so e-Switch will remain
>> responsible of updating its PF MPFS l2 table on behalf of its VFs.
>>
>> Due to this change we also don't require enabling vport(0) (PF vport)
>> unicast mac changes events anymore, for when SRIOV is not enabled.
>> Which means eswitch is now activated only on SRIOV activation, and not
>> required otherwise.
>
>
>
> On overall it looks good - one nit.
>
>> +static int alloc_l2table_index(struct mlx5_mpfs *l2table, u32 *ix)
>> +{
>> + int err = 0;
>> +
>> + *ix = find_first_zero_bit(l2table->bitmap, l2table->size);
>> + if (*ix >= l2table->size)
>> + err = -ENOSPC;
>> + else
>> + __set_bit(*ix, l2table->bitmap);
>> +
>> + return err;
>> +}
>
>
> You pass in a pointer for ix but you don't modify it, why not just pass in
> the value?.
>
we do modify ix:
*ix = find_first_zero_bit(l2table->bitmap, l2table->size);
The idea is to find the next free index and return it to the caller
>> +static void free_l2table_index(struct mlx5_mpfs *l2table, u32 ix)
>> +{
>> + __clear_bit(ix, l2table->bitmap);
>> +}
>
>
> Here you stick to the u32.
to free the index we allocated from before
>
> Jes
^ permalink raw reply
* Re: [PATCH 00/10] pull request for net-next: batman-adv 2017-06-13
From: David Miller @ 2017-06-13 17:52 UTC (permalink / raw)
To: sw; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20170613113700.31220-1-sw@simonwunderlich.de>
From: Simon Wunderlich <sw@simonwunderlich.de>
Date: Tue, 13 Jun 2017 13:36:50 +0200
> here is our feature/cleanup pull request of batman-adv to go into net-next.
>
> Please pull or let me know of any problem!
Pulled, thanks.
^ permalink raw reply
* Re: Lockdep splat with tc filter on 4.11
From: Cong Wang @ 2017-06-13 17:52 UTC (permalink / raw)
To: Laura Abbott
Cc: Jamal Hadi Salim, David S. Miller,
Linux Kernel Network Developers, Linux Kernel Mailing List,
nicholashuber
In-Reply-To: <d1a11d1e-c167-3bab-7b82-10932dedfb1d@redhat.com>
On Tue, Jun 13, 2017 at 10:28 AM, Laura Abbott <labbott@redhat.com> wrote:
> Hi,
>
> Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1459626
> of a hang on 4.11.3 with lockdep splat:
>
> [ 129.100206] BUG: sleeping function called from invalid context at mm/slab.h:432
> [ 129.100237] in_atomic(): 1, irqs_disabled(): 0, pid: 1793, name: tc
> [ 129.100239] 2 locks held by tc/1793:
> [ 129.100241] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff8c826217>] rtnl_lock+0x17/0x20
> [ 129.100250] #1: (&(&p->tcfa_lock)->rlock){+...+.}, at: [<ffffffffc08ba22d>] tcf_act_police_init+0x22d/0x580 [act_police]
> [ 129.100259] CPU: 2 PID: 1793 Comm: tc Not tainted 4.11.3-202.fc25.x86_64+debug #1
> [ 129.100261] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.fc25 04/01/2014
> [ 129.100262] Call Trace:
> [ 129.100270] dump_stack+0x86/0xc3
> [ 129.100274] ___might_sleep+0x17d/0x250
> [ 129.100277] __might_sleep+0x4a/0x80
> [ 129.100280] kmem_cache_alloc_trace+0x1e6/0x2d0
> [ 129.100284] ? gen_new_estimator+0x76/0x1d0
> [ 129.100288] gen_new_estimator+0x76/0x1d0
> [ 129.100293] gen_replace_estimator+0xe/0x10
> [ 129.100296] tcf_act_police_init+0x255/0x580 [act_police]
Thanks for the report!
That spinlock is intended to serialize police->tcf_rate_est,
but it looks unnecessary since we already have rtnl lock.
I will work on a patch.
^ permalink raw reply
* Re: pull-request: mac80211-next 2017-06-13
From: David Miller @ 2017-06-13 17:53 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20170613122223.2386-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Tue, 13 Jun 2017 14:22:21 +0200
> Looks like I haven't sent you anything for a long time, so here
> we go. There isn't a ton of things, but in particular the 4-way-
> handshake offload has been a long time in the making.
Looks good, pulled, thanks Johannes.
> I'll send you the conversion for more skb_put_zero() users in a
> separate patch after this.
Ok.
^ permalink raw reply
* Re: [PATCH] Add printk for bonding module packets_per_slave parameter
From: Nikolay Aleksandrov @ 2017-06-13 17:53 UTC (permalink / raw)
To: Joe Perches, jtoppins, David Miller, michael.j.dilmore
Cc: j.vosburgh, vfalico, andy, netdev, linux-kernel
In-Reply-To: <1497373252.18751.19.camel@perches.com>
On 13/06/17 20:00, Joe Perches wrote:
> On Tue, 2017-06-13 at 12:42 -0400, Jonathan Toppins wrote:
>> On 06/13/2017 12:21 PM, Joe Perches wrote:
>>> On Tue, 2017-06-13 at 11:34 -0400, David Miller wrote:
>>>> From: Michael Dilmore <michael.j.dilmore@gmail.com>
>>>> Date: Tue, 13 Jun 2017 14:42:46 +0100
>>>>
>>>>> The packets per slave parameter used by round robin mode does not have a printk debug
>>>>> message in its set function in bond_options.c. Adding such a function would aid debugging
>>>>> of round-robin mode and allow the user to more easily verify that the parameter has been
>>>>> set correctly. I should add that I'm motivated by my own experience here - it's not
>>>>> obvious from output of tools such as wireshark and ifstat that the parameter is working
>>>>> correctly, and with the differences in bonding configuration across different distributions,
>>>>> it would have been comforting to see this output.
> []
>>>> You can verify things by simplying reading the value back.
>>>>
>>>> If every parameter emitted a kernel log message, it would be
>>>> unreadable.
>>>>
>>>> I'm not applying this, sorry.
>>>
>>> I agree. Noisy logging output is not good.
>>>
>>> Perhaps a general conversion of the dozens
>>> of existing netdev_info uses in this file to
>>> netdev_dbg and adding this at netdev_dbg is
>>> appropriate.
>>
>> In general I agree. The few times I have debugged bonds, I always ended
>> up enabling debug prinks anyway. I don't see a problem moving these to
>> debug as well.
>>
>> Adding nik whom converted a lot of this code to common paths for input.
>
> If Nikolay agrees with the conversion, it's trivial.
> Please submit it. I did it just for reference.
>
> Stylistic nits about the existing file:
>
> There are some inconsistencies in pr_info/pr_err uses
> with invalid inputs.
>
> It would also be nicer if the forward static declarations
> were removed and the static definitions reordered.
>
Agreed, there are many ways to extract the values.
^ 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