Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] e1000: avoid null pointer dereference on invalid stat type
From: Dan Carpenter @ 2017-09-22 11:50 UTC (permalink / raw)
  To: Colin King
  Cc: Jeff Kirsher, intel-wired-lan, netdev, kernel-janitors,
	linux-kernel
In-Reply-To: <20170921220158.19341-1-colin.king@canonical.com>

On Thu, Sep 21, 2017 at 11:01:58PM +0100, Colin King wrote:
> @@ -1837,12 +1838,13 @@ static void e1000_get_ethtool_stats(struct net_device *netdev,
>  			p = (char *)adapter + stat->stat_offset;
>  			break;
>  		default:
> +			p = NULL;
>  			WARN_ONCE(1, "Invalid E1000 stat type: %u index %d\n",
>  				  stat->type, i);
>  			break;
>  		}
>  
> -		if (stat->sizeof_stat == sizeof(u64))
> +		if (p && stat->sizeof_stat == sizeof(u64))
>  			data[i] = *(u64 *)p;
>  		else
>  			data[i] = *(u32 *)p;
                                   ^^^^^^^^

The else side will still crash.

regards,
dan carpenter

^ permalink raw reply

* [PATCH iproute2 v2] man: fix documentation for range of route table ID
From: Thomas Haller @ 2017-09-22 11:28 UTC (permalink / raw)
  To: Stephen Hemminger, netdev; +Cc: Phil Sutter, Thomas Haller
In-Reply-To: <20170921182647.GB30364@orbyte.nwl.cc>

Signed-off-by: Thomas Haller <thaller@redhat.com>
---
Changes in v2:
  - "0" is not a valid table ID.

 man/man8/ip-route.8.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/man8/ip-route.8.in b/man/man8/ip-route.8.in
index 803de3b9..705ceb20 100644
--- a/man/man8/ip-route.8.in
+++ b/man/man8/ip-route.8.in
@@ -322,7 +322,7 @@ normal routing tables.
 .P
 .B Route tables:
 Linux-2.x can pack routes into several routing tables identified
-by a number in the range from 1 to 2^31 or by name from the file
+by a number in the range from 1 to 2^32-1 or by name from the file
 .B @SYSCONFDIR@/rt_tables
 By default all normal routes are inserted into the
 .B main
-- 
2.13.5

^ permalink raw reply related

* [PATCH] net: stmmac: Meet alignment requirements for DMA
From: Matt Redfearn @ 2017-09-22 11:13 UTC (permalink / raw)
  To: David S . Miller
  Cc: Matt Redfearn, netdev, Alexandre Torgue, Giuseppe Cavallaro,
	linux-kernel

According to Documentation/DMA-API.txt:
 Warnings:  Memory coherency operates at a granularity called the cache
 line width.  In order for memory mapped by this API to operate
 correctly, the mapped region must begin exactly on a cache line
 boundary and end exactly on one (to prevent two separately mapped
 regions from sharing a single cache line).  Since the cache line size
 may not be known at compile time, the API will not enforce this
 requirement.  Therefore, it is recommended that driver writers who
 don't take special care to determine the cache line size at run time
 only map virtual regions that begin and end on page boundaries (which
 are guaranteed also to be cache line boundaries).

On some systems where DMA is non-coherent and requires software
writeback / invalidate of the caches, we must ensure that
dma_(un)map_single is called with a cacheline aligned buffer and a
length of a whole number of cachelines.

To address the alignment requirements of DMA buffers, keep a separate
entry in stmmac_rx_queue for the aligned skbuff head. Use this for
dma_map_single, such that the address meets the cacheline alignment
requirents. Use skb_headroom() to convert between rx_skbuff_head, the
aligned head of the buffer, and the packet data, rx_skbuff_dma.

Tested on a Creator Ci40 with Pistachio SoC.

Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
---

 drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  1 +
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 50 ++++++++++++++++-------
 2 files changed, 36 insertions(+), 15 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index a916e13624eb..dd26a724dee7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -67,6 +67,7 @@ struct stmmac_rx_queue {
 	struct dma_desc *dma_rx ____cacheline_aligned_in_smp;
 	struct sk_buff **rx_skbuff;
 	dma_addr_t *rx_skbuff_dma;
+	dma_addr_t *rx_skbuff_head;
 	unsigned int cur_rx;
 	unsigned int dirty_rx;
 	u32 rx_zeroc_thresh;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 1763e48c84e2..da68eeff2a1c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1132,14 +1132,16 @@ static int stmmac_init_rx_buffers(struct stmmac_priv *priv, struct dma_desc *p,
 		return -ENOMEM;
 	}
 	rx_q->rx_skbuff[i] = skb;
-	rx_q->rx_skbuff_dma[i] = dma_map_single(priv->device, skb->data,
-						priv->dma_buf_sz,
-						DMA_FROM_DEVICE);
-	if (dma_mapping_error(priv->device, rx_q->rx_skbuff_dma[i])) {
+	rx_q->rx_skbuff_head[i] = dma_map_single(priv->device, skb->head,
+						 skb_headroom(skb) +
+						 priv->dma_buf_sz,
+						 DMA_FROM_DEVICE);
+	if (dma_mapping_error(priv->device, rx_q->rx_skbuff_head[i])) {
 		netdev_err(priv->dev, "%s: DMA mapping error\n", __func__);
 		dev_kfree_skb_any(skb);
 		return -EINVAL;
 	}
+	rx_q->rx_skbuff_dma[i] = rx_q->rx_skbuff_head[i] + skb_headroom(skb);
 
 	if (priv->synopsys_id >= DWMAC_CORE_4_00)
 		p->des0 = cpu_to_le32(rx_q->rx_skbuff_dma[i]);
@@ -1164,7 +1166,8 @@ static void stmmac_free_rx_buffer(struct stmmac_priv *priv, u32 queue, int i)
 	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
 
 	if (rx_q->rx_skbuff[i]) {
-		dma_unmap_single(priv->device, rx_q->rx_skbuff_dma[i],
+		dma_unmap_single(priv->device, rx_q->rx_skbuff_head[i],
+				 skb_headroom(rx_q->rx_skbuff[i]) +
 				 priv->dma_buf_sz, DMA_FROM_DEVICE);
 		dev_kfree_skb_any(rx_q->rx_skbuff[i]);
 	}
@@ -1438,6 +1441,7 @@ static void free_dma_rx_desc_resources(struct stmmac_priv *priv)
 					  rx_q->dma_erx, rx_q->dma_rx_phy);
 
 		kfree(rx_q->rx_skbuff_dma);
+		kfree(rx_q->rx_skbuff_head);
 		kfree(rx_q->rx_skbuff);
 	}
 }
@@ -1500,6 +1504,12 @@ static int alloc_dma_rx_desc_resources(struct stmmac_priv *priv)
 		if (!rx_q->rx_skbuff_dma)
 			goto err_dma;
 
+		rx_q->rx_skbuff_head = kmalloc_array(DMA_RX_SIZE,
+						     sizeof(dma_addr_t),
+						     GFP_KERNEL);
+		if (!rx_q->rx_skbuff_head)
+			goto err_dma;
+
 		rx_q->rx_skbuff = kmalloc_array(DMA_RX_SIZE,
 						sizeof(struct sk_buff *),
 						GFP_KERNEL);
@@ -3225,15 +3235,18 @@ static inline void stmmac_rx_refill(struct stmmac_priv *priv, u32 queue)
 			}
 
 			rx_q->rx_skbuff[entry] = skb;
-			rx_q->rx_skbuff_dma[entry] =
-			    dma_map_single(priv->device, skb->data, bfsize,
+			rx_q->rx_skbuff_head[entry] =
+			    dma_map_single(priv->device, skb->head,
+					   skb_headroom(skb) + bfsize,
 					   DMA_FROM_DEVICE);
 			if (dma_mapping_error(priv->device,
-					      rx_q->rx_skbuff_dma[entry])) {
+					      rx_q->rx_skbuff_head[entry])) {
 				netdev_err(priv->dev, "Rx DMA map failed\n");
 				dev_kfree_skb(skb);
 				break;
 			}
+			rx_q->rx_skbuff_dma[entry] = rx_q->rx_skbuff_head[entry]
+						     + skb_headroom(skb);
 
 			if (unlikely(priv->synopsys_id >= DWMAC_CORE_4_00)) {
 				p->des0 = cpu_to_le32(rx_q->rx_skbuff_dma[entry]);
@@ -3333,10 +3346,12 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 				 * them in stmmac_rx_refill() function so that
 				 * device can reuse it.
 				 */
+				int head = skb_headroom(rx_q->rx_skbuff[entry]);
+
 				rx_q->rx_skbuff[entry] = NULL;
 				dma_unmap_single(priv->device,
-						 rx_q->rx_skbuff_dma[entry],
-						 priv->dma_buf_sz,
+						 rx_q->rx_skbuff_head[entry],
+						 head + priv->dma_buf_sz,
 						 DMA_FROM_DEVICE);
 			}
 		} else {
@@ -3384,6 +3399,8 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 			if (unlikely(!priv->plat->has_gmac4 &&
 				     ((frame_len < priv->rx_copybreak) ||
 				     stmmac_rx_threshold_count(rx_q)))) {
+				int total_len;
+
 				skb = netdev_alloc_skb_ip_align(priv->dev,
 								frame_len);
 				if (unlikely(!skb)) {
@@ -3394,9 +3411,11 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 					break;
 				}
 
+				total_len = skb_headroom(skb) + frame_len;
+
 				dma_sync_single_for_cpu(priv->device,
-							rx_q->rx_skbuff_dma
-							[entry], frame_len,
+							rx_q->rx_skbuff_head
+							[entry], total_len,
 							DMA_FROM_DEVICE);
 				skb_copy_to_linear_data(skb,
 							rx_q->
@@ -3405,8 +3424,8 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 
 				skb_put(skb, frame_len);
 				dma_sync_single_for_device(priv->device,
-							   rx_q->rx_skbuff_dma
-							   [entry], frame_len,
+							   rx_q->rx_skbuff_head
+							   [entry], total_len,
 							   DMA_FROM_DEVICE);
 			} else {
 				skb = rx_q->rx_skbuff[entry];
@@ -3423,7 +3442,8 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 
 				skb_put(skb, frame_len);
 				dma_unmap_single(priv->device,
-						 rx_q->rx_skbuff_dma[entry],
+						 rx_q->rx_skbuff_head[entry],
+						 skb_headroom(skb) +
 						 priv->dma_buf_sz,
 						 DMA_FROM_DEVICE);
 			}
-- 
2.7.4

^ permalink raw reply related

* Re: [PATCH net-next] net: mvpp2: phylink support
From: Russell King - ARM Linux @ 2017-09-22 11:07 UTC (permalink / raw)
  To: Antoine Tenart
  Cc: davem, andrew, gregory.clement, thomas.petazzoni, miquel.raynal,
	nadavh, linux-kernel, mw, stefanc, netdev
In-Reply-To: <20170921134522.10993-1-antoine.tenart@free-electrons.com>

On Thu, Sep 21, 2017 at 03:45:22PM +0200, Antoine Tenart wrote:
> Convert the PPv2 driver to use phylink, which models the MAC to PHY
> link. The phylink support is made such a way the GoP link IRQ can still
> be used: the two modes are incompatible and the GoP link IRQ will be
> used if no PHY is described in the device tree. This is the same
> behaviour as before.

This makes no sense.  The point of phylink is to be able to support SFP
cages, and SFP cages do not have a PHY described in DT.  So, when you
want to use phylink because of SFP, you can't, because if you omit
the PHY the driver avoids using phylink.

> +static void mvpp2_phylink_validate(struct net_device *dev,
> +				   unsigned long *supported,
> +				   struct phylink_link_state *state)
> +{
> +	__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
> +
> +	phylink_set_port_modes(mask);
> +
> +	phylink_set(mask, Autoneg);
> +	phylink_set(mask, Pause);
> +	phylink_set(mask, Asym_Pause);
> +
> +	phylink_set(mask, 10baseT_Half);
> +	phylink_set(mask, 10baseT_Full);
> +	phylink_set(mask, 100baseT_Half);
> +	phylink_set(mask, 100baseT_Full);
> +	phylink_set(mask, 1000baseT_Half);
> +	phylink_set(mask, 1000baseT_Full);
> +	phylink_set(mask, 1000baseX_Full);
> +	phylink_set(mask, 10000baseKR_Full);
> +
> +	bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
> +	bitmap_and(state->advertising, state->advertising, mask,
> +		   __ETHTOOL_LINK_MODE_MASK_NBITS);
> +}

I don't think you've understood this despite the comments in the header
file.  What you describe above basically means you don't support any
kind of copper connection at 10G speeds, or any fiber modes at 10G
speeds either.

You need to set 10000baseT_Full for copper, 10000baseSR_Full,
10000baseLR_Full, 10000baseLRM_Full etc for fiber.  Had you looked at
my modifications for Marvell's mvpp2x driver you'd have spotted this...

> +
> +static int mvpp2_phylink_mac_link_state(struct net_device *dev,
> +					struct phylink_link_state *state)
> +{
> +	struct mvpp2_port *port = netdev_priv(dev);
> +	u32 val;
> +
> +	if (!phy_interface_mode_is_rgmii(port->phy_interface) &&
> +	    port->phy_interface != PHY_INTERFACE_MODE_SGMII)
> +		return 0;

You're blocking this for 1000base-X and 10G connections, which is not
correct.  The expectation is that this function returns the current
MAC state irrespective of the interface mode.

> +
> +	val = readl(port->base + MVPP2_GMAC_STATUS0);
> +
> +	state->an_complete = !!(val & MVPP2_GMAC_STATUS0_AN_COMPLETE);
> +	state->link = !!(val & MVPP2_GMAC_STATUS0_LINK_UP);
> +	state->duplex = !!(val & MVPP2_GMAC_STATUS0_FULL_DUPLEX);
> +
> +	if (val & MVPP2_GMAC_STATUS0_GMII_SPEED)
> +		state->speed = SPEED_1000;
> +	else
> +		state->speed = (val & MVPP2_GMAC_STATUS0_MII_SPEED) ?
> +			       SPEED_100 : SPEED_10;
> +
> +	state->pause = 0;
> +	if (val & MVPP2_GMAC_STATUS0_RX_PAUSE)
> +		state->pause |= MLO_PAUSE_RX;
> +	if (val & MVPP2_GMAC_STATUS0_TX_PAUSE)
> +		state->pause |= MLO_PAUSE_TX;
> +
> +	return 1;
> +}
> +
> +static void mvpp2_mac_an_restart(struct net_device *dev)
> +{
> +	struct mvpp2_port *port = netdev_priv(dev);
> +	u32 val;
> +
> +	if (!phy_interface_mode_is_rgmii(port->phy_interface) &&
> +	    port->phy_interface != PHY_INTERFACE_MODE_SGMII)
> +		return;

This prevents AN restart in 1000base-X mode, which is exactly the
mode that you need to do this.  SGMII doesn't care, and RGMII doesn't
have inband AN.

> +
> +	val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
> +	val |= MVPP2_GMAC_IN_BAND_RESTART_AN;
> +	writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
> +}
> +
> +static void mvpp2_mac_config(struct net_device *dev, unsigned int mode,
> +			     const struct phylink_link_state *state)
> +{
> +	struct mvpp2_port *port = netdev_priv(dev);
> +	u32 val;
> +
> +	/* disable current port for reconfiguration */
> +	mvpp2_interrupts_disable(port);
> +	netif_carrier_off(port->dev);
> +	mvpp2_port_disable(port);
> +	phy_power_off(port->comphy);
> +
> +	/* comphy reconfiguration */
> +	port->phy_interface = state->interface;
> +	mvpp22_comphy_init(port);
> +
> +	/* gop/mac reconfiguration */
> +	mvpp22_gop_init(port);
> +	mvpp2_port_mii_set(port);
> +
> +	if (!phy_interface_mode_is_rgmii(port->phy_interface) &&
> +	    port->phy_interface != PHY_INTERFACE_MODE_SGMII)
> +		return;

Again, 1000base-X is excluded, which will break it.  You do need
to avoid touching the GMAC for 10G connections however.

> +
> +	val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
> +	val &= ~(MVPP2_GMAC_CONFIG_MII_SPEED |
> +		 MVPP2_GMAC_CONFIG_GMII_SPEED |
> +		 MVPP2_GMAC_CONFIG_FULL_DUPLEX |
> +		 MVPP2_GMAC_AN_SPEED_EN |
> +		 MVPP2_GMAC_AN_DUPLEX_EN);
> +
> +	if (state->duplex)
> +		val |= MVPP2_GMAC_CONFIG_FULL_DUPLEX;
> +
> +	if (state->speed == SPEED_1000)
> +		val |= MVPP2_GMAC_CONFIG_GMII_SPEED;
> +	else if (state->speed == SPEED_100)
> +		val |= MVPP2_GMAC_CONFIG_MII_SPEED;
> +
> +	writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);

You're assuming that this function only sets the current parameters for
the MAC.  That's incorrect - it also needs to deal with autonegotiation
for inband AN, such as SGMII and 1000base-X.

> +
> +	if (port->priv->hw_version == MVPP21 && port->flags & MVPP2_F_LOOPBACK)
> +		mvpp2_port_loopback_set(port, state);
> +}
> +
> +static void mvpp2_mac_link_down(struct net_device *dev, unsigned int mode)
> +{
> +	struct mvpp2_port *port = netdev_priv(dev);
> +	u32 val;
> +
> +	netif_tx_stop_all_queues(dev);
> +	netif_carrier_off(dev);
> +	mvpp2_ingress_disable(port);
> +	mvpp2_egress_disable(port);
> +
> +	mvpp2_port_disable(port);
> +	mvpp2_interrupts_disable(port);
> +
> +	if (!phylink_autoneg_inband(mode)) {
> +		val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
> +		val &= ~MVPP2_GMAC_FORCE_LINK_PASS;
> +		val |= MVPP2_GMAC_FORCE_LINK_DOWN;
> +		writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
> +	}

Please explain why you think its necessary to force the link down when
the link is already down - if there's no media connected, we only
need to stop the ingress and egress.

It's certainly wrong to disable interrupts - how do we end up with
link status changes reported from the MAC to phylink if interrupts
have been disabled?

phylink in the presence of a PHY checks that both the PHY _and_ MAC
are reporting link before it calls mac_link_up(), so if you've
disabled interrupts...


You guys know that I have working example code for both mvneta and the
Marvell PP2x driver.  It probably would help if you looked at those
examples.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

^ permalink raw reply

* Re: [net-next 1/2] dummy: add device MTU validation check
From: Eric Dumazet @ 2017-09-22 11:05 UTC (permalink / raw)
  To: Sabrina Dubroca
  Cc: Jarod Wilson, Zhang Shengju, davem, willemb, stephen, netdev
In-Reply-To: <20170922085610.GA4544@bistromath.localdomain>

On Fri, 2017-09-22 at 10:56 +0200, Sabrina Dubroca wrote:
> 2017-09-21, 08:02:18 -0700, Eric Dumazet wrote:
> > On Thu, 2017-09-21 at 21:32 +0800, Zhang Shengju wrote:
> > > Currently, any mtu value can be assigned when adding a new dummy device:
> > > [~]# ip link add name dummy1 mtu 100000 type dummy
> > > [~]# ip link show dummy1
> > > 15: dummy1: <BROADCAST,NOARP> mtu 100000 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> > >     link/ether 0a:61:6b:16:14:ce brd ff:ff:ff:ff:ff:ff
> > > 
> > > This patch adds device MTU validation check.
> > 
> > What is wrong with big MTU on dummy ?
> 
> It looks like the "centralize MTU checking" series broke that, but
> only for changing the MTU on an existing dummy device. Commit
> a52ad514fdf3 defined min_mtu/max_mtu in ether_setup, which dummy uses,
> but there was no MTU check in dummy prior to that commit.
> 

It looks like we accept big mtu on loopback, right ?

lpaa23:~# ifconfig lo mtu 100000
lpaa23:~# ifconfig lo
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:100000  Metric:1
          RX packets:3823 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3823 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:759159 (759.1 KB)  TX bytes:759159 (759.1 KB)

Also we accept very small MTU as well (although this automatically
removes IP addresses, as one would expect)

lpaa23:~# ifconfig lo mtu 50
lpaa23:~# ifconfig lo
lo        Link encap:Local Loopback  
          UP LOOPBACK RUNNING  MTU:50  Metric:1
          RX packets:4052 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4052 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:806274 (806.2 KB)  TX bytes:806274 (806.2 KB)



So, why dummy devices would not accept bit MTU ?

Do we have some fundamental assumption in the stack ?

If yes, we need to fix loopback urgently, it is more important than
dummy.

Thanks.

^ permalink raw reply

* [PATCH 5/5] net: nfc: llcp_core: use setup_timer() helper.
From: Allen Pais @ 2017-09-22 10:58 UTC (permalink / raw)
  To: netdev; +Cc: davem, sameo, Allen Pais
In-Reply-To: <1506077902-1796-1-git-send-email-allen.lkml@gmail.com>

   Use setup_timer function instead of initializing timer with the
   function and data fields.

Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
 net/nfc/llcp_core.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c
index 02eef5c..7988185 100644
--- a/net/nfc/llcp_core.c
+++ b/net/nfc/llcp_core.c
@@ -1573,9 +1573,8 @@ int nfc_llcp_register_device(struct nfc_dev *ndev)
 	INIT_LIST_HEAD(&local->list);
 	kref_init(&local->ref);
 	mutex_init(&local->sdp_lock);
-	init_timer(&local->link_timer);
-	local->link_timer.data = (unsigned long) local;
-	local->link_timer.function = nfc_llcp_symm_timer;
+	setup_timer(&local->link_timer, nfc_llcp_symm_timer,
+		    (unsigned long)local);
 
 	skb_queue_head_init(&local->tx_queue);
 	INIT_WORK(&local->tx_work, nfc_llcp_tx_work);
@@ -1601,9 +1600,8 @@ int nfc_llcp_register_device(struct nfc_dev *ndev)
 
 	mutex_init(&local->sdreq_lock);
 	INIT_HLIST_HEAD(&local->pending_sdreqs);
-	init_timer(&local->sdreq_timer);
-	local->sdreq_timer.data = (unsigned long) local;
-	local->sdreq_timer.function = nfc_llcp_sdreq_timer;
+	setup_timer(&local->sdreq_timer, nfc_llcp_sdreq_timer,
+		    (unsigned long)local);
 	INIT_WORK(&local->sdreq_timeout_work, nfc_llcp_sdreq_timeout_work);
 
 	list_add(&local->list, &llcp_devices);
-- 
2.7.4

^ permalink raw reply related

* [PATCH 4/5] net: nfc: core: use setup_timer() helper.
From: Allen Pais @ 2017-09-22 10:58 UTC (permalink / raw)
  To: netdev; +Cc: davem, sameo, Allen Pais
In-Reply-To: <1506077902-1796-1-git-send-email-allen.lkml@gmail.com>

   Use setup_timer function instead of initializing timer with the
   function and data fields.

Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
 net/nfc/core.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/net/nfc/core.c b/net/nfc/core.c
index 5cf33df..e5e23c2 100644
--- a/net/nfc/core.c
+++ b/net/nfc/core.c
@@ -1094,9 +1094,8 @@ struct nfc_dev *nfc_allocate_device(struct nfc_ops *ops,
 	dev->targets_generation = 1;
 
 	if (ops->check_presence) {
-		init_timer(&dev->check_pres_timer);
-		dev->check_pres_timer.data = (unsigned long)dev;
-		dev->check_pres_timer.function = nfc_check_pres_timeout;
+		setup_timer(&dev->check_pres_timer, nfc_check_pres_timeout,
+			    (unsigned long)dev);
 
 		INIT_WORK(&dev->check_pres_work, nfc_check_pres_work);
 	}
-- 
2.7.4

^ permalink raw reply related

* [PATCH 3/5] net: af_packet: use setup_timer() helper.
From: Allen Pais @ 2017-09-22 10:58 UTC (permalink / raw)
  To: netdev; +Cc: davem, sameo, Allen Pais
In-Reply-To: <1506077902-1796-1-git-send-email-allen.lkml@gmail.com>

   Use setup_timer function instead of initializing timer with the
   function and data fields.

Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
 net/packet/af_packet.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index c261729..1d3e3ce 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -544,9 +544,7 @@ static void prb_init_blk_timer(struct packet_sock *po,
 		struct tpacket_kbdq_core *pkc,
 		void (*func) (unsigned long))
 {
-	init_timer(&pkc->retire_blk_timer);
-	pkc->retire_blk_timer.data = (long)po;
-	pkc->retire_blk_timer.function = func;
+	setup_timer(&pkc->retire_blk_timer, func, (long)po);
 	pkc->retire_blk_timer.expires = jiffies;
 }
 
-- 
2.7.4

^ permalink raw reply related

* [PATCH 2/5] net: nfc: hci: llc_shdlc: use setup_timer() helper.
From: Allen Pais @ 2017-09-22 10:58 UTC (permalink / raw)
  To: netdev; +Cc: davem, sameo, Allen Pais
In-Reply-To: <1506077902-1796-1-git-send-email-allen.lkml@gmail.com>

   Use setup_timer function instead of initializing timer with the
   function and data fields.

Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
 net/nfc/hci/llc_shdlc.c | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/net/nfc/hci/llc_shdlc.c b/net/nfc/hci/llc_shdlc.c
index 17e59a0..58df37e 100644
--- a/net/nfc/hci/llc_shdlc.c
+++ b/net/nfc/hci/llc_shdlc.c
@@ -763,17 +763,14 @@ static void *llc_shdlc_init(struct nfc_hci_dev *hdev, xmit_to_drv_t xmit_to_drv,
 	mutex_init(&shdlc->state_mutex);
 	shdlc->state = SHDLC_DISCONNECTED;
 
-	init_timer(&shdlc->connect_timer);
-	shdlc->connect_timer.data = (unsigned long)shdlc;
-	shdlc->connect_timer.function = llc_shdlc_connect_timeout;
+	setup_timer(&shdlc->connect_timer, llc_shdlc_connect_timeout,
+		    (unsigned long)shdlc);
 
-	init_timer(&shdlc->t1_timer);
-	shdlc->t1_timer.data = (unsigned long)shdlc;
-	shdlc->t1_timer.function = llc_shdlc_t1_timeout;
+	setup_timer(&shdlc->t1_timer, llc_shdlc_t1_timeout,
+		    (unsigned long)shdlc);
 
-	init_timer(&shdlc->t2_timer);
-	shdlc->t2_timer.data = (unsigned long)shdlc;
-	shdlc->t2_timer.function = llc_shdlc_t2_timeout;
+	setup_timer(&shdlc->t2_timer, llc_shdlc_t2_timeout,
+		    (unsigned long)shdlc);
 
 	shdlc->w = SHDLC_MAX_WINDOW;
 	shdlc->srej_support = SHDLC_SREJ_SUPPORT;
-- 
2.7.4

^ permalink raw reply related

* [PATCH 1/5] net: nfc: hci: use setup_timer() helper.
From: Allen Pais @ 2017-09-22 10:58 UTC (permalink / raw)
  To: netdev; +Cc: davem, sameo, Allen Pais
In-Reply-To: <1506077902-1796-1-git-send-email-allen.lkml@gmail.com>

   Use setup_timer function instead of initializing timer with the
   function and data fields.

Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
 net/nfc/hci/core.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/net/nfc/hci/core.c b/net/nfc/hci/core.c
index b740fef..a8a6e78 100644
--- a/net/nfc/hci/core.c
+++ b/net/nfc/hci/core.c
@@ -1004,9 +1004,8 @@ int nfc_hci_register_device(struct nfc_hci_dev *hdev)
 
 	INIT_WORK(&hdev->msg_tx_work, nfc_hci_msg_tx_work);
 
-	init_timer(&hdev->cmd_timer);
-	hdev->cmd_timer.data = (unsigned long)hdev;
-	hdev->cmd_timer.function = nfc_hci_cmd_timeout;
+	setup_timer(&hdev->cmd_timer, nfc_hci_cmd_timeout,
+		    (unsigned long)hdev);
 
 	skb_queue_head_init(&hdev->rx_hcp_frags);
 
-- 
2.7.4

^ permalink raw reply related

* [PATCH 0/5] use setup_timer() helper function.
From: Allen Pais @ 2017-09-22 10:58 UTC (permalink / raw)
  To: netdev; +Cc: davem, sameo, Allen Pais

This series uses setup_timer() helper function. The series
addresses the files under net/*.



Allen Pais (5):
  net: nfc: hci: use setup_timer() helper.
  net: nfc: hci: llc_shdlc: use setup_timer() helper.
  net: af_packet: use setup_timer() helper.
  net: nfc: core: use setup_timer() helper.
  net: nfc: llcp_core: use setup_timer() helper.

 net/nfc/core.c          |  5 ++---
 net/nfc/hci/core.c      |  5 ++---
 net/nfc/hci/llc_shdlc.c | 15 ++++++---------
 net/nfc/llcp_core.c     | 10 ++++------
 net/packet/af_packet.c  |  4 +---
 5 files changed, 15 insertions(+), 24 deletions(-)

-- 
2.7.4

^ permalink raw reply

* Re: [PATCH] wireless: iwlegacy: make const array static to shink object code size Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit
From: Julia Lawall @ 2017-09-22 10:54 UTC (permalink / raw)
  To: Joe Perches
  Cc: Colin Ian King, Stanislaw Gruszka, Kalle Valo, linux-wireless,
	netdev, kernel-janitors, linux-kernel
In-Reply-To: <1506077181.12311.39.camel@perches.com>

[-- Attachment #1: Type: text/plain, Size: 3584 bytes --]



On Fri, 22 Sep 2017, Joe Perches wrote:

> On Fri, 2017-09-22 at 12:06 +0200, Julia Lawall wrote:
> >
> > On Fri, 22 Sep 2017, Colin Ian King wrote:
> >
> > > On 22/09/17 11:03, Joe Perches wrote:
> > > > On Fri, 2017-09-22 at 09:23 +0200, Julia Lawall wrote:
> > > > >
> > > > > On Thu, 21 Sep 2017, Colin King wrote:
> > > > >
> > > > > > From: Colin Ian King <colin.king@canonical.com>
> > > > > >
> > > > > > Don't populate const array ac_to_fifo on the stack in an inlined
> > > > > > function, instead make it static.  Makes the object code smaller
> > > > > > by over 800 bytes:
> > > > > >
> > > > > >    text	   data	    bss	    dec	    hex	filename
> > > > > >  159029	  33154	   1216	 193399	  2f377	4965-mac.o
> > > > > >
> > > > > >    text	   data	    bss	    dec	    hex	filename
> > > > > >  158122	  33250	   1216	 192588	  2f04c	4965-mac.o
> > > > > >
> > > > > > (gcc version 7.2.0 x86_64)
> > > > >
> > > > > Gcc 7 must be much more aggressive about inlining than gcc 4.  Here is the
> > > > > change that I got on this file:
> > > > >
> > > > >      text          data     bss     dec     hex filename
> > > > > -   76346          1494     152   77992   130a8 drivers/net/wireless/intel/iwlegacy/4965-mac.o
> > > > > +   76298          1494     152   77944   13078 drivers/net/wireless/intel/iwlegacy/4965-mac.o
> > > > > decrease of 48
> > > >
> > > > More likely different CONFIG options.
> > > >
> > > > e.g. allyesconfig vs defconfig with wireless
> > > >
> > >
> > > yup, I used allyesconfig
> >
> > Mine is also allyesconfig.
>
> Odd.
>
> Here is what I get: (Sorry, no gcc-7)
>
> gcc4: gcc-4.9 (Ubuntu 4.9.4-2ubuntu1) 4.9.4
> gcc5: gcc-5 (Ubuntu 5.4.1-8ubuntu1) 5.4.1 20170304
> gcc6: gcc-6 (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406
>
> $ size drivers/net/wireless/intel/iwlegacy/4965-mac.o*
>    text	   data	    bss	    dec	    hex	filename
>  118559	   1766	    152	 120477	  1d69d	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc4.allyesconfig.new
>  118623	   1766	    152	 120541	  1d6dd	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc4.allyesconfig.old

My gcc is 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)

You get a savings of 64 and I got a savings of 48, but it's not that big a
difference, compared to what the later versions give.

julia

>   51595	   1156	      0	  52751	   ce0f	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc4.defconfig.new
>   51659	   1156	      0	  52815	   ce4f	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc4.defconfig.old
>  141956	  29790	   1216	 172962	  2a3a2	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc5.allyesconfig.new
>  142671	  29702	   1216	 173589	  2a615	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc5.allyesconfig.old
>   51733	   1156	      0	  52889	   ce99	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc5.defconfig.new
>   51813	   1156	      0	  52969	   cee9	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc5.defconfig.old
>  152991	  29790	   1216	 183997	  2cebd	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc6.allyesconfig.new
>  153722	  29702	   1216	 184640	  2d140	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc6.allyesconfig.old
>   51813	   1156	      0	  52969	   cee9	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc6.defconfig.new
>   51893	   1156	      0	  53049	   cf39	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc6.defconfig.old
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 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] wireless: iwlegacy: make const array static to shink object code size Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit
From: Joe Perches @ 2017-09-22 10:46 UTC (permalink / raw)
  To: Julia Lawall, Colin Ian King
  Cc: Stanislaw Gruszka, Kalle Valo, linux-wireless, netdev,
	kernel-janitors, linux-kernel
In-Reply-To: <alpine.DEB.2.20.1709221206050.3170@hadrien>

On Fri, 2017-09-22 at 12:06 +0200, Julia Lawall wrote:
> 
> On Fri, 22 Sep 2017, Colin Ian King wrote:
> 
> > On 22/09/17 11:03, Joe Perches wrote:
> > > On Fri, 2017-09-22 at 09:23 +0200, Julia Lawall wrote:
> > > > 
> > > > On Thu, 21 Sep 2017, Colin King wrote:
> > > > 
> > > > > From: Colin Ian King <colin.king@canonical.com>
> > > > > 
> > > > > Don't populate const array ac_to_fifo on the stack in an inlined
> > > > > function, instead make it static.  Makes the object code smaller
> > > > > by over 800 bytes:
> > > > > 
> > > > >    text	   data	    bss	    dec	    hex	filename
> > > > >  159029	  33154	   1216	 193399	  2f377	4965-mac.o
> > > > > 
> > > > >    text	   data	    bss	    dec	    hex	filename
> > > > >  158122	  33250	   1216	 192588	  2f04c	4965-mac.o
> > > > > 
> > > > > (gcc version 7.2.0 x86_64)
> > > > 
> > > > Gcc 7 must be much more aggressive about inlining than gcc 4.  Here is the
> > > > change that I got on this file:
> > > > 
> > > >      text          data     bss     dec     hex filename
> > > > -   76346          1494     152   77992   130a8 drivers/net/wireless/intel/iwlegacy/4965-mac.o
> > > > +   76298          1494     152   77944   13078 drivers/net/wireless/intel/iwlegacy/4965-mac.o
> > > > decrease of 48
> > > 
> > > More likely different CONFIG options.
> > > 
> > > e.g. allyesconfig vs defconfig with wireless
> > > 
> > 
> > yup, I used allyesconfig
> 
> Mine is also allyesconfig.

Odd.

Here is what I get: (Sorry, no gcc-7)

gcc4: gcc-4.9 (Ubuntu 4.9.4-2ubuntu1) 4.9.4
gcc5: gcc-5 (Ubuntu 5.4.1-8ubuntu1) 5.4.1 20170304
gcc6: gcc-6 (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406

$ size drivers/net/wireless/intel/iwlegacy/4965-mac.o*
   text	   data	    bss	    dec	    hex	filename
 118559	   1766	    152	 120477	  1d69d	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc4.allyesconfig.new
 118623	   1766	    152	 120541	  1d6dd	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc4.allyesconfig.old
  51595	   1156	      0	  52751	   ce0f	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc4.defconfig.new
  51659	   1156	      0	  52815	   ce4f	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc4.defconfig.old
 141956	  29790	   1216	 172962	  2a3a2	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc5.allyesconfig.new
 142671	  29702	   1216	 173589	  2a615	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc5.allyesconfig.old
  51733	   1156	      0	  52889	   ce99	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc5.defconfig.new
  51813	   1156	      0	  52969	   cee9	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc5.defconfig.old
 152991	  29790	   1216	 183997	  2cebd	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc6.allyesconfig.new
 153722	  29702	   1216	 184640	  2d140	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc6.allyesconfig.old
  51813	   1156	      0	  52969	   cee9	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc6.defconfig.new
  51893	   1156	      0	  53049	   cf39	drivers/net/wireless/intel/iwlegacy/4965-mac.o.gcc6.defconfig.old

^ permalink raw reply

* Re: [PATCH] wireless: iwlegacy:  make const array static to shink object code size Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit
From: Kalle Valo @ 2017-09-22 10:32 UTC (permalink / raw)
  To: Stanislaw Gruszka
  Cc: Colin King, linux-wireless, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170922095609.GA27551@redhat.com>

Stanislaw Gruszka <sgruszka@redhat.com> writes:

> On Thu, Sep 21, 2017 at 11:56:30PM +0100, Colin King wrote:
>> From: Colin Ian King <colin.king@canonical.com>
>> 
>> Don't populate const array ac_to_fifo on the stack in an inlined
>> function, instead make it static.  Makes the object code smaller
>> by over 800 bytes:
>> 
>>    text	   data	    bss	    dec	    hex	filename
>>  159029	  33154	   1216	 193399	  2f377	4965-mac.o
>> 
>>    text	   data	    bss	    dec	    hex	filename
>>  158122	  33250	   1216	 192588	  2f04c	4965-mac.o
>> 
>> (gcc version 7.2.0 x86_64)
>> 
>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>
> Content type information was added at the end of the topic, but
> I think Kalle can fix that when he will be committing the patch.

Yeah, I'll fix that when I commit this. But very good that you pointed
it out, I might miss stuff like this.

I'll also remove the "wireless:" prefix from the title.

-- 
Kalle Valo

^ permalink raw reply

* tools: selftests: psock_tpacket: skip un-supported tpacket_v3 test
From: Orson Zhai @ 2017-09-22 10:17 UTC (permalink / raw)
  To: Shuah Khan
  Cc: David S . Miller, milosz.wasilewski, sumit.semwal, netdev,
	linux-kselftest, Orson Zhai

The TPACKET_V3 test of PACKET_TX_RING will fail with kernel version
lower than v4.11. Supported code of tx ring was add with commit id
<7f953ab2ba46: af_packet: TX_RING support for TPACKET_V3> at Jan. 3
of 2017.

So skip this item test instead of reporting failing for old kernels.

Signed-off-by: Orson Zhai <orson.zhai@linaro.org>
---
 tools/testing/selftests/net/psock_tpacket.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/net/psock_tpacket.c b/tools/testing/selftests/net/psock_tpacket.c
index 7f6cd9fdacf3..f0cfc18c3726 100644
--- a/tools/testing/selftests/net/psock_tpacket.c
+++ b/tools/testing/selftests/net/psock_tpacket.c
@@ -57,6 +57,7 @@
 #include <net/if.h>
 #include <inttypes.h>
 #include <poll.h>
+#include <errno.h>
 
 #include "psock_lib.h"
 
@@ -676,7 +677,7 @@ static void __v3_fill(struct ring *ring, unsigned int blocks, int type)
 	ring->flen = ring->req3.tp_block_size;
 }
 
-static void setup_ring(int sock, struct ring *ring, int version, int type)
+static int setup_ring(int sock, struct ring *ring, int version, int type)
 {
 	int ret = 0;
 	unsigned int blocks = 256;
@@ -703,7 +704,11 @@ static void setup_ring(int sock, struct ring *ring, int version, int type)
 
 	if (ret == -1) {
 		perror("setsockopt");
-		exit(1);
+		if (errno == EINVAL) {
+			printf("[SKIP] This type seems un-supported in current kernel, skipped.\n");
+			return -1;
+		} else
+			exit(1);
 	}
 
 	ring->rd_len = ring->rd_num * sizeof(*ring->rd);
@@ -715,6 +720,7 @@ static void setup_ring(int sock, struct ring *ring, int version, int type)
 
 	total_packets = 0;
 	total_bytes = 0;
+	return 0;
 }
 
 static void mmap_ring(int sock, struct ring *ring)
@@ -830,7 +836,12 @@ static int test_tpacket(int version, int type)
 
 	sock = pfsocket(version);
 	memset(&ring, 0, sizeof(ring));
-	setup_ring(sock, &ring, version, type);
+	if(setup_ring(sock, &ring, version, type)) {
+		/* skip test when error of invalid argument */
+		close(sock);
+		return 0;
+	}
+
 	mmap_ring(sock, &ring);
 	bind_ring(sock, &ring);
 	walk_ring(sock, &ring);
-- 
2.12.2

^ permalink raw reply related

* Re: [PATCH] wireless: iwlegacy: make const array static to shink object code size Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit
From: Julia Lawall @ 2017-09-22 10:06 UTC (permalink / raw)
  To: Colin Ian King
  Cc: Joe Perches, Stanislaw Gruszka, Kalle Valo, linux-wireless,
	netdev, kernel-janitors, linux-kernel
In-Reply-To: <f6cb5b73-4ed5-92d9-3909-32b8e3aafc45@canonical.com>



On Fri, 22 Sep 2017, Colin Ian King wrote:

> On 22/09/17 11:03, Joe Perches wrote:
> > On Fri, 2017-09-22 at 09:23 +0200, Julia Lawall wrote:
> >>
> >> On Thu, 21 Sep 2017, Colin King wrote:
> >>
> >>> From: Colin Ian King <colin.king@canonical.com>
> >>>
> >>> Don't populate const array ac_to_fifo on the stack in an inlined
> >>> function, instead make it static.  Makes the object code smaller
> >>> by over 800 bytes:
> >>>
> >>>    text	   data	    bss	    dec	    hex	filename
> >>>  159029	  33154	   1216	 193399	  2f377	4965-mac.o
> >>>
> >>>    text	   data	    bss	    dec	    hex	filename
> >>>  158122	  33250	   1216	 192588	  2f04c	4965-mac.o
> >>>
> >>> (gcc version 7.2.0 x86_64)
> >>
> >> Gcc 7 must be much more aggressive about inlining than gcc 4.  Here is the
> >> change that I got on this file:
> >>
> >>      text          data     bss     dec     hex filename
> >> -   76346          1494     152   77992   130a8 drivers/net/wireless/intel/iwlegacy/4965-mac.o
> >> +   76298          1494     152   77944   13078 drivers/net/wireless/intel/iwlegacy/4965-mac.o
> >> decrease of 48
> >
> > More likely different CONFIG options.
> >
> > e.g. allyesconfig vs defconfig with wireless
> >
> yup, I used allyesconfig

Mine is also allyesconfig.

julia

>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 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] wireless: iwlegacy: make const array static to shink object code size Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit
From: Colin Ian King @ 2017-09-22 10:05 UTC (permalink / raw)
  To: Joe Perches, Julia Lawall
  Cc: Stanislaw Gruszka, Kalle Valo, linux-wireless, netdev,
	kernel-janitors, linux-kernel
In-Reply-To: <1506074588.12311.37.camel@perches.com>

On 22/09/17 11:03, Joe Perches wrote:
> On Fri, 2017-09-22 at 09:23 +0200, Julia Lawall wrote:
>>
>> On Thu, 21 Sep 2017, Colin King wrote:
>>
>>> From: Colin Ian King <colin.king@canonical.com>
>>>
>>> Don't populate const array ac_to_fifo on the stack in an inlined
>>> function, instead make it static.  Makes the object code smaller
>>> by over 800 bytes:
>>>
>>>    text	   data	    bss	    dec	    hex	filename
>>>  159029	  33154	   1216	 193399	  2f377	4965-mac.o
>>>
>>>    text	   data	    bss	    dec	    hex	filename
>>>  158122	  33250	   1216	 192588	  2f04c	4965-mac.o
>>>
>>> (gcc version 7.2.0 x86_64)
>>
>> Gcc 7 must be much more aggressive about inlining than gcc 4.  Here is the
>> change that I got on this file:
>>
>>      text          data     bss     dec     hex filename
>> -   76346          1494     152   77992   130a8 drivers/net/wireless/intel/iwlegacy/4965-mac.o
>> +   76298          1494     152   77944   13078 drivers/net/wireless/intel/iwlegacy/4965-mac.o
>> decrease of 48
> 
> More likely different CONFIG options.
> 
> e.g. allyesconfig vs defconfig with wireless
> 
yup, I used allyesconfig

^ permalink raw reply

* Re: [PATCH] wireless: iwlegacy: make const array static to shink object code size Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit
From: Joe Perches @ 2017-09-22 10:03 UTC (permalink / raw)
  To: Julia Lawall, Colin King
  Cc: Stanislaw Gruszka, Kalle Valo, linux-wireless, netdev,
	kernel-janitors, linux-kernel
In-Reply-To: <alpine.DEB.2.20.1709220921350.2024@hadrien>

On Fri, 2017-09-22 at 09:23 +0200, Julia Lawall wrote:
> 
> On Thu, 21 Sep 2017, Colin King wrote:
> 
> > From: Colin Ian King <colin.king@canonical.com>
> > 
> > Don't populate const array ac_to_fifo on the stack in an inlined
> > function, instead make it static.  Makes the object code smaller
> > by over 800 bytes:
> > 
> >    text	   data	    bss	    dec	    hex	filename
> >  159029	  33154	   1216	 193399	  2f377	4965-mac.o
> > 
> >    text	   data	    bss	    dec	    hex	filename
> >  158122	  33250	   1216	 192588	  2f04c	4965-mac.o
> > 
> > (gcc version 7.2.0 x86_64)
> 
> Gcc 7 must be much more aggressive about inlining than gcc 4.  Here is the
> change that I got on this file:
> 
>      text          data     bss     dec     hex filename
> -   76346          1494     152   77992   130a8 drivers/net/wireless/intel/iwlegacy/4965-mac.o
> +   76298          1494     152   77944   13078 drivers/net/wireless/intel/iwlegacy/4965-mac.o
> decrease of 48

More likely different CONFIG options.

e.g. allyesconfig vs defconfig with wireless

^ permalink raw reply

* Re: [PATCH] wireless: iwlegacy:  make const array static to shink object code size Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit
From: Stanislaw Gruszka @ 2017-09-22  9:56 UTC (permalink / raw)
  To: Colin King
  Cc: Kalle Valo, linux-wireless, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170921225630.21916-1-colin.king@canonical.com>

On Thu, Sep 21, 2017 at 11:56:30PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
> 
> Don't populate const array ac_to_fifo on the stack in an inlined
> function, instead make it static.  Makes the object code smaller
> by over 800 bytes:
> 
>    text	   data	    bss	    dec	    hex	filename
>  159029	  33154	   1216	 193399	  2f377	4965-mac.o
> 
>    text	   data	    bss	    dec	    hex	filename
>  158122	  33250	   1216	 192588	  2f04c	4965-mac.o
> 
> (gcc version 7.2.0 x86_64)
> 
> Signed-off-by: Colin Ian King <colin.king@canonical.com>

Content type information was added at the end of the topic, but
I think Kalle can fix that when he will be committing the patch.

Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>

^ permalink raw reply

* Re: [PATCH net-next RFC 3/5] vhost: introduce vhost_add_used_idx()
From: Stefan Hajnoczi @ 2017-09-22  9:07 UTC (permalink / raw)
  To: Jason Wang; +Cc: mst, virtualization, netdev, linux-kernel, kvm
In-Reply-To: <1506067355-5771-4-git-send-email-jasowang@redhat.com>

On Fri, Sep 22, 2017 at 04:02:33PM +0800, Jason Wang wrote:
> This patch introduces a helper which just increase the used idx. This
> will be used in pair with vhost_prefetch_desc_indices() by batching
> code.
> 
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
>  drivers/vhost/vhost.c | 33 +++++++++++++++++++++++++++++++++
>  drivers/vhost/vhost.h |  1 +
>  2 files changed, 34 insertions(+)

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

^ permalink raw reply

* Re: [PATCH net-next RFC 2/5] vhost: introduce helper to prefetch desc index
From: Stefan Hajnoczi @ 2017-09-22  9:02 UTC (permalink / raw)
  To: Jason Wang; +Cc: netdev, virtualization, linux-kernel, kvm, mst
In-Reply-To: <1506067355-5771-3-git-send-email-jasowang@redhat.com>

On Fri, Sep 22, 2017 at 04:02:32PM +0800, Jason Wang wrote:
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index f87ec75..8424166d 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -2437,6 +2437,61 @@ struct vhost_msg_node *vhost_dequeue_msg(struct vhost_dev *dev,
>  }
>  EXPORT_SYMBOL_GPL(vhost_dequeue_msg);
>  
> +int vhost_prefetch_desc_indices(struct vhost_virtqueue *vq,
> +				struct vring_used_elem *heads,
> +				u16 num, bool used_update)

Missing doc comment.

> +{
> +	int ret, ret2;
> +	u16 last_avail_idx, last_used_idx, total, copied;
> +	__virtio16 avail_idx;
> +	struct vring_used_elem __user *used;
> +	int i;

The following variable names are a little confusing:

last_avail_idx vs vq->last_avail_idx.  last_avail_idx is a wrapped
avail->ring[] index, vq->last_avail_idx is a free-running counter.  The
same for last_used_idx vs vq->last_used_idx.

num argument vs vq->num.  The argument could be called nheads instead to
make it clear that this is heads[] and not the virtqueue size.

Not a bug but it took me a while to figure out what was going on.

^ permalink raw reply

* Re: [net-next 1/2] dummy: add device MTU validation check
From: Sabrina Dubroca @ 2017-09-22  8:56 UTC (permalink / raw)
  To: Eric Dumazet, Jarod Wilson; +Cc: Zhang Shengju, davem, willemb, stephen, netdev
In-Reply-To: <1506006138.29839.132.camel@edumazet-glaptop3.roam.corp.google.com>

2017-09-21, 08:02:18 -0700, Eric Dumazet wrote:
> On Thu, 2017-09-21 at 21:32 +0800, Zhang Shengju wrote:
> > Currently, any mtu value can be assigned when adding a new dummy device:
> > [~]# ip link add name dummy1 mtu 100000 type dummy
> > [~]# ip link show dummy1
> > 15: dummy1: <BROADCAST,NOARP> mtu 100000 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> >     link/ether 0a:61:6b:16:14:ce brd ff:ff:ff:ff:ff:ff
> > 
> > This patch adds device MTU validation check.
> 
> What is wrong with big MTU on dummy ?

It looks like the "centralize MTU checking" series broke that, but
only for changing the MTU on an existing dummy device. Commit
a52ad514fdf3 defined min_mtu/max_mtu in ether_setup, which dummy uses,
but there was no MTU check in dummy prior to that commit.


> If this is a generic rule, this check should belong in core network
> stack.
> 
> > 
> > Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
> > ---
> >  drivers/net/dummy.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c
> > index e31ab3b..0276b2b 100644
> > --- a/drivers/net/dummy.c
> > +++ b/drivers/net/dummy.c
> > @@ -365,6 +365,14 @@ static int dummy_validate(struct nlattr *tb[], struct nlattr *data[],
> >  		if (!is_valid_ether_addr(nla_data(tb[IFLA_ADDRESS])))
> >  			return -EADDRNOTAVAIL;
> >  	}
> > +
> > +	if (tb[IFLA_MTU]) {
> > +		u32 mtu = nla_get_u32(tb[IFLA_MTU]);
> 
> You do not verify/validate nla_len(tb[IFLA_MTU]).

I think ifla_policy already performs that check:


static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
[...]
	[IFLA_MTU]		= { .type = NLA_U32 },


static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh,
			struct netlink_ext_ack *extack)
{
[...]
	err = nlmsg_parse(nlh, sizeof(*ifm), tb, IFLA_MAX, ifla_policy, extack);


-- 
Sabrina

^ permalink raw reply

* Re: [PATCH 2/2] ip_tunnel: add mpls over gre encapsulation
From: Amine Kherbouche @ 2017-09-22  8:39 UTC (permalink / raw)
  To: Roopa Prabhu; +Cc: netdev@vger.kernel.org, xeb, David Lamparter
In-Reply-To: <CAJieiUicOTaxeT4t-y6QzoPibi1i7WJ31X978OP6sqjMjVuVNw@mail.gmail.com>



On 09/22/2017 12:35 AM, Roopa Prabhu wrote:
>> > diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
>> > index 36ea2ad..060ed07 100644
>> > --- a/net/mpls/af_mpls.c
>> > +++ b/net/mpls/af_mpls.c
>> > @@ -16,6 +16,7 @@
>> >  #include <net/arp.h>
>> >  #include <net/ip_fib.h>
>> >  #include <net/netevent.h>
>> > +#include <net/ip_tunnels.h>
>> >  #include <net/netns/generic.h>
>> >  #if IS_ENABLED(CONFIG_IPV6)
>> >  #include <net/ipv6.h>
>> > @@ -39,6 +40,40 @@ static int one = 1;
>> >  static int label_limit = (1 << 20) - 1;
>> >  static int ttl_max = 255;
>> >
>> > +size_t ipgre_mpls_encap_hlen(struct ip_tunnel_encap *e)
>> > +{
>> > +       return sizeof(struct mpls_shim_hdr);
>> > +}
>> > +
>> > +int ipgre_mpls_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
>> > +                           u8 *protocol, struct flowi4 *fl4)
>> > +{
>> > +       return 0;
>> > +}
>
> any reason you are supporting only rx ?

Tx path doesn't need changes, all gre hdr fields remain the same except 
for the protocol type which is loaded from skb->protocol this last is 
set by the mpls stack before entering gre device.

^ permalink raw reply

* Re: [patch net-next 07/12] mlxsw: spectrum: Add the multicast routing offloading logic
From: Yotam Gigi @ 2017-09-22  8:36 UTC (permalink / raw)
  To: Andrew Lunn, Jiri Pirko; +Cc: netdev, davem, idosch, mlxsw
In-Reply-To: <20170921152654.GF27589@lunn.ch>

On 09/21/2017 06:26 PM, Andrew Lunn wrote:
>> +static void mlxsw_sp_mr_route_stats_update(struct mlxsw_sp *mlxsw_sp,
>> +					   struct mlxsw_sp_mr_route *mr_route)
>> +{
>> +	struct mlxsw_sp_mr *mr = mlxsw_sp->mr;
>> +	u64 packets, bytes;
>> +
>> +	if (mr_route->route_action == MLXSW_SP_MR_ROUTE_ACTION_TRAP)
>> +		return;
>> +
>> +	mr->mr_ops->route_stats(mlxsw_sp, mr_route->route_priv, &packets,
>> +				&bytes);
>> +
>> +	switch (mr_route->mr_table->proto) {
>> +	case MLXSW_SP_L3_PROTO_IPV4:
>> +		mr_route->mfc4->mfc_un.res.pkt = packets;
>> +		mr_route->mfc4->mfc_un.res.bytes = bytes;
> What about wrong_if and lastuse? 

wronf_if is updated by ipmr as it is trapped to the CPU. We did not
address lastuse currently, though it can be easily addressed here.

>
> Is an mfc with iif on the host, not the switch, not offloaded?


I am not sure I followed. What do you mean MFC with iif on the host? you mean
MFC with iif that is an external NIC which is not part of the spectrum ASIC? in
this case, the route will not be offloaded and all traffic will pass in slowpath.


>
>    Andrew

^ permalink raw reply

* Re: [PATCH net-next RFC 1/5] vhost: split out ring head fetching logic
From: Stefan Hajnoczi @ 2017-09-22  8:31 UTC (permalink / raw)
  To: Jason Wang; +Cc: mst, virtualization, netdev, linux-kernel, kvm
In-Reply-To: <1506067355-5771-2-git-send-email-jasowang@redhat.com>

On Fri, Sep 22, 2017 at 04:02:31PM +0800, Jason Wang wrote:
> +/* This looks in the virtqueue and for the first available buffer, and converts
> + * it to an iovec for convenient access.  Since descriptors consist of some
> + * number of output then some number of input descriptors, it's actually two
> + * iovecs, but we pack them into one and note how many of each there were.
> + *
> + * This function returns the descriptor number found, or vq->num (which is
> + * never a valid descriptor number) if none was found.  A negative code is
> + * returned on error. */
> +int __vhost_get_vq_desc(struct vhost_virtqueue *vq,
> +			struct iovec iov[], unsigned int iov_size,
> +			unsigned int *out_num, unsigned int *in_num,
> +			struct vhost_log *log, unsigned int *log_num,
> +			__virtio16 head)
[...]
> +int vhost_get_vq_desc(struct vhost_virtqueue *vq,
> +		      struct iovec iov[], unsigned int iov_size,
> +		      unsigned int *out_num, unsigned int *in_num,
> +		      struct vhost_log *log, unsigned int *log_num)

Please document vhost_get_vq_desc().

Please also explain the difference between __vhost_get_vq_desc() and
vhost_get_vq_desc() in the documentation.

^ 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