Netdev List
 help / color / mirror / Atom feed
* [PATCH net-next v2] ipv6: make unsolicited report intervals configurable for mld
From: Hannes Frederic Sowa @ 2013-08-12 11:28 UTC (permalink / raw)
  To: netdev; +Cc: xiyou.wangcong, william.manley, bcrl, yoshfuji

Commit cab70040dfd95ee32144f02fade64f0cb94f31a0 ("net: igmp:
Reduce Unsolicited report interval to 1s when using IGMPv3") and
2690048c01f32bf45d1c1e1ab3079bc10ad2aea7 ("net: igmp: Allow user-space
configuration of igmp unsolicited report interval") by William Manley made
igmp unsolicited report intervals configurable per interface and corrected
the interval of unsolicited igmpv3 report messages resendings to 1s.

Same needs to be done for IPv6:

MLDv1 (RFC2710 7.10.): 10 seconds
MLDv2 (RFC3810 9.11.): 1 second

Both intervals are configurable via new procfs knobs
mldv1_unsolicited_report_interval and mldv2_unsolicited_report_interval.

(also added .force_mld_version to ipv6_devconf_dflt to bring structs in
line without semantic changes)

v2:
a) Joined documentation update for IPv4 and IPv6 MLD/IGMP
   unsolicited_report_interval procfs knobs.
b) incorporate stylistic feedback from William Manley

Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: William Manley <william.manley@youview.com>
Cc: Benjamin LaHaise <bcrl@kvack.org>
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
 Documentation/networking/ip-sysctl.txt | 18 ++++++++++++++++++
 include/linux/ipv6.h                   |  2 ++
 include/uapi/linux/ipv6.h              |  2 ++
 net/ipv6/addrconf.c                    | 25 +++++++++++++++++++++++++
 net/ipv6/mcast.c                       | 17 ++++++++++++++---
 5 files changed, 61 insertions(+), 3 deletions(-)

diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 36be26b..debfe85 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1039,7 +1039,15 @@ disable_policy - BOOLEAN
 disable_xfrm - BOOLEAN
 	Disable IPSEC encryption on this interface, whatever the policy
 
+igmpv2_unsolicited_report_interval - INTEGER
+	The interval in milliseconds in which the next unsolicited
+	IGMPv1 or IGMPv2 report retransmit will take place.
+	Default: 10000 (10 seconds)
 
+igmpv3_unsolicited_report_interval - INTEGER
+	The interval in milliseconds in which the next unsolicited
+	IGMPv3 report retransmit will take place.
+	Default: 1000 (1 seconds)
 
 tag - INTEGER
 	Allows you to write a number, which can be used as required.
@@ -1331,6 +1339,16 @@ ndisc_notify - BOOLEAN
 	1 - Generate unsolicited neighbour advertisements when device is brought
 	    up or hardware address changes.
 
+mldv1_unsolicited_report_interval - INTEGER
+	The interval in milliseconds in which the next unsolicited
+	MLDv1 report retransmit will take place.
+	Default: 10000 (10 seconds)
+
+mldv2_unsolicited_report_interval - INTEGER
+	The interval in milliseconds in which the next unsolicited
+	MLDv2 report retransmit will take place.
+	Default: 1000 (1 second)
+
 icmp/*:
 ratelimit - INTEGER
 	Limit the maximal rates for sending ICMPv6 packets.
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 850e95b..77a4784 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -19,6 +19,8 @@ struct ipv6_devconf {
 	__s32		rtr_solicit_interval;
 	__s32		rtr_solicit_delay;
 	__s32		force_mld_version;
+	__s32		mldv1_unsolicited_report_interval;
+	__s32		mldv2_unsolicited_report_interval;
 #ifdef CONFIG_IPV6_PRIVACY
 	__s32		use_tempaddr;
 	__s32		temp_valid_lft;
diff --git a/include/uapi/linux/ipv6.h b/include/uapi/linux/ipv6.h
index 4bda4cf..315f133 100644
--- a/include/uapi/linux/ipv6.h
+++ b/include/uapi/linux/ipv6.h
@@ -147,6 +147,8 @@ enum {
 	DEVCONF_MAX_DESYNC_FACTOR,
 	DEVCONF_MAX_ADDRESSES,
 	DEVCONF_FORCE_MLD_VERSION,
+	DEVCONF_MLDV1_UNSOLICITED_REPORT_INTERVAL,
+	DEVCONF_MLDV2_UNSOLICITED_REPORT_INTERVAL,
 	DEVCONF_ACCEPT_RA_DEFRTR,
 	DEVCONF_ACCEPT_RA_PINFO,
 	DEVCONF_ACCEPT_RA_RTR_PREF,
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 7fd8572..ad12f7c 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -177,6 +177,8 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
 	.accept_redirects	= 1,
 	.autoconf		= 1,
 	.force_mld_version	= 0,
+	.mldv1_unsolicited_report_interval = 10 * HZ,
+	.mldv2_unsolicited_report_interval = HZ,
 	.dad_transmits		= 1,
 	.rtr_solicits		= MAX_RTR_SOLICITATIONS,
 	.rtr_solicit_interval	= RTR_SOLICITATION_INTERVAL,
@@ -211,6 +213,9 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
 	.accept_ra		= 1,
 	.accept_redirects	= 1,
 	.autoconf		= 1,
+	.force_mld_version	= 0,
+	.mldv1_unsolicited_report_interval = 10 * HZ,
+	.mldv2_unsolicited_report_interval = HZ,
 	.dad_transmits		= 1,
 	.rtr_solicits		= MAX_RTR_SOLICITATIONS,
 	.rtr_solicit_interval	= RTR_SOLICITATION_INTERVAL,
@@ -4179,6 +4184,10 @@ static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
 	array[DEVCONF_RTR_SOLICIT_DELAY] =
 		jiffies_to_msecs(cnf->rtr_solicit_delay);
 	array[DEVCONF_FORCE_MLD_VERSION] = cnf->force_mld_version;
+	array[DEVCONF_MLDV1_UNSOLICITED_REPORT_INTERVAL] =
+		jiffies_to_msecs(cnf->mldv1_unsolicited_report_interval);
+	array[DEVCONF_MLDV2_UNSOLICITED_REPORT_INTERVAL] =
+		jiffies_to_msecs(cnf->mldv2_unsolicited_report_interval);
 #ifdef CONFIG_IPV6_PRIVACY
 	array[DEVCONF_USE_TEMPADDR] = cnf->use_tempaddr;
 	array[DEVCONF_TEMP_VALID_LFT] = cnf->temp_valid_lft;
@@ -4862,6 +4871,22 @@ static struct addrconf_sysctl_table
 			.mode		= 0644,
 			.proc_handler	= proc_dointvec,
 		},
+		{
+			.procname	= "mldv1_unsolicited_report_interval",
+			.data		=
+				&ipv6_devconf.mldv1_unsolicited_report_interval,
+			.maxlen		= sizeof(int),
+			.mode		= 0644,
+			.proc_handler	= proc_dointvec_ms_jiffies,
+		},
+		{
+			.procname	= "mldv2_unsolicited_report_interval",
+			.data		=
+				&ipv6_devconf.mldv2_unsolicited_report_interval,
+			.maxlen		= sizeof(int),
+			.mode		= 0644,
+			.proc_handler	= proc_dointvec_ms_jiffies,
+		},
 #ifdef CONFIG_IPV6_PRIVACY
 		{
 			.procname	= "use_tempaddr",
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index db25b8e..6c76df9 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -108,7 +108,6 @@ static int ip6_mc_leave_src(struct sock *sk, struct ipv6_mc_socklist *iml,
 			    struct inet6_dev *idev);
 
 
-#define IGMP6_UNSOLICITED_IVAL	(10*HZ)
 #define MLD_QRV_DEFAULT		2
 
 #define MLD_V1_SEEN(idev) (dev_net((idev)->dev)->ipv6.devconf_all->force_mld_version == 1 || \
@@ -129,6 +128,18 @@ int sysctl_mld_max_msf __read_mostly = IPV6_MLD_MAX_MSF;
 	     pmc != NULL;					\
 	     pmc = rcu_dereference(pmc->next))
 
+static int unsolicited_report_interval(struct inet6_dev *idev)
+{
+	int iv;
+
+	if (MLD_V1_SEEN(idev))
+		iv = idev->cnf.mldv1_unsolicited_report_interval;
+	else
+		iv = idev->cnf.mldv2_unsolicited_report_interval;
+
+	return iv > 0 ? iv : 1;
+}
+
 int ipv6_sock_mc_join(struct sock *sk, int ifindex, const struct in6_addr *addr)
 {
 	struct net_device *dev = NULL;
@@ -2158,7 +2169,7 @@ static void igmp6_join_group(struct ifmcaddr6 *ma)
 
 	igmp6_send(&ma->mca_addr, ma->idev->dev, ICMPV6_MGM_REPORT);
 
-	delay = net_random() % IGMP6_UNSOLICITED_IVAL;
+	delay = net_random() % unsolicited_report_interval(ma->idev);
 
 	spin_lock_bh(&ma->mca_lock);
 	if (del_timer(&ma->mca_timer)) {
@@ -2325,7 +2336,7 @@ void ipv6_mc_init_dev(struct inet6_dev *idev)
 	setup_timer(&idev->mc_dad_timer, mld_dad_timer_expire,
 		    (unsigned long)idev);
 	idev->mc_qrv = MLD_QRV_DEFAULT;
-	idev->mc_maxdelay = IGMP6_UNSOLICITED_IVAL;
+	idev->mc_maxdelay = unsolicited_report_interval(idev);
 	idev->mc_v1_seen = 0;
 	write_unlock_bh(&idev->lock);
 }
-- 
1.8.3.1

^ permalink raw reply related
* [PATCH] myri10ge: Update MAINTAINERS
From: Hyong-Youb Kim @ 2013-08-12  9:20 UTC (permalink / raw)
  To: David S. Miller; +Cc: netdev, Hyong-Youb Kim

Remove Andrew Gallatin, as he is no longer with Myricom. Add
Hyong-Youb Kim as the new maintainer. Update the website URL.

Signed-off-by: Hyong-Youb Kim <hykim@myri.com>
---
 MAINTAINERS |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index b57ecb1..0eb35c3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5576,9 +5576,9 @@ S:	Maintained
 F:	drivers/media/tuners/mxl5007t.*
 
 MYRICOM MYRI-10G 10GbE DRIVER (MYRI10GE)
-M:	Andrew Gallatin <gallatin@myri.com>
+M:	Hyong-Youb Kim <hykim@myri.com>
 L:	netdev@vger.kernel.org
-W:	http://www.myri.com/scs/download-Myri10GE.html
+W:	https://www.myricom.com/support/downloads/myri10ge.html
 S:	Supported
 F:	drivers/net/ethernet/myricom/myri10ge/
 
-- 
1.7.9

^ permalink raw reply related
* Re: [PATCH net-next] ipv6: make unsolicited report intervals configurable for mld
From: Hannes Frederic Sowa @ 2013-08-12 11:09 UTC (permalink / raw)
  To: William Manley; +Cc: netdev, bcrl, yoshfuji
In-Reply-To: <5208B602.4040107@youview.com>

On Mon, Aug 12, 2013 at 11:16:34AM +0100, William Manley wrote:
> On 12/08/13 02:48, Hannes Frederic Sowa wrote:
> >Commit cab70040dfd95ee32144f02fade64f0cb94f31a0 ("net: igmp:
> >Reduce Unsolicited report interval to 1s when using IGMPv3") and
> >2690048c01f32bf45d1c1e1ab3079bc10ad2aea7 ("net: igmp: Allow user-space
> >configuration of igmp unsolicited report interval") by William Manley made
> >igmp unsolicited report intervals configurable per interface and corrected
> >the interval of unsolicited igmpv3 report messages resendings to 1s.
> >
> >Same needs to be done for IPv6:
> >
> >MLDv1 (RFC2710 7.10.): 10 seconds
> >MLDv2 (RFC3810 9.11.): 1 second
> >
> >Both intervals are configurable via new procfs knobs
> >mldv1_unsolicited_report_interval and mldv2_unsolicited_report_interval.
> >
> >Cc: William Manley<william.manley@youview.com>
> >Cc: Benjamin LaHaise<bcrl@kvack.org>
> >Cc: YOSHIFUJI Hideaki<yoshfuji@linux-ipv6.org>
> >Signed-off-by: Hannes Frederic Sowa<hannes@stressinduktion.org>
> 
> Thanks for this.  I'd meant to save you the bother.

I am very sorry if you already started with this. I feared it might already be
forgotten.

> >diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> >index 7fd8572..158c5e1 100644
> >--- a/net/ipv6/addrconf.c
> >+++ b/net/ipv6/addrconf.c
> >@@ -177,6 +177,8 @@ static struct ipv6_devconf ipv6_devconf __read_mostly 
> >= {
> >  	.accept_redirects	= 1,
> >  	.autoconf		= 1,
> >  	.force_mld_version	= 0,
> >+	.mldv1_unsolicited_report_interval = 10*HZ,
> 
> I think you want spaces around that * operator.
> 
> >+	.mldv2_unsolicited_report_interval = HZ,
> >  	.dad_transmits		= 1,
> >  	.rtr_solicits		= MAX_RTR_SOLICITATIONS,
> >  	.rtr_solicit_interval	= RTR_SOLICITATION_INTERVAL,
> >@@ -211,6 +213,9 @@ static struct ipv6_devconf ipv6_devconf_dflt 
> >__read_mostly = {
> >  	.accept_ra		= 1,
> >  	.accept_redirects	= 1,
> >  	.autoconf		= 1,
> >+	.force_mld_version	= 0,
> 
> Is this a tidyup or does it make a functional difference to this patch? 
>  I suspect the former but I thought I'd check for my own understanding.

Yes, It is solely a small tidy up to bring both structs in line. I will
mention it in the commit message.

> 
> >+	.mldv1_unsolicited_report_interval = 10*HZ,
> 
> Spaces here as well
> 
I will incorporate your other feedback in my next patch.

Thanks you,

  Hannes

^ permalink raw reply
* [PATCH][net-next v2] gianfar: Add flow control support
From: Claudiu Manoil @ 2013-08-12 10:53 UTC (permalink / raw)
  To: netdev; +Cc: David S. Miller, Ben Hutchings, Lutz Jaenicke
In-Reply-To: <1376068786-29868-1-git-send-email-claudiu.manoil@freescale.com>

eTSEC has Rx and Tx flow control capabilities that may be enabled
through MACCFG1[Rx_Flow, Tx_Flow] bits.  These bits must not be set
however when eTSEC is operated in Half-Duplex mode.  Unfortunately,
the driver currently sets these bits unconditionally.
This patch adds the proper handling of the PAUSE frame capability
register bits by implementing the ethtool -A interface.  When pause
autoneg is enabled, the controller uses the phy's capability to
negotiate PAUSE frame settings with the link partner and reconfigures
its Rx_Flow and Tx_Flow settings to match the capabilities of the
link partner.  If pause autoneg is off, the PAUSE frame generation
may be forced manually (ethtool -A).  Flow control is disabled by
default now.
This implementation is inspired by the tg3 driver.

Signed-off-by: Lutz Jaenicke <ljaenicke@innominate.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
---
v1 - Cleaned-up version of:
http://patchwork.ozlabs.org/patch/265940/
v2 - move code to gfar_get_flowctrl_cfg()
   - remove unused 'err'


 drivers/net/ethernet/freescale/gianfar.c         | 51 +++++++++++++++-
 drivers/net/ethernet/freescale/gianfar.h         | 10 +++-
 drivers/net/ethernet/freescale/gianfar_ethtool.c | 74 ++++++++++++++++++++++++
 3 files changed, 132 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index edf06f1..808b6a2 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -1016,7 +1016,14 @@ static int gfar_probe(struct platform_device *ofdev)
 	/* We need to delay at least 3 TX clocks */
 	udelay(2);
 
-	tempval = (MACCFG1_TX_FLOW | MACCFG1_RX_FLOW);
+	tempval = 0;
+	if (!priv->pause_aneg_en && priv->tx_pause_en)
+		tempval |= MACCFG1_TX_FLOW;
+	if (!priv->pause_aneg_en && priv->rx_pause_en)
+		tempval |= MACCFG1_RX_FLOW;
+	/* the soft reset bit is not self-resetting, so we need to
+	 * clear it before resuming normal operation
+	 */
 	gfar_write(&regs->maccfg1, tempval);
 
 	/* Initialize MACCFG2. */
@@ -1462,7 +1469,7 @@ static int init_phy(struct net_device *dev)
 	struct gfar_private *priv = netdev_priv(dev);
 	uint gigabit_support =
 		priv->device_flags & FSL_GIANFAR_DEV_HAS_GIGABIT ?
-		SUPPORTED_1000baseT_Full : 0;
+		GFAR_SUPPORTED_GBIT : 0;
 	phy_interface_t interface;
 
 	priv->oldlink = 0;
@@ -3025,6 +3032,41 @@ static irqreturn_t gfar_interrupt(int irq, void *grp_id)
 	return IRQ_HANDLED;
 }
 
+static u32 gfar_get_flowctrl_cfg(struct gfar_private *priv)
+{
+	struct phy_device *phydev = priv->phydev;
+	u32 val = 0;
+
+	if (!phydev->duplex)
+		return val;
+
+	if (!priv->pause_aneg_en) {
+		if (priv->tx_pause_en)
+			val |= MACCFG1_TX_FLOW;
+		if (priv->rx_pause_en)
+			val |= MACCFG1_RX_FLOW;
+	} else {
+		u16 lcl_adv, rmt_adv;
+		u8 flowctrl;
+		/* get link partner capabilities */
+		rmt_adv = 0;
+		if (phydev->pause)
+			rmt_adv = LPA_PAUSE_CAP;
+		if (phydev->asym_pause)
+			rmt_adv |= LPA_PAUSE_ASYM;
+
+		lcl_adv = mii_advertise_flowctrl(phydev->advertising);
+
+		flowctrl = mii_resolve_flowctrl_fdx(lcl_adv, rmt_adv);
+		if (flowctrl & FLOW_CTRL_TX)
+			val |= MACCFG1_TX_FLOW;
+		if (flowctrl & FLOW_CTRL_RX)
+			val |= MACCFG1_RX_FLOW;
+	}
+
+	return val;
+}
+
 /* Called every time the controller might need to be made
  * aware of new link state.  The PHY code conveys this
  * information through variables in the phydev structure, and this
@@ -3043,6 +3085,7 @@ static void adjust_link(struct net_device *dev)
 	lock_tx_qs(priv);
 
 	if (phydev->link) {
+		u32 tempval1 = gfar_read(&regs->maccfg1);
 		u32 tempval = gfar_read(&regs->maccfg2);
 		u32 ecntrl = gfar_read(&regs->ecntrl);
 
@@ -3091,6 +3134,10 @@ static void adjust_link(struct net_device *dev)
 			priv->oldspeed = phydev->speed;
 		}
 
+		tempval1 &= ~(MACCFG1_TX_FLOW | MACCFG1_RX_FLOW);
+		tempval1 |= gfar_get_flowctrl_cfg(priv);
+
+		gfar_write(&regs->maccfg1, tempval1);
 		gfar_write(&regs->maccfg2, tempval);
 		gfar_write(&regs->ecntrl, ecntrl);
 
diff --git a/drivers/net/ethernet/freescale/gianfar.h b/drivers/net/ethernet/freescale/gianfar.h
index ee19f2c..46f56f3 100644
--- a/drivers/net/ethernet/freescale/gianfar.h
+++ b/drivers/net/ethernet/freescale/gianfar.h
@@ -146,6 +146,10 @@ extern const char gfar_driver_version[];
 		| SUPPORTED_Autoneg \
 		| SUPPORTED_MII)
 
+#define GFAR_SUPPORTED_GBIT (SUPPORTED_1000baseT_Full \
+		| SUPPORTED_Pause \
+		| SUPPORTED_Asym_Pause)
+
 /* TBI register addresses */
 #define MII_TBICON		0x11
 
@@ -1100,7 +1104,11 @@ struct gfar_private {
 		/* Wake-on-LAN enabled */
 		wol_en:1,
 		/* Enable priorty based Tx scheduling in Hw */
-		prio_sched_en:1;
+		prio_sched_en:1,
+		/* Flow control flags */
+		pause_aneg_en:1,
+		tx_pause_en:1,
+		rx_pause_en:1;
 
 	/* The total tx and rx ring size for the enabled queues */
 	unsigned int total_tx_ring_size;
diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c
index 21cd881..d3d7ede 100644
--- a/drivers/net/ethernet/freescale/gianfar_ethtool.c
+++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c
@@ -535,6 +535,78 @@ static int gfar_sringparam(struct net_device *dev,
 	return err;
 }
 
+static void gfar_gpauseparam(struct net_device *dev,
+			     struct ethtool_pauseparam *epause)
+{
+	struct gfar_private *priv = netdev_priv(dev);
+
+	epause->autoneg = !!priv->pause_aneg_en;
+	epause->rx_pause = !!priv->rx_pause_en;
+	epause->tx_pause = !!priv->tx_pause_en;
+}
+
+static int gfar_spauseparam(struct net_device *dev,
+			    struct ethtool_pauseparam *epause)
+{
+	struct gfar_private *priv = netdev_priv(dev);
+	struct phy_device *phydev = priv->phydev;
+	struct gfar __iomem *regs = priv->gfargrp[0].regs;
+	u32 oldadv, newadv;
+
+	if (!(phydev->supported & SUPPORTED_Pause) ||
+	    (!(phydev->supported & SUPPORTED_Asym_Pause) &&
+	     (epause->rx_pause != epause->tx_pause)))
+		return -EINVAL;
+
+	priv->rx_pause_en = priv->tx_pause_en = 0;
+	if (epause->rx_pause) {
+		priv->rx_pause_en = 1;
+
+		if (epause->tx_pause) {
+			priv->tx_pause_en = 1;
+			/* FLOW_CTRL_RX & TX */
+			newadv = ADVERTISED_Pause;
+		} else  /* FLOW_CTLR_RX */
+			newadv = ADVERTISED_Pause | ADVERTISED_Asym_Pause;
+	} else if (epause->tx_pause) {
+		priv->tx_pause_en = 1;
+		/* FLOW_CTLR_TX */
+		newadv = ADVERTISED_Asym_Pause;
+	} else
+		newadv = 0;
+
+	if (epause->autoneg)
+		priv->pause_aneg_en = 1;
+	else
+		priv->pause_aneg_en = 0;
+
+	oldadv = phydev->advertising &
+		(ADVERTISED_Pause | ADVERTISED_Asym_Pause);
+	if (oldadv != newadv) {
+		phydev->advertising &=
+			~(ADVERTISED_Pause | ADVERTISED_Asym_Pause);
+		phydev->advertising |= newadv;
+		if (phydev->autoneg)
+			/* inform link partner of our
+			 * new flow ctrl settings
+			 */
+			return phy_start_aneg(phydev);
+
+		if (!epause->autoneg) {
+			u32 tempval;
+			tempval = gfar_read(&regs->maccfg1);
+			tempval &= ~(MACCFG1_TX_FLOW | MACCFG1_RX_FLOW);
+			if (priv->tx_pause_en)
+				tempval |= MACCFG1_TX_FLOW;
+			if (priv->rx_pause_en)
+				tempval |= MACCFG1_RX_FLOW;
+			gfar_write(&regs->maccfg1, tempval);
+		}
+	}
+
+	return 0;
+}
+
 int gfar_set_features(struct net_device *dev, netdev_features_t features)
 {
 	struct gfar_private *priv = netdev_priv(dev);
@@ -1806,6 +1878,8 @@ const struct ethtool_ops gfar_ethtool_ops = {
 	.set_coalesce = gfar_scoalesce,
 	.get_ringparam = gfar_gringparam,
 	.set_ringparam = gfar_sringparam,
+	.get_pauseparam = gfar_gpauseparam,
+	.set_pauseparam = gfar_spauseparam,
 	.get_strings = gfar_gstrings,
 	.get_sset_count = gfar_sset_count,
 	.get_ethtool_stats = gfar_fill_stats,
-- 
1.7.11.7

^ permalink raw reply related
* Re: [PATCH net-next] ipv6: make unsolicited report intervals configurable for mld
From: William Manley @ 2013-08-12 10:16 UTC (permalink / raw)
  To: netdev, bcrl, yoshfuji
In-Reply-To: <20130812014859.GA13886@order.stressinduktion.org>

On 12/08/13 02:48, Hannes Frederic Sowa wrote:
> Commit cab70040dfd95ee32144f02fade64f0cb94f31a0 ("net: igmp:
> Reduce Unsolicited report interval to 1s when using IGMPv3") and
> 2690048c01f32bf45d1c1e1ab3079bc10ad2aea7 ("net: igmp: Allow user-space
> configuration of igmp unsolicited report interval") by William Manley made
> igmp unsolicited report intervals configurable per interface and corrected
> the interval of unsolicited igmpv3 report messages resendings to 1s.
>
> Same needs to be done for IPv6:
>
> MLDv1 (RFC2710 7.10.): 10 seconds
> MLDv2 (RFC3810 9.11.): 1 second
>
> Both intervals are configurable via new procfs knobs
> mldv1_unsolicited_report_interval and mldv2_unsolicited_report_interval.
>
> Cc: William Manley<william.manley@youview.com>
> Cc: Benjamin LaHaise<bcrl@kvack.org>
> Cc: YOSHIFUJI Hideaki<yoshfuji@linux-ipv6.org>
> Signed-off-by: Hannes Frederic Sowa<hannes@stressinduktion.org>

Thanks for this.  I'd meant to save you the bother.

> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 7fd8572..158c5e1 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -177,6 +177,8 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
>   	.accept_redirects	= 1,
>   	.autoconf		= 1,
>   	.force_mld_version	= 0,
> +	.mldv1_unsolicited_report_interval = 10*HZ,

I think you want spaces around that * operator.

> +	.mldv2_unsolicited_report_interval = HZ,
>   	.dad_transmits		= 1,
>   	.rtr_solicits		= MAX_RTR_SOLICITATIONS,
>   	.rtr_solicit_interval	= RTR_SOLICITATION_INTERVAL,
> @@ -211,6 +213,9 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
>   	.accept_ra		= 1,
>   	.accept_redirects	= 1,
>   	.autoconf		= 1,
> +	.force_mld_version	= 0,

Is this a tidyup or does it make a functional difference to this patch? 
  I suspect the former but I thought I'd check for my own understanding.

> +	.mldv1_unsolicited_report_interval = 10*HZ,

Spaces here as well

Thanks

Will

^ permalink raw reply
* Re: [PATCH] stmmac: fix init_dma_desc_rings() to handle errors
From: Bartlomiej Zolnierkiewicz @ 2013-08-12  9:36 UTC (permalink / raw)
  To: Denis Kirjanov; +Cc: Giuseppe Cavallaro, netdev
In-Reply-To: <CAOJe8K0JasYtXZ7JaMGEYyzp8t=Gwj=p7EZT7=EwLVeERQLZGw@mail.gmail.com>

On Friday, August 09, 2013 11:51:19 PM Denis Kirjanov wrote:
> On 8/9/13, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> wrote:
> > In stmmac_init_rx_buffers():
> > * add missing handling of dma_map_single() error
> > * remove superfluous unlikely() optimization while at it
> >
> > Add stmmac_free_rx_buffers() helper and use it in dma_free_rx_skbufs().
> >
> > In init_dma_desc_rings():
> > * add missing handling of kmalloc_array() errors
> > * fix handling of dma_alloc_coherent() and stmmac_init_rx_buffers() errors
> > * make function return an error value on error and 0 on success
> >
> > In stmmac_open():
> > * add handling of init_dma_desc_rings() return value
> >
> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> > ---
> >  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |  111
> > ++++++++++++++++++----
> >  1 file changed, 92 insertions(+), 19 deletions(-)
> >
> > Index: b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > ===================================================================
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c	2013-08-08
> > 14:36:44.000000000 +0200
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c	2013-08-08
> > 15:31:27.015438117 +0200
> > @@ -939,15 +939,20 @@ static int stmmac_init_rx_buffers(struct
> >
> >  	skb = __netdev_alloc_skb(priv->dev, priv->dma_buf_sz + NET_IP_ALIGN,
> >  				 GFP_KERNEL);
> > -	if (unlikely(skb == NULL)) {
> > +	if (!skb) {
> >  		pr_err("%s: Rx init fails; skb is NULL\n", __func__);
> > -		return 1;
> > +		return -ENOMEM;
> >  	}
> >  	skb_reserve(skb, NET_IP_ALIGN);
> >  	priv->rx_skbuff[i] = skb;
> >  	priv->rx_skbuff_dma[i] = dma_map_single(priv->device, skb->data,
> >  						priv->dma_buf_sz,
> >  						DMA_FROM_DEVICE);
> > +	if (dma_mapping_error(priv->device, priv->rx_skbuff_dma[i])) {
> > +		pr_err("%s: DMA mapping error\n", __func__);
> > +		dev_kfree_skb_any(skb);
> > +		return -EINVAL;
> > +	}
> 
> If dma fail here then you can crash in stmmac_free_rx_buffers()
> while touching priv->rx_skbuff[i]

Are you sure?

stmmac_free_rx_buffers() is not called for the current "i" but only
for the (fully initialized) past ones (please note "--i" in while loop
under err_init_rx_buffers label).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> >  	p->des2 = priv->rx_skbuff_dma[i];
> >
> > @@ -958,6 +963,16 @@ static int stmmac_init_rx_buffers(struct
> >  	return 0;
> >  }
> >
> > +static void stmmac_free_rx_buffers(struct stmmac_priv *priv, int i)
> > +{
> > +	if (priv->rx_skbuff[i]) {
> > +		dma_unmap_single(priv->device, priv->rx_skbuff_dma[i],
> > +				 priv->dma_buf_sz, DMA_FROM_DEVICE);
> > +		dev_kfree_skb_any(priv->rx_skbuff[i]);
> > +	}
> > +	priv->rx_skbuff[i] = NULL;
> > +}
> > +
> >  /**
> >   * init_dma_desc_rings - init the RX/TX descriptor rings
> >   * @dev: net device structure
> > @@ -965,13 +980,14 @@ static int stmmac_init_rx_buffers(struct
> >   * and allocates the socket buffers. It suppors the chained and ring
> >   * modes.
> >   */
> > -static void init_dma_desc_rings(struct net_device *dev)
> > +static int init_dma_desc_rings(struct net_device *dev)
> >  {
> >  	int i;
> >  	struct stmmac_priv *priv = netdev_priv(dev);
> >  	unsigned int txsize = priv->dma_tx_size;
> >  	unsigned int rxsize = priv->dma_rx_size;
> >  	unsigned int bfsize = 0;
> > +	int ret = -ENOMEM;
> >
> >  	/* Set the max buffer size according to the DESC mode
> >  	 * and the MTU. Note that RING mode allows 16KiB bsize.
> > @@ -992,34 +1008,60 @@ static void init_dma_desc_rings(struct n
> >  							  dma_extended_desc),
> >  						   &priv->dma_rx_phy,
> >  						   GFP_KERNEL);
> > +		if (!priv->dma_erx)
> > +			goto err_dma;
> > +
> >  		priv->dma_etx = dma_alloc_coherent(priv->device, txsize *
> >  						   sizeof(struct
> >  							  dma_extended_desc),
> >  						   &priv->dma_tx_phy,
> >  						   GFP_KERNEL);
> > -		if ((!priv->dma_erx) || (!priv->dma_etx))
> > -			return;
> > +		if (!priv->dma_etx) {
> > +			dma_free_coherent(priv->device, priv->dma_rx_size *
> > +					sizeof(struct dma_extended_desc),
> > +					priv->dma_erx, priv->dma_rx_phy);
> > +			goto err_dma;
> > +		}
> >  	} else {
> >  		priv->dma_rx = dma_alloc_coherent(priv->device, rxsize *
> >  						  sizeof(struct dma_desc),
> >  						  &priv->dma_rx_phy,
> >  						  GFP_KERNEL);
> > +		if (!priv->dma_rx)
> > +			goto err_dma;
> > +
> >  		priv->dma_tx = dma_alloc_coherent(priv->device, txsize *
> >  						  sizeof(struct dma_desc),
> >  						  &priv->dma_tx_phy,
> >  						  GFP_KERNEL);
> > -		if ((!priv->dma_rx) || (!priv->dma_tx))
> > -			return;
> > +		if (!priv->dma_tx) {
> > +			dma_free_coherent(priv->device, priv->dma_rx_size *
> > +					sizeof(struct dma_desc),
> > +					priv->dma_rx, priv->dma_rx_phy);
> > +			goto err_dma;
> > +		}
> >  	}
> >
> >  	priv->rx_skbuff_dma = kmalloc_array(rxsize, sizeof(dma_addr_t),
> >  					    GFP_KERNEL);
> > +	if (!priv->rx_skbuff_dma)
> > +		goto err_rx_skbuff_dma;
> > +
> >  	priv->rx_skbuff = kmalloc_array(rxsize, sizeof(struct sk_buff *),
> >  					GFP_KERNEL);
> > +	if (!priv->rx_skbuff)
> > +		goto err_rx_skbuff;
> > +
> >  	priv->tx_skbuff_dma = kmalloc_array(txsize, sizeof(dma_addr_t),
> >  					    GFP_KERNEL);
> > +	if (!priv->tx_skbuff_dma)
> > +		goto err_tx_skbuff_dma;
> > +
> >  	priv->tx_skbuff = kmalloc_array(txsize, sizeof(struct sk_buff *),
> >  					GFP_KERNEL);
> > +	if (!priv->tx_skbuff)
> > +		goto err_tx_skbuff;
> > +
> >  	if (netif_msg_probe(priv)) {
> >  		pr_debug("(%s) dma_rx_phy=0x%08x dma_tx_phy=0x%08x\n", __func__,
> >  			 (u32) priv->dma_rx_phy, (u32) priv->dma_tx_phy);
> > @@ -1034,8 +1076,9 @@ static void init_dma_desc_rings(struct n
> >  		else
> >  			p = priv->dma_rx + i;
> >
> > -		if (stmmac_init_rx_buffers(priv, p, i))
> > -			break;
> > +		ret = stmmac_init_rx_buffers(priv, p, i);
> > +		if (ret)
> > +			goto err_init_rx_buffers;
> >
> >  		if (netif_msg_probe(priv))
> >  			pr_debug("[%p]\t[%p]\t[%x]\n", priv->rx_skbuff[i],
> > @@ -1081,20 +1124,44 @@ static void init_dma_desc_rings(struct n
> >
> >  	if (netif_msg_hw(priv))
> >  		stmmac_display_rings(priv);
> > +
> > +	return 0;
> > +err_init_rx_buffers:
> > +	while (--i >= 0)
> > +		stmmac_free_rx_buffers(priv, i);
> > +	kfree(priv->tx_skbuff);
> > +err_tx_skbuff:
> > +	kfree(priv->tx_skbuff_dma);
> > +err_tx_skbuff_dma:
> > +	kfree(priv->rx_skbuff);
> > +err_rx_skbuff:
> > +	kfree(priv->rx_skbuff_dma);
> > +err_rx_skbuff_dma:
> > +	if (priv->extend_desc) {
> > +		dma_free_coherent(priv->device, priv->dma_tx_size *
> > +				  sizeof(struct dma_extended_desc),
> > +				  priv->dma_etx, priv->dma_tx_phy);
> > +		dma_free_coherent(priv->device, priv->dma_rx_size *
> > +				  sizeof(struct dma_extended_desc),
> > +				  priv->dma_erx, priv->dma_rx_phy);
> > +	} else {
> > +		dma_free_coherent(priv->device,
> > +				priv->dma_tx_size * sizeof(struct dma_desc),
> > +				priv->dma_tx, priv->dma_tx_phy);
> > +		dma_free_coherent(priv->device,
> > +				priv->dma_rx_size * sizeof(struct dma_desc),
> > +				priv->dma_rx, priv->dma_rx_phy);
> > +	}
> > +err_dma:
> > +	return ret;
> >  }
> >
> >  static void dma_free_rx_skbufs(struct stmmac_priv *priv)
> >  {
> >  	int i;
> >
> > -	for (i = 0; i < priv->dma_rx_size; i++) {
> > -		if (priv->rx_skbuff[i]) {
> > -			dma_unmap_single(priv->device, priv->rx_skbuff_dma[i],
> > -					 priv->dma_buf_sz, DMA_FROM_DEVICE);
> > -			dev_kfree_skb_any(priv->rx_skbuff[i]);
> > -		}
> > -		priv->rx_skbuff[i] = NULL;
> > -	}
> > +	for (i = 0; i < priv->dma_rx_size; i++)
> > +		stmmac_free_rx_buffers(priv, i);
> >  }
> >
> >  static void dma_free_tx_skbufs(struct stmmac_priv *priv)
> > @@ -1560,12 +1627,17 @@ static int stmmac_open(struct net_device
> >  	priv->dma_tx_size = STMMAC_ALIGN(dma_txsize);
> >  	priv->dma_rx_size = STMMAC_ALIGN(dma_rxsize);
> >  	priv->dma_buf_sz = STMMAC_ALIGN(buf_sz);
> > -	init_dma_desc_rings(dev);
> > +
> > +	ret = init_dma_desc_rings(dev);
> > +	if (ret < 0) {
> > +		pr_err("%s: DMA descriptors initialization failed\n", __func__);
> > +		goto dma_desc_error;
> > +	}
> >
> >  	/* DMA initialization and SW reset */
> >  	ret = stmmac_init_dma_engine(priv);
> >  	if (ret < 0) {
> > -		pr_err("%s: DMA initialization failed\n", __func__);
> > +		pr_err("%s: DMA engine initialization failed\n", __func__);
> >  		goto init_error;
> >  	}
> >
> > @@ -1672,6 +1744,7 @@ wolirq_error:
> >
> >  init_error:
> >  	free_dma_desc_resources(priv);
> > +dma_desc_error:
> >  	if (priv->phydev)
> >  		phy_disconnect(priv->phydev);
> >  phy_error:
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply
* Re: [PATCH v2 3.11] genetlink: fix family dump race
From: Johannes Berg @ 2013-08-12  8:54 UTC (permalink / raw)
  To: David Miller
  Cc: linux-wireless, netdev, tgraf, andrei.otcheretianski, ilan.peer,
	stable, Pravin B Shelar
In-Reply-To: <20130811.212942.413012801159758438.davem@davemloft.net>

On Sun, 2013-08-11 at 21:29 -0700, David Miller wrote:

> > BUG: unable to handle kernel paging request at f8467360
> > IP: [<c14c56bb>] ctrl_dumpfamily+0x6b/0xe0
> > EIP: 0060:[<c14c56bb>] EFLAGS: 00210297 CPU: 2
> > EIP is at ctrl_dumpfamily+0x6b/0xe0
> > EAX: f8467378 EBX: f8467340 ECX: 00000000 EDX: ec1610c4
> > ESI: 00000001 EDI: c2077cc0 EBP: c46c3c00 ESP: c46c3bd4
> >  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> > CR0: 80050033 CR2: f8467360 CR3: 26e54000 CR4: 001407d0
> > DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> > DR6: ffff0ff0 DR7: 00000400
> > Process wpa_supplicant (pid: 20081, ti=c46c2000 task=c44640b0 task.ti=c46c2000)
> > Call Trace:
> >  [<c14c20bc>] netlink_dump+0x5c/0x200
> >  [<c14c3450>] __netlink_dump_start+0x140/0x160
> >  [<c14c5172>] genl_rcv_msg+0x102/0x270
> >  [<c14c4b5e>] netlink_rcv_skb+0x8e/0xb0
> >  [<c14c505c>] genl_rcv+0x1c/0x30
> >  [<c14c456b>] netlink_unicast+0x17b/0x1c0
> >  [<c14c47d4>] netlink_sendmsg+0x224/0x370
> >  [<c1485adf>] sock_sendmsg+0xff/0x120
> 
> I completely agree with your analysis that we need locking here, but
> the crash OOPS backtrace doesn't make any sense to me.
> 
> The bug should trigger when we enter the dump continuation path, which
> would look like:
> 
>         ctrl_dumpfamily()
>         netlink_dump()
>         netlink_recvmsg()
>         ...
> 
> Since this is the only way we get into ctrl_dumpfamily() without
> holding genl_lock().
> 
> But in your trace we're going through genl_rcv() which means this is
> the first call of the dump, and genl_rcv() takes the necessary locks.

Huh, yes, I only looked at the crash info as far as I needed to see that
it was crashing at accessing "rt->netnsok" with a not totally invalid
pointer "rt" (it's in EBX) and then went from the code ...

Ok, I see what's going on here. The bug was reported to me against an
old kernel (3.4.47!) and that actually did an unlock in genl_rcv_msg()
before calling netlink_dump_start():

        if (nlh->nlmsg_flags & NLM_F_DUMP) {
                if (ops->dumpit == NULL)
                        return -EOPNOTSUPP;

                genl_unlock();
                {
                        struct netlink_dump_control c = {
                                .dump = ops->dumpit,
                                .done = ops->done,
                        };
                        err = netlink_dump_start(net->genl_sock, skb,
nlh, &c);
                }
                genl_lock();
                return err;
        }

That was changed in Pravin's commit
def3117493eafd9dfa1f809d861e0031b2cc8a07
"genl: Allow concurrent genl callbacks." very recently - I'm not sure if
that was intentional, it's not described in the commit log.


I think for the current code the fix would still be correct, I can
change the commit message if you like. For backporting, we'll have to
check which tree has Pravin's change and which doesn't and change this
accordingly, I suppose.

johannes

^ permalink raw reply
* [PATCH net-next] ipip: Add room for user-specified custom header
From: Kristian Evensen @ 2013-08-12  8:39 UTC (permalink / raw)
  To: netdev; +Cc: Kristian Evensen

This patch adds support for specifying the size of a custom header to be
inserted between the two IP headers. The actual content will be inserted later,
for example by a module that is attached to a hook.

A use-case for the feature provided by this patch is to ease the implementation
of custom tunneling protocols. Instead of implementing them directly in the
kernel and having to look out for changes in the kernel behavior/APIs, a
tunneling protocol can be implemented as an independent module.

To avoid breaking user space (by updating ip_tunnel_params), it is only possible
to specify the custom header length when an IPIP-tunnel is created using
netlink-messages.

Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
---
 include/uapi/linux/if_tunnel.h |  1 +
 net/ipv4/ipip.c                | 20 ++++++++++++++++----
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/if_tunnel.h b/include/uapi/linux/if_tunnel.h
index aee73d0..a8ef1d3 100644
--- a/include/uapi/linux/if_tunnel.h
+++ b/include/uapi/linux/if_tunnel.h
@@ -44,6 +44,7 @@ enum {
 	IFLA_IPTUN_REMOTE,
 	IFLA_IPTUN_TTL,
 	IFLA_IPTUN_TOS,
+	IFLA_IPTUN_HLEN,
 	IFLA_IPTUN_ENCAP_LIMIT,
 	IFLA_IPTUN_FLOWINFO,
 	IFLA_IPTUN_FLAGS,
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index 51fc2a1..1e5bd85 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -190,13 +190,14 @@ static int ipip_rcv(struct sk_buff *skb)
 	struct ip_tunnel *tunnel;
 	const struct iphdr *iph;
 
-	if (iptunnel_pull_header(skb, 0, tpi.proto))
-		goto drop;
-
 	iph = ip_hdr(skb);
 	tunnel = ip_tunnel_lookup(itn, skb->dev->ifindex, TUNNEL_NO_KEY,
 			iph->saddr, iph->daddr, 0);
+
 	if (tunnel) {
+		if (iptunnel_pull_header(skb, tunnel->hlen, tpi.proto))
+			goto drop;
+
 		if (!xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb))
 			goto drop;
 		return ip_tunnel_rcv(tunnel, skb, &tpi, log_ecn_error);
@@ -226,6 +227,9 @@ static netdev_tx_t ipip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
 		skb->encapsulation = 1;
 	}
 
+	if (tunnel->hlen > 0)
+		skb_push(skb, tunnel->hlen);
+
 	ip_tunnel_xmit(skb, dev, tiph, tiph->protocol);
 	return NETDEV_TX_OK;
 
@@ -302,7 +306,6 @@ static int ipip_tunnel_init(struct net_device *dev)
 	memcpy(dev->dev_addr, &tunnel->parms.iph.saddr, 4);
 	memcpy(dev->broadcast, &tunnel->parms.iph.daddr, 4);
 
-	tunnel->hlen = 0;
 	tunnel->parms.iph.protocol = IPPROTO_IPIP;
 	return ip_tunnel_init(dev);
 }
@@ -345,8 +348,13 @@ static int ipip_newlink(struct net *src_net, struct net_device *dev,
 			struct nlattr *tb[], struct nlattr *data[])
 {
 	struct ip_tunnel_parm p;
+	struct ip_tunnel *tunnel = netdev_priv(dev);
 
 	ipip_netlink_parms(data, &p);
+
+	if (data[IFLA_IPTUN_HLEN])
+		tunnel->hlen = nla_get_u32(data[IFLA_IPTUN_HLEN]);
+
 	return ip_tunnel_newlink(dev, tb, &p);
 }
 
@@ -373,6 +381,8 @@ static size_t ipip_get_size(const struct net_device *dev)
 		nla_total_size(4) +
 		/* IFLA_IPTUN_REMOTE */
 		nla_total_size(4) +
+		/* IFLA_IPTUN_HLEN */
+		nla_total_size(4) +
 		/* IFLA_IPTUN_TTL */
 		nla_total_size(1) +
 		/* IFLA_IPTUN_TOS */
@@ -390,6 +400,7 @@ static int ipip_fill_info(struct sk_buff *skb, const struct net_device *dev)
 	if (nla_put_u32(skb, IFLA_IPTUN_LINK, parm->link) ||
 	    nla_put_be32(skb, IFLA_IPTUN_LOCAL, parm->iph.saddr) ||
 	    nla_put_be32(skb, IFLA_IPTUN_REMOTE, parm->iph.daddr) ||
+	    nla_put_u32(skb, IFLA_IPTUN_HLEN, tunnel->hlen) ||
 	    nla_put_u8(skb, IFLA_IPTUN_TTL, parm->iph.ttl) ||
 	    nla_put_u8(skb, IFLA_IPTUN_TOS, parm->iph.tos) ||
 	    nla_put_u8(skb, IFLA_IPTUN_PMTUDISC,
@@ -405,6 +416,7 @@ static const struct nla_policy ipip_policy[IFLA_IPTUN_MAX + 1] = {
 	[IFLA_IPTUN_LINK]		= { .type = NLA_U32 },
 	[IFLA_IPTUN_LOCAL]		= { .type = NLA_U32 },
 	[IFLA_IPTUN_REMOTE]		= { .type = NLA_U32 },
+	[IFLA_IPTUN_HLEN]		= { .type = NLA_U32 },
 	[IFLA_IPTUN_TTL]		= { .type = NLA_U8 },
 	[IFLA_IPTUN_TOS]		= { .type = NLA_U8 },
 	[IFLA_IPTUN_PMTUDISC]		= { .type = NLA_U8 },
-- 
1.8.1.2

^ permalink raw reply related
* Re: [RFC PATCH 1/3] of: provide a binding for the 'fixed-link' property
From: Sascha Hauer @ 2013-08-12  8:37 UTC (permalink / raw)
  To: Thomas Petazzoni
  Cc: Grant Likely, Rob Herring, David S. Miller, Florian Fainelli,
	Lior Amsalem, netdev, devicetree-discuss, linux-arm-kernel
In-Reply-To: <20130812101649.743c08aa@skate>

On Mon, Aug 12, 2013 at 10:16:49AM +0200, Thomas Petazzoni wrote:
> Dear Sascha Hauer,
> 
> On Mon, 12 Aug 2013 08:38:06 +0200, Sascha Hauer wrote:
> 
> > > This patch adds:
> > > 
> > >  * A documentation for the Device Tree property "fixed-link".
> > > 
> > >  * A of_phy_register_fixed_link() OF helper, which provided an OF node
> > >    that contains a "fixed-link" property, registers the corresponding
> > >    fixed PHY.
> > > 
> > >  * Removes the warning on the of_phy_connect_fixed_link() that says
> > >    new drivers should not use it, since Grant Likely indicated that
> > >    this "fixed-link" property is indeed the way to go.
> > > 
> > 
> > Any progress with this series?
> 
> I am not sure there really was a consensus yet on what the DT binding
> looks like. As soon as there is a consensus, I'm definitely willing to
> make progress on this series.
> 
> > We have more and more boards here with exactly the same problem as
> > Thomas has. For reasons stated below I don't like this binding, but
> > still it would solve my problem.
> 
> Ok.
> 
> > > +Example:
> > > +
> > > +ethernet@0 {
> > > +	...
> > > +	fixed-link = <1 1 1000 0 0>;
> > > +	...
> > > +};
> > 
> > I must say I don't like this binding at all for two reasons.
> 
> As I explained, this binding was chosen for this RFC for two reasons:
> 
>  * It's the binding used on PowerPC platforms to represent fixed links.
>  * It allows to encode all the informations into a single property,
>    which avoids the need for a separate DT node for a "fake PHY", which
>    isn't a representation of the hardware.

The fake phy is avoided by making the other side of the link what it
really is: An ethernet switch. I'm currently not aware of a situation
where a fixed link is needed and the other side is not a switch. And I
can't think of a situation in which the other side of the other side of
the fixed link really is pure 'virtual', I mean there always must be
something connected, right?

> 
> > First the positional arguments make it impossible to add optional
> > arguments to the link.
> > 
> > Second the other side of the link is most likely a switch. Once this
> > switch has its own node in the devicetree it seems like having a phandle
> > to the switch here would be better.
> 
> So, in other words, what you're suggesting is something like:
> 
> 	ethernet@0 {
> 		reg = <...>;
> 		interrupt = <...>;
> 		phy = <&phy0>;
> 		phy0: phy@0 {
> 			fixed-link;
> 			speed = <1000>;
> 			full-duplex;
> 			...
> 		};
> 	};

Yes, this looks good. ePAPR suggests naming the phy property
"phy-handle" instead of just "phy", but that's just details. In case the
phy really is a switch the phandle could just point to a i2c device instead
of the ethernet node.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply
* [PATCH net-next] net/mlx4_en: Advertise HIGH DMA support only if dma mask is 64 bit
From: Amir Vadai @ 2013-08-12  8:30 UTC (permalink / raw)
  To: David S. Miller; +Cc: netdev, Amir Vadai, Or Gerlitz, Alexander Guller

Need to check that the pci device DMA mask was set to 64 bit support
(done by mlx4_core) before advertising HIGH DMA support in higher drivers.
Otherwise, may run into an issue that skb/frag/data is in high memory
and can't dma map it, thus packets are dropped.


Signed-off-by: Alexander Guller <alexg@mellanox.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
 drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index fa37b7a..9568b77 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -2317,9 +2317,13 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
 	dev->vlan_features = dev->hw_features;
 
 	dev->hw_features |= NETIF_F_RXCSUM | NETIF_F_RXHASH;
-	dev->features = dev->hw_features | NETIF_F_HIGHDMA |
+	dev->features = dev->hw_features |
 			NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX |
 			NETIF_F_HW_VLAN_CTAG_FILTER;
+
+	if (mdev->dev->pdev->dma_mask == DMA_BIT_MASK(64))
+		dev->features |= NETIF_F_HIGHDMA;
+
 	dev->hw_features |= NETIF_F_LOOPBACK;
 
 	if (mdev->dev->caps.steering_mode ==
-- 
1.8.3.4

^ permalink raw reply related
* Re: [RFC PATCH 1/3] of: provide a binding for the 'fixed-link' property
From: Thomas Petazzoni @ 2013-08-12  8:16 UTC (permalink / raw)
  To: Sascha Hauer
  Cc: Grant Likely, Rob Herring, David S. Miller, Florian Fainelli,
	Lior Amsalem, netdev, devicetree-discuss, linux-arm-kernel
In-Reply-To: <20130812063806.GD2324@pengutronix.de>

Dear Sascha Hauer,

On Mon, 12 Aug 2013 08:38:06 +0200, Sascha Hauer wrote:

> > This patch adds:
> > 
> >  * A documentation for the Device Tree property "fixed-link".
> > 
> >  * A of_phy_register_fixed_link() OF helper, which provided an OF node
> >    that contains a "fixed-link" property, registers the corresponding
> >    fixed PHY.
> > 
> >  * Removes the warning on the of_phy_connect_fixed_link() that says
> >    new drivers should not use it, since Grant Likely indicated that
> >    this "fixed-link" property is indeed the way to go.
> > 
> 
> Any progress with this series?

I am not sure there really was a consensus yet on what the DT binding
looks like. As soon as there is a consensus, I'm definitely willing to
make progress on this series.

> We have more and more boards here with exactly the same problem as
> Thomas has. For reasons stated below I don't like this binding, but
> still it would solve my problem.

Ok.

> > +Example:
> > +
> > +ethernet@0 {
> > +	...
> > +	fixed-link = <1 1 1000 0 0>;
> > +	...
> > +};
> 
> I must say I don't like this binding at all for two reasons.

As I explained, this binding was chosen for this RFC for two reasons:

 * It's the binding used on PowerPC platforms to represent fixed links.
 * It allows to encode all the informations into a single property,
   which avoids the need for a separate DT node for a "fake PHY", which
   isn't a representation of the hardware.

> First the positional arguments make it impossible to add optional
> arguments to the link.
> 
> Second the other side of the link is most likely a switch. Once this
> switch has its own node in the devicetree it seems like having a phandle
> to the switch here would be better.

So, in other words, what you're suggesting is something like:

	ethernet@0 {
		reg = <...>;
		interrupt = <...>;
		phy = <&phy0>;
		phy0: phy@0 {
			fixed-link;
			speed = <1000>;
			full-duplex;
			...
		};
	};

Or something else?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply
* Re: Where are OVS VXLAN patches?
From: David Miller @ 2013-08-12  7:52 UTC (permalink / raw)
  To: amwang; +Cc: netdev, pshelar, jesse, stephen
In-Reply-To: <1376291275.17589.18.camel@cr0>

From: Cong Wang <amwang@redhat.com>
Date: Mon, 12 Aug 2013 15:07:55 +0800

> Hello, David
> 
> I am wondering where are the patches for OVS VXLAN support from Pravin?
> v7 were posted one week ago:
> http://marc.info/?l=linux-netdev&m=137572485116601&w=2
> 
> and no one complains about them, so I think they are ready for merge?

They don't go into my tree, that's all I know.

^ permalink raw reply
* Re: [PATCH][net-next v1] gianfar: Add flow control support
From: Claudiu Manoil @ 2013-08-12  7:09 UTC (permalink / raw)
  To: Fabio Estevam; +Cc: netdev, David S. Miller, Ben Hutchings, Lutz Jaenicke
In-Reply-To: <CAOMZO5CG3L3Jhjki-V7-jc+jBqRca_TTz_3e7=DP_1Zn8apZXQ@mail.gmail.com>

Right, thanks.
___
Claudiu

On 8/9/2013 8:36 PM, Fabio Estevam wrote:
> On Fri, Aug 9, 2013 at 2:19 PM, Claudiu Manoil
> <claudiu.manoil@freescale.com> wrote:
>
>> +static int gfar_spauseparam(struct net_device *dev,
>> +                           struct ethtool_pauseparam *epause)
>> +{
>> +       struct gfar_private *priv = netdev_priv(dev);
>> +       struct phy_device *phydev = priv->phydev;
>> +       struct gfar __iomem *regs = priv->gfargrp[0].regs;
>> +       u32 oldadv, newadv;
>> +       int err = 0;
>
> You could drop this 'err' variable, no?
>
> ...
>
>> +
>> +       return err;
>
> Then just 'return 0' here.
>

^ permalink raw reply
* Re: [PATCH][net-next v1] gianfar: Add flow control support
From: Claudiu Manoil @ 2013-08-12  7:08 UTC (permalink / raw)
  To: Joe Perches; +Cc: netdev, David S. Miller, Ben Hutchings, Lutz Jaenicke
In-Reply-To: <1376075396.2087.148.camel@joe-AO722>

Will provide a static function to factor out the code
that configures the 2 flow control bits for maccfg1.
Thanks.
___
Claudiu

On 8/9/2013 10:09 PM, Joe Perches wrote:
> On Fri, 2013-08-09 at 20:19 +0300, Claudiu Manoil wrote:
>> eTSEC has Rx and Tx flow control capabilities that may be enabled
>> through MACCFG1[Rx_Flow, Tx_Flow] bits.
>
> Trivial note:
>
>> diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
> []
>> @@ -3043,6 +3050,7 @@ static void adjust_link(struct net_device *dev)
> []
>> +		u32 tempval1 = gfar_read(&regs->maccfg1);
> []
>> @@ -3091,6 +3099,32 @@ static void adjust_link(struct net_device *dev)
>>   			priv->oldspeed = phydev->speed;
>>   		}
>>
>> +		tempval1 &= ~(MACCFG1_TX_FLOW | MACCFG1_RX_FLOW);
>> +		if (phydev->duplex) {
>> +			if (!priv->pause_aneg_en) {
>> +				if (priv->tx_pause_en)
>> +					tempval1 |= MACCFG1_TX_FLOW;
>> +				if (priv->rx_pause_en)
>> +					tempval1 |= MACCFG1_RX_FLOW;
>> +			} else {
>> +				u8 flowctrl;
>> +				u16 lcl_adv = mii_advertise_flowctrl(
>> +						phydev->advertising);
>> +				u16 rmt_adv = 0;
>> +				if (phydev->pause)
>> +					rmt_adv = LPA_PAUSE_CAP;
>> +				if (phydev->asym_pause)
>> +					rmt_adv |= LPA_PAUSE_ASYM;
>> +				flowctrl = mii_resolve_flowctrl_fdx(
>> +						lcl_adv, rmt_adv);
>> +				if (flowctrl & FLOW_CTRL_TX)
>> +					tempval1 |= MACCFG1_TX_FLOW;
>> +				if (flowctrl & FLOW_CTRL_RX)
>> +					tempval1 |= MACCFG1_RX_FLOW;
>> +			}
>> +		}
>
> I think this bit would be nicer as a static function.
>
> Something like: (uncompiled/untested)
>
> static int gfar_get_cfg1(struct net_device *dev)
> {
> 	struct gfar_private *priv = netdev_priv(dev);
> 	struct gfar __iomem *regs = priv->gfargrp[0].regs;
> 	struct phy_device *phydev = priv->phydev;
> 	int val;
>
> 	val = gfar_read(&regs->maccfg1);
> 	val &= ~(MACCFG1_TX_FLOW | MACCFG1_RX_FLOW);
>
> 	if (!phydev->duplex)
> 		return val;
>
> 	if (!priv->pause_aneg_en) {
> 		if (priv->tx_pause_en)
> 			val |= MACCFG1_TX_FLOW;
> 		if (priv->rx_pause_en)
> 			val |= MACCFG1_RX_FLOW;
> 	} else {
> 		u8 flowctrl;
> 		u16 lcl_adv = mii_advertise_flowctrl(phydev->advertising);
> 		u16 rmt_adv = 0;
> 		if (phydev->pause)
> 			rmt_adv = LPA_PAUSE_CAP;
> 		if (phydev->asym_pause)
> 			rmt_adv |= LPA_PAUSE_ASYM;
> 		flowctrl = mii_resolve_flowctrl_fdx(lcl_adv, rmt_adv);
> 		if (flowctrl & FLOW_CTRL_TX)
> 			val |= MACCFG1_TX_FLOW;
> 		if (flowctrl & FLOW_CTRL_RX)
> 			val |= MACCFG1_RX_FLOW;
> 	}
>
> 	return val;
> }
>

^ permalink raw reply
* Where are OVS VXLAN patches?
From: Cong Wang @ 2013-08-12  7:07 UTC (permalink / raw)
  To: David S. Miller; +Cc: netdev, Pravin B Shelar, Jesse Gross, Stephen Hemminger

Hello, David

I am wondering where are the patches for OVS VXLAN support from Pravin?
v7 were posted one week ago:
http://marc.info/?l=linux-netdev&m=137572485116601&w=2

and no one complains about them, so I think they are ready for merge?

But they still do not appear in net-next, nor I can find them in vxlan
tree of Stephen or openvswitch tree of Jesse. What's more, I even can't
find them in netdev patchwork [1].

So, where are they? And who will take them? :)

Thanks!

1. http://patchwork.ozlabs.org/project/netdev/list/

^ permalink raw reply
* Re: [RFC PATCH 1/3] of: provide a binding for the 'fixed-link' property
From: Sascha Hauer @ 2013-08-12  6:38 UTC (permalink / raw)
  To: Thomas Petazzoni
  Cc: Grant Likely, Rob Herring, David S. Miller, Florian Fainelli,
	Lior Amsalem, netdev, devicetree-discuss, linux-arm-kernel
In-Reply-To: <1373902450-11857-2-git-send-email-thomas.petazzoni@free-electrons.com>

On Mon, Jul 15, 2013 at 05:34:08PM +0200, Thomas Petazzoni wrote:
> Some Ethernet MACs have a "fixed link", and are not connected to a
> normal MDIO-managed PHY device. For those situations, a Device Tree
> binding allows to describe a "fixed link", as a "fixed-link" property
> of the Ethernet device Device Tree node.
> 
> This patch adds:
> 
>  * A documentation for the Device Tree property "fixed-link".
> 
>  * A of_phy_register_fixed_link() OF helper, which provided an OF node
>    that contains a "fixed-link" property, registers the corresponding
>    fixed PHY.
> 
>  * Removes the warning on the of_phy_connect_fixed_link() that says
>    new drivers should not use it, since Grant Likely indicated that
>    this "fixed-link" property is indeed the way to go.
> 

Any progress with this series?

We have more and more boards here with exactly the same problem as
Thomas has. For reasons stated below I don't like this binding, but
still it would solve my problem.


> +Fixed link Device Tree binding
> +------------------------------
> +
> +Some Ethernet MACs have a "fixed link", and are not connected to a
> +normal MDIO-managed PHY device. For those situations, a Device Tree
> +binding allows to describe a "fixed link".
> +
> +Such a fixed link situation is described within an Ethernet device
> +Device Tree node using a 'fixed-link' property, composed of 5
> +elements:
> +
> + 1. A fake PHY ID, which must be unique accross all fixed-link PHYs in
> +    the system.
> + 2. The duplex (1 for full-duplex, 0 for half-duplex)
> + 3. The speed (10, 100, 1000)
> + 4. The pause setting (1 for enabled, 0 for disabled)
> + 5. The asym pause setting (1 for enabled, 0 for disabled)
> +
> +Example:
> +
> +ethernet@0 {
> +	...
> +	fixed-link = <1 1 1000 0 0>;
> +	...
> +};

I must say I don't like this binding at all for two reasons.

First the positional arguments make it impossible to add optional
arguments to the link.

Second the other side of the link is most likely a switch. Once this
switch has its own node in the devicetree it seems like having a phandle
to the switch here would be better.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply
* ATN network stack  implementation
From: Prabhakar_Pujeri @ 2013-08-12  6:09 UTC (permalink / raw)
  To: linux-kernel, netdev; +Cc: Prabhakar_Pujeri

Hi All,

Required some input for ATN network stack  implementation (IDRP, ES-IS, IS-IS, CLNP). I have following questions
1.	Is there any implementation already exist in open source  like IDRP or ES-IS etc 
2.	Is it feasible to implement in Linux kernel stack. I found some implementation "Oki Electric Industry Ground-Ground ATN Router for Linux" which is not open source
3.	Is there any advice or input or suggestion for me to start with 


Thanks
Prabhakar   

^ permalink raw reply
* Re: [PATCH RFC] xfrm{4,6}: only report errors back to local sockets if we don't cross address family
From: Steffen Klassert @ 2013-08-12  5:54 UTC (permalink / raw)
  To: Eric Dumazet, netdev, vi0oss
In-Reply-To: <20130810161629.GR14001@order.stressinduktion.org>

On Sat, Aug 10, 2013 at 06:16:29PM +0200, Hannes Frederic Sowa wrote:
> 
> Seems skb->encapsulated helps, but I still have to wire it up for the ipv6
> tunnels.
> 
> I just prototyped this patch, but I fear I now introduced a dependency
> from core xfrm to ipv6, which I would like to have prevented (this would
> even happen if I put xfrm_local_error in a header file). Is this actually
> a problem? I fear so. The other way would be to put the local_error
> handler as function pointers somewhere reachable from struct sock.
> 

Maybe we should put a local_error() function pointer to struct
xfrm_state_afinfo and call it via inner_mode->afinfo->local_error().

This should always call the right local_error function and we
would not need to touch generic networking code to fix it.

^ permalink raw reply
* [PATCH net] be2net: Clear any capability flags that driver is not interested in.
From: sarveshwar.bandi @ 2013-08-12  5:51 UTC (permalink / raw)
  To: davem; +Cc: netdev, Sarveshwar Bandi

From: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>

It is possible for some versions of firmware to advertise capabilities that driver
is not ready to handle. This may lead to controller stall. Clear all flags that driver
is not interested in.

Signed-off-by: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
---
 drivers/net/ethernet/emulex/benet/be_cmds.h |    6 ++++++
 drivers/net/ethernet/emulex/benet/be_main.c |    2 ++
 2 files changed, 8 insertions(+)

diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.h b/drivers/net/ethernet/emulex/benet/be_cmds.h
index 5228d88..8fba7dd 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.h
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.h
@@ -563,6 +563,12 @@ enum be_if_flags {
 	BE_IF_FLAGS_MULTICAST = 0x1000
 };
 
+#define BE_IF_CAP_FLAGS (BE_IF_FLAGS_RSS | BE_IF_FLAGS_PROMISCUOUS |\
+			 BE_IF_FLAGS_BROADCAST | BE_IF_FLAGS_VLAN_PROMISCUOUS |\
+			 BE_IF_FLAGS_VLAN | BE_IF_FLAGS_MCAST_PROMISCUOUS |\
+			 BE_IF_FLAGS_PASS_L3L4_ERRORS | BE_IF_FLAGS_MULTICAST |\
+			 BE_IF_FLAGS_UNTAGGED)
+
 /* An RX interface is an object with one or more MAC addresses and
  * filtering capabilities. */
 struct be_cmd_req_if_create {
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 181edb5..8d7ee2e 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -3044,6 +3044,8 @@ static void be_get_resources(struct be_adapter *adapter)
 		if (adapter->max_event_queues < adapter->max_rss_queues)
 			adapter->max_rss_queues = adapter->max_event_queues;
 
+		/* Clear flags that driver is not interested in */
+		adapter->if_cap_flags &=  BE_IF_CAP_FLAGS;
 	} else {
 		if (be_physfn(adapter))
 			adapter->max_pmac_cnt = BE_UC_PMAC_COUNT;
-- 
1.7.9.5

^ permalink raw reply related
* [PATCHv2 net-next] xfrm: Make xfrm_state timer monotonic
From: Fan Du @ 2013-08-12  5:40 UTC (permalink / raw)
  To: Steffen Klassert; +Cc: davem, netdev
In-Reply-To: <20130806092220.GH25511@secunet.com>



On 2013年08月06日 17:22, Steffen Klassert wrote:
> On Tue, Aug 06, 2013 at 02:57:05PM +0800, Fan Du wrote:
>> xfrm_state timer should be independent of system clock change,
>> so switch to monotonic clock base.
>>
>
> I think a monotonic timer will reintroduce a bug on suspend/resume
> that was fixed by commit 9e0d57fd6
> (xfrm: SAD entries do not expire correctly after suspend-resume)
>
> Please make sure that this does not happen.

What about using CLOCK_BOOTTIME? it's monotonic, but includes suspend time as well.


 From 1dae5a22c203224ee46e2a2f95b569a04b74117b Mon Sep 17 00:00:00 2001
From: Fan Du <fan.du@windriver.com>
Date: Mon, 12 Aug 2013 13:33:45 +0800
Subject: [PATCHv2 net-next] xfrm: Make xfrm_state timer monotonic

xfrm_state timer should be independent of system clock change,
so switch to CLOCK_BOOTTIME base which is not only monotonic but
also counting suspend time.

Signed-off-by: Fan Du <fan.du@windriver.com>
---
  net/xfrm/xfrm_state.c |    2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 78f66fa..1df4436 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -499,7 +499,7 @@ struct xfrm_state *xfrm_state_alloc(struct net *net)
  		INIT_HLIST_NODE(&x->bydst);
  		INIT_HLIST_NODE(&x->bysrc);
  		INIT_HLIST_NODE(&x->byspi);
-		tasklet_hrtimer_init(&x->mtimer, xfrm_timer_handler, CLOCK_REALTIME, HRTIMER_MODE_ABS);
+		tasklet_hrtimer_init(&x->mtimer, xfrm_timer_handler, CLOCK_BOOTTIME, HRTIMER_MODE_ABS);
  		setup_timer(&x->rtimer, xfrm_replay_timer_handler,
  				(unsigned long)x);
  		x->curlft.add_time = get_seconds();
-- 
1.7.9.5




> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
浮沉随浪只记今朝笑

--fan

^ permalink raw reply related
* Re: [PATCH v2] tipc: avoid possible deadlock while enable and disable bearer
From: Ying Xue @ 2013-08-12  5:03 UTC (permalink / raw)
  To: David Miller
  Cc: dingtianhong, jon.maloy, allan.stephens, tipc-discussion, netdev,
	wangweidong1
In-Reply-To: <20130811.215939.1897644088555839854.davem@davemloft.net>

On 08/12/2013 12:59 PM, David Miller wrote:
> From: Ying Xue <ying.xue@windriver.com>
> Date: Fri, 9 Aug 2013 17:34:05 +0800
> 
>>
>>> The problem is that the tipc_link_delete() will cancel the timer disc_timeout() when
>>> the b_ptr->lock is hold, but the disc_timeout() still call b_ptr->lock to finish the
>>> work, so the dead lock occurs.
>>>
>>> We should unlock the b_ptr->lock when del the disc_timeout().
>>>
>>> Remove link_timeout() still met the same problem, the patch:
>>>
>>> http://article.gmane.org/gmane.network.tipc.general/4380
>>>
>>> fix the problem, so no need to send patch for fix link_timeout() deadlock warming.
>>>
>>> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>> Cc: Ying Xue <ying.xue@windriver.com>
>>
>> Ack-by: Ying Xue <ying.xue@windriver.com>
> 
> The proper syntax is "Acked-by: " not "Ack-by: "
> 

Thanks, I knew :)

Regards,
Ying

> Applied.
> 
> 

^ permalink raw reply
* Re: [PATCH net-next] af_unix: fix bug on large send()
From: David Miller @ 2013-08-12  5:02 UTC (permalink / raw)
  To: eric.dumazet; +Cc: hannes, rientjes, netdev
In-Reply-To: <1376283288.3338.7.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 11 Aug 2013 21:54:48 -0700

> From: Eric Dumazet <edumazet@google.com>
> 
> commit e370a723632 ("af_unix: improve STREAM behavior with fragmented
> memory") added a bug on large send() because the
> skb_copy_datagram_from_iovec() call always start from the beginning
> of iovec.
> 
> We must instead use the @sent variable to properly skip the
> already processed part.
> 
> Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied, thanks Eric.

^ permalink raw reply
* Re: [PATCH v2] tipc: avoid possible deadlock while enable and disable bearer
From: David Miller @ 2013-08-12  4:59 UTC (permalink / raw)
  To: ying.xue
  Cc: dingtianhong, jon.maloy, allan.stephens, tipc-discussion, netdev,
	wangweidong1
In-Reply-To: <5204B78D.4090509@windriver.com>

From: Ying Xue <ying.xue@windriver.com>
Date: Fri, 9 Aug 2013 17:34:05 +0800

> 
>> The problem is that the tipc_link_delete() will cancel the timer disc_timeout() when
>> the b_ptr->lock is hold, but the disc_timeout() still call b_ptr->lock to finish the
>> work, so the dead lock occurs.
>> 
>> We should unlock the b_ptr->lock when del the disc_timeout().
>> 
>> Remove link_timeout() still met the same problem, the patch:
>> 
>> http://article.gmane.org/gmane.network.tipc.general/4380
>> 
>> fix the problem, so no need to send patch for fix link_timeout() deadlock warming.
>> 
>> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> Cc: Ying Xue <ying.xue@windriver.com>
> 
> Ack-by: Ying Xue <ying.xue@windriver.com>

The proper syntax is "Acked-by: " not "Ack-by: "

Applied.

^ permalink raw reply
* [PATCH net-next] af_unix: fix bug on large send()
From: Eric Dumazet @ 2013-08-12  4:54 UTC (permalink / raw)
  To: Hannes Frederic Sowa; +Cc: David Miller, David Rientjes, netdev
In-Reply-To: <20130811143715.GA3699@order.stressinduktion.org>

From: Eric Dumazet <edumazet@google.com>

commit e370a723632 ("af_unix: improve STREAM behavior with fragmented
memory") added a bug on large send() because the
skb_copy_datagram_from_iovec() call always start from the beginning
of iovec.

We must instead use the @sent variable to properly skip the
already processed part.

Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 net/unix/af_unix.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index fee9e33..86de99a 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1669,7 +1669,8 @@ static int unix_stream_sendmsg(struct kiocb *kiocb, struct socket *sock,
 		skb_put(skb, size - data_len);
 		skb->data_len = data_len;
 		skb->len = size;
-		err = skb_copy_datagram_from_iovec(skb, 0, msg->msg_iov, 0, size);
+		err = skb_copy_datagram_from_iovec(skb, 0, msg->msg_iov,
+						   sent, size);
 		if (err) {
 			kfree_skb(skb);
 			goto out_err;

^ permalink raw reply related
* Re: [PATCH] can: pcan_usb: fix wrong memcpy() bytes length
From: David Miller @ 2013-08-12  4:52 UTC (permalink / raw)
  To: mkl; +Cc: netdev, kernel, linux-can, s.grosjean, stable
In-Reply-To: <1376041446-24058-2-git-send-email-mkl@pengutronix.de>

From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Fri,  9 Aug 2013 11:44:06 +0200

> From: Stephane Grosjean <s.grosjean@peak-system.com>
> 
> Fix possibly wrong memcpy() bytes length since some CAN records received from
> PCAN-USB could define a DLC field in range [9..15].
> In that case, the real DLC value MUST be used to move forward the record pointer
> but, only 8 bytes max. MUST be copied into the data field of the struct
> can_frame object of the skb given to the network core.
> 
> Cc: linux-stable <stable@vger.kernel.org>
> Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

Applied, thanks.

^ permalink raw reply
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox