Netdev List
 help / color / mirror / Atom feed
* [PATCH 7/8] r8169: (re)init phy on resume
From: Stanislaw Gruszka @ 2010-10-21  8:25 UTC (permalink / raw)
  To: Francois Romieu, netdev; +Cc: Denis Kirjanov, Stanislaw Gruszka
In-Reply-To: <1287649543-6569-1-git-send-email-sgruszka@redhat.com>

Fix switching device to low-speed mode after resume reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=502974

Reported-and-tested-by: Laurentiu Badea <bugzilla-redhat@wotevah.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
 drivers/net/r8169.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index ad3f37a..1165e7d 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -4824,6 +4824,9 @@ static int rtl8169_resume(struct device *device)
 {
 	struct pci_dev *pdev = to_pci_dev(device);
 	struct net_device *dev = pci_get_drvdata(pdev);
+	struct rtl8169_private *tp = netdev_priv(dev);
+
+	rtl8169_init_phy(dev, tp);
 
 	if (netif_running(dev))
 		__rtl8169_resume(dev);
@@ -4864,6 +4867,8 @@ static int rtl8169_runtime_resume(struct device *device)
 	tp->saved_wolopts = 0;
 	spin_unlock_irq(&tp->lock);
 
+	rtl8169_init_phy(dev, tp);
+
 	__rtl8169_resume(dev);
 
 	return 0;
-- 
1.6.5.2


^ permalink raw reply related

* [PATCH 8/8] r8169: print errors when dma mapping fail
From: Stanislaw Gruszka @ 2010-10-21  8:25 UTC (permalink / raw)
  To: Francois Romieu, netdev; +Cc: Denis Kirjanov, Stanislaw Gruszka
In-Reply-To: <1287649543-6569-1-git-send-email-sgruszka@redhat.com>

If dma mapping fail we are dropping packages or fail to open device.
But exact reason of drop/fail stays unknow for a user, so print errors.

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
 drivers/net/r8169.c |   16 +++++++++++++---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 1165e7d..cd16077 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -3974,8 +3974,11 @@ static struct sk_buff *rtl8169_alloc_rx_data(struct rtl8169_private *tp,
 
 	mapping = dma_map_single(d, rtl8169_align(data), rx_buf_sz,
 				 DMA_FROM_DEVICE);
-	if (unlikely(dma_mapping_error(d, mapping)))
+	if (unlikely(dma_mapping_error(d, mapping))) {
+		if (net_ratelimit())
+			netif_err(tp, drv, tp->dev, "Failed to map RX DMA!\n");
 		goto err_out;
+	}
 
 	rtl8169_map_to_asic(desc, mapping, rx_buf_sz);
 	return data;
@@ -4203,8 +4206,12 @@ static int rtl8169_xmit_frags(struct rtl8169_private *tp, struct sk_buff *skb,
 		len = frag->size;
 		addr = ((void *) page_address(frag->page)) + frag->page_offset;
 		mapping = dma_map_single(d, addr, len, DMA_TO_DEVICE);
-		if (unlikely(dma_mapping_error(d, mapping)))
+		if (unlikely(dma_mapping_error(d, mapping))) {
+			if (net_ratelimit())
+				netif_err(tp, drv, tp->dev,
+					  "Failed to map TX fragments DMA!\n");
 			goto err_out;
+		}
 
 		/* anti gcc 2.95.3 bugware (sic) */
 		status = opts1 | len | (RingEnd * !((entry + 1) % NUM_TX_DESC));
@@ -4270,8 +4277,11 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
 
 	len = skb_headlen(skb);
 	mapping = dma_map_single(d, skb->data, len, DMA_TO_DEVICE);
-	if (unlikely(dma_mapping_error(d, mapping)))
+	if (unlikely(dma_mapping_error(d, mapping))) {
+		if (net_ratelimit())
+			netif_err(tp, drv, dev, "Failed to map TX DMA!\n");
 		goto err_dma_0;
+	}
 
 	tp->tx_skb[entry].len = len;
 	txd->addr = cpu_to_le64(mapping);
-- 
1.6.5.2


^ permalink raw reply related

* Re: [RFC PATCH 5/9] ipvs network name space aware
From: Horms @ 2010-10-21  8:27 UTC (permalink / raw)
  To: Hans Schillstrom
  Cc: lvs-devel@vger.kernel.org, netdev@vger.kernel.org,
	netfilter-devel@vger.kernel.org, ja@ssi.bg, wensong@linux-vs.org,
	daniel.lezcano@free.fr
In-Reply-To: <201010210935.13311.hans.schillstrom@ericsson.com>

On Thu, Oct 21, 2010 at 09:35:12AM +0200, Hans Schillstrom wrote:
> On Wednesday 20 October 2010 17:21:45 Simon Horman wrote:
> > On Fri, Oct 08, 2010 at 01:17:02PM +0200, Hans Schillstrom wrote:
> > > This patch just contains ip_vs_ctl
> > >
> > > Signed-off-by:Hans Schillstrom <hans.schillstrom@ericsson.com>
> > >
> > > diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> > > index ca8ec8c..7e99cbc 100644
> > > --- a/net/netfilter/ipvs/ip_vs_ctl.c
> > > +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> >
> > [ snip ]
> >
> > > @@ -3377,62 +3383,131 @@ static void ip_vs_genl_unregister(void)
> > >  }
> > >
> > >  /* End of Generic Netlink interface definitions */
> > > +/*
> > > + * per netns intit/exit func.
> > > + */
> > > +int /*__net_init*/ __ip_vs_control_init(struct net *net)
> >
> > Can you describe why __net_init is commented out?
> 
> The coloring in my editor get fucked up  :-)
> I just forgott to remove the comment

Thanks, I'll remove it :-)


^ permalink raw reply

* Re: [PATCH] Fixed race condition at ip_vs.ko module init.
From: Patrick McHardy @ 2010-10-21  8:31 UTC (permalink / raw)
  To: Simon Horman
  Cc: Eduardo Blanco, lvs-devel, netdev, netfilter-devel, Wensong Zhang,
	Julian Anastasov
In-Reply-To: <20101019152311.GJ6193@verge.net.au>

Am 19.10.2010 17:23, schrieb Simon Horman:
> On Tue, Oct 19, 2010 at 10:26:47AM +0100, Eduardo Blanco wrote:
>> Lists were initialized after the module was registered.  Multiple ipvsadm
>> processes at module load triggered a race condition that resulted in a null
>> pointer dereference in do_ip_vs_get_ctl(). As a result, __ip_vs_mutex
>> was left locked preventing all further ipvsadm commands.
>>
>> Signed-off-by: Eduardo J. Blanco <ejblanco@google.com>
> 
> Thanks Eduardo.
> 
> Patrick, please consider pulling
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-test-2.6.git for-patrick
> 
> to get this change.

Pulled, thanks.


^ permalink raw reply

* Re: [PATCH v2 00/14] Move vlan acceleration into networking core.
From: David Miller @ 2010-10-21  8:33 UTC (permalink / raw)
  To: jesse; +Cc: netdev
In-Reply-To: <1287618974-4714-1-git-send-email-jesse@nicira.com>

From: Jesse Gross <jesse@nicira.com>
Date: Wed, 20 Oct 2010 16:56:00 -0700

> Hardware vlan acceleration behaves fairly differently from other types of
> offloading, which limits its usefulness.  This patch series aims to bring
> it more in line with other common forms of acceleration, such as checksum
> offloading and TSO.  In doing this it eliminates common driver bugs, increases
> flexibility, and improves performance, while reducing the number of lines of
> code.
> 
> The first eleven patches can be applied immediately, while the last three need
> to wait until all drivers that support vlan acceleration are updated.  If
> people agree that this patch set makes sense I will go ahead and switch over
> the dozen or so drivers that would need to change.

First 11 patches applied, thanks!

^ permalink raw reply

* Re: [PATCH -next 1/2] ibmveth: Cleanup error handling inside ibmveth_open
From: David Miller @ 2010-10-21  8:34 UTC (permalink / raw)
  To: dkirjanov; +Cc: rcj, netdev
In-Reply-To: <20101020142113.GA1026@hera.kernel.org>

From: Denis Kirjanov <dkirjanov@kernel.org>
Date: Wed, 20 Oct 2010 14:21:13 +0000

> Remove duplicated code in one place.
> 
> Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>

Applied.

^ permalink raw reply

* Re: [PATCH -next 2/2] ibmveth: Free irq on error path
From: David Miller @ 2010-10-21  8:34 UTC (permalink / raw)
  To: dkirjanov; +Cc: rcj, netdev
In-Reply-To: <20101020142151.GA1846@hera.kernel.org>

From: Denis Kirjanov <dkirjanov@kernel.org>
Date: Wed, 20 Oct 2010 14:21:51 +0000

> Free irq on error path.
> 
> Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>

Applied.

^ permalink raw reply

* Re: [net-next-2.6 PATCH 0/5] enic: updates to version 1.4.1.6
From: David Miller @ 2010-10-21  8:34 UTC (permalink / raw)
  To: vkolluri; +Cc: netdev, roprabhu, dwang2
In-Reply-To: <20101020201609.26870.80308.stgit@savbu-pc100.cisco.com>

From: Vasanthy Kolluri <vkolluri@cisco.com>
Date: Wed, 20 Oct 2010 13:16:53 -0700

> The following patch series implements enic driver updates:
> 
> 1/5 - Add support for multiple hardware receive queues
> 2/5 - Make firmware cognizant of the user set mac address
> 3/5 - Replace firmware devcmd CMD_ENABLE with CMD_ENABLE_WAIT
> 4/5 - Change min MTU
> 5/5 - Fix log message
> 
> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
> Signed-off-by: David Wang <dwang2@cisco.com>

All applied, thanks.

^ permalink raw reply

* Re: [PATCH 0/8] r8169 patches for net-next v2
From: David Miller @ 2010-10-21  8:35 UTC (permalink / raw)
  To: sgruszka; +Cc: romieu, netdev, kirjanov
In-Reply-To: <1287649543-6569-1-git-send-email-sgruszka@redhat.com>

From: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Thu, 21 Oct 2010 10:25:35 +0200

> v1 -> v2
> - update to current code and some minor changes/cleanups
> - do not return NETDEV_TX_BUSY from start_xmit when mapping fail (patch 1)
> - add missing unlikely (patch 1)
> - account tx bytes based on skb->len (patch 5)
> - new patches: changing mtu clean up, (re)init phy on resume
> - add net_ratelimit (patch 8)
> 
> All patches in series was tested on RTL8111/8168B

All applied, thank you.

^ permalink raw reply

* Re: [PATCH 4/9] tproxy: added tproxy sockopt interface in the IPV6 layer
From: Jan Engelhardt @ 2010-10-21  8:39 UTC (permalink / raw)
  To: KOVACS Krisztian; +Cc: netdev, netfilter-devel, Patrick McHardy, David Miller
In-Reply-To: <20101020112118.6260.78508.stgit@este.odu>

On Wednesday 2010-10-20 13:21, KOVACS Krisztian wrote:

>@@ -268,6 +268,10 @@ struct in6_flowlabel_req {
> /* RFC5082: Generalized Ttl Security Mechanism */
> #define IPV6_MINHOPCOUNT		73
> 
>+#define IPV6_ORIGDSTADDR        74
>+#define IPV6_RECVORIGDSTADDR    IPV6_ORIGDSTADDR
>+#define IPV6_TRANSPARENT        75
>+

Why do we actually need two names for the same thing?

^ permalink raw reply

* Re: [PATCH 1/2] r6040: fix multicast operations
From: Shawn Lin @ 2010-10-21  8:27 UTC (permalink / raw)
  To: Ben Hutchings
  Cc: Florian Fainelli, netdev, Marc Leclerc, Albert Chen, David Miller
In-Reply-To: <1287629751.20865.220.camel@localhost>

Dear Ben,

I help to answer your questions.

On Thu, 2010-10-21 at 03:55 +0100, Ben Hutchings wrote:
> On Wed, 2010-10-20 at 22:25 +0100, Florian Fainelli wrote:
> > This patch fixes the following issues with the r6040 NIC operating in
> > multicast:
> > 
> > 1) When the IFF_ALLMULTI flag is set, we should write 0xffff to the NIC hash
> >    table registers to make it process multicast traffic
> > 2) When the number of multicast address to handle is smaller than MCAST_MAX
> >    we should use the NIC multicast registers MID1_{L,M,H}.
> > 3) The hashing of the address was not correct, due to an invalid substraction
> >    (15 - (crc & 0x0f)) instead of (crc & 0x0f)
> 
> > Reported-by: Marc Leclerc <marc-leclerc@signaturealpha.com>
> > Tested-by: Marc Leclerc <marc-leclerc@signaturealpha.com>
> > Signed-off-by: Shawn Lin <shawn@dmp.com.tw>
> > Signed-off-by: Albert Chen <albert.chen@rdc.com.tw>
> > Signed-off-by: Florian Fainelli <florian@openwrt.org>
> > CC: stable@kernel.org
> 
> Remember you'll need to provide a different version for 2.6.27.y and
> 2.6.32.y.
> 
> > ---
> > diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
> > index 68a8419..3843363 100644
> > --- a/drivers/net/r6040.c
> > +++ b/drivers/net/r6040.c
> > @@ -852,74 +852,90 @@ static void r6040_multicast_list(struct net_device *dev)
> >  	struct r6040_private *lp = netdev_priv(dev);
> >  	void __iomem *ioaddr = lp->base;
> >  	u16 *adrp;
> > -	u16 reg;
> >  	unsigned long flags;
> >  	struct netdev_hw_addr *ha;
> >  	int i;
> >  
> > -	/* MAC Address */
> > -	adrp = (u16 *)dev->dev_addr;
> > -	iowrite16(adrp[0], ioaddr + MID_0L);
> > -	iowrite16(adrp[1], ioaddr + MID_0M);
> > -	iowrite16(adrp[2], ioaddr + MID_0H);
> > -
> > -	/* Promiscous Mode */
> >  	spin_lock_irqsave(&lp->lock, flags);
> >  
> >  	/* Clear AMCP & PROM bits */
> > -	reg = ioread16(ioaddr) & ~0x0120;
> > -	if (dev->flags & IFF_PROMISC) {
> > -		reg |= 0x0020;
> > +	lp->mcr0 = ioread16(ioaddr) & ~0x0120;
> > +
> > +	/* Promiscuous Mode */
> > +	if (dev->flags & IFF_PROMISC)
> >  		lp->mcr0 |= 0x0020;
> > -	}
> > -	/* Too many multicast addresses
> > -	 * accept all traffic */
> > -	else if ((netdev_mc_count(dev) > MCAST_MAX) ||
> > -		 (dev->flags & IFF_ALLMULTI))
> > -		reg |= 0x0020;
> >  
> > -	iowrite16(reg, ioaddr);
> > -	spin_unlock_irqrestore(&lp->lock, flags);
> > +	/* Enable multicast hash table function to
> > +	 * receive all multicast packets.
> > +	 */
> > +	else if (dev->flags & IFF_ALLMULTI) {
> > +		lp->mcr0 |= 0x0100;
> 
> Please give these flags names.
> 
> >  
> > -	/* Build the hash table */
> > -	if (netdev_mc_count(dev) > MCAST_MAX) {
> > -		u16 hash_table[4];
> > +		for (i = 0; i < MCAST_MAX ; i++) {
> > +			iowrite16(0, ioaddr + MID_1L + 8 * i);
> > +			iowrite16(0, ioaddr + MID_1M + 8 * i);
> > +			iowrite16(0, ioaddr + MID_1H + 8 * i);
> > +		}
> > +
> > +		iowrite16(0xffff, ioaddr + MAR0);
> > +		iowrite16(0xffff, ioaddr + MAR1);
> > +		iowrite16(0xffff, ioaddr + MAR2);
> > +		iowrite16(0xffff, ioaddr + MAR3);
> > +	}
> > +
> > +	/* Use internal multicast address registers
> > +	 * if the number of multicast addresses is not greater than MCAST_MAX.
> > +	 */
> > +	else if (netdev_mc_empty(dev)) {
> > +		for (i = 0; i < MCAST_MAX ; i++) {
> > +			iowrite16(0, ioaddr + MID_1L + 8 * i);
> > +			iowrite16(0, ioaddr + MID_1M + 8 * i);
> > +			iowrite16(0, ioaddr + MID_1H + 8 * i);
> > +		}
> > +	} else if (netdev_mc_count(dev) <= MCAST_MAX) {
> > +		i = 0;
> > +		netdev_for_each_mc_addr(ha, dev) {
> > +			adrp = (u16 *) ha->addr;
> > +			iowrite16(adrp[0], ioaddr + MID_1L + 8 * i);
> > +			iowrite16(adrp[1], ioaddr + MID_1M + 8 * i);
> > +			iowrite16(adrp[2], ioaddr + MID_1H + 8 * i);
> > +			i++;
> > +		}
> 
> What about the unused exact match entries?  And why is the empty case
> special?

Unused exact match entries? I am not sure which entries are you
mentioned.

There are five match entries in the code:

1) if (dev->flags & IFF_PROMISC)
then write a hardware flag to enable promiscuous function.


2) if (netdev_mc_count(dev) <= 3)
There are two hardware features could be used to filter multicast
frames:

[1] Three extra MAC/Multicast registers that could be used to get the
exact frames from specified multicast addresses.

[2] Multicast hash table registers.

I follow the original code to write exact multicast addresses to the
three registers when they are not greater than 3.


3) if (netdev_mc_empty(dev))
because we masked the multicast hash table flag before examine all
conditions, we only need to clear the addresses in the three
MAC/Multicast registers.


4) if (dev->flags & IFF_ALLMULTI)
then enable multicast hash table function and write 0xffff to all
multicast hash table registers.


5) else
to enablue multicast hash table and calculate corresponding bit
according to each multicast address.

> 
> > +	}
> > +	/* Otherwise, Enable multicast hash table function. */
> > +	else {
> > +		u16 hash_table[4] = { 0, };
> >  		u32 crc;
> >  
> > -		for (i = 0; i < 4; i++)
> > -			hash_table[i] = 0;
> > +		lp->mcr0 |= 0x0100;
> >  
> > +		for (i = 0; i < MCAST_MAX ; i++) {
> > +			iowrite16(0, ioaddr + MID_1L + 8 * i);
> > +			iowrite16(0, ioaddr + MID_1M + 8 * i);
> > +			iowrite16(0, ioaddr + MID_1H + 8 * i);
> > +		}
> > +
> > +		/* Build multicast hash table */
> >  		netdev_for_each_mc_addr(ha, dev) {
> >  			char *addrs = ha->addr;
> >  
> >  			if (!(*addrs & 1))
> >  				continue;
> >  
> > -			crc = ether_crc_le(6, addrs);
> > +			crc = ether_crc(ETH_ALEN, addrs);
> 
> You're reversing the order of bits in the CRC, which is not mentioned in
> the commit message; are you sure that's right?

This hash alogorithm is provided by RDC's engineers.

We also verified on different hardware platforms.

I will double confirm it with RDC's engineers.

> 
> >  			crc >>= 26;
> > -			hash_table[crc >> 4] |= 1 << (15 - (crc & 0xf));
> > +			hash_table[crc >> 4] |= 1 << (crc & 0xf);
> >  		}
> > +
> >  		/* Fill the MAC hash tables with their values */
> >  		iowrite16(hash_table[0], ioaddr + MAR0);
> >  		iowrite16(hash_table[1], ioaddr + MAR1);
> >  		iowrite16(hash_table[2], ioaddr + MAR2);
> >  		iowrite16(hash_table[3], ioaddr + MAR3);
> >  	}
> > -	/* Multicast Address 1~4 case */
> > -	i = 0;
> > -	netdev_for_each_mc_addr(ha, dev) {
> > -		if (i < MCAST_MAX) {
> > -			adrp = (u16 *) ha->addr;
> > -			iowrite16(adrp[0], ioaddr + MID_1L + 8 * i);
> > -			iowrite16(adrp[1], ioaddr + MID_1M + 8 * i);
> > -			iowrite16(adrp[2], ioaddr + MID_1H + 8 * i);
> > -		} else {
> > -			iowrite16(0xffff, ioaddr + MID_1L + 8 * i);
> > -			iowrite16(0xffff, ioaddr + MID_1M + 8 * i);
> > -			iowrite16(0xffff, ioaddr + MID_1H + 8 * i);
> > -		}
> 
> This conflicts with my patch in
> <http://article.gmane.org/gmane.linux.network/174926> which Dave has
> already applied (but not pushed out).
> 
> Ben.
> 
> > -		i++;
> > -	}
> > +	iowrite16(lp->mcr0, ioaddr);
> > +
> > +	spin_unlock_irqrestore(&lp->lock, flags);
> >  }
> >  
> >  static void netdev_get_drvinfo(struct net_device *dev,
> > --
> > 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
> > 
> > 
> 

Hope some issues have been clarified.

--
Regards,

Shawn Lin


===========================================================================================
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. 
If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. 
Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of DM&P Group is strictly prohibited; and any information in this email irrelevant to the official business of DM&P Group shall be deemed as neither given nor endorsed by DM&P Group.

===========================================================================================

^ permalink raw reply

* Re: [PATCH 6/9] tproxy: added IPv6 socket lookup function to nf_tproxy_core
From: Jan Engelhardt @ 2010-10-21  8:42 UTC (permalink / raw)
  To: KOVACS Krisztian; +Cc: netdev, netfilter-devel, Patrick McHardy, David Miller
In-Reply-To: <20101020112118.6260.89471.stgit@este.odu>


On Wednesday 2010-10-20 13:21, KOVACS Krisztian wrote:
>+
>+	pr_debug("tproxy socket lookup: proto %u %pI6:%u -> %pI6:%u, lookup type: %d, sock %p\n",
>+		 protocol, saddr, ntohs(sport), daddr, ntohs(dport), lookup_type, sk);

Shorts should preferably be used with %hd/%hu.

^ permalink raw reply

* Re: [PATCH 4/9] tproxy: added tproxy sockopt interface in the IPV6 layer
From: KOVACS Krisztian @ 2010-10-21  8:46 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netdev, netfilter-devel, Patrick McHardy, David Miller
In-Reply-To: <alpine.LNX.2.01.1010211037520.22922@obet.zrqbmnf.qr>

Hi,

On Thu, 2010-10-21 at 10:39 +0200, Jan Engelhardt wrote:
> On Wednesday 2010-10-20 13:21, KOVACS Krisztian wrote:
> 
> >@@ -268,6 +268,10 @@ struct in6_flowlabel_req {
> > /* RFC5082: Generalized Ttl Security Mechanism */
> > #define IPV6_MINHOPCOUNT		73
> > 
> >+#define IPV6_ORIGDSTADDR        74
> >+#define IPV6_RECVORIGDSTADDR    IPV6_ORIGDSTADDR
> >+#define IPV6_TRANSPARENT        75
> >+
> 
> Why do we actually need two names for the same thing?

IPV6_RECVORIGDSTADDR is the name of the socket option you're supposed to
set if you require the original destination address. IPV6_ORIGDSTADDR is
the name of the ancillary message you get with the actual address in it.
Just like we have it for IP_TOS/IP_RECVTOS, for example.

--KK




^ permalink raw reply

* Re: [PATCH 7/9] tproxy: added IPv6 support to the TPROXY target
From: Jan Engelhardt @ 2010-10-21  8:47 UTC (permalink / raw)
  To: KOVACS Krisztian; +Cc: netdev, netfilter-devel, Patrick McHardy, David Miller
In-Reply-To: <20101020112118.6260.51773.stgit@este.odu>


On Wednesday 2010-10-20 13:21, KOVACS Krisztian wrote:
> 
> /* TPROXY target is capable of marking the packet to perform
>  * redirection. We can get rid of that whenever we get support for
>  * mutliple targets in the same rule. */
>-struct xt_tproxy_target_info {
>+struct xt_tproxy_target_info_v0 {
> 	u_int32_t mark_mask;
> 	u_int32_t mark_value;
> 	__be32 laddr;
> 	__be16 lport;
> };

You cannot change the struct name either, or it may break userspace
compilations.


^ permalink raw reply

* Re: [PATCH 7/9] tproxy: added IPv6 support to the TPROXY target
From: KOVACS Krisztian @ 2010-10-21  8:50 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netdev, netfilter-devel, Patrick McHardy, David Miller
In-Reply-To: <alpine.LNX.2.01.1010211042190.22922@obet.zrqbmnf.qr>

Hi,

On Thu, 2010-10-21 at 10:47 +0200, Jan Engelhardt wrote:
> On Wednesday 2010-10-20 13:21, KOVACS Krisztian wrote:
> > 
> > /* TPROXY target is capable of marking the packet to perform
> >  * redirection. We can get rid of that whenever we get support for
> >  * mutliple targets in the same rule. */
> >-struct xt_tproxy_target_info {
> >+struct xt_tproxy_target_info_v0 {
> > 	u_int32_t mark_mask;
> > 	u_int32_t mark_value;
> > 	__be32 laddr;
> > 	__be16 lport;
> > };
> 
> You cannot change the struct name either, or it may break userspace
> compilations.

True, though iptables has its own copy of the header anyway.

--KK



^ permalink raw reply

* Re: [RFC PATCH 1/9] ipvs network name space aware
From: Eric Dumazet @ 2010-10-21  8:58 UTC (permalink / raw)
  To: paulmck
  Cc: Hans Schillstrom, Daniel Lezcano, lvs-devel@vger.kernel.org,
	netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
	horms@verge.net.au, ja@ssi.bg, wensong@linux-vs.org
In-Reply-To: <20101020160205.GB2386@linux.vnet.ibm.com>


> You said that there were a lot of "stepi" commands to get through
> rcu_read_lock() on x86_64.  This is quite surprising, especially if you
> built with CONFIG_RCU_TREE.  Even if you built with CONFIG_PREEMPT_RCU_TREE,
> you should only see something like the following from rcu_read_lock():
> 
> 000000b7 <__rcu_read_lock>:
>       b7:	55                   	push   %ebp
>       b8:	64 a1 00 00 00 00    	mov    %fs:0x0,%eax
>       be:	ff 80 80 01 00 00    	incl   0x180(%eax)
>       c4:	89 e5                	mov    %esp,%ebp
>       c6:	5d                   	pop    %ebp
>       c7:	c3                   	ret    
> 
> Unless you have some sort of debugging options turned on.  Or unless
> six instructions counts for "quite many" stepi commands.  ;-)
> 

Paul, this should be inlined, dont you think ?

Also, I dont understand why we use ACCESS_ONCE() in rcu_read_lock()

ACCESS_ONCE(current->rcu_read_lock_nesting)++;

Apparently, some compilers are a bit noisy here.

mov    0x1b0(%rdx),%eax
inc    %eax
mov    %eax,0x1b0(%rdx)

instead of :

incl   0x1b0(%rax)

So if the ACCESS_ONCE() is needed, we might add a comment, because it's
not obvious ;)




^ permalink raw reply

* [net-next-2.6 PATCH 1/3] ixgbe: update copyright info
From: Jeff Kirsher @ 2010-10-21  8:59 UTC (permalink / raw)
  To: davem; +Cc: netdev, gospo, bphilips, Emil Tantilov, Jeff Kirsher

From: Emil Tantilov <emil.s.tantilov@intel.com>

Update copyright notice

Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---

 drivers/net/ixgbe/ixgbe_mbx.c   |    2 +-
 drivers/net/ixgbe/ixgbe_mbx.h   |    2 +-
 drivers/net/ixgbe/ixgbe_sriov.c |    2 +-
 drivers/net/ixgbe/ixgbe_sriov.h |    2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_mbx.c b/drivers/net/ixgbe/ixgbe_mbx.c
index 435e028..471f0f2 100644
--- a/drivers/net/ixgbe/ixgbe_mbx.c
+++ b/drivers/net/ixgbe/ixgbe_mbx.c
@@ -1,7 +1,7 @@
 /*******************************************************************************
 
   Intel 10 Gigabit PCI Express Linux driver
-  Copyright(c) 1999 - 2009 Intel Corporation.
+  Copyright(c) 1999 - 2010 Intel Corporation.
 
   This program is free software; you can redistribute it and/or modify it
   under the terms and conditions of the GNU General Public License,
diff --git a/drivers/net/ixgbe/ixgbe_mbx.h b/drivers/net/ixgbe/ixgbe_mbx.h
index c5ae4b4..7e0d08f 100644
--- a/drivers/net/ixgbe/ixgbe_mbx.h
+++ b/drivers/net/ixgbe/ixgbe_mbx.h
@@ -1,7 +1,7 @@
 /*******************************************************************************
 
   Intel 10 Gigabit PCI Express Linux driver
-  Copyright(c) 1999 - 2009 Intel Corporation.
+  Copyright(c) 1999 - 2010 Intel Corporation.
 
   This program is free software; you can redistribute it and/or modify it
   under the terms and conditions of the GNU General Public License,
diff --git a/drivers/net/ixgbe/ixgbe_sriov.c b/drivers/net/ixgbe/ixgbe_sriov.c
index a6b720a..5428153 100644
--- a/drivers/net/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ixgbe/ixgbe_sriov.c
@@ -1,7 +1,7 @@
 /*******************************************************************************
 
   Intel 10 Gigabit PCI Express Linux driver
-  Copyright(c) 1999 - 2009 Intel Corporation.
+  Copyright(c) 1999 - 2010 Intel Corporation.
 
   This program is free software; you can redistribute it and/or modify it
   under the terms and conditions of the GNU General Public License,
diff --git a/drivers/net/ixgbe/ixgbe_sriov.h b/drivers/net/ixgbe/ixgbe_sriov.h
index 9a424bb..49dc14d 100644
--- a/drivers/net/ixgbe/ixgbe_sriov.h
+++ b/drivers/net/ixgbe/ixgbe_sriov.h
@@ -1,7 +1,7 @@
 /*******************************************************************************
 
   Intel 10 Gigabit PCI Express Linux driver
-  Copyright(c) 1999 - 2009 Intel Corporation.
+  Copyright(c) 1999 - 2010 Intel Corporation.
 
   This program is free software; you can redistribute it and/or modify it
   under the terms and conditions of the GNU General Public License,


^ permalink raw reply related

* [net-next-2.6 PATCH 2/3] ixgbe: fix stats handling
From: Jeff Kirsher @ 2010-10-21  9:00 UTC (permalink / raw)
  To: davem; +Cc: netdev, gospo, bphilips, Eric Dumazet, Don Skidmore, Jeff Kirsher
In-Reply-To: <20101021085740.12059.20577.stgit@localhost.localdomain>

From: Eric Dumazet <eric.dumazet@gmail.com>

Current ixgbe stats have following problems :

- Not 64 bit safe (on 32bit arches)

- Not safe in ixgbe_clean_rx_irq() :
   All cpus dirty a common location (netdev->stats.rx_bytes &
netdev->stats.rx_packets) without proper synchronization.
   This slow down a bit multiqueue operations, and possibly miss some
updates.

Fixes :

Implement ndo_get_stats64() method to provide accurate 64bit rx|tx
bytes/packets counters, using 64bit safe infrastructure.

ixgbe_get_ethtool_stats() also use this infrastructure to provide 64bit
safe counters.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Don Skidmore <donald.c.skidmore@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---

 drivers/net/ixgbe/ixgbe.h         |    3 ++-
 drivers/net/ixgbe/ixgbe_ethtool.c |   29 ++++++++++++++++-----------
 drivers/net/ixgbe/ixgbe_main.c    |   40 ++++++++++++++++++++++++++++++++++---
 3 files changed, 56 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe.h b/drivers/net/ixgbe/ixgbe.h
index a8c47b0..944d9e2 100644
--- a/drivers/net/ixgbe/ixgbe.h
+++ b/drivers/net/ixgbe/ixgbe.h
@@ -180,8 +180,9 @@ struct ixgbe_ring {
 					 */
 
 	struct ixgbe_queue_stats stats;
-	unsigned long reinit_state;
+	struct u64_stats_sync syncp;
 	int numa_node;
+	unsigned long reinit_state;
 	u64 rsc_count;			/* stat for coalesced packets */
 	u64 rsc_flush;			/* stats for flushed packets */
 	u32 restart_queue;		/* track tx queue restarts */
diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c b/drivers/net/ixgbe/ixgbe_ethtool.c
index d4ac943..3c7f15d 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -999,12 +999,11 @@ static void ixgbe_get_ethtool_stats(struct net_device *netdev,
                                     struct ethtool_stats *stats, u64 *data)
 {
 	struct ixgbe_adapter *adapter = netdev_priv(netdev);
-	u64 *queue_stat;
-	int stat_count = sizeof(struct ixgbe_queue_stats) / sizeof(u64);
 	struct rtnl_link_stats64 temp;
 	const struct rtnl_link_stats64 *net_stats;
-	int j, k;
-	int i;
+	unsigned int start;
+	struct ixgbe_ring *ring;
+	int i, j;
 	char *p = NULL;
 
 	ixgbe_update_stats(adapter);
@@ -1025,16 +1024,22 @@ static void ixgbe_get_ethtool_stats(struct net_device *netdev,
 		           sizeof(u64)) ? *(u64 *)p : *(u32 *)p;
 	}
 	for (j = 0; j < adapter->num_tx_queues; j++) {
-		queue_stat = (u64 *)&adapter->tx_ring[j]->stats;
-		for (k = 0; k < stat_count; k++)
-			data[i + k] = queue_stat[k];
-		i += k;
+		ring = adapter->tx_ring[j];
+		do {
+			start = u64_stats_fetch_begin_bh(&ring->syncp);
+			data[i]   = ring->stats.packets;
+			data[i+1] = ring->stats.bytes;
+		} while (u64_stats_fetch_retry_bh(&ring->syncp, start));
+		i += 2;
 	}
 	for (j = 0; j < adapter->num_rx_queues; j++) {
-		queue_stat = (u64 *)&adapter->rx_ring[j]->stats;
-		for (k = 0; k < stat_count; k++)
-			data[i + k] = queue_stat[k];
-		i += k;
+		ring = adapter->rx_ring[j];
+		do {
+			start = u64_stats_fetch_begin_bh(&ring->syncp);
+			data[i]   = ring->stats.packets;
+			data[i+1] = ring->stats.bytes;
+		} while (u64_stats_fetch_retry_bh(&ring->syncp, start));
+		i += 2;
 	}
 	if (adapter->flags & IXGBE_FLAG_DCB_ENABLED) {
 		for (j = 0; j < MAX_TX_PACKET_BUFFERS; j++) {
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 790a0da..d066ba3 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -824,8 +824,10 @@ static bool ixgbe_clean_tx_irq(struct ixgbe_q_vector *q_vector,
 
 	tx_ring->total_bytes += total_bytes;
 	tx_ring->total_packets += total_packets;
+	u64_stats_update_begin(&tx_ring->syncp);
 	tx_ring->stats.packets += total_packets;
 	tx_ring->stats.bytes += total_bytes;
+	u64_stats_update_end(&tx_ring->syncp);
 	return count < tx_ring->work_limit;
 }
 
@@ -1172,7 +1174,6 @@ static bool ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
 			       int *work_done, int work_to_do)
 {
 	struct ixgbe_adapter *adapter = q_vector->adapter;
-	struct net_device *netdev = adapter->netdev;
 	struct pci_dev *pdev = adapter->pdev;
 	union ixgbe_adv_rx_desc *rx_desc, *next_rxd;
 	struct ixgbe_rx_buffer *rx_buffer_info, *next_buffer;
@@ -1298,8 +1299,10 @@ static bool ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
 					rx_ring->rsc_count++;
 				rx_ring->rsc_flush++;
 			}
+			u64_stats_update_begin(&rx_ring->syncp);
 			rx_ring->stats.packets++;
 			rx_ring->stats.bytes += skb->len;
+			u64_stats_update_end(&rx_ring->syncp);
 		} else {
 			if (rx_ring->flags & IXGBE_RING_RX_PS_ENABLED) {
 				rx_buffer_info->skb = next_buffer->skb;
@@ -1375,8 +1378,6 @@ next_desc:
 
 	rx_ring->total_packets += total_rx_packets;
 	rx_ring->total_bytes += total_rx_bytes;
-	netdev->stats.rx_bytes += total_rx_bytes;
-	netdev->stats.rx_packets += total_rx_packets;
 
 	return cleaned;
 }
@@ -6558,6 +6559,38 @@ static void ixgbe_netpoll(struct net_device *netdev)
 }
 #endif
 
+static struct rtnl_link_stats64 *ixgbe_get_stats64(struct net_device *netdev,
+						   struct rtnl_link_stats64 *stats)
+{
+	struct ixgbe_adapter *adapter = netdev_priv(netdev);
+	int i;
+
+	/* accurate rx/tx bytes/packets stats */
+	dev_txq_stats_fold(netdev, stats);
+	for (i = 0; i < adapter->num_rx_queues; i++) {
+		struct ixgbe_ring *ring = adapter->rx_ring[i];
+		u64 bytes, packets;
+		unsigned int start;
+
+		do {
+			start = u64_stats_fetch_begin_bh(&ring->syncp);
+			packets = ring->stats.packets;
+			bytes   = ring->stats.bytes;
+		} while (u64_stats_fetch_retry_bh(&ring->syncp, start));
+		stats->rx_packets += packets;
+		stats->rx_bytes   += bytes;
+	}
+
+	/* following stats updated by ixgbe_watchdog_task() */
+	stats->multicast	= netdev->stats.multicast;
+	stats->rx_errors	= netdev->stats.rx_errors;
+	stats->rx_length_errors	= netdev->stats.rx_length_errors;
+	stats->rx_crc_errors	= netdev->stats.rx_crc_errors;
+	stats->rx_missed_errors	= netdev->stats.rx_missed_errors;
+	return stats;
+}
+
+
 static const struct net_device_ops ixgbe_netdev_ops = {
 	.ndo_open		= ixgbe_open,
 	.ndo_stop		= ixgbe_close,
@@ -6577,6 +6610,7 @@ static const struct net_device_ops ixgbe_netdev_ops = {
 	.ndo_set_vf_vlan	= ixgbe_ndo_set_vf_vlan,
 	.ndo_set_vf_tx_rate	= ixgbe_ndo_set_vf_bw,
 	.ndo_get_vf_config	= ixgbe_ndo_get_vf_config,
+	.ndo_get_stats64	= ixgbe_get_stats64,
 #ifdef CONFIG_NET_POLL_CONTROLLER
 	.ndo_poll_controller	= ixgbe_netpoll,
 #endif


^ permalink raw reply related

* [net-next-2.6 PATCH 3/3] ixgbe: add a refcnt when turning on/off FCoE offload capability
From: Jeff Kirsher @ 2010-10-21  9:00 UTC (permalink / raw)
  To: davem; +Cc: netdev, gospo, bphilips, Yi Zou, Jeff Kirsher
In-Reply-To: <20101021085740.12059.20577.stgit@localhost.localdomain>

From: Yi Zou <yi.zou@intel.com>

The FCoE offload is enabled/disabled per adapter, but upper FCoE protocol
stack could have multiple FCoE instances created on the same physical network
interface, e.g., FCoE on multiple VLAN interfaces on the same physical
network interface. In this case we want to turn on FCoE offload at the first
request from ndo_fcoe_enable() but only turn off FCoE offload at the very last
call to ndo_fcoe_disable(). This is fixed by adding a refcnt in the per adapter
FCoE structure and tear down FCoE offload when refcnt decrements to zero.

Signed-off-by: Yi Zou <yi.zou@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---

 drivers/net/ixgbe/ixgbe_fcoe.c |    6 ++++++
 drivers/net/ixgbe/ixgbe_fcoe.h |    1 +
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_fcoe.c b/drivers/net/ixgbe/ixgbe_fcoe.c
index 2f1de8b..05efa6a 100644
--- a/drivers/net/ixgbe/ixgbe_fcoe.c
+++ b/drivers/net/ixgbe/ixgbe_fcoe.c
@@ -604,11 +604,13 @@ int ixgbe_fcoe_enable(struct net_device *netdev)
 {
 	int rc = -EINVAL;
 	struct ixgbe_adapter *adapter = netdev_priv(netdev);
+	struct ixgbe_fcoe *fcoe = &adapter->fcoe;
 
 
 	if (!(adapter->flags & IXGBE_FLAG_FCOE_CAPABLE))
 		goto out_enable;
 
+	atomic_inc(&fcoe->refcnt);
 	if (adapter->flags & IXGBE_FLAG_FCOE_ENABLED)
 		goto out_enable;
 
@@ -648,6 +650,7 @@ int ixgbe_fcoe_disable(struct net_device *netdev)
 {
 	int rc = -EINVAL;
 	struct ixgbe_adapter *adapter = netdev_priv(netdev);
+	struct ixgbe_fcoe *fcoe = &adapter->fcoe;
 
 	if (!(adapter->flags & IXGBE_FLAG_FCOE_CAPABLE))
 		goto out_disable;
@@ -655,6 +658,9 @@ int ixgbe_fcoe_disable(struct net_device *netdev)
 	if (!(adapter->flags & IXGBE_FLAG_FCOE_ENABLED))
 		goto out_disable;
 
+	if (!atomic_dec_and_test(&fcoe->refcnt))
+		goto out_disable;
+
 	e_info(drv, "Disabling FCoE offload features.\n");
 	netdev->features &= ~NETIF_F_FCOE_CRC;
 	netdev->features &= ~NETIF_F_FSO;
diff --git a/drivers/net/ixgbe/ixgbe_fcoe.h b/drivers/net/ixgbe/ixgbe_fcoe.h
index abf4b2b..4bc2c55 100644
--- a/drivers/net/ixgbe/ixgbe_fcoe.h
+++ b/drivers/net/ixgbe/ixgbe_fcoe.h
@@ -66,6 +66,7 @@ struct ixgbe_fcoe {
 	u8 tc;
 	u8 up;
 #endif
+	atomic_t refcnt;
 	spinlock_t lock;
 	struct pci_pool *pool;
 	struct ixgbe_fcoe_ddp ddp[IXGBE_FCOE_DDP_MAX];


^ permalink raw reply related

* Re: [PATCH 9/9] tproxy: use the interface primary IP address as a default value for --on-ip
From: Jan Engelhardt @ 2010-10-21  9:12 UTC (permalink / raw)
  To: KOVACS Krisztian; +Cc: netdev, netfilter-devel, Patrick McHardy, David Miller
In-Reply-To: <20101020112118.6260.54362.stgit@este.odu>


On Wednesday 2010-10-20 13:21, KOVACS Krisztian wrote:
>+
>+	if (!ipv6_addr_any(user_laddr))
>+		return user_laddr;
>+	laddr = NULL;
>+
>+	rcu_read_lock();
>+	indev = __in6_dev_get(skb->dev);
>+	if (indev)
>+		list_for_each_entry(ifa, &indev->addr_list, if_list) {
>+			/* FIXME: address selection */

Per our realworld discussion, I believe we should add checks for
some conditions (RFC 4862 section 2):

1. ignore tentative addresses

	if (ifa->ifa_flags & IFA_F_TENTATIVE)
		continue;

2. tests for when the interface's ifa->preferred_lft == 0/deprecatedness:

	if (ctinfo == IP_CT_NEW/RELATED && (ifa->ifa_flags & IFA_F_DEPRECATED))
		continue;

3. check for invalid addresses
(There might be a flag like tentative..)

	if (ifa->valid_lft == 0)
		continue;


^ permalink raw reply

* Re: [PATCH 7/9] tproxy: added IPv6 support to the TPROXY target
From: Jan Engelhardt @ 2010-10-21  9:14 UTC (permalink / raw)
  To: KOVACS Krisztian; +Cc: netdev, netfilter-devel, Patrick McHardy, David Miller
In-Reply-To: <1287651014.13326.2.camel@este.odu>

On Thursday 2010-10-21 10:50, KOVACS Krisztian wrote:

>Hi,
>
>On Thu, 2010-10-21 at 10:47 +0200, Jan Engelhardt wrote:
>> On Wednesday 2010-10-20 13:21, KOVACS Krisztian wrote:
>> > 
>> > /* TPROXY target is capable of marking the packet to perform
>> >  * redirection. We can get rid of that whenever we get support for
>> >  * mutliple targets in the same rule. */
>> >-struct xt_tproxy_target_info {
>> >+struct xt_tproxy_target_info_v0 {
>> > 	u_int32_t mark_mask;
>> > 	u_int32_t mark_value;
>> > 	__be32 laddr;
>> > 	__be16 lport;
>> > };
>> 
>> You cannot change the struct name either, or it may break userspace
>> compilations.
>
>True, though iptables has its own copy of the header anyway.

There is - or so I always hear - other userspace programs.

As for iptables, we only do the copy so that it compiles independent of 
the kernel version. You have to assume that the headers can be updated 
at any time.

^ permalink raw reply

* Re: [PATCH 7/9] tproxy: added IPv6 support to the TPROXY target
From: KOVACS Krisztian @ 2010-10-21  9:33 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netdev, netfilter-devel, Patrick McHardy, David Miller
In-Reply-To: <alpine.LNX.2.01.1010211113020.22922@obet.zrqbmnf.qr>

Hi,

On Thu, 2010-10-21 at 11:14 +0200, Jan Engelhardt wrote:
> On Thursday 2010-10-21 10:50, KOVACS Krisztian wrote:
> 
> >Hi,
> >
> >On Thu, 2010-10-21 at 10:47 +0200, Jan Engelhardt wrote:
> >> On Wednesday 2010-10-20 13:21, KOVACS Krisztian wrote:
> >> > 
> >> > /* TPROXY target is capable of marking the packet to perform
> >> >  * redirection. We can get rid of that whenever we get support for
> >> >  * mutliple targets in the same rule. */
> >> >-struct xt_tproxy_target_info {
> >> >+struct xt_tproxy_target_info_v0 {
> >> > 	u_int32_t mark_mask;
> >> > 	u_int32_t mark_value;
> >> > 	__be32 laddr;
> >> > 	__be16 lport;
> >> > };
> >> 
> >> You cannot change the struct name either, or it may break userspace
> >> compilations.
> >
> >True, though iptables has its own copy of the header anyway.
> 
> There is - or so I always hear - other userspace programs.
> 
> As for iptables, we only do the copy so that it compiles independent of 
> the kernel version. You have to assume that the headers can be updated 
> at any time.

Sure, I wasn't implying we shouldn't fix this in the patch, I just doubt
there's anything else other than iptables using this and iptables itself
isn't affected.

Anyway, I've fixed it. Thanks, Jan.

--KK



^ permalink raw reply

* Re: [PATCH 6/9] tproxy: added IPv6 socket lookup function to nf_tproxy_core
From: KOVACS Krisztian @ 2010-10-21  9:48 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netdev, netfilter-devel, Patrick McHardy, David Miller
In-Reply-To: <alpine.LNX.2.01.1010211040250.22922@obet.zrqbmnf.qr>

Hi,

On Thu, 2010-10-21 at 10:42 +0200, Jan Engelhardt wrote:
> On Wednesday 2010-10-20 13:21, KOVACS Krisztian wrote:
> >+
> >+	pr_debug("tproxy socket lookup: proto %u %pI6:%u -> %pI6:%u, lookup type: %d, sock %p\n",
> >+		 protocol, saddr, ntohs(sport), daddr, ntohs(dport), lookup_type, sk);
> 
> Shorts should preferably be used with %hd/%hu.

Fixed, thanks Jan.

--KK



^ permalink raw reply

* Re: [PATCH net-2.6] net/sched: fix missing spinlock init
From: David Miller @ 2010-10-21 10:10 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev
In-Reply-To: <1287206554.2799.32.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 16 Oct 2010 07:22:34 +0200

> Under network load, doing :
> 
> tc qdisc del dev eth0 root
> 
> triggers :
 ...
> commit 79640a4ca695 (add additional lock to qdisc to increase
> throughput) forgot to initialize  noop_qdisc and noqueue_qdisc busylock 
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---

Applied.

^ permalink raw reply

* Re: [PATCH net-next] fib: introduce fib_alias_accessed() helper
From: David Miller @ 2010-10-21 10:11 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev
In-Reply-To: <1287648218.6871.18.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 21 Oct 2010 10:03:38 +0200

> Perf tools session at NFWS 2010 pointed out a false sharing on struct
> fib_alias that can be avoided pretty easily, if we set FA_S_ACCESSED bit
> only if needed (ie : not already set)
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>

Applied.

^ 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