Netdev List
 help / color / mirror / Atom feed
* [PATCH 4/4] ipg: fix Tx completion irq request
From: Francois Romieu @ 2008-01-10 23:38 UTC (permalink / raw)
  To: David Miller; +Cc: linux, jeff, Andrew Morton, netdev
In-Reply-To: <20080110233508.GA13315@electric-eye.fr.zoreil.com>

The current logic will only request an ack for the first pending
packet. No irq is triggered as soon as the CPU submits a few
packets a bit quickly.  Let's request an irq for every packet
instead.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
---
 drivers/net/ipg.c |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index b234b29..50f0c17 100644
--- a/drivers/net/ipg.c
+++ b/drivers/net/ipg.c
@@ -1934,10 +1934,7 @@ static int ipg_nic_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	 */
 	if (sp->tenmbpsmode)
 		txfd->tfc |= cpu_to_le64(IPG_TFC_TXINDICATE);
-	else if (!((sp->tx_current - sp->tx_dirty + 1) >
-	    IPG_FRAMESBETWEENTXDMACOMPLETES)) {
-		txfd->tfc |= cpu_to_le64(IPG_TFC_TXDMAINDICATE);
-	}
+	txfd->tfc |= cpu_to_le64(IPG_TFC_TXDMAINDICATE);
 	/* Based on compilation option, determine if FCS is to be
 	 * appended to transmit frame by IPG.
 	 */
-- 
1.5.3.3


^ permalink raw reply related
* Re: [NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache
From: Paul E. McKenney @ 2008-01-10 23:51 UTC (permalink / raw)
  To: Jarek Poplawski; +Cc: Eric Dumazet, Herbert Xu, davem, dipankar, netdev
In-Reply-To: <20080110231042.GA3199@ami.dom.local>

On Fri, Jan 11, 2008 at 12:10:42AM +0100, Jarek Poplawski wrote:
> Eric Dumazet wrote, On 01/09/2008 11:37 AM:
> ...
> > [NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache
> ...
> > diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> > index d337706..28484f3 100644
> > --- a/net/ipv4/route.c
> > +++ b/net/ipv4/route.c
> > @@ -283,12 +283,12 @@ static struct rtable *rt_cache_get_first(struct seq_file *seq)
> >  			break;
> >  		rcu_read_unlock_bh();
> >  	}
> > -	return r;
> > +	return rcu_dereference(r);
> >  }
> >  
> >  static struct rtable *rt_cache_get_next(struct seq_file *seq, struct rtable *r)
> >  {
> > -	struct rt_cache_iter_state *st = rcu_dereference(seq->private);
> > +	struct rt_cache_iter_state *st = seq->private;
> >  
> >  	r = r->u.dst.rt_next;
> >  	while (!r) {
> > @@ -298,7 +298,7 @@ static struct rtable *rt_cache_get_next(struct seq_file *seq, struct rtable *r)
> >  		rcu_read_lock_bh();
> >  		r = rt_hash_table[st->bucket].chain;
> >  	}
> > -	return r;
> > +	return rcu_dereference(r);
> >  }
> 
> It seems this optimization could've a side effect: if during such a
> loop updates are done, and r is seen !NULL during while() check, but
> NULL after rcu_dereference(), the listing/counting could stop too
> soon. So, IMHO, probably the first version of this patch is more
> reliable. (Or alternatively additional check is needed before return.)

Looks to me like "r" is a local variable (argument list), so there
should not be any possibility of it being changed by some other
task, right?

							Thanx, Paul

^ permalink raw reply
* [PATCH 2/4] ipg: plug Tx completion leak
From: Francois Romieu @ 2008-01-10 23:37 UTC (permalink / raw)
  To: David Miller; +Cc: linux, jeff, Andrew Morton, netdev
In-Reply-To: <20080110233508.GA13315@electric-eye.fr.zoreil.com>

The Tx skb release could not free more than one skb per call.
Add it to the fact that the xmit handler does not check for
a queue full condition and you have a recipe to leak quickly.

Let's release every pending Tx descriptor which has been given
back to the host CPU by the network controller. The xmit handler
suggests that it is done through the IPG_TFC_TFDDONE bit.

Remove the former "curr" computing: it does not produce anything
usable in its current form.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
---
 drivers/net/ipg.c |   19 +++++--------------
 1 files changed, 5 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index cd1650e..9752902 100644
--- a/drivers/net/ipg.c
+++ b/drivers/net/ipg.c
@@ -857,21 +857,14 @@ static void init_tfdlist(struct net_device *dev)
 static void ipg_nic_txfree(struct net_device *dev)
 {
 	struct ipg_nic_private *sp = netdev_priv(dev);
-	void __iomem *ioaddr = sp->ioaddr;
-	unsigned int curr;
-	u64 txd_map;
-	unsigned int released, pending;
-
-	txd_map = (u64)sp->txd_map;
-	curr = ipg_r32(TFD_LIST_PTR_0) -
-		do_div(txd_map, sizeof(struct ipg_tx)) - 1;
+	unsigned int released, pending, dirty;
 
 	IPG_DEBUG_MSG("_nic_txfree\n");
 
 	pending = sp->tx_current - sp->tx_dirty;
+	dirty = sp->tx_dirty % IPG_TFDLIST_LENGTH;
 
 	for (released = 0; released < pending; released++) {
-		unsigned int dirty = sp->tx_dirty % IPG_TFDLIST_LENGTH;
 		struct sk_buff *skb = sp->TxBuff[dirty];
 		struct ipg_tx *txfd = sp->txd + dirty;
 
@@ -882,11 +875,8 @@ static void ipg_nic_txfree(struct net_device *dev)
 		 * If the TFDDone bit is set, free the associated
 		 * buffer.
 		 */
-		if (dirty == curr)
-			break;
-
-		/* Setup TFDDONE for compatible issue. */
-		txfd->tfc |= cpu_to_le64(IPG_TFC_TFDDONE);
+		if (!(txfd->tfc & cpu_to_le64(IPG_TFC_TFDDONE)))
+                        break;
 
 		/* Free the transmit buffer. */
 		if (skb) {
@@ -898,6 +888,7 @@ static void ipg_nic_txfree(struct net_device *dev)
 
 			sp->TxBuff[dirty] = NULL;
 		}
+		dirty = (dirty + 1) % IPG_TFDLIST_LENGTH;
 	}
 
 	sp->tx_dirty += released;
-- 
1.5.3.3


^ permalink raw reply related
* [PATCH 0/4] Pull request for 'ipg-fixes' branch
From: Francois Romieu @ 2008-01-10 23:35 UTC (permalink / raw)
  To: David Miller; +Cc: linux, jeff, Andrew Morton, netdev

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

Please pull from branch 'ipg-fixes' in repository

git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git ipg-fixes

to get the changes below.

I have tested the driver with a PIV HT based motherboard. The network
controller is connected to a fast ethernet switch (yeah, I'm cheap).
A second host is performing two loop of scp in both direction for a
400Mb file. The files are sha1sumed after each scp. I have added a
'ping -q -f -l16' from the computer under test after some time.

After 35 copies from the computer under test and 28 copies to it
(the ping eats a bit):
             total       used       free     shared    buffers     cached
Mem:       1019040    1003860      15180          0      20556     936792
-/+ buffers/cache:      46512     972528
Swap:      2031608          0    2031608

Before:
             total       used       free     shared    buffers     cached
Mem:       1019040     572036     447004          0      14988     525924
-/+ buffers/cache:      31124     987916
Swap:      2031608          0    2031608

/proc/slabinfo before and after the test are attached.

The driver is still a POMS but it seems better now.

I will not be available to work further on this issue before sunday.
I'd appreciate being Cced though.

Distance from 'net-2.6/master' (27d1cba21fcc50c37eef5042c6be9fa7135e88fc)
-------------------------------------------------------------------------

286c83ce6e8263a5c4c55a57b4c1040800de0171
d42f3afc953f9c99ffe84667a3ecf0d3b69f3d64
358bf4b8e8cbde5d6411b219e93a61728c892685
a58cceed4464ba8ae94294184c15f43e92a5de89

Diffstat
--------

 drivers/net/ipg.c |   36 ++++++++++++------------------------
 1 files changed, 12 insertions(+), 24 deletions(-)

Shortlog
--------

Francois Romieu (4):
      ipg: balance locking in irq handler
      ipg: plug Tx completion leak
      ipg: fix queue stop condition in the xmit handler
      ipg: fix Tx completion irq request

Patch
-----

diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index dbd23bb..50f0c17 100644
--- a/drivers/net/ipg.c
+++ b/drivers/net/ipg.c
@@ -857,21 +857,14 @@ static void init_tfdlist(struct net_device *dev)
 static void ipg_nic_txfree(struct net_device *dev)
 {
 	struct ipg_nic_private *sp = netdev_priv(dev);
-	void __iomem *ioaddr = sp->ioaddr;
-	unsigned int curr;
-	u64 txd_map;
-	unsigned int released, pending;
-
-	txd_map = (u64)sp->txd_map;
-	curr = ipg_r32(TFD_LIST_PTR_0) -
-		do_div(txd_map, sizeof(struct ipg_tx)) - 1;
+	unsigned int released, pending, dirty;
 
 	IPG_DEBUG_MSG("_nic_txfree\n");
 
 	pending = sp->tx_current - sp->tx_dirty;
+	dirty = sp->tx_dirty % IPG_TFDLIST_LENGTH;
 
 	for (released = 0; released < pending; released++) {
-		unsigned int dirty = sp->tx_dirty % IPG_TFDLIST_LENGTH;
 		struct sk_buff *skb = sp->TxBuff[dirty];
 		struct ipg_tx *txfd = sp->txd + dirty;
 
@@ -882,11 +875,8 @@ static void ipg_nic_txfree(struct net_device *dev)
 		 * If the TFDDone bit is set, free the associated
 		 * buffer.
 		 */
-		if (dirty == curr)
-			break;
-
-		/* Setup TFDDONE for compatible issue. */
-		txfd->tfc |= cpu_to_le64(IPG_TFC_TFDDONE);
+		if (!(txfd->tfc & cpu_to_le64(IPG_TFC_TFDDONE)))
+                        break;
 
 		/* Free the transmit buffer. */
 		if (skb) {
@@ -898,6 +888,7 @@ static void ipg_nic_txfree(struct net_device *dev)
 
 			sp->TxBuff[dirty] = NULL;
 		}
+		dirty = (dirty + 1) % IPG_TFDLIST_LENGTH;
 	}
 
 	sp->tx_dirty += released;
@@ -1630,6 +1621,8 @@ static irqreturn_t ipg_interrupt_handler(int irq, void *dev_inst)
 #ifdef JUMBO_FRAME
 	ipg_nic_rxrestore(dev);
 #endif
+	spin_lock(&sp->lock);
+
 	/* Get interrupt source information, and acknowledge
 	 * some (i.e. TxDMAComplete, RxDMAComplete, RxEarly,
 	 * IntRequested, MacControlFrame, LinkEvent) interrupts
@@ -1647,9 +1640,7 @@ static irqreturn_t ipg_interrupt_handler(int irq, void *dev_inst)
 	handled = 1;
 
 	if (unlikely(!netif_running(dev)))
-		goto out;
-
-	spin_lock(&sp->lock);
+		goto out_unlock;
 
 	/* If RFDListEnd interrupt, restore all used RFDs. */
 	if (status & IPG_IS_RFD_LIST_END) {
@@ -1733,9 +1724,9 @@ out_enable:
 	ipg_w16(IPG_IE_TX_DMA_COMPLETE | IPG_IE_RX_DMA_COMPLETE |
 		IPG_IE_HOST_ERROR | IPG_IE_INT_REQUESTED | IPG_IE_TX_COMPLETE |
 		IPG_IE_LINK_EVENT | IPG_IE_UPDATE_STATS, INT_ENABLE);
-
+out_unlock:
 	spin_unlock(&sp->lock);
-out:
+
 	return IRQ_RETVAL(handled);
 }
 
@@ -1943,10 +1934,7 @@ static int ipg_nic_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	 */
 	if (sp->tenmbpsmode)
 		txfd->tfc |= cpu_to_le64(IPG_TFC_TXINDICATE);
-	else if (!((sp->tx_current - sp->tx_dirty + 1) >
-	    IPG_FRAMESBETWEENTXDMACOMPLETES)) {
-		txfd->tfc |= cpu_to_le64(IPG_TFC_TXDMAINDICATE);
-	}
+	txfd->tfc |= cpu_to_le64(IPG_TFC_TXDMAINDICATE);
 	/* Based on compilation option, determine if FCS is to be
 	 * appended to transmit frame by IPG.
 	 */
@@ -2003,7 +1991,7 @@ static int ipg_nic_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	ipg_w32(IPG_DC_TX_DMA_POLL_NOW, DMA_CTRL);
 
 	if (sp->tx_current == (sp->tx_dirty + IPG_TFDLIST_LENGTH))
-		netif_wake_queue(dev);
+		netif_stop_queue(dev);
 
 	spin_unlock_irqrestore(&sp->lock, flags);
 
-- 
Ueimor

[-- Attachment #2: slab.tgz --]
[-- Type: application/x-gzip, Size: 9304 bytes --]

^ permalink raw reply related
* [PATCH 1/4] ipg: balance locking in irq handler
From: Francois Romieu @ 2008-01-10 23:35 UTC (permalink / raw)
  To: David Miller; +Cc: linux, jeff, Andrew Morton, netdev
In-Reply-To: <20080110233508.GA13315@electric-eye.fr.zoreil.com>

Spotted-by: <linux@horizon.com>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
---
 drivers/net/ipg.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index dbd23bb..cd1650e 100644
--- a/drivers/net/ipg.c
+++ b/drivers/net/ipg.c
@@ -1630,6 +1630,8 @@ static irqreturn_t ipg_interrupt_handler(int irq, void *dev_inst)
 #ifdef JUMBO_FRAME
 	ipg_nic_rxrestore(dev);
 #endif
+	spin_lock(&sp->lock);
+
 	/* Get interrupt source information, and acknowledge
 	 * some (i.e. TxDMAComplete, RxDMAComplete, RxEarly,
 	 * IntRequested, MacControlFrame, LinkEvent) interrupts
@@ -1647,9 +1649,7 @@ static irqreturn_t ipg_interrupt_handler(int irq, void *dev_inst)
 	handled = 1;
 
 	if (unlikely(!netif_running(dev)))
-		goto out;
-
-	spin_lock(&sp->lock);
+		goto out_unlock;
 
 	/* If RFDListEnd interrupt, restore all used RFDs. */
 	if (status & IPG_IS_RFD_LIST_END) {
@@ -1733,9 +1733,9 @@ out_enable:
 	ipg_w16(IPG_IE_TX_DMA_COMPLETE | IPG_IE_RX_DMA_COMPLETE |
 		IPG_IE_HOST_ERROR | IPG_IE_INT_REQUESTED | IPG_IE_TX_COMPLETE |
 		IPG_IE_LINK_EVENT | IPG_IE_UPDATE_STATS, INT_ENABLE);
-
+out_unlock:
 	spin_unlock(&sp->lock);
-out:
+
 	return IRQ_RETVAL(handled);
 }
 
-- 
1.5.3.3


^ permalink raw reply related
* Re: [NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache
From: Jarek Poplawski @ 2008-01-10 23:10 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Herbert Xu, Paul E. McKenney, davem, dipankar, netdev
In-Reply-To: <20080109113727.50eae500.dada1@cosmosbay.com>

Eric Dumazet wrote, On 01/09/2008 11:37 AM:
...
> [NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache
...
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index d337706..28484f3 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -283,12 +283,12 @@ static struct rtable *rt_cache_get_first(struct seq_file *seq)
>  			break;
>  		rcu_read_unlock_bh();
>  	}
> -	return r;
> +	return rcu_dereference(r);
>  }
>  
>  static struct rtable *rt_cache_get_next(struct seq_file *seq, struct rtable *r)
>  {
> -	struct rt_cache_iter_state *st = rcu_dereference(seq->private);
> +	struct rt_cache_iter_state *st = seq->private;
>  
>  	r = r->u.dst.rt_next;
>  	while (!r) {
> @@ -298,7 +298,7 @@ static struct rtable *rt_cache_get_next(struct seq_file *seq, struct rtable *r)
>  		rcu_read_lock_bh();
>  		r = rt_hash_table[st->bucket].chain;
>  	}
> -	return r;
> +	return rcu_dereference(r);
>  }

It seems this optimization could've a side effect: if during such a
loop updates are done, and r is seen !NULL during while() check, but
NULL after rcu_dereference(), the listing/counting could stop too
soon. So, IMHO, probably the first version of this patch is more
reliable. (Or alternatively additional check is needed before return.)

Regards,
Jarek P.

^ permalink raw reply
* Re : Re : Re : Re : Re : Bonding : Monitoring of 4965 wireless card
From: patnel972-linux @ 2008-01-10 23:01 UTC (permalink / raw)
  To: Jay Vosburgh; +Cc: netdev

I try arp monitoring but it doesn't work! Test an ip, the interface must have an address, and the dhcpcd is launch by ifplugd if bond0 is linked ... so it goes around in circles.
So i return to miimon, and i figured out that bond detect when wlan0 is associated and set it active interface. But when i switch rf_kill it don't react. So i try to deassociate and magic it detect interface off!! I presume it is a bug of the wlan driver which not re-initialise the info on the wlan. So i made a small script in acpi to provide that behavior.



----- Message d'origine ----
De : Jay Vosburgh <fubar@us.ibm.com>
À : patnel972-linux@yahoo.fr
Cc : netdev@vger.kernel.org
Envoyé le : Jeudi, 10 Janvier 2008, 21h59mn 20s
Objet : Re: Re : Re : Re : Re : Bonding : Monitoring of 4965 wireless card 

patnel972-linux@yahoo.fr wrote:

>Yes it's what i'm looking for. I don't understand how to change the
 arp_ip_target with the gateway, arp_ip_target is a module option.

    If you're running a relatively recent bonding driver (version
3.0.0 or later), the arp_ip_targets can be changed on the fly via
 sysfs,
e.g.,

echo +10.0.0.1 > /sys/class/net/bond0/bonding/arp_ip_target
echo -20.0.0.1 > /sys/class/net/bond0/bonding/arp_ip_target

    You can check out Documentation/networking/bonding.txt (in the
kernel source code) for more details.

    -J

---
    -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com


>----- Message d'origine ----
>De : Jay Vosburgh <fubar@us.ibm.com>
>À : patnel972-linux@yahoo.fr
>Cc : netdev@vger.kernel.org
>Envoyé le : Jeudi, 10 Janvier 2008, 0h26mn 38s
>Objet : Re: Re : Re : Re : Bonding : Monitoring of 4965 wireless card 
>
>patnel972-linux@yahoo.fr wrote:
>
>>I mean that instead of arp test an ip in lan or else, i want it to
> test 127.0.0.1 but in order to do this it must go out and re-enter
 and
> then use wlan0 to go out.
>
>    In other words, what I think you're saying (and I'm not entirely
>sure here) is that you want probes to go to a remote node on the
>network, and back, without having to actually know the identity of the
>remote node (because, presumably, on a roaming type of wireless
>configuration, your gateway and whatnot can change from time to time).
>
>    Is that what you're looking for?
>
>    That isn't available now, but might be straightforward to plug
>into the address update system to keep the arp_ip_target up to date as
>the current gateway as the gateway changes.  I haven't looked into the
>details of doing that, but in theory it sounds straightforward.
>
>    -J
>
>---
>    -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
--
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





      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr

^ permalink raw reply
* Re: AF_UNIX MSG_PEEK bug?
From: Alan Cox @ 2008-01-10 22:36 UTC (permalink / raw)
  To: Brent Casavant; +Cc: Herbert Xu, penguin-kernel, netdev, davem, linux-kernel
In-Reply-To: <alpine.BSF.1.00.0801101554100.52456@pkunk.americas.sgi.com>

> and the parallel portions/comments in unix_dgram_recvmsg(),
> it looks like there's been a lot of uncertainty as to how
> file descriptor passing should be handled durning MSG_PEEK
> operations.  To quote:

The specs basically don't answer the question. What is critical is that
the behaviour does not change compared with older Linux releases.


^ permalink raw reply
* Re: AF_UNIX MSG_PEEK bug?
From: Brent Casavant @ 2008-01-10 22:35 UTC (permalink / raw)
  To: Herbert Xu; +Cc: penguin-kernel, netdev, davem, linux-kernel
In-Reply-To: <alpine.BSF.1.00.0801092031290.35527@pkunk.americas.sgi.com>

Here's what I think is a better patch.  Or maybe just simpler.

However, I'm still unsure what the effect of this patch on
file descriptor passing might be.  Reading the prior code,
and the parallel portions/comments in unix_dgram_recvmsg(),
it looks like there's been a lot of uncertainty as to how
file descriptor passing should be handled durning MSG_PEEK
operations.  To quote:

	/* It is questionable: on PEEK we could:
	   - do not return fds - good, but too simple 8)
	   - return fds, and do not return them on read (old strategy,
	     apparently wrong)
	   - clone fds (I chose it for now, it is the most universal
	     solution)

	   POSIX 1003.1g does not actually define this clearly
	   at all. POSIX 1003.1g doesn't define a lot of things
	   clearly however!
	*/

With this patch, passed file descriptors are ignored during MSG_PEEK.
This is essentially the first case in the comment above.  What I
can't seem to figure out is why this is incorrect.  I suspect there's
some history here that I can't find via Google, mailing list archives,
or revision logs.

So, that said, here's a cleaner patch.  It's still not ready for
application until the file descriptor passing is better understood.

Thanks,
Brent

diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 060bba4..6d6cdb4 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1750,6 +1750,8 @@ static int unix_stream_recvmsg(struct ki
 	int target;
 	int err = 0;
 	long timeo;
+	struct sk_buff *skb;
+	struct sk_buff_head peek_stack;
 
 	err = -EINVAL;
 	if (sk->sk_state != TCP_ESTABLISHED)
@@ -1759,6 +1761,9 @@ static int unix_stream_recvmsg(struct ki
 	if (flags&MSG_OOB)
 		goto out;
 
+	if (flags & MSG_PEEK)
+		skb_queue_head_init(&peek_stack);
+
 	target = sock_rcvlowat(sk, flags&MSG_WAITALL, size);
 	timeo = sock_rcvtimeo(sk, flags&MSG_DONTWAIT);
 
@@ -1778,7 +1783,6 @@ static int unix_stream_recvmsg(struct ki
 	do
 	{
 		int chunk;
-		struct sk_buff *skb;
 
 		unix_state_lock(sk);
 		skb = skb_dequeue(&sk->sk_receive_queue);
@@ -1864,19 +1868,14 @@ static int unix_stream_recvmsg(struct ki
 
 			if (siocb->scm->fp)
 				break;
-		}
-		else
-		{
-			/* It is questionable, see note in unix_dgram_recvmsg.
-			 */
-			if (UNIXCB(skb).fp)
-				siocb->scm->fp = scm_fp_dup(UNIXCB(skb).fp);
+		} else
+			__skb_queue_head(&peek_stack, skb);
+	} while (size);
 
-			/* put message back and return */
+	/* Push all peeked skbs back onto receive queue */
+	if (flags & MSG_PEEK)
+		while ((skb = __skb_dequeue(&peek_stack)))
 			skb_queue_head(&sk->sk_receive_queue, skb);
-			break;
-		}
-	} while (size);
 
 	mutex_unlock(&u->readlock);
 	scm_recv(sock, msg, siocb->scm, flags);

^ permalink raw reply related
* Re: [PATCH 2.6.23+] ingress classify to [nf]mark
From: jamal @ 2008-01-10 21:39 UTC (permalink / raw)
  To: mahatma; +Cc: netdev
In-Reply-To: <47866C69.3080904@bspu.unibel.by>


On Thu, 2008-10-01 at 17:05 -0200, Dzianis Kahanovich wrote:
> To "classid x:y" = "mark=mark&x|y" ("classid :y" = "-j MARK --set-mark y", etc).
> 
> --- linux-2.6.23-gentoo-r2/net/sched/Kconfig
> +++ linux-2.6.23-gentoo-r2.fixed/net/sched/Kconfig
> @@ -222,6 +222,16 @@
[..]
>   			skb->tc_index = TC_H_MIN(res.classid);
> +#ifdef CONFIG_NET_SCH_INGRESS_TC2MARK
> +			skb->mark = (skb->mark&(res.classid>>16))|TC_H_MIN(res.classid);
> +#endif
>   		default:


Please either use ipt action and netfilter fwmarker for this activity or
create a new action. 
If you choose the later (example because you want to dynamically compute
the mark), look at net/sched/act_simple.c to start from and i can help
you if you have any questions.
 
If you want to use ipt action, the syntax would be something like:

---
tc qdisc add dev XXX ingress
tc filter add dev XXX parent ffff: protocol ip prio 5 \
u32 blah bleh \
flowid 1:12 action ipt -j mark --set-mark 13 
-----

cheers,
jamal


^ permalink raw reply
* Please pull 'fixes-jgarzik' branch of wireless-2.6 (use this one)
From: John W. Linville @ 2008-01-10 21:30 UTC (permalink / raw)
  To: jeff-o2qLIJkoznsdnm+yROfE0A
  Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA

[2nd try -- turns-out the Mattis Nissler patch needed an extra tweak.
It will probably also cause build breakage when you rebase since
rt2x00lib_txdone(...) becomes rt2x00pci_txdone(rt2x00dev,...) in 2.6.25,
so FYI... :-)

This also includes another patch (the "4 byte boundary" one) which
is already in your upstream branch.  So, beware of that one too. :-)]

Jeff,

Three more fixes for 2.6.24.  The one from Mattias Nissler is already
in your upstream tree...FYI.

Let me know if there are problems!

Thanks,

John

---

Individual patches available here:

	http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/

---

The following changes since commit 3ce54450461bad18bbe1f9f5aa3ecd2f8e8d1235:
  Linus Torvalds (1):
        Linux 2.6.24-rc7

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-jgarzik

Ivo van Doorn (2):
      rt2x00: Corectly initialize rt2500usb MAC
      rt2x00: Put 802.11 data on 4 byte boundary

Mattias Nissler (1):
      rt2x00: Allow rt61 to catch up after a missing tx report

 drivers/net/wireless/rt2x00/rt2500usb.c |    2 +-
 drivers/net/wireless/rt2x00/rt2x00pci.c |   20 ++++++++++++++++----
 drivers/net/wireless/rt2x00/rt2x00usb.c |   17 +++++++++++++++--
 drivers/net/wireless/rt2x00/rt61pci.c   |   12 ++++++++++++
 4 files changed, 44 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index 50775f9..18b1f91 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -257,7 +257,7 @@ static const struct rt2x00debug rt2500usb_rt2x00debug = {
 static void rt2500usb_config_mac_addr(struct rt2x00_dev *rt2x00dev,
 				      __le32 *mac)
 {
-	rt2500usb_register_multiwrite(rt2x00dev, MAC_CSR2, &mac,
+	rt2500usb_register_multiwrite(rt2x00dev, MAC_CSR2, mac,
 				      (3 * sizeof(__le16)));
 }
 
diff --git a/drivers/net/wireless/rt2x00/rt2x00pci.c b/drivers/net/wireless/rt2x00/rt2x00pci.c
index 2780df0..6d5d9ab 100644
--- a/drivers/net/wireless/rt2x00/rt2x00pci.c
+++ b/drivers/net/wireless/rt2x00/rt2x00pci.c
@@ -124,7 +124,10 @@ void rt2x00pci_rxdone(struct rt2x00_dev *rt2x00dev)
 	struct data_entry *entry;
 	struct data_desc *rxd;
 	struct sk_buff *skb;
+	struct ieee80211_hdr *hdr;
 	struct rxdata_entry_desc desc;
+	int header_size;
+	int align;
 	u32 word;
 
 	while (1) {
@@ -138,17 +141,26 @@ void rt2x00pci_rxdone(struct rt2x00_dev *rt2x00dev)
 		memset(&desc, 0x00, sizeof(desc));
 		rt2x00dev->ops->lib->fill_rxdone(entry, &desc);
 
+		hdr = (struct ieee80211_hdr *)entry->data_addr;
+		header_size =
+		    ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_control));
+
+		/*
+		 * The data behind the ieee80211 header must be
+		 * aligned on a 4 byte boundary.
+		 */
+		align = NET_IP_ALIGN + (2 * (header_size % 4 == 0));
+
 		/*
 		 * Allocate the sk_buffer, initialize it and copy
 		 * all data into it.
 		 */
-		skb = dev_alloc_skb(desc.size + NET_IP_ALIGN);
+		skb = dev_alloc_skb(desc.size + align);
 		if (!skb)
 			return;
 
-		skb_reserve(skb, NET_IP_ALIGN);
-		skb_put(skb, desc.size);
-		memcpy(skb->data, entry->data_addr, desc.size);
+		skb_reserve(skb, align);
+		memcpy(skb_put(skb, desc.size), entry->data_addr, desc.size);
 
 		/*
 		 * Send the frame to rt2x00lib for further processing.
diff --git a/drivers/net/wireless/rt2x00/rt2x00usb.c b/drivers/net/wireless/rt2x00/rt2x00usb.c
index 1f5675d..ab4797e 100644
--- a/drivers/net/wireless/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/rt2x00/rt2x00usb.c
@@ -221,7 +221,9 @@ static void rt2x00usb_interrupt_rxdone(struct urb *urb)
 	struct data_ring *ring = entry->ring;
 	struct rt2x00_dev *rt2x00dev = ring->rt2x00dev;
 	struct sk_buff *skb;
+	struct ieee80211_hdr *hdr;
 	struct rxdata_entry_desc desc;
+	int header_size;
 	int frame_size;
 
 	if (!test_bit(DEVICE_ENABLED_RADIO, &rt2x00dev->flags) ||
@@ -253,9 +255,20 @@ static void rt2x00usb_interrupt_rxdone(struct urb *urb)
 	skb_put(skb, frame_size);
 
 	/*
-	 * Trim the skb_buffer to only contain the valid
-	 * frame data (so ignore the device's descriptor).
+	 * The data behind the ieee80211 header must be
+	 * aligned on a 4 byte boundary.
+	 * After that trim the entire buffer down to only
+	 * contain the valid frame data excluding the device
+	 * descriptor.
 	 */
+	hdr = (struct ieee80211_hdr *)entry->skb->data;
+	header_size =
+	    ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_control));
+
+	if (header_size % 4 == 0) {
+		skb_push(entry->skb, 2);
+		memmove(entry->skb->data, entry->skb->data + 2, skb->len - 2);
+	}
 	skb_trim(entry->skb, desc.size);
 
 	/*
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index 01dbef1..ecae968 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -1738,6 +1738,7 @@ static void rt61pci_txdone(struct rt2x00_dev *rt2x00dev)
 {
 	struct data_ring *ring;
 	struct data_entry *entry;
+	struct data_entry *entry_done;
 	struct data_desc *txd;
 	u32 word;
 	u32 reg;
@@ -1791,6 +1792,17 @@ static void rt61pci_txdone(struct rt2x00_dev *rt2x00dev)
 		    !rt2x00_get_field32(word, TXD_W0_VALID))
 			return;
 
+		entry_done = rt2x00_get_data_entry_done(ring);
+		while (entry != entry_done) {
+			/* Catch up. Just report any entries we missed as
+			 * failed. */
+			WARNING(rt2x00dev,
+				"TX status report missed for entry %p\n",
+				entry_done);
+			rt2x00lib_txdone(entry_done, TX_FAIL_OTHER, 0);
+			entry_done = rt2x00_get_data_entry_done(ring);
+		}
+
 		/*
 		 * Obtain the status about this packet.
 		 */
-- 
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org

^ permalink raw reply related
* Re: questions on NAPI processing latency and dropped network packets
From: Chris Friesen @ 2008-01-10 21:29 UTC (permalink / raw)
  To: James Chapman; +Cc: netdev, linux-kernel
In-Reply-To: <47866327.8090905@katalix.com>

James Chapman wrote:

> What's changed in your application? Any real-time threads in there?
> 
>>From the top output below, looks like SigtranServices is consuming all
> your CPU...

There are two cpus, and SigtranServices is multithreaded with many 
threads.  Most of these threads are affined to cpu0, a couple to cpu1. 
None of the threads are realtime.

Top is showing 37% idle on cpu0, and 6% idle on cpu1, so not all the cpu 
is being consumed.  However, I'm wondering if we're hitting bursty bits 
and we're just running out of time.

I'm going to try a system with MAX_SOFTIRQ_RESTART bumped up a bit, and 
also enable profiling.

Chris

^ permalink raw reply
* Re: [PATCH take2] Re: Nested VLAN causes recursive locking error
From: Jarek Poplawski @ 2008-01-10 21:33 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: Benny Amorsen, Chuck Ebbert, netdev
In-Reply-To: <20080110210816.GA3064@ami.dom.local>

On Thu, Jan 10, 2008 at 10:08:16PM +0100, Jarek Poplawski wrote:
...
> But still some 'quirks' are possible there: removing and adding
> devices 'properly' would often require resetting of many subclasses,

...Hmm, probably they are always removed from/with the children, then no
problem! (I know, I could've checked...)

Jarek P.

^ permalink raw reply
* RE: e1000 performance issue in 4 simultaneous links
From: Brandeburg, Jesse @ 2008-01-10 20:52 UTC (permalink / raw)
  To: Breno Leitao; +Cc: netdev, Brandeburg, Jesse
In-Reply-To: <1199981839.8931.35.camel@cafe>

Breno Leitao wrote:
> When I run netperf in just one interface, I get 940.95 * 10^6 bits/sec
> of transfer rate. If I run 4 netperf against 4 different interfaces, I
> get around 720 * 10^6 bits/sec.

This is actually a known issue that we have worked with your company
before on.  It comes down to your system's default behavior of round
robining interrupts (see cat /proc/interrupts while running the test)
combined with e1000's way of exiting / rescheduling NAPI.

The default round robin behavior of the interrupts on your system is the
root cause of this issue, and here is what happens:

4 interfaces start generating interrupts, if you're lucky the round
robin balancer has them all on different cpus.
As the e1000 driver goes into and out of polling mode, the round robin
balancer keeps moving the interrupt to the next cpu.
Eventually 2 or more driver instances end up on the same CPU, which
causes both driver instances to stay in NAPI polling mode, due to the
amount of work being done, and that there are always more than
"netdev->weight" packets to do for each instance.  This keeps *hardware*
interrupts for each interface *disabled*.
Staying in NAPI polling mode causes higher cpu utilization on that one
processor, which guarantees that when the hardware round robin balancer
moves any other network interrupt onto that CPU, it too will join the
NAPI polling mode chain.
So no matter how many processors you have, with this round robin style
of hardware interrupts, it guarantees you that if there is a lot of work
to do (more than weight) at each softirq, then, all network interfaces
will end up on the same cpu eventually (the busiest one)
Your performance becomes the same as if you had booted with maxcpus=1

I hope this explanation makes sense, but what it comes down to is that
combining hardware round robin balancing with NAPI is a BAD IDEA.  In
general the behavior of hardware round robin balancing is bad and I'm
sure it is causing all sorts of other performance issues that you may
not even be aware of.

I'm sure your problem will go away if you run e1000 in interrupt mode.
(use make CFLAGS_EXTRA=-DE1000_NO_NAPI)
 
> If I run the same test against 2 interfaces I get a 940 * 10^6
> bits/sec transfer rate also, and if I run it against 3 interfaces I
> get around 850 * 10^6 bits/sec performance.
> 
> I got this results using the upstream netdev-2.6 branch kernel plus
> David Miller's 7 NAPI patches set[1]. In the kernel 2.6.23.12 the
> result is a bit worse, and the the transfer rate was around 600 * 10^6
> bits/sec.

Thank you for testing the latest kernel.org kernel.

Hope this helps.

^ permalink raw reply
* Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
From: Andy Gospodarek @ 2008-01-10 21:03 UTC (permalink / raw)
  To: Jay Vosburgh
  Cc: Herbert Xu, Andy Gospodarek, Krzysztof Oledzki, netdev,
	Jeff Garzik, David Miller
In-Reply-To: <25832.1199998246@death>

On Thu, Jan 10, 2008 at 12:50:46PM -0800, Jay Vosburgh wrote:
> Herbert Xu <herbert@gondor.apana.org.au> wrote:
> 
> >On Thu, Jan 10, 2008 at 09:51:44AM -0500, Andy Gospodarek wrote:
> >>
> >> That wasn't the only purpose, Herbert.  Making sure that calls to
> >> dev_set_mac_address were called from process context was important at
> >> the time of the coding as well since at least the tg3 driver took locks
> >> that could not be taken reliably in soft-irq context.  Michael Chan
> >> fixed this here:
> >
> >Sure, but where do you call that function while holding the bond lock?
> 
> 	If I recall correctly, the problem was that tg3, et al, did
> things that might sleep, and bonding was calling from a timer context,
> which couldn't sleep.  It wasn't about the lock.
> 

Exactly, I was just about to post the same.

^ permalink raw reply
* Re: [PATCH take2] Re: Nested VLAN causes recursive locking error
From: Jarek Poplawski @ 2008-01-10 21:08 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: Benny Amorsen, Chuck Ebbert, netdev
In-Reply-To: <47863A4A.6070303@trash.net>

On Thu, Jan 10, 2008 at 04:31:22PM +0100, Patrick McHardy wrote:
...
> No, this seems fine, thanks. Even better would be a way to get
> the last lockdep subclass through lockdep somehow, but I couldn't
> find a clean way for this. So I've applied your patch and also
> fixed macvlan.

As a matter of fact this simplified version was done mainly to remove
this bad looking effect of a never decreased global. Of course, your
proposal with using parent's subclass + 1 would be better, if deeper
nestings are required: so, I could try to enhance this (probably with
such additional lockdep macro) after some hint.

But still some 'quirks' are possible there: removing and adding
devices 'properly' would often require resetting of many subclasses,
so quite a lot of activities if more devices. And probably not very
common if not requested until now...

Thanks,
Jarek P.

^ permalink raw reply
* Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
From: Herbert Xu @ 2008-01-10 21:05 UTC (permalink / raw)
  To: Andy Gospodarek
  Cc: Jay Vosburgh, Krzysztof Oledzki, netdev, Jeff Garzik,
	David Miller
In-Reply-To: <20080110210353.GI8728@gospo.usersys.redhat.com>

On Thu, Jan 10, 2008 at 04:03:53PM -0500, Andy Gospodarek wrote:
>
> > >Sure, but where do you call that function while holding the bond lock?
> > 
> > 	If I recall correctly, the problem was that tg3, et al, did
> > things that might sleep, and bonding was calling from a timer context,
> > which couldn't sleep.  It wasn't about the lock.
> 
> Exactly, I was just about to post the same.

In other words, changing read_lock on bond->lock to read_lock_bh doesn't
affect this one bit.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply
* Re: Re : Re : Re : Re : Bonding : Monitoring of 4965 wireless card
From: Jay Vosburgh @ 2008-01-10 20:59 UTC (permalink / raw)
  To: patnel972-linux; +Cc: netdev
In-Reply-To: <722263.85774.qm@web25703.mail.ukl.yahoo.com>

patnel972-linux@yahoo.fr wrote:

>Yes it's what i'm looking for. I don't understand how to change the arp_ip_target with the gateway, arp_ip_target is a module option.

	If you're running a relatively recent bonding driver (version
3.0.0 or later), the arp_ip_targets can be changed on the fly via sysfs,
e.g.,

echo +10.0.0.1 > /sys/class/net/bond0/bonding/arp_ip_target
echo -20.0.0.1 > /sys/class/net/bond0/bonding/arp_ip_target

	You can check out Documentation/networking/bonding.txt (in the
kernel source code) for more details.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com


>----- Message d'origine ----
>De : Jay Vosburgh <fubar@us.ibm.com>
>À : patnel972-linux@yahoo.fr
>Cc : netdev@vger.kernel.org
>Envoyé le : Jeudi, 10 Janvier 2008, 0h26mn 38s
>Objet : Re: Re : Re : Re : Bonding : Monitoring of 4965 wireless card 
>
>patnel972-linux@yahoo.fr wrote:
>
>>I mean that instead of arp test an ip in lan or else, i want it to
> test 127.0.0.1 but in order to do this it must go out and re-enter and
> then use wlan0 to go out.
>
>    In other words, what I think you're saying (and I'm not entirely
>sure here) is that you want probes to go to a remote node on the
>network, and back, without having to actually know the identity of the
>remote node (because, presumably, on a roaming type of wireless
>configuration, your gateway and whatnot can change from time to time).
>
>    Is that what you're looking for?
>
>    That isn't available now, but might be straightforward to plug
>into the address update system to keep the arp_ip_target up to date as
>the current gateway as the gateway changes.  I haven't looked into the
>details of doing that, but in theory it sounds straightforward.
>
>    -J
>
>---
>    -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

^ permalink raw reply
* Re: Please pull 'fixes-jgarzik' branch of wireless-2.6
From: John W. Linville @ 2008-01-10 20:57 UTC (permalink / raw)
  To: jeff-o2qLIJkoznsdnm+yROfE0A
  Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20080110194922.GF3109-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>

On Thu, Jan 10, 2008 at 02:49:22PM -0500, John W. Linville wrote:
> Jeff,
> 
> A couple more fixes for 2.6.24.  The one from Mattias Nissler is already
> in your upstream tree...FYI.
> 
> Let me know if there are problems!

Please disregard this request.  The 'upstream-jgarzik-2' request is still valid.

Thanks,

John

-- 
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org

^ permalink raw reply
* Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
From: Jay Vosburgh @ 2008-01-10 20:50 UTC (permalink / raw)
  To: Herbert Xu
  Cc: Andy Gospodarek, Krzysztof Oledzki, netdev, Jeff Garzik,
	David Miller
In-Reply-To: <20080110203604.GB16621@gondor.apana.org.au>

Herbert Xu <herbert@gondor.apana.org.au> wrote:

>On Thu, Jan 10, 2008 at 09:51:44AM -0500, Andy Gospodarek wrote:
>>
>> That wasn't the only purpose, Herbert.  Making sure that calls to
>> dev_set_mac_address were called from process context was important at
>> the time of the coding as well since at least the tg3 driver took locks
>> that could not be taken reliably in soft-irq context.  Michael Chan
>> fixed this here:
>
>Sure, but where do you call that function while holding the bond lock?

	If I recall correctly, the problem was that tg3, et al, did
things that might sleep, and bonding was calling from a timer context,
which couldn't sleep.  It wasn't about the lock.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

^ permalink raw reply
* Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
From: Jay Vosburgh @ 2008-01-10 20:45 UTC (permalink / raw)
  To: Andy Gospodarek
  Cc: Herbert Xu, Krzysztof Oledzki, netdev, Jeff Garzik, David Miller
In-Reply-To: <20080110145144.GH8728@gospo.usersys.redhat.com>

Andy Gospodarek <andy@greyhouse.net> wrote:
[...]
>That wasn't the only purpose, Herbert.  Making sure that calls to
>dev_set_mac_address were called from process context was important at
>the time of the coding as well since at least the tg3 driver took locks
>that could not be taken reliably in soft-irq context.  Michael Chan
>fixed this here:
>
>commit 986e0aeb9ae09127b401c3baa66f15b7a31f354c
>Author: Michael Chan <mchan@broadcom.com>
>Date:   Sat May 5 12:10:20 2007 -0700
>
>    [TG3]: Remove reset during MAC address changes.
>
>so if wasn't as much of an issue after that, but moving as much of the
>code to process context was important for that as well (hence the move
>to not continue to try to not use bh-locks everywhere).

	Well, not for tg3 perhaps, but other network device drivers do
the same thing (if memory serves, any USB ethernet adapter will have
issues there).  Also, I believe the netlink notifier callback,
rtnetlink_event, which every dev_set_whatever calls, does a
possibly-sleeping memory allocation (rtmsg_ifinfo -> nlmsg_new ->
alloc_skb(GFP_KERNEL)); so we don't really want to hold extra locks for
that, either.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

^ permalink raw reply
* Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
From: Herbert Xu @ 2008-01-10 20:36 UTC (permalink / raw)
  To: Andy Gospodarek
  Cc: Jay Vosburgh, Krzysztof Oledzki, netdev, Jeff Garzik,
	David Miller
In-Reply-To: <20080110145144.GH8728@gospo.usersys.redhat.com>

On Thu, Jan 10, 2008 at 09:51:44AM -0500, Andy Gospodarek wrote:
>
> That wasn't the only purpose, Herbert.  Making sure that calls to
> dev_set_mac_address were called from process context was important at
> the time of the coding as well since at least the tg3 driver took locks
> that could not be taken reliably in soft-irq context.  Michael Chan
> fixed this here:

Sure, but where do you call that function while holding the bond lock?

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply
* iproute2: make max rounds in ip {neigh,addr} flush configurable.
From: Andreas Henriksson @ 2008-01-10 20:33 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20080110195423.GA26373@scream.fatal.se>


On tor, 2008-01-10 at 20:54 +0100, Andreas Henriksson wrote:
> An additional patch will be provided in a followup mail (not available in
> Debian) that was created by request from Patrick McHardy. This one makes max
> rounds configurable (and 0 means try to infinity, so you can restore old
> behaviour).

In my opinion 10 tries should be enough for anyone, but here's the patch anyway.

This one is on top of the patches in the previous mail.


diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index ff9e318..232fd64 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -67,6 +67,7 @@ static void usage(void)
 	fprintf(stderr, "       ip addr del IFADDR dev STRING\n");
 	fprintf(stderr, "       ip addr {show|flush} [ dev STRING ] [ scope SCOPE-ID ]\n");
 	fprintf(stderr, "                            [ to PREFIX ] [ FLAG-LIST ] [ label PATTERN ]\n");
+	fprintf(stderr, "                            [ maxrounds N ]\n");
 	fprintf(stderr, "IFADDR := PREFIX | ADDR peer PREFIX\n");
 	fprintf(stderr, "          [ broadcast ADDR ] [ anycast ADDR ]\n");
 	fprintf(stderr, "          [ label STRING ] [ scope SCOPE-ID ]\n");
@@ -566,6 +567,7 @@ int ipaddr_list_or_flush(int argc, char **argv, int flush)
 	struct nlmsg_list *l, *n;
 	char *filter_dev = NULL;
 	int no_link = 0;
+	unsigned maxrounds = MAX_ROUNDS;
 
 	ipaddr_reset_filter(oneline);
 	filter.showqueue = 1;
@@ -630,6 +632,10 @@ int ipaddr_list_or_flush(int argc, char **argv, int flush)
 		} else if (strcmp(*argv, "label") == 0) {
 			NEXT_ARG();
 			filter.label = *argv;
+		} else if (strcmp(*argv, "maxrounds") == 0) {
+			NEXT_ARG();
+			if (get_unsigned(&maxrounds, *argv, 0))
+				invarg("maxrounds must be 0 (infinite) or higher", "maxrounds");
 		} else {
 			if (strcmp(*argv, "dev") == 0) {
 				NEXT_ARG();
@@ -669,7 +675,7 @@ int ipaddr_list_or_flush(int argc, char **argv, int flush)
 		filter.flushp = 0;
 		filter.flushe = sizeof(flushb);
 
-		while (round < MAX_ROUNDS) {
+		while (maxrounds == 0 || round < maxrounds) {
 			if (rtnl_wilddump_request(&rth, filter.family, RTM_GETADDR) < 0) {
 				perror("Cannot send dump request");
 				exit(1);
@@ -696,7 +702,10 @@ int ipaddr_list_or_flush(int argc, char **argv, int flush)
 				fflush(stdout);
 			}
 		}
-		fprintf(stderr, "*** Flush remains incomplete after %d rounds. ***\n", MAX_ROUNDS); fflush(stderr);
+		fprintf(stderr,
+			"*** Flush remains incomplete after %u rounds. ***\n",
+			maxrounds);
+		fflush(stderr);
 		return 1;
 	}
 
diff --git a/ip/ipneigh.c b/ip/ipneigh.c
index db684f5..61fac66 100644
--- a/ip/ipneigh.c
+++ b/ip/ipneigh.c
@@ -53,6 +53,7 @@ static void usage(void)
 		        "          [ nud { permanent | noarp | stale | reachable } ]\n"
 		        "          | proxy ADDR } [ dev DEV ]\n");
 	fprintf(stderr, "       ip neigh {show|flush} [ to PREFIX ] [ dev DEV ] [ nud STATE ]\n");
+	fprintf(stderr, "                             [ maxrounds N ]\n");
 	exit(-1);
 }
 
@@ -321,6 +322,7 @@ int do_show_or_flush(int argc, char **argv, int flush)
 {
 	char *filter_dev = NULL;
 	int state_given = 0;
+	unsigned maxrounds = MAX_ROUNDS;
 
 	ipneigh_reset_filter();
 
@@ -361,6 +363,10 @@ int do_show_or_flush(int argc, char **argv, int flush)
 			if (state == 0)
 				state = 0x100;
 			filter.state |= state;
+		} else if (strcmp(*argv, "maxrounds") == 0) {
+			NEXT_ARG();
+			if (get_unsigned(&maxrounds, *argv, 0))
+				invarg("maxrounds must be 0 (infinite) or higher", "maxrounds");
 		} else {
 			if (strcmp(*argv, "to") == 0) {
 				NEXT_ARG();
@@ -392,7 +398,7 @@ int do_show_or_flush(int argc, char **argv, int flush)
 		filter.flushe = sizeof(flushb);
 		filter.state &= ~NUD_FAILED;
 
-		while (round < MAX_ROUNDS) {
+		while (maxrounds == 0 || round < maxrounds) {
 			if (rtnl_wilddump_request(&rth, filter.family, RTM_GETNEIGH) < 0) {
 				perror("Cannot send dump request");
 				exit(1);
@@ -418,8 +424,10 @@ int do_show_or_flush(int argc, char **argv, int flush)
 				fflush(stdout);
 			}
 		}
-		printf("*** Flush not complete bailing out after %d rounds\n",
-			MAX_ROUNDS);
+		fprintf(stderr,
+			"*** Flush remains incomplete after %u rounds. ***\n",
+			maxrounds);
+		fflush(stderr);
 		return 1;
 	}
 






-- 
Regards,
Andreas Henriksson


^ permalink raw reply related
* Please pull 'upstream-jgarzik-2' branch of wireless-2.6
From: John W. Linville @ 2008-01-10 19:48 UTC (permalink / raw)
  To: jeff; +Cc: netdev, linux-wireless
In-Reply-To: <20080109032009.GC3048@tuxdriver.com>

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

Jeff,

This is additive on top of the pull request posted on Tuesday evening:

	http://marc.info/?l=linux-wireless&m=119985065704687&w=2

If you pull this one, you will get that one as well.

Please let me know if there are any problems!

Thanks,

John

---

Individual patches are available here:

	http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-jgarzik-2/

---

The following changes since commit deb27641a93290475f6c66b99d2fceabbc28d6fb:
  Michael Buesch (1):
        zd1211rw: fix alignment for QOS and WDS frames

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-jgarzik-2

John W. Linville (2):
      b43: finish removal of pio support
      iwlwifi: fix-up damage from rebase of namespace separation patches

Michael Buesch (3):
      b43: Add N-PHY register definitions
      b43: Fix PHY register routing
      b43: Remove the PHY spinlock

Pavel Roskin (1):
      hostap_cs: don't match revisions in presense of the MAC chip name

 drivers/net/wireless/b43/Makefile           |    1 +
 drivers/net/wireless/b43/b43.h              |   17 +-
 drivers/net/wireless/b43/debugfs.c          |    6 +-
 drivers/net/wireless/b43/lo.c               |   64 ++--
 drivers/net/wireless/b43/main.c             |    4 -
 drivers/net/wireless/b43/nphy.c             |   34 ++
 drivers/net/wireless/b43/nphy.h             |  706 +++++++++++++++++++++++++++
 drivers/net/wireless/b43/phy.c              |  235 +++++----
 drivers/net/wireless/b43/phy.h              |   57 +--
 drivers/net/wireless/b43/pio.c              |  652 -------------------------
 drivers/net/wireless/b43/pio.h              |  153 ------
 drivers/net/wireless/hostap/hostap_cs.c     |   15 +-
 drivers/net/wireless/iwlwifi/iwl3945-base.c |    9 +-
 drivers/net/wireless/iwlwifi/iwl4965-base.c |    9 +-
 14 files changed, 949 insertions(+), 1013 deletions(-)
 create mode 100644 drivers/net/wireless/b43/nphy.c
 create mode 100644 drivers/net/wireless/b43/nphy.h
 delete mode 100644 drivers/net/wireless/b43/pio.c
 delete mode 100644 drivers/net/wireless/b43/pio.h

Omnibus patch attached as upstream-jgarzik-2.patch.bz2
-- 
John W. Linville
linville@tuxdriver.com

[-- Attachment #2: upstream-jgarzik-2.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 21165 bytes --]

^ permalink raw reply
* Please pull 'fixes-jgarzik' branch of wireless-2.6
From: John W. Linville @ 2008-01-10 19:49 UTC (permalink / raw)
  To: jeff; +Cc: netdev, linux-wireless

Jeff,

A couple more fixes for 2.6.24.  The one from Mattias Nissler is already
in your upstream tree...FYI.

Let me know if there are problems!

Thanks,

John

---

Individual patches available here:

	http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/

---

The following changes since commit 3ce54450461bad18bbe1f9f5aa3ecd2f8e8d1235:
  Linus Torvalds (1):
        Linux 2.6.24-rc7

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-jgarzik

Ivo van Doorn (1):
      rt2x00: Corectly initialize rt2500usb MAC

Mattias Nissler (1):
      rt2x00: Allow rt61 to catch up after a missing tx report

 drivers/net/wireless/rt2x00/rt2500usb.c |    2 +-
 drivers/net/wireless/rt2x00/rt61pci.c   |   13 +++++++++++++
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index 50775f9..18b1f91 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -257,7 +257,7 @@ static const struct rt2x00debug rt2500usb_rt2x00debug = {
 static void rt2500usb_config_mac_addr(struct rt2x00_dev *rt2x00dev,
 				      __le32 *mac)
 {
-	rt2500usb_register_multiwrite(rt2x00dev, MAC_CSR2, &mac,
+	rt2500usb_register_multiwrite(rt2x00dev, MAC_CSR2, mac,
 				      (3 * sizeof(__le16)));
 }
 
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index 01dbef1..0d9436d 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -1738,6 +1738,7 @@ static void rt61pci_txdone(struct rt2x00_dev *rt2x00dev)
 {
 	struct data_ring *ring;
 	struct data_entry *entry;
+	struct data_entry *entry_done;
 	struct data_desc *txd;
 	u32 word;
 	u32 reg;
@@ -1791,6 +1792,18 @@ static void rt61pci_txdone(struct rt2x00_dev *rt2x00dev)
 		    !rt2x00_get_field32(word, TXD_W0_VALID))
 			return;
 
+		entry_done = rt2x00_get_data_entry_done(ring);
+		while (entry != entry_done) {
+			/* Catch up. Just report any entries we missed as
+			 * failed. */
+			WARNING(rt2x00dev,
+				"TX status report missed for entry %p\n",
+				entry_done);
+			rt2x00pci_txdone(rt2x00dev, entry_done, TX_FAIL_OTHER,
+					 0);
+			entry_done = rt2x00_get_data_entry_done(ring);
+		}
+
 		/*
 		 * Obtain the status about this packet.
 		 */
-- 
John W. Linville
linville@tuxdriver.com

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