date:20060928

On Wed, 2006-09-27 at 19:17 +0200, matthieu castet wrote:

> > 2304, I think, as that's
> > synonym sMaxMsduLng Integer = 2304; /* max octets in an MSDU */
> > 
> 
> Yes but if it is bigger the frame get framented at the 802.11 layer : in 
> theory we could put mtu (IP max packet size) a big as we want [1].

No, you're confusing MPDU and MSDU. Or I am :) Please try to read the
spec as well.

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

Re: tc related lockdep warning.

2006-09-28 Thread Jarek Poplawski

On Wed, Sep 27, 2006 at 02:07:04PM +0200, Patrick McHardy wrote:
> Dave Jones wrote:
> > With this patch, I get no lockdep warnings, but the machine locks up 
> > completely.
> > I hooked up a serial console, and found this..
> > 
> > 
> > u32 classifier
> > Performance counters on
> > input device check on 
> > Actions configured 
> > BUG: warning at net/sched/sch_htb.c:395/htb_safe_rb_erase()
> > 
> > Call Trace:
> >  [] show_trace+0xae/0x336
> >  [] dump_stack+0x15/0x17
> >  [] :sch_htb:htb_safe_rb_erase+0x3b/0x55
> 
> I found the reason for this, it was an unrelated bug. I've attached
> the latest version of the locking fixes and the fix for the HTB bug.

Congratulations! (But I think David Jones could have saved some brain
cycles applying fixes to the same version where the bug originated). 

...
> [NET_SCHED]: Fix fallout from dev->qdisc RCU change

Sorry again but I can't abstain from some doubts: 

...
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 14de297..4d891be 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1480,14 +1480,16 @@ #endif
>   if (q->enqueue) {
>   /* Grab device queue */
>   spin_lock(&dev->queue_lock);
> + q = dev->qdisc;

I don't get it. If it is some anti-race step according to
rcu rules it should be again:
q = rcu_dereference(dev->qdisc);

But I don't know which of the attached lockups would be
fixed by this. 
And by the way - a few lines above is:
rcu_read_lock_bh();
which according to the rules should be
rcu_read_lock();
(or call_rcu should be changed to call_rcu_bh).

> + if (q->enqueue) {
> + rc = q->enqueue(skb, q);
> + qdisc_run(dev);
> + spin_unlock(&dev->queue_lock);
>  
> - rc = q->enqueue(skb, q);
> -
> - qdisc_run(dev);
> -
> + rc = rc == NET_XMIT_BYPASS ? NET_XMIT_SUCCESS : rc;
> + goto out;
> + }
>   spin_unlock(&dev->queue_lock);
> - rc = rc == NET_XMIT_BYPASS ? NET_XMIT_SUCCESS : rc;
> - goto out;
>   }

By the way: rcu_read_unlock could be done here instead
at the very end. 

> @@ -504,32 +489,23 @@ #endif
>  
>  void qdisc_destroy(struct Qdisc *qdisc)
>  {
> - struct list_head cql = LIST_HEAD_INIT(cql);
> - struct Qdisc *cq, *q, *n;
> + struct Qdisc_ops  *ops = qdisc->ops;
>  
>   if (qdisc->flags & TCQ_F_BUILTIN ||
> - !atomic_dec_and_test(&qdisc->refcnt))
> + !atomic_dec_and_test(&qdisc->refcnt))
>   return;
...
> + list_del(&qdisc->list);
> +#ifdef CONFIG_NET_ESTIMATOR
> + gen_kill_estimator(&qdisc->bstats, &qdisc->rate_est);
> +#endif
> + if (ops->reset)
> + ops->reset(qdisc);
> + if (ops->destroy)
> + ops->destroy(qdisc);
>  
> + module_put(ops->owner);
> + dev_put(qdisc->dev);
>   call_rcu(&qdisc->q_rcu, __qdisc_destroy);

This qdisc way of RCU looks very "special" to me.
Is this really doing anything here? There is no
pointers switching, everything is deleted in place, 
refcnt checked, no clean read_lock_rcu (without
spin_locks) anywhere - in my once more not very
humble opinion it is only very advanced method of
time wasting. 

Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

e100 changes in git-netdev-all break reboot with netconsole

2006-09-28 Thread Andrew Morton


Enable netconsole-over-e100, and `reboot -f' hangs.  Disabling netconsole
prevents that from happening.

I assume what's happening is that the driver gets shut down and then
something tries to do a printk through it, and things hang.

For some reason sysrq-B still reboots the machine.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PROBLEM: kernel BUG at net/ipv6/ip6_output.c:718

2006-09-28 Thread cagri coltekin

On Thu, Sep 28, 2006 at 10:38:29AM +1000, Herbert Xu wrote:
> On Tue, Sep 26, 2006 at 01:21:22PM +0200, cagri coltekin wrote:
> >
> > --
> > [ 1395.890897] [ cut here ]
> > [ 1395.946093] kernel BUG at net/ipv6/ip6_output.c:940!
> 
> Could you go further back in the logs to see if there was a
> warning message? Either that or turn the WARN_ON into a BUG.

No. Bug is the first after boot:

[   34.042841] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   44.110469] eth0: no IPv6 routers present
[   80.968012] process `syslogd' is using obsolete setsockopt SO_BSDCOMPAT
[   81.452248] process `named' is using obsolete setsockopt SO_BSDCOMPAT
[  110.559560] process `lwresd' is using obsolete setsockopt SO_BSDCOMPAT
[  140.568831] process `named' is using obsolete setsockopt SO_BSDCOMPAT
[ 1395.890897] [ cut here ]
[ 1395.946093] kernel BUG at net/ipv6/ip6_output.c:940!
[ 1396.005441] invalid opcode:  [#1]

Cheers,
-- 
cagri
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tc related lockdep warning.

2006-09-28 Thread Jarek Poplawski

On Wed, Sep 27, 2006 at 04:53:04PM -0700, David Miller wrote:
> From: Patrick McHardy <[EMAIL PROTECTED]>
> Date: Wed, 27 Sep 2006 14:07:04 +0200
...
> Although the HTB bug is post-2.6.18, the other issue has been
> around for a long time.
> 
> Thus I'll need to submit the second patch to -stable, but I want
> it to cook in Linus's tree for a few days before I do that.

I don't know which version of act_police.c is planned for
2.6.18 -stable but I think it would be nice to fix the
original bug of this thread in 2.6.17 etc.
So I remind the proposal of read_lock_bh in tcf_police_lookup. 

Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] cfg80211 and nl80211

This patch adds cfg80211, a new configuration system for wireless hardware
as well as nl80211, the netlink-based userspace interface for it.

It currently features a bunch of configuration requests, support for
adding and removing virtual interfaces, the ability to inject packets and
more.

Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
---
This is the

  I think nl80211 is the future if I don't have to do it all by myself
-- johill

release. Please take the time to read at least the stuff before the patch.

There should be support for notifications, but that isn't currently done
as I'm still thinking about how to do it best.

It probably still requires the patches in
http://marc.theaimsgroup.com/?l=linux-netdev&m=115625436628696&w=2
and
http://marc.theaimsgroup.com/?l=linux-netdev&m=115625168405439&w=2

(the latter doesn't apply cleanly against wireless-dev, but you can
safely ignore the pieces that don't, at least for wireless testing :) )

It also requires the NLA_PUT_FLAG patch I did:
http://marc.theaimsgroup.com/?l=linux-netdev&m=115650333420169&w=2

(obviously, all those patches aren't required any more if they have been
applied, but I've been lazy and not tracked which are and which aren't)

I've removed the use of NLA_CUSTOM_CHECK as it isn't going to be applied,
but that currently results in a warning about an unused static method.

Also new in this iteration is a lot more fleshed-out internal cfg80211
interface. Also new is the following paragraph ;)

Here's an explanation of what cfg80211 and nl80211 are. cfg80211 is
the interface between the configuration backend and the driver or stack
("users" of cfg80211). cfg80211 provides a wiphy index whenever a user
registers with it, and allows things to be enumerated etc. nl80211 is
currently the only interface between cfg80211 and userspace and will
most likely remain the primary interface forever, but it is possible
to add (for example) a configfs interface between userspace and cfg80211,
users of cfg80211 can remain blissfully unaware of this. Also, WExt
backward compatibility will be implemented as an interface between
userspace and cfg80211.

cfg80211 does, however, use some constants defined in nl80211 in order
to not define them twice (and the other way around isn't quite good
because they need to be visible in userspace and cfg80211 is not).

I'm still not sure if there should be an explicit 'device supports
configuration parameters x, y and z' or if userspace should just
grab the current configuration (which is supposed to be complete then)
and see what's in it. Along the same lines, should unsupported
parameters result in the rejection, or should they be ignored?
(currently they are ignored)

As mentioned to Larry, I'd like to integrate his great work on
regulation and use nl80211 as the userspace interface for it. I do
have a couple of questions wrt. that:

 * why should there be configuration per device? The user can only
   be operating in one country at a time... I think that information
   should just be available inside cfg80211 in a global structure
   for use by drivers whenever they need it (with some accessor
   methods to ensure locked access).

 * as far as I understood the communication is the kernel telling
   the daemon all the information it has (which may be none, the
   country from a broadcasting AP or more info from that) and the
   daemon then builds up a correct set of limitations and gives that
   to the kernel, without the daemon the kernel limits to some minimal
   set that is (likely) legal everywhere. Correct?

 * Should the userspace daemon be allowed to unilaterally update the
   regulatory information if it learns something new (via the user)?
   Or why not even just publish the regulatory information APs might
   broadcast in the scan results, and let the userspace daemon pick
   that apart? Then the kernel need not ask for anything at all...

 * I seem to have read between the lines that the EEPROM data is
   pretty much useless. Is that generally true, or should the userspace
   daemon be told what it contains (somehow)?

 * Should the kernel perform some kind of validation on the regulatory
   data the daemon gives it as well?

Right now I'd think that it would make sense to just leave the whole
task to our userspace daemon, iow. nl80211 just provides a command
to update the kernel's knowledge about regulory and the daemon periodically
checks the scan results for country information, asks the user for
the country, or similar. If it's not running, the kernel simply starts
from a generic no-frills set.

--- wireless-dev.orig/net/Kconfig   2006-09-27 19:10:21.384088173 +0200
+++ wireless-dev/net/Kconfig2006-09-27 19:14:44.214088173 +0200
@@ -250,6 +250,9 @@ source "net/ieee80211/Kconfig"
 config WIRELESS_EXT
bool
 
+config CFG80211
+   tristate
+
 endif   # if NET
 endmenu # Networking
 
--- wireless-dev.orig/net/Makefile  2006-09-27 19:10:21.414088173 +0200
+++ wireless-dev/net/Mak

Re the default linux tcp algorithm being changed from bic to cubic.

2006-09-28 Thread Douglas Leith

Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Steve,

I think we're all conscious of the fact that recent history contains 
quite a number of proposals for changes to tcp's congestion control 
algorithm for high bandwidth-delay product paths that on closer 
inspection have proved problematic in one way or another.   It seems to 
be a hard problem to solve, so maybe that's fair enough and hopefully 
we'll end up with a workable solution soon.

Where I'm coming from here though is that bic was made the linux default 
a year or so ago at a time when there were essentially no tests 
available on its performance other than the infocom paper by Injong. 
Subsequent tests have since highlighted a bunch of issues with bic.  To 
my knowledge, we're currently in a similar situation with cubic as we 
were with bic back then i.e. essentially no independent tests 
investigating its behaviour.

Of course I know Injong has posted some test results, but these are 
hardly independent as he's the author of both bic and cubic.  Have there 
perhaps been private tests carried out (e.g. by osdl) ?  If so, would it 
be possible to make them public ?  If not, well that would be good to 
know too.

Doug

Hamilton Institute
www.hamilton.ie



--- Original Message 
Subject: [TCP]: make cubic the default
Date: Tue, 26 Sep 2006 00:59:56 GMT
From: Linux Kernel Mailing List 
To: git-commits-head@vger.kernel.org

commit 597811ec167fa01c926a0957a91d9e39baa30e64
tree 24e6ce26a4464d21993f2cd17dbdb9aec13360ab
parent 3d2573f7ebe507e372a23cdd3c8b03305d6e90aa
author Stephen Hemminger <[EMAIL PROTECTED]> 1159153983 -0700
committer David S. Miller <[EMAIL PROTECTED]> 1159153983 -0700

[TCP]: make cubic the default

Change default congestion control used from BIC to the newer CUBIC
which it the successor to BIC but has better properties over long delay
links.

Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>

  net/ipv4/Kconfig |   12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 1bbc368..30af4a4 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -455,7 +455,7 @@ menuconfig TCP_CONG_ADVANCED
  modules.

  Nearly all users can safely say no here, and a safe default
- selection will be made (BIC-TCP with new Reno as a fallback).
+ selection will be made (CUBIC with new Reno as a fallback).

  If unsure, say N.

@@ -463,7 +463,7 @@ if TCP_CONG_ADVANCED

  config TCP_CONG_BIC
tristate "Binary Increase Congestion (BIC) control"
-   default y
+   default m
---help---
BIC-TCP is a sender-side only change that ensures a linear RTT
fairness under large windows while offering both scalability and
@@ -477,7 +477,7 @@ config TCP_CONG_BIC

  config TCP_CONG_CUBIC
tristate "CUBIC TCP"
-   default m
+   default y
---help---
This is version 2.0 of BIC-TCP which uses a cubic growth function
among other techniques.
@@ -574,7 +574,7 @@ config TCP_CONG_VENO

  choice
prompt "Default TCP congestion control"
-   default DEFAULT_BIC
+   default DEFAULT_CUBIC
help
  Select the TCP congestion control that will be used by default
  for all connections.
@@ -601,7 +601,7 @@ endchoice

  endif

-config TCP_CONG_BIC
+config TCP_CONG_CUBIC
tristate
depends on !TCP_CONG_ADVANCED
default y
@@ -614,7 +614,7 @@ config DEFAULT_TCP_CONG
default "vegas" if DEFAULT_VEGAS
default "westwood" if DEFAULT_WESTWOOD
default "reno" if DEFAULT_RENO
-   default "bic"
+   default "cubic"

  source "net/ipv4/ipvs/Kconfig"

-
To unsubscribe from this list: send the line "unsubscribe
git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcm43xx-softmac: fix warning from ignoring returned value from pci_enable_device

2006-09-28 Thread Ian McDonald


On 9/28/06, Larry Finger <[EMAIL PROTECTED]> wrote:

Linus's tree now has a configuration option that prints a warning whenever
the returned value of any routine is ignored. This patch fixes the only such
warning for bcm43xx.


Can you tell me how to make this check please so I can check my code
in the kernel? I could look it up but obviously you can tell me
quickly :-)

Regards,

Ian
--
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] bonding: lockdep annotation

2006-09-28 Thread Peter Zijlstra


=
[ INFO: possible recursive locking detected ]
2.6.17-1.2600.fc6 #1
-
ifconfig/2411 is trying to acquire lock:
 (&dev->_xmit_lock){-...}, at: [] dev_mc_add+0x45/0x15f

but task is already holding lock:
 (&dev->_xmit_lock){-...}, at: [] dev_mc_add+0x45/0x15f

other info that might help us debug this:
3 locks held by ifconfig/2411:
 #0:  (rtnl_mutex){--..}, at: [] mutex_lock+0x2a/0x2e
 #1:  (&dev->_xmit_lock){-...}, at: [] dev_mc_add+0x45/0x15f
 #2:  (&bond->lock){-.-+}, at: [] 
bond_set_multicast_list+0x2c/0x26a [bonding]

stack backtrace:

Call Trace:
 [] show_trace+0xae/0x319
 [] dump_stack+0x15/0x17
 [] __lock_acquire+0x135/0xa64
 [] lock_acquire+0x4b/0x69
 [] _spin_lock_bh+0x2a/0x36
 [] dev_mc_add+0x45/0x15f
 [] :bonding:bond_set_multicast_list+0x138/0x26a
 [] __dev_mc_upload+0x22/0x24
 [] dev_mc_add+0x11a/0x15f
 [] igmp_group_added+0x55/0x10f
 [] ip_mc_inc_group+0x1d6/0x21a
 [] ip_mc_up+0x46/0x61
 [] inetdev_init+0x11c/0x136
 [] devinet_ioctl+0x3eb/0x5e9
 [] inet_ioctl+0x71/0x8f
 [] sock_ioctl+0x1e8/0x20a
 [] do_ioctl+0x2a/0x77
 [] vfs_ioctl+0x25a/0x277
 [] sys_ioctl+0x5f/0x82
 [] system_call+0x7e/0x83

The bonding driver nests other drivers, give the bonding driver its own
lock class.

Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 0fb5f65..ebbf002 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4692,6 +4692,8 @@ static int bond_check_params(struct bond
return 0;
 }
 
+static struct lock_class_key bonding_netdev_xmit_lock_key;
+
 /* Create a new bond based on the specified name and bonding parameters.
  * Caller must NOT hold rtnl_lock; we need to release it here before we
  * set up our sysfs entries.
@@ -4727,6 +4729,9 @@ int bond_create(char *name, struct bond_
if (res < 0) {
goto out_bond;
}
+
+   lockdep_set_class(&bond_dev->_xmit_lock, &bonding_netdev_xmit_lock_key);
+
if (newbond)
*newbond = bond_dev->priv;
 


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

[PATCH] tcp-lp: prevent chance for oops

2006-09-28 Thread Wong Edison


This patch fix the chance for tcp_lp_remote_hz_estimator return 0, if
0 < rhz < 64. It also make sure the flag LP_VALID_RHZ is set
correctly.

Signed-off-by: Wong Hoi Sing Edison <[EMAIL PROTECTED]>

---

diff -urpN linux-2.6.18/net/ipv4/tcp_lp.c linux/net/ipv4/tcp_lp.c
--- linux-2.6.18/net/ipv4/tcp_lp.c  2006-09-20 11:42:06.0 +0800
+++ linux/net/ipv4/tcp_lp.c 2006-09-28 18:30:17.0 +0800
@@ -32,7 +32,7 @@
 * SourceForge project page:
 *   http://tcp-lp-mod.sourceforge.net/
 *
- * Version: $Id: tcp_lp.c,v 1.24 2006/09/05 20:22:53 hswong3i Exp $
+ * Version: $Id: tcp_lp.c,v 1.25 2006/09/22 20:50:27 hswong3i Exp $
 */

#include 
@@ -165,7 +165,7 @@ static u32 tcp_lp_remote_hz_estimator(st

 out:
/* record time for successful remote HZ calc */
-   if (rhz > 0)
+   if ((rhz >> 6) > 0)
lp->flag |= LP_VALID_RHZ;
else
lp->flag &= ~LP_VALID_RHZ;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2.6.18] AT91RM9200 Ethernet update

2006-09-28 Thread Andrew Victor

This patch contains a few updates to the AT91RM9200 Ethernet driver.

The changes are:
1. Remove the global 'at91_dev' variable.
2. The global 'check_timer' moved into the private data structure.
3. Rather use dev_alloc_skb() instead of alloc_skb().
4. It is not necessary to adjust skb->len manually.
5. The I/O base-address and IRQ are no longer hard-coded, but are passed
via platform_device resources.


Signed-off-by: Andrew Victor <[EMAIL PROTECTED]>



diff -urN linux-2.6.18.orig/drivers/net/arm/at91_ether.c 
linux-2.6.18/drivers/net/arm/at91_ether.c
--- linux-2.6.18.orig/drivers/net/arm/at91_ether.c  Thu Sep 28 12:12:10 2006
+++ linux-2.6.18/drivers/net/arm/at91_ether.c   Thu Sep 28 12:21:40 2006
@@ -41,9 +41,6 @@
 #define DRV_NAME   "at91_ether"
 #define DRV_VERSION"1.0"
 
-static struct net_device *at91_dev;
-
-static struct timer_list check_timer;
 #define LINK_POLL_INTERVAL (HZ)
 
 /* . */
@@ -252,8 +249,8 @@
 * PHY doesn't have an IRQ pin (RTL8201, DP83847, AC101L),
 * or board does not have it connected.
 */
-   check_timer.expires = jiffies + LINK_POLL_INTERVAL;
-   add_timer(&check_timer);
+   lp->check_timer.expires = jiffies + LINK_POLL_INTERVAL;
+   add_timer(&lp->check_timer);
return;
}
 
@@ -300,7 +297,7 @@
 
irq_number = lp->board_data.phy_irq_pin;
if (!irq_number) {
-   del_timer_sync(&check_timer);
+   del_timer_sync(&lp->check_timer);
return;
}
 
@@ -362,13 +359,14 @@
 static void at91ether_check_link(unsigned long dev_id)
 {
struct net_device *dev = (struct net_device *) dev_id;
+   struct at91_private *lp = (struct at91_private *) dev->priv;
 
enable_mdi();
update_linkspeed(dev, 1);
disable_mdi();
 
-   check_timer.expires = jiffies + LINK_POLL_INTERVAL;
-   add_timer(&check_timer);
+   lp->check_timer.expires = jiffies + LINK_POLL_INTERVAL;
+   add_timer(&lp->check_timer);
 }
 
 /* . ADDRESS MANAGEMENT  */
@@ -857,14 +855,13 @@
while (dlist->descriptors[lp->rxBuffIndex].addr & EMAC_DESC_DONE) {
p_recv = dlist->recv_buf[lp->rxBuffIndex];
pktlen = dlist->descriptors[lp->rxBuffIndex].size & 0x7ff;  
/* Length of frame including FCS */
-   skb = alloc_skb(pktlen + 2, GFP_ATOMIC);
+   skb = dev_alloc_skb(pktlen + 2);
if (skb != NULL) {
skb_reserve(skb, 2);
memcpy(skb_put(skb, pktlen), p_recv, pktlen);
 
skb->dev = dev;
skb->protocol = eth_type_trans(skb, dev);
-   skb->len = pktlen;
dev->last_rx = jiffies;
lp->stats.rx_bytes += pktlen;
netif_rx(skb);
@@ -937,17 +934,22 @@
struct net_device *dev;
struct at91_private *lp;
unsigned int val;
-   int res;
-
-   if (at91_dev)   /* already initialized */
-   return 0;
+   struct resource *res;
+   int ret;
 
dev = alloc_etherdev(sizeof(struct at91_private));
if (!dev)
return -ENOMEM;
 
-   dev->base_addr = AT91_VA_BASE_EMAC;
-   dev->irq = AT91RM9200_ID_EMAC;
+   /* Get I/O base address and IRQ */
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res) {
+   free_netdev(dev);
+   return -ENODEV;
+   }
+   dev->base_addr = res->start;
+   dev->irq = platform_get_irq(pdev, 0);
+
SET_MODULE_OWNER(dev);
 
/* Install the interrupt handler */
@@ -1017,14 +1019,13 @@
lp->phy_address = phy_address;  /* MDI address of PHY */
 
/* Register the network interface */
-   res = register_netdev(dev);
-   if (res) {
+   ret = register_netdev(dev);
+   if (ret) {
free_irq(dev->irq, dev);
free_netdev(dev);
dma_free_coherent(NULL, sizeof(struct recv_desc_bufs), 
lp->dlist, (dma_addr_t)lp->dlist_phys);
-   return res;
+   return ret;
}
-   at91_dev = dev;
 
/* Determine current link speed */
spin_lock_irq(&lp->lock);
@@ -1036,9 +1037,9 @@
 
/* If board has no PHY IRQ, use a timer to poll the PHY */
if (!lp->board_data.phy_irq_pin) {
-   init_timer(&check_timer);
-   check_timer.data = (unsigned long)dev;
-   check_timer.function = at91ether_check_link;
+   init_timer(&lp->check_timer);
+   lp->check_timer.data = (unsigned long)dev;
+   lp->check_timer.function = at91ether_check_link;
}
 
/* Display ethernet banner */
@@

Re: [PATCH 2/7] d80211: add support for SIOCSIWRATE and SIOCGIWRATE

2006-09-28 Thread Jiri Benc

On Thu, 21 Sep 2006 09:59:39 -0700, mabbas wrote:
> I can not see how does it break per-STA TX rate limit, especially 
> PRISM2_HOSTAPD_SET_RATE_SETS almost doing the same thing. I am not saying
> the patch is correct I just want to know how to fix it to get it in.

As Jouni wrote, it's not useful to change the per-radio rate table. You
want to limit the rates you are using to communicate with the current AP
while not limiting other virtual interfaces. (Imagine you have the card
that is capable to associate to two APs at the same time. You don't want to
limit rates for both APs with SIOCSIWRATE.)

To do that I think the following is needed:

1. Add 'allowed_rates' field to struct sta_info. It defaults to 0x.
(Or perhaps call it 'disabled_rates' and make it default to 0.)

2. The SIOCSIWRATE handler: If the interface is not in a STA mode, return
-EOPNOTSUPP. Otherwise, modify the allowed_rates field of the sta entry
belonging to the current AP.

3. Bitmask sta->curr_rates with sta->allowed_rates (or
~sta->disabled_rates) in various places (ieee80211_ioctl_add_sta,
ieee80211_rx_mgmt_assoc_resp, ieee80211_rx_bss_info; please check for other
places).

In IBSS and AP mode setting this (per-STA, of course, which is not
supported by WE, btw.) can be useful as well but it can be done later.

 Jiri

-- 
Jiri Benc
SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mii-tool gigabit support.

2006-09-28 Thread Maciej W. Rozycki

On Wed, 27 Sep 2006, Auke Kok wrote:

> > Older equipment, which may still be in use here and there, allowed
> > full-duplex operation, but no auto-negotiation.  The duplex setting was
> > either fixed or selectable in a system-specific manner.  In such a case you
> > certainly want your modern other end to be forced to full-duplex, but still
> > let it detect the link speed, so that you do not have to do reconfiguration
> > whenever you move a link between a 10base-T and a 100base-Tx port.
> 
> in this case the new addition to ethtool will not help as it only changes the
> modes that the NIC will advertise. In this specific case you will need to turn
> of advertising/autonegotiation and force a speed/duplex pair anyway.

 My whole point is to keep the speed negotiation enabled.  If you force a 
given speed and the partner only supports a different one, you will get no 
link.

> Advertising all half-duplex modes to a partner that does not do
> autonegotiation is (by spec I think) an unsupported configuration (i.e.
> undetermined behaviour).

 Yes, but more reasonable PHYs will autosense the link speed if allowed 
to, even if the partner is not capable of negotiating.  It is useful, so 
why should we limit people so that they cannot do it?

 And as I wrote, it is not half-duplex operation that is problematic as it 
is the default if the partner does not negotiate anyway.

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

Re: tc related lockdep warning.

2006-09-28 Thread Patrick McHardy

[My mail provider is down, so responding "manually"]

Jarek Poplawski wrote:
> > [NET_SCHED]: Fix fallout from dev->qdisc RCU change
>
> Sorry again but I can't abstain from some doubts:
>
> ...
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 14de297..4d891be 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -1480,14 +1480,16 @@ #endif
> > if (q->enqueue) {
> > /* Grab device queue */
> > spin_lock(&dev->queue_lock);
> > +   q = dev->qdisc;
>
> I don't get it. If it is some anti-race step according to
> rcu rules it should be again:
> q = rcu_dereference(dev->qdisc);

At this point RCU protection is not needed anymore since we
have the lock. We simply want to avoid taking the lock for
devices that don't have a real qdisc attached (like loopback).
Thats what the test for q->enqueue is there for. RCU is only
needed to avoid races between testing q->enqueue and freeing
of the qdisc.

> But I don't know which of the attached lockups would be
> fixed by this.

None - the repeated check is needed because deconstruction
of the qdisc tree now happens immediately instead of in the
RCU callback, so stale data can't be tolerated.

> And by the way - a few lines above is:
> rcu_read_lock_bh();
> which according to the rules should be
> rcu_read_lock();
> (or call_rcu should be changed to call_rcu_bh).

Read up on how it got there or simply look at the comment directly
above it:

/* Disable soft irqs for various locks below. Also
 * stops preemption for RCU.
 */

> > @@ -504,32 +489,23 @@ #endif
> >
> >  void qdisc_destroy(struct Qdisc *qdisc)
> >  {
> > -   struct list_head cql = LIST_HEAD_INIT(cql);
> > -   struct Qdisc *cq, *q, *n;
> > +   struct Qdisc_ops  *ops = qdisc->ops;
> >
> > if (qdisc->flags & TCQ_F_BUILTIN ||
> > -   !atomic_dec_and_test(&qdisc->refcnt))
> > +   !atomic_dec_and_test(&qdisc->refcnt))
> > return;
> ...
> > +   list_del(&qdisc->list);
> > +#ifdef CONFIG_NET_ESTIMATOR
> > +   gen_kill_estimator(&qdisc->bstats, &qdisc->rate_est);
> > +#endif
> > +   if (ops->reset)
> > +   ops->reset(qdisc);
> > +   if (ops->destroy)
> > +   ops->destroy(qdisc);
> >
> > +   module_put(ops->owner);
> > +   dev_put(qdisc->dev);
> > call_rcu(&qdisc->q_rcu, __qdisc_destroy);
>
>
> This qdisc way of RCU looks very "special" to me.
> Is this really doing anything here? There is no
> pointers switching, everything is deleted in place,
> refcnt checked, no clean read_lock_rcu (without
> spin_locks) anywhere - in my once more not very
> humble opinion it is only very advanced method of
> time wasting.

You don't seem to understand what is done here at all and
additionally haven't even read any of the comments explaining
what this is for. You are wasting time.

As I already explained, RCU is only needed for one thing,
and for nothing more: to make sure the q->enqueue check
in net/core/dev.c doesn't reference freed memory.
Therefore just the final free is done in the RCU callback.
We could also have used synchronize_net(), but it doesn't
really matter.

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

Re: simplify microsecond rtt sampling

2006-09-28 Thread John Heffner


Here is a corrected patch.


Signed-off-by: John Heffner <[EMAIL PROTECTED]>

-static u32 tcp_usrtt(const struct sk_buff *skb)
+static u32 tcp_usrtt(struct timeval *tv)
 {
-   struct timeval tv, now;
+   struct timeval now;
 
do_gettimeofday(&now);
-   skb_get_timestamp(skb, &tv);
-   return (now.tv_sec - tv.tv_sec) * 100 + (now.tv_usec - tv.tv_usec);
+   return (now.tv_sec - tv->tv_sec) * 100 + (now.tv_usec - 
tv->tv_usec);
 }
 
 /* Remove acknowledged frames from the retransmission queue. */
@@ -2249,6 +2248,7 @@ static int tcp_clean_rtx_queue(struct so
u32 pkts_acked = 0;
void (*rtt_sample)(struct sock *sk, u32 usrtt)
= icsk->icsk_ca_ops->rtt_sample;
+   struct timeval tv;
 
while ((skb = skb_peek(&sk->sk_write_queue)) &&
   skb != sk->sk_send_head) {
@@ -2297,8 +2297,7 @@ static int tcp_clean_rtx_queue(struct so
seq_rtt = -1;
} else if (seq_rtt < 0) {
seq_rtt = now - scb->when;
-   if (rtt_sample)
-   (*rtt_sample)(sk, tcp_usrtt(skb));
+   skb_get_timestamp(skb, &tv);
}
if (sacked & TCPCB_SACKED_ACKED)
tp->sacked_out -= tcp_skb_pcount(skb);
@@ -2311,8 +2310,7 @@ static int tcp_clean_rtx_queue(struct so
}
} else if (seq_rtt < 0) {
seq_rtt = now - scb->when;
-   if (rtt_sample)
-   (*rtt_sample)(sk, tcp_usrtt(skb));
+   skb_get_timestamp(skb, &tv);
}
tcp_dec_pcount_approx(&tp->fackets_out, skb);
tcp_packets_out_dec(tp, skb);
@@ -2324,6 +2322,8 @@ static int tcp_clean_rtx_queue(struct so
if (acked&FLAG_ACKED) {
tcp_ack_update_rtt(sk, acked, seq_rtt);
tcp_ack_packets_out(sk, tp);
+   if (rtt_sample && !(acked & FLAG_RETRANS_DATA_ACKED))
+   (*rtt_sample)(sk, tcp_usrtt(&tv));
 
if (icsk->icsk_ca_ops->pkts_acked)
icsk->icsk_ca_ops->pkts_acked(sk, pkts_acked);

[PATCH 2.6.19-rc1] ehea firmware interface changes (hvcall interface)

2006-09-28 Thread Jan-Bernd Themann

Hi Jeff,

this eHEA patch covers required changes related to Anton's new hvcall interface.

Thanks,
Jan-Bernd

Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---

diff --git a/drivers/net/ehea/ehea_phyp.c b/drivers/net/ehea/ehea_phyp.c
index 4a85aca..0b51a8c 100644
--- a/drivers/net/ehea/ehea_phyp.c
+++ b/drivers/net/ehea/ehea_phyp.c
@@ -44,71 +44,99 @@ #define H_ALL_RES_TYPE_EQ3
 #define H_ALL_RES_TYPE_MR5
 #define H_ALL_RES_TYPE_MW6
 
-static long ehea_hcall_9arg_9ret(unsigned long opcode,
-unsigned long arg1, unsigned long arg2,
-unsigned long arg3, unsigned long arg4,
-unsigned long arg5, unsigned long arg6,
-unsigned long arg7, unsigned long arg8,
-unsigned long arg9, unsigned long *out1,
-unsigned long *out2,unsigned long *out3,
-unsigned long *out4,unsigned long *out5,
-unsigned long *out6,unsigned long *out7,
-unsigned long *out8,unsigned long *out9)
+static long ehea_plpar_hcall_norets(unsigned long opcode,
+   unsigned long arg1,
+   unsigned long arg2,
+   unsigned long arg3,
+   unsigned long arg4,
+   unsigned long arg5,
+   unsigned long arg6,
+   unsigned long arg7)
 {
-   long hret;
+   long ret;
int i, sleep_msecs;
 
for (i = 0; i < 5; i++) {
-   hret = plpar_hcall_9arg_9ret(opcode,arg1, arg2, arg3, arg4,
-arg5, arg6, arg7, arg8, arg9, out1,
-out2, out3, out4, out5, out6, out7,
-out8, out9);
-   if (H_IS_LONG_BUSY(hret)) {
-   sleep_msecs = get_longbusy_msecs(hret);
+   ret = plpar_hcall_norets(opcode, arg1, arg2, arg3, arg4,
+arg5, arg6, arg7);
+
+   if (H_IS_LONG_BUSY(ret)) {
+   sleep_msecs = get_longbusy_msecs(ret);
msleep_interruptible(sleep_msecs);
continue;
}
 
-   if (hret < H_SUCCESS)
-   ehea_error("op=%lx hret=%lx "
-  "i1=%lx i2=%lx i3=%lx i4=%lx i5=%lx i6=%lx "
-  "i7=%lx i8=%lx i9=%lx "
-  "o1=%lx o2=%lx o3=%lx o4=%lx o5=%lx o6=%lx "
-  "o7=%lx o8=%lx o9=%lx",
-  opcode, hret, arg1, arg2, arg3, arg4, arg5,
-  arg6, arg7, arg8, arg9, *out1, *out2, *out3,
-  *out4, *out5, *out6, *out7, *out8, *out9);
-   return hret;
+   if (ret < H_SUCCESS)
+   ehea_error("opcode=%lx ret=%lx"
+  " arg1=%lx arg2=%lx arg3=%lx arg4=%lx"
+  " arg5=%lx arg6=%lx arg7=%lx ",
+  opcode, ret,
+  arg1, arg2, arg3, arg4, arg5,
+  arg6, arg7);
+
+   return ret;
}
+
return H_BUSY;
 }
 
-u64 ehea_h_query_ehea_qp(const u64 adapter_handle, const u8 qp_category,
-const u64 qp_handle, const u64 sel_mask, void *cb_addr)
+static long ehea_plpar_hcall9(unsigned long opcode,
+ unsigned long *outs, /* array of 9 outputs */
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long arg9)
 {
-   u64 dummy;
+   long ret;
+   int i, sleep_msecs;
 
-   if u64)cb_addr) & (PAGE_SIZE - 1)) != 0) {
-   ehea_error("not on pageboundary");
-   return H_PARAMETER;
+   for (i = 0; i < 5; i++) {
+   ret = plpar_hcall9(opcode, outs,
+  arg1, arg2, arg3, arg4, arg5,
+  arg6, arg7, arg8, arg9);
+
+   if (H_IS_LONG_BUSY(ret)) {
+   sleep_msecs = get_longbusy_msecs(ret);
+   msleep_interruptible(sleep_msecs);
+   continue;
+   }
+
+   if (r

[PATCH 2.6.19-rc1] ehea bug fix (port state notification, default queue sizes)

2006-09-28 Thread Jan-Bernd Themann

Hi Jeff,

this patch includes a bug fix for the port state notification
and fixes the default queue sizes.

Thanks,
Jan-Bernd

Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
 drivers/net/ehea/ehea.h  |   13 +++--
 drivers/net/ehea/ehea_main.c |6 +++---
 2 files changed, 10 insertions(+), 9 deletions(-)


diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 23b451a..b40724f 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@ #include 
 #include 
 
 #define DRV_NAME   "ehea"
-#define DRV_VERSION"EHEA_0028"
+#define DRV_VERSION"EHEA_0034"
 
 #define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
@@ -50,6 +50,7 @@ #define EHEA_MAX_ENTRIES_RQ3 16383
 #define EHEA_MAX_ENTRIES_SQ  32767
 #define EHEA_MIN_ENTRIES_QP  127
 
+#define EHEA_SMALL_QUEUES
 #define EHEA_NUM_TX_QP 1
 
 #ifdef EHEA_SMALL_QUEUES
@@ -59,11 +60,11 @@ #define EHEA_DEF_ENTRIES_RQ14095
 #define EHEA_DEF_ENTRIES_RQ21023
 #define EHEA_DEF_ENTRIES_RQ31023
 #else
-#define EHEA_MAX_CQE_COUNT 32000
-#define EHEA_DEF_ENTRIES_SQ16000
-#define EHEA_DEF_ENTRIES_RQ1   32080
-#define EHEA_DEF_ENTRIES_RQ24020
-#define EHEA_DEF_ENTRIES_RQ34020
+#define EHEA_MAX_CQE_COUNT  4080
+#define EHEA_DEF_ENTRIES_SQ 4080
+#define EHEA_DEF_ENTRIES_RQ18160
+#define EHEA_DEF_ENTRIES_RQ22040
+#define EHEA_DEF_ENTRIES_RQ32040
 #endif
 
 #define EHEA_MAX_ENTRIES_EQ 20
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 263d1c5..0edb2f8 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -769,7 +769,7 @@ static void ehea_parse_eqe(struct ehea_a
if (EHEA_BMASK_GET(NEQE_PORT_UP, eqe)) {
if (!netif_carrier_ok(port->netdev)) {
ret = ehea_sense_port_attr(
-   adapter->port[portnum]);
+   port);
if (ret) {
ehea_error("failed resensing port "
   "attributes");
@@ -821,7 +821,7 @@ static void ehea_parse_eqe(struct ehea_a
netif_stop_queue(port->netdev);
break;
default:
-   ehea_error("unknown event code %x", ec);
+   ehea_error("unknown event code %x, eqe=0x%lX", ec, eqe);
break;
}
 }
@@ -1845,7 +1845,7 @@ static int ehea_start_xmit(struct sk_buf
 
if (netif_msg_tx_queued(port)) {
ehea_info("post swqe on QP %d", pr->qp->init_attr.qp_nr);
-   ehea_dump(swqe, sizeof(*swqe), "swqe");
+   ehea_dump(swqe, 512, "swqe");
}
 
ehea_post_swqe(pr->qp, swqe);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ACRYPTO] New asynchronous crypto layer (acrypto) release.

2006-09-28 Thread Evgeniy Polyakov

Hello.

I'm pleased to announce asynchronous crypto layer (acrypto) [1] release 
for 2.6.18 kernel tree. Acrypto allows to handle crypto requests 
asynchronously in hardware.

Combined patchset includes:
 * acrypto core
 * IPsec ESP4 port to acrypto
 * dm-crypt port to acrypto
 * OCF to acrypto bridge

Acrypto supports following crypto providers:
 * SW crypto provider
 * HIFN 795x adapters
 * VIA nehemiah CPU
 * SuperCrypt CE99C003B
 * devices supported by OCF

With this release of combined patchset for 2.6.18 I drop feature
extensions for 2.6.16 and 2.6.17 trees and move them into maintenance
state.

Combined patchset [190k] and drivers for various acrypto providers can 
be found on project's homepage.

1. Acrypto homepage.
http://tservice.net.ru/~s0mbre/old/?section=projects&item=acrypto

Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>

-- 
Evgeniy Polyakov


-- 
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Resend][RFC/PATCH] fix deadlock on high loads in bond_alb_monitor()

2006-09-28 Thread Karsten Keil

In bond_alb_monitor the bond->curr_slave_lock write lock is taken
and then dev_set_promiscuity maybe called which can take some time,
depending on the network HW. If a network IRQ for this card come in
the softirq handler maybe try to deliver more packets which end up in
a request to the read lock of bond->curr_slave_lock -> deadlock.
This issue was found by a test lab during network stress tests, this patch
disable the softirq handler for this case and solved the issue.

Signed-off-by: Karsten Keil <[EMAIL PROTECTED]>


---

 drivers/net/bonding/bond_alb.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

921ada40bf96d7dc9c4258821af3d4616fb3cbae
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index e83bc82..3292316 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -1433,7 +1433,7 @@ void bond_alb_monitor(struct bonding *bo
 * write lock to protect from other code that also
 * sets the promiscuity.
 */
-   write_lock(&bond->curr_slave_lock);
+   write_lock_bh(&bond->curr_slave_lock);
 
if (bond_info->primary_is_promisc &&
(++bond_info->rlb_promisc_timeout_counter >= 
RLB_PROMISC_TIMEOUT)) {
@@ -1448,7 +1448,7 @@ void bond_alb_monitor(struct bonding *bo
bond_info->primary_is_promisc = 0;
}
 
-   write_unlock(&bond->curr_slave_lock);
+   write_unlock_bh(&bond->curr_slave_lock);
 
if (bond_info->rlb_rebalance) {
bond_info->rlb_rebalance = 0;


-- 
Karsten Keil
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: simplify microsecond rtt sampling

2006-09-28 Thread John Heffner


Sigh.  Here's one that's not corrupted.  And for the record:


This changes the microsecond RTT sampling so that samples are taken in 
the same way that RTT samples are taken for the RTO calculator: on the 
last segment acknowledged, and only when the segment hasn't been 
retransmitted.



Signed-off-by: John Heffner <[EMAIL PROTECTED]>
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index b5521a9..d0f6bd6 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2228,13 +2228,12 @@ static int tcp_tso_acked(struct sock *sk
return acked;
 }
 
-static u32 tcp_usrtt(const struct sk_buff *skb)
+static u32 tcp_usrtt(struct timeval *tv)
 {
-   struct timeval tv, now;
+   struct timeval now;
 
do_gettimeofday(&now);
-   skb_get_timestamp(skb, &tv);
-   return (now.tv_sec - tv.tv_sec) * 100 + (now.tv_usec - tv.tv_usec);
+   return (now.tv_sec - tv->tv_sec) * 100 + (now.tv_usec - 
tv->tv_usec);
 }
 
 /* Remove acknowledged frames from the retransmission queue. */
@@ -2249,6 +2248,7 @@ static int tcp_clean_rtx_queue(struct so
u32 pkts_acked = 0;
void (*rtt_sample)(struct sock *sk, u32 usrtt)
= icsk->icsk_ca_ops->rtt_sample;
+   struct timeval tv;
 
while ((skb = skb_peek(&sk->sk_write_queue)) &&
   skb != sk->sk_send_head) {
@@ -2297,8 +2297,7 @@ static int tcp_clean_rtx_queue(struct so
seq_rtt = -1;
} else if (seq_rtt < 0) {
seq_rtt = now - scb->when;
-   if (rtt_sample)
-   (*rtt_sample)(sk, tcp_usrtt(skb));
+   skb_get_timestamp(skb, &tv);
}
if (sacked & TCPCB_SACKED_ACKED)
tp->sacked_out -= tcp_skb_pcount(skb);
@@ -2311,8 +2310,7 @@ static int tcp_clean_rtx_queue(struct so
}
} else if (seq_rtt < 0) {
seq_rtt = now - scb->when;
-   if (rtt_sample)
-   (*rtt_sample)(sk, tcp_usrtt(skb));
+   skb_get_timestamp(skb, &tv);
}
tcp_dec_pcount_approx(&tp->fackets_out, skb);
tcp_packets_out_dec(tp, skb);
@@ -2324,6 +2322,8 @@ static int tcp_clean_rtx_queue(struct so
if (acked&FLAG_ACKED) {
tcp_ack_update_rtt(sk, acked, seq_rtt);
tcp_ack_packets_out(sk, tp);
+   if (rtt_sample && !(acked & FLAG_RETRANS_DATA_ACKED))
+   (*rtt_sample)(sk, tcp_usrtt(&tv));
 
if (icsk->icsk_ca_ops->pkts_acked)
icsk->icsk_ca_ops->pkts_acked(sk, pkts_acked);

Re: [PATCH] softmac: Fix WX and association related races

On Thursday 28 September 2006 06:09, Larry Finger wrote:
> Michael Buesch wrote:
> > On Wednesday 27 September 2006 18:18, Larry Finger wrote:
> >> Michael Buesch wrote:
> >>> This fixes some race conditions in the WirelessExtension
> >>> handling and association handling code.
> >>>
> >>> Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
> >>>
> >>> ---
> >> This patch doesn't apply.
> > 
> > Oh, linville merged stuff on the 25th. That's the day I updated
> > my tree to do this patch. But seems like I did it just before
> > the merge.
> > Who could suspect that linville merges something. :D
> > *me runs away*
> > 
> > Anyway. Here's an updated patch.
> 
> NACK this version. It applied correctly, but introduced a new problem. My 
> device occasionally gets 
> deauthentication messages from my AP.Preciously, it would do a scan or two, 
> and then reauthenticate. 
> After your patch was applied, it never stops scanning.

Oh, well... It's impossible to completely fix softmac race issues.
I am _not_ going to rewrite huge parts of softmac to get locking
working. If you want this to be fixed, please hack up a solution by
yourself. I'm really not going to do more work on softmac. This
has various reasons. 1) I cannot reproduce all these bugs I'm hunting
2) Time is spent better at d80211 or other projects.

But to debug the problem:
Why do you get deauth messages? Broken AP?
I'd say that it's _correct_ behaviour to stop working
after getting a deauth ;). wpa_supplicant is responsible to re-auth.
Why doesn't it re-auth? Or does it do and it just doesn't work as
expected?

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/1] atl1: New driver, Attansic L1 Gigabit Ethernet

2006-09-28 Thread Jay Cliburn

On Thu, Sep 28, 2006 at 08:59:12AM +0200, Francois Romieu wrote:
> Jay Cliburn <[EMAIL PROTECTED]> :
> > Apologies:  I neglected to cc netdev on the initial message.
> 
> No patch here (netdev, l-k subscribed).
> 
> Can you publish the patch somewhere ?

At 200ish kbytes, the patch was apparently too large for the lists.  The
version I sent to the lists may be found at:

ftp://hogchain.net/pub/linux/m2v/attansic/kernel_driver/obsolete/20060927_full_atl1.patch.gz

You will note that it's in a directory called "obsolete."  That's
because it is undergoing significant rework based on shemminger's
comments and other considerations.

A new version will be posted in the upcoming days.

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

Re: tc related lockdep warning.

2006-09-28 Thread Jarek Poplawski

On Thu, Sep 28, 2006 at 02:17:51PM +0200, Patrick McHardy wrote:
> [My mail provider is down, so responding "manually"]
> 
> Jarek Poplawski wrote:
> > > [NET_SCHED]: Fix fallout from dev->qdisc RCU change
> >
> > Sorry again but I can't abstain from some doubts:
> >
> > ...
> > > diff --git a/net/core/dev.c b/net/core/dev.c
> > > index 14de297..4d891be 100644
> > > --- a/net/core/dev.c
> > > +++ b/net/core/dev.c
> > > @@ -1480,14 +1480,16 @@ #endif
> > >   if (q->enqueue) {
> > >   /* Grab device queue */
> > >   spin_lock(&dev->queue_lock);
> > > + q = dev->qdisc;
> >
> > I don't get it. If it is some anti-race step according to
> > rcu rules it should be again:
> > q = rcu_dereference(dev->qdisc);
> 
> At this point RCU protection is not needed anymore since we
> have the lock. We simply want to avoid taking the lock for
> devices that don't have a real qdisc attached (like loopback).
> Thats what the test for q->enqueue is there for. RCU is only
> needed to avoid races between testing q->enqueue and freeing
> of the qdisc.

But in Documentation/RCU/whatisRCU.txt I see this:

/*
 * Return the value of field "a" of the current gbl_foo
 * structure.  Use rcu_read_lock() and rcu_read_unlock()
 * to ensure that the structure does not get deleted out
 * from under us, and use rcu_dereference() to ensure that
 * we see the initialized version of the structure (important
 * for DEC Alpha and for people reading the code).
 */
int foo_get_a(void)
{
int retval;

rcu_read_lock();
retval = rcu_dereference(gbl_foo)->a;
rcu_read_unlock();
return retval;
}

 
> > But I don't know which of the attached lockups would be
> > fixed by this.
> 
> None - the repeated check is needed because deconstruction
> of the qdisc tree now happens immediately instead of in the
> RCU callback, so stale data can't be tolerated.
> 
> > And by the way - a few lines above is:
> > rcu_read_lock_bh();
> > which according to the rules should be
> > rcu_read_lock();
> > (or call_rcu should be changed to call_rcu_bh).
> 
> Read up on how it got there or simply look at the comment directly
> above it:
> 
> /* Disable soft irqs for various locks below. Also
>  * stops preemption for RCU.
>  */
> 

I've read it. And also this from include/linux/rcupdate.h:

/**
 * rcu_read_lock_bh - mark the beginning of a softirq-only RCU critical section
 *
 * This is equivalent of rcu_read_lock(), but to be used when updates
 * are being done using call_rcu_bh(). Since call_rcu_bh() callbacks
 * consider completion of a softirq handler to be a quiescent state,
 * a process in RCU read-side critical section must be protected by
 * disabling softirqs. Read-side critical sections in interrupt context
 * can use just rcu_read_lock().
 *
 */
#define rcu_read_lock_bh() \


> > > @@ -504,32 +489,23 @@ #endif
> > >
> > >  void qdisc_destroy(struct Qdisc *qdisc)
> > >  {
> > > - struct list_head cql = LIST_HEAD_INIT(cql);
> > > - struct Qdisc *cq, *q, *n;
> > > + struct Qdisc_ops  *ops = qdisc->ops;
> > >
> > >   if (qdisc->flags & TCQ_F_BUILTIN ||
> > > - !atomic_dec_and_test(&qdisc->refcnt))
> > > + !atomic_dec_and_test(&qdisc->refcnt))
> > >   return;
> > ...
> > > + list_del(&qdisc->list);
> > > +#ifdef CONFIG_NET_ESTIMATOR
> > > + gen_kill_estimator(&qdisc->bstats, &qdisc->rate_est);
> > > +#endif
> > > + if (ops->reset)
> > > + ops->reset(qdisc);
> > > + if (ops->destroy)
> > > + ops->destroy(qdisc);
> > >
> > > + module_put(ops->owner);
> > > + dev_put(qdisc->dev);
> > >   call_rcu(&qdisc->q_rcu, __qdisc_destroy);
> >
> >
> > This qdisc way of RCU looks very "special" to me.
> > Is this really doing anything here? There is no
> > pointers switching, everything is deleted in place,
> > refcnt checked, no clean read_lock_rcu (without
> > spin_locks) anywhere - in my once more not very
> > humble opinion it is only very advanced method of
> > time wasting.
> 
> You don't seem to understand what is done here at all and
> additionally haven't even read any of the comments explaining
> what this is for. You are wasting time.

I've only written my personal opinion and a word "special"
could suggest it is hard to comprehend for me. I didn't
intend to offend anybody so I'm very sorry.  
 
> As I already explained, RCU is only needed for one thing,
> and for nothing more: to make sure the q->enqueue check
> in net/core/dev.c doesn't reference freed memory.
> Therefore just the final free is done in the RCU callback.
> We could also have used synchronize_net(), but it doesn't
> really matter.

Probably my problem is I didn't see anything like that
in docs. Anyway thank you very much for explanation.

Jarek P.  

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
Mo

[Patch] check dev_alloc_skb() return value in s2io.c

2006-09-28 Thread Eric Sesterhenn

hi,

coverity spotted two dev_alloc_skb() calls,
where we use the return value without checking it
for NULL. This patch simply adds the check, including
the debug message that is used in all other dev_alloc_skb()
calls.

Signed-off-by: Eric Sesterhenn <[EMAIL PROTECTED]>

--- linux-2.6.18-git8/drivers/net/s2io.c.orig   2006-09-28 01:25:36.0 
+0200
+++ linux-2.6.18-git8/drivers/net/s2io.c2006-09-28 01:26:32.0 
+0200
@@ -5989,6 +5989,12 @@ static int set_rxd_buffer_pointer(nic_t 
((RxD3_t*)rxdp)->Buffer1_ptr = *temp1;
} else {
*skb = dev_alloc_skb(size);
+   if (!*skb) {
+   DBG_PRINT(ERR_DBG, "%s: dev_alloc_skb \
+   failed\n ", dev->name);
+   return -ENOMEM;
+   }
+
((RxD3_t*)rxdp)->Buffer2_ptr = *temp2 =
pci_map_single(sp->pdev, (*skb)->data,
   dev->mtu + 4,
@@ -6011,6 +6017,11 @@ static int set_rxd_buffer_pointer(nic_t 
((RxD3_t*)rxdp)->Buffer2_ptr = *temp2;
} else {
*skb = dev_alloc_skb(size);
+   if (!*skb) {
+   DBG_PRINT(ERR_DBG, "%s: dev_alloc_skb \
+   failed\n ", dev->name);
+   return -ENOMEM;
+   }
 
((RxD3_t*)rxdp)->Buffer0_ptr = *temp0 =
pci_map_single(sp->pdev, ba->ba_0, BUF0_LEN,


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

Re: [PATCH] softmac: Fix WX and association related races

2006-09-28 Thread Dan Williams

On Thu, 2006-09-28 at 14:55 +0200, Michael Buesch wrote:
> On Thursday 28 September 2006 06:09, Larry Finger wrote:
> > Michael Buesch wrote:
> > > On Wednesday 27 September 2006 18:18, Larry Finger wrote:
> > >> Michael Buesch wrote:
> > >>> This fixes some race conditions in the WirelessExtension
> > >>> handling and association handling code.
> > >>>
> > >>> Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
> > >>>
> > >>> ---
> > >> This patch doesn't apply.
> > > 
> > > Oh, linville merged stuff on the 25th. That's the day I updated
> > > my tree to do this patch. But seems like I did it just before
> > > the merge.
> > > Who could suspect that linville merges something. :D
> > > *me runs away*
> > > 
> > > Anyway. Here's an updated patch.
> > 
> > NACK this version. It applied correctly, but introduced a new problem. My 
> > device occasionally gets 
> > deauthentication messages from my AP.Preciously, it would do a scan or two, 
> > and then reauthenticate. 
> > After your patch was applied, it never stops scanning.
> 
> Oh, well... It's impossible to completely fix softmac race issues.
> I am _not_ going to rewrite huge parts of softmac to get locking
> working. If you want this to be fixed, please hack up a solution by
> yourself. I'm really not going to do more work on softmac. This
> has various reasons. 1) I cannot reproduce all these bugs I'm hunting
> 2) Time is spent better at d80211 or other projects.
> 
> But to debug the problem:
> Why do you get deauth messages? Broken AP?
> I'd say that it's _correct_ behaviour to stop working
> after getting a deauth ;). wpa_supplicant is responsible to re-auth.

I'd buy that argument.  When the driver gets the deauth message,
shouldn't it be sending an IWAP 00:00:00:00:00:00 wireless event to
userspace?  That would cause a tool like wpa_supplicant (or NM) to
attempt reauth/reassoc anyway, based on their own policy.

"Stations may send Disassociation or Deauthentication frames in response
to traffic when the sender has not properly joined the network." (802.11
Wireless Networks)

What's the value of the Reason Code received in the deauth frame?  That
will give a clue as to why the AP is rejecting you:

0   Reserved; unused
1   Unspecified
2   Prior authentication is not valid
3   Station has left the basic service area or extended service area
and is deauthenticated
4   Inactivity timer expired and station was disassociated
5   Disassociated due to insufficient resources at the access point
6   Incorrect frame type or subtype received from unauthenticated station
7   Incorrect frame type or subtype received from unassociated station
8   Station has left the basic service area or extended service area and is
   disassociated
9   Association or reassociation requested before authentication is complete
10  Reserved; unused

> Why doesn't it re-auth? Or does it do and it just doesn't work as
> expected?

It would be interesting to know what state the driver's state machine is
in when it gets this message.  Does the driver think it's authenticated?
Does the AP think the same thing?

Dan

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

Re: [PATCH] softmac: Fix WX and association related races

On Thu, 2006-09-28 at 10:19 -0400, Dan Williams wrote:

> I'd buy that argument.  When the driver gets the deauth message,
> shouldn't it be sending an IWAP 00:00:00:00:00:00 wireless event to
> userspace?

I thought we did that since a long time now, didn't you actually develop
the initial patch?

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

Re: [PATCH] softmac: Fix WX and association related races

2006-09-28 Thread Dan Williams

On Thu, 2006-09-28 at 16:27 +0200, Johannes Berg wrote:
> On Thu, 2006-09-28 at 10:19 -0400, Dan Williams wrote:
> 
> > I'd buy that argument.  When the driver gets the deauth message,
> > shouldn't it be sending an IWAP 00:00:00:00:00:00 wireless event to
> > userspace?
> 
> I thought we did that since a long time now, didn't you actually develop
> the initial patch?

Yes, I think I did.  My point here wasn't that the driver is _not_
sending those messages (it almost certainly is), but what's _implied_ by
those messages.  Namely that, if you're using a tool like wpa_supplicant
and/or NM, when you get a deauth from the AP and send the IWAP event,
all bets are off because the tool will likely override whatever the
driver thinks its doing.

I'm somewhat ambiguous on just how much policy a driver should try to
enforce.  I guess I'm OK with reassociation with the _same_ credentials.
But what airo does with "auto_wep" is very nearly, if not completely,
crossing the line [1].  The real question is, how much should drivers
really do, and how much should they leave to userspace?

Dan

[1] if the auth mode (open or shared-key) doesn't work, airo schedules a
timer and bumps the auth mode to the other one automatically, and tries
reassociation.

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

Re: [PATCH] softmac: Fix WX and association related races

On Thu, 2006-09-28 at 10:37 -0400, Dan Williams wrote:

> Yes, I think I did.  My point here wasn't that the driver is _not_
> sending those messages (it almost certainly is), but what's _implied_ by
> those messages.  Namely that, if you're using a tool like wpa_supplicant
> and/or NM, when you get a deauth from the AP and send the IWAP event,
> all bets are off because the tool will likely override whatever the
> driver thinks its doing.

Ah ok. But I suppose the actual problem is that different drivers do it
differently and hence wpa_supplicant or similar simply cannot react
properly.

That said, I do believe softmac tries reauth or did at some point, I
remember implementing that because the net at uni kept kicking me out.

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

Re: [PATCH] softmac: Fix WX and association related races

On Thursday 28 September 2006 16:37, Dan Williams wrote:
> On Thu, 2006-09-28 at 16:27 +0200, Johannes Berg wrote:
> > On Thu, 2006-09-28 at 10:19 -0400, Dan Williams wrote:
> > 
> > > I'd buy that argument.  When the driver gets the deauth message,
> > > shouldn't it be sending an IWAP 00:00:00:00:00:00 wireless event to
> > > userspace?
> > 
> > I thought we did that since a long time now, didn't you actually develop
> > the initial patch?
> 
> Yes, I think I did.  My point here wasn't that the driver is _not_
> sending those messages (it almost certainly is), but what's _implied_ by
> those messages.  Namely that, if you're using a tool like wpa_supplicant
> and/or NM, when you get a deauth from the AP and send the IWAP event,
> all bets are off because the tool will likely override whatever the
> driver thinks its doing.
> 
> I'm somewhat ambiguous on just how much policy a driver should try to
> enforce.  I guess I'm OK with reassociation with the _same_ credentials.
> But what airo does with "auto_wep" is very nearly, if not completely,
> crossing the line [1].  The real question is, how much should drivers
> really do, and how much should they leave to userspace?

IMO a driver should implement absolutely _zero_ policy, as this
is the only way to get the same (default) policy for different
cards. A driver should _only_ provide generic events for
userspace tools to make decisions.
A "I got a deauth" event is really enough for userspace to
know what to do.

> Dan
> 
> [1] if the auth mode (open or shared-key) doesn't work, airo schedules a
> timer and bumps the auth mode to the other one automatically, and tries
> reassociation.
> 
> 
> 

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: e100 changes in git-netdev-all break reboot with netconsole

2006-09-28 Thread Auke Kok


Andrew Morton wrote:

Enable netconsole-over-e100, and `reboot -f' hangs.  Disabling netconsole
prevents that from happening.

I assume what's happening is that the driver gets shut down and then
something tries to do a printk through it, and things hang.

For some reason sysrq-B still reboots the machine.


okay, I guess that means I'm setting up netconsole today ;)

digging into this ...

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

Re: [PATCH] softmac: Fix WX and association related races

2006-09-28 Thread Dan Williams

On Thu, 2006-09-28 at 16:43 +0200, Michael Buesch wrote:
> On Thursday 28 September 2006 16:37, Dan Williams wrote:
> > On Thu, 2006-09-28 at 16:27 +0200, Johannes Berg wrote:
> > > On Thu, 2006-09-28 at 10:19 -0400, Dan Williams wrote:
> > > 
> > > > I'd buy that argument.  When the driver gets the deauth message,
> > > > shouldn't it be sending an IWAP 00:00:00:00:00:00 wireless event to
> > > > userspace?
> > > 
> > > I thought we did that since a long time now, didn't you actually develop
> > > the initial patch?
> > 
> > Yes, I think I did.  My point here wasn't that the driver is _not_
> > sending those messages (it almost certainly is), but what's _implied_ by
> > those messages.  Namely that, if you're using a tool like wpa_supplicant
> > and/or NM, when you get a deauth from the AP and send the IWAP event,
> > all bets are off because the tool will likely override whatever the
> > driver thinks its doing.
> > 
> > I'm somewhat ambiguous on just how much policy a driver should try to
> > enforce.  I guess I'm OK with reassociation with the _same_ credentials.
> > But what airo does with "auto_wep" is very nearly, if not completely,
> > crossing the line [1].  The real question is, how much should drivers
> > really do, and how much should they leave to userspace?
> 
> IMO a driver should implement absolutely _zero_ policy, as this
> is the only way to get the same (default) policy for different
> cards. A driver should _only_ provide generic events for
> userspace tools to make decisions.
> A "I got a deauth" event is really enough for userspace to
> know what to do.

As a counterpoint, does every developer _really_ want to run
wpa_supplicant just to use a WEP-encrypted connection where you may
occasionally get kicked off?

I think it's clear that with WPA, it's pretty nearly impossible to do
reauth/reassoc because you need a user-space supplicant, right?  But WEP
doesn't require any interaction other than the 2- or 4-stage handshake
for open or shared key, and that's already done in the driver.

I'd say that handling WEP reauth/reassoc in the driver is probably fine
[1] since many drivers already try to do this, but I believe it's
probably inappropriate for anything more than WEP.  It's probably also
impossible to do with any sort of more-than-WEP roaming, maybe even WEP
roaming.

Dan

[1] with a suitable timeout or #tries clamp so it doesn't try forever.
airo does the auto_wep thing twice before failing and sending IWAP
00:00:... I believe.

> > Dan
> > 
> > [1] if the auth mode (open or shared-key) doesn't work, airo schedules a
> > timer and bumps the auth mode to the other one automatically, and tries
> > reassociation.
> > 
> > 
> > 
> 

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

Re: Re the default linux tcp algorithm being changed from bic to cubic.

On Thu, 28 Sep 2006 11:07:18 +0100
Douglas Leith <[EMAIL PROTECTED]> wrote:

> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> Steve,
> 
> I think we're all conscious of the fact that recent history contains 
> quite a number of proposals for changes to tcp's congestion control 
> algorithm for high bandwidth-delay product paths that on closer 
> inspection have proved problematic in one way or another.   It seems to 
> be a hard problem to solve, so maybe that's fair enough and hopefully 
> we'll end up with a workable solution soon.
> 
> Where I'm coming from here though is that bic was made the linux default 
> a year or so ago at a time when there were essentially no tests 
> available on its performance other than the infocom paper by Injong. 
> Subsequent tests have since highlighted a bunch of issues with bic.  To 
> my knowledge, we're currently in a similar situation with cubic as we 
> were with bic back then i.e. essentially no independent tests 
> investigating its behaviour.
> 
> Of course I know Injong has posted some test results, but these are 
> hardly independent as he's the author of both bic and cubic.  Have there 
> perhaps been private tests carried out (e.g. by osdl) ?  If so, would it 
> be possible to make them public ?  If not, well that would be good to 
> know too.

My tests have been limited and showed no difference. It is worthy
of more discussion as to what is best. Could you rerun your tests?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tc related lockdep warning.

On Thu, 28 Sep 2006 15:13:01 +0200
Jarek Poplawski <[EMAIL PROTECTED]> wrote:

> On Thu, Sep 28, 2006 at 02:17:51PM +0200, Patrick McHardy wrote:
> > [My mail provider is down, so responding "manually"]
> > 
> > Jarek Poplawski wrote:
> > > > [NET_SCHED]: Fix fallout from dev->qdisc RCU change
> > >
> > > Sorry again but I can't abstain from some doubts:
> > >
> > > ...
> > > > diff --git a/net/core/dev.c b/net/core/dev.c
> > > > index 14de297..4d891be 100644
> > > > --- a/net/core/dev.c
> > > > +++ b/net/core/dev.c
> > > > @@ -1480,14 +1480,16 @@ #endif
> > > > if (q->enqueue) {
> > > > /* Grab device queue */
> > > > spin_lock(&dev->queue_lock);
> > > > +   q = dev->qdisc;
> > >
> > > I don't get it. If it is some anti-race step according to
> > > rcu rules it should be again:
> > > q = rcu_dereference(dev->qdisc);
> > 
> > At this point RCU protection is not needed anymore since we
> > have the lock. We simply want to avoid taking the lock for
> > devices that don't have a real qdisc attached (like loopback).
> > Thats what the test for q->enqueue is there for. RCU is only
> > needed to avoid races between testing q->enqueue and freeing
> > of the qdisc.
> 
> But in Documentation/RCU/whatisRCU.txt I see this:
> 
> /*
>  * Return the value of field "a" of the current gbl_foo
>  * structure.  Use rcu_read_lock() and rcu_read_unlock()
>  * to ensure that the structure does not get deleted out
>  * from under us, and use rcu_dereference() to ensure that
>  * we see the initialized version of the structure (important
>  * for DEC Alpha and for people reading the code).
>  */
> int foo_get_a(void)
> {
> int retval;
> 
> rcu_read_lock();
> retval = rcu_dereference(gbl_foo)->a;
> rcu_read_unlock();
> return retval;
> }
> 

The example uses rcu_read_lock() which is a weaker form of protection
than a real lock, so the rcu_dereference() is needed to do memory barriers.

In the qdisc case we have the proper spin_lock() so no additional
barrier is needed.

-- 
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] softmac: Fix WX and association related races

On Thursday 28 September 2006 16:52, Dan Williams wrote:
> On Thu, 2006-09-28 at 16:43 +0200, Michael Buesch wrote:
> > On Thursday 28 September 2006 16:37, Dan Williams wrote:
> > > On Thu, 2006-09-28 at 16:27 +0200, Johannes Berg wrote:
> > > > On Thu, 2006-09-28 at 10:19 -0400, Dan Williams wrote:
> > > > 
> > > > > I'd buy that argument.  When the driver gets the deauth message,
> > > > > shouldn't it be sending an IWAP 00:00:00:00:00:00 wireless event to
> > > > > userspace?
> > > > 
> > > > I thought we did that since a long time now, didn't you actually develop
> > > > the initial patch?
> > > 
> > > Yes, I think I did.  My point here wasn't that the driver is _not_
> > > sending those messages (it almost certainly is), but what's _implied_ by
> > > those messages.  Namely that, if you're using a tool like wpa_supplicant
> > > and/or NM, when you get a deauth from the AP and send the IWAP event,
> > > all bets are off because the tool will likely override whatever the
> > > driver thinks its doing.
> > > 
> > > I'm somewhat ambiguous on just how much policy a driver should try to
> > > enforce.  I guess I'm OK with reassociation with the _same_ credentials.
> > > But what airo does with "auto_wep" is very nearly, if not completely,
> > > crossing the line [1].  The real question is, how much should drivers
> > > really do, and how much should they leave to userspace?
> > 
> > IMO a driver should implement absolutely _zero_ policy, as this
> > is the only way to get the same (default) policy for different
> > cards. A driver should _only_ provide generic events for
> > userspace tools to make decisions.
> > A "I got a deauth" event is really enough for userspace to
> > know what to do.
> 
> As a counterpoint, does every developer _really_ want to run
> wpa_supplicant just to use a WEP-encrypted connection where you may
> occasionally get kicked off?

I think that's the way we want to take. Even for unencrypted networks,
probably. We want as much as possible of the high level MAC
implementation in userspace. Remember the summit and Simon's talk?
It was a good talk and made a lot of sense.

This userspace implementation should probably renamed from wpa_supplicant
to wireless_supplicant or whatever.

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] softmac: Fix WX and association related races

Dan Williams wrote:

On Thu, 2006-09-28 at 16:43 +0200, Michael Buesch wrote:

On Thursday 28 September 2006 16:37, Dan Williams wrote:

On Thu, 2006-09-28 at 16:27 +0200, Johannes Berg wrote:

On Thu, 2006-09-28 at 10:19 -0400, Dan Williams wrote:

I'd buy that argument. When the driver gets the deauth message,
shouldn't it be sending an IWAP 00:00:00:00:00:00 wireless event to
userspace?

I thought we did that since a long time now, didn't you actually develop
the initial patch?

Yes, I think I did. My point here wasn't that the driver is _not_
sending those messages (it almost certainly is), but what's _implied_ by
those messages. Namely that, if you're using a tool like wpa_supplicant
and/or NM, when you get a deauth from the AP and send the IWAP event,
all bets are off because the tool will likely override whatever the
driver thinks its doing.

I'm somewhat ambiguous on just how much policy a driver should try to
enforce. I guess I'm OK with reassociation with the _same_ credentials.
But what airo does with "auto_wep" is very nearly, if not completely,
crossing the line [1]. The real question is, how much should drivers
really do, and how much should they leave to userspace?

IMO a driver should implement absolutely _zero_ policy, as this
is the only way to get the same (default) policy for different
cards. A driver should _only_ provide generic events for
userspace tools to make decisions.
A "I got a deauth" event is really enough for userspace to
know what to do.

As a counterpoint, does every developer _really_ want to run
wpa_supplicant just to use a WEP-encrypted connection where you may
occasionally get kicked off?

I think it's clear that with WPA, it's pretty nearly impossible to do
reauth/reassoc because you need a user-space supplicant, right? But WEP
doesn't require any interaction other than the 2- or 4-stage handshake
for open or shared key, and that's already done in the driver.

I'd say that handling WEP reauth/reassoc in the driver is probably fine
[1] since many drivers already try to do this, but I believe it's
probably inappropriate for anything more than WEP. It's probably also
impossible to do with any sort of more-than-WEP roaming, maybe even WEP
roaming.

Dan

[1] with a suitable timeout or #tries clamp so it doesn't try forever.
airo does the auto_wep thing twice before failing and sending IWAP
00:00:... I believe.

Dan

[1] if the auth mode (open or shared-key) doesn't work, airo schedules a
timer and bumps the auth mode to the other one automatically, and tries
reassociation.

Thanks for the educational discourse here. I have quite a bit of food for
thought.

First of all, my problem is quite likely caused by a buggy AP. It is a Linksys WRT54G V5, which is
one of those with a VxWorks kernel, not Linux. I have already reported one bug to Linksys, which
they have neither acknowledged nor fixed! In that case, SoftMAC had to be modified as a work-around.

I don't know why the deauthentication is being sent. The reason is not logged, which will be my
first change in the code. The second place to look is why SoftMAC reports the network is unknown
when the MAC printed is that of my AP.

Once I know more about the above points, I'll likely be back with more questions. Once I get the
response to the deauthentication to be better behaved, I will retry Michael's patch. The main
difficulty in all of this is that it happens even less frequently than the NETDEV WATCHDOG timeouts,
which were bad enough to troubleshoot.

Thanks again,

Larry

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

Re: [PATCH] softmac: Fix WX and association related races

On Thursday 28 September 2006 17:16, Larry Finger wrote:
> Dan Williams wrote:
> > On Thu, 2006-09-28 at 16:43 +0200, Michael Buesch wrote:
> >> On Thursday 28 September 2006 16:37, Dan Williams wrote:
> >>> On Thu, 2006-09-28 at 16:27 +0200, Johannes Berg wrote:
>  On Thu, 2006-09-28 at 10:19 -0400, Dan Williams wrote:
> 
> > I'd buy that argument.  When the driver gets the deauth message,
> > shouldn't it be sending an IWAP 00:00:00:00:00:00 wireless event to
> > userspace?
>  I thought we did that since a long time now, didn't you actually develop
>  the initial patch?
> >>> Yes, I think I did.  My point here wasn't that the driver is _not_
> >>> sending those messages (it almost certainly is), but what's _implied_ by
> >>> those messages.  Namely that, if you're using a tool like wpa_supplicant
> >>> and/or NM, when you get a deauth from the AP and send the IWAP event,
> >>> all bets are off because the tool will likely override whatever the
> >>> driver thinks its doing.
> >>>
> >>> I'm somewhat ambiguous on just how much policy a driver should try to
> >>> enforce.  I guess I'm OK with reassociation with the _same_ credentials.
> >>> But what airo does with "auto_wep" is very nearly, if not completely,
> >>> crossing the line [1].  The real question is, how much should drivers
> >>> really do, and how much should they leave to userspace?
> >> IMO a driver should implement absolutely _zero_ policy, as this
> >> is the only way to get the same (default) policy for different
> >> cards. A driver should _only_ provide generic events for
> >> userspace tools to make decisions.
> >> A "I got a deauth" event is really enough for userspace to
> >> know what to do.
> > 
> > As a counterpoint, does every developer _really_ want to run
> > wpa_supplicant just to use a WEP-encrypted connection where you may
> > occasionally get kicked off?
> > 
> > I think it's clear that with WPA, it's pretty nearly impossible to do
> > reauth/reassoc because you need a user-space supplicant, right?  But WEP
> > doesn't require any interaction other than the 2- or 4-stage handshake
> > for open or shared key, and that's already done in the driver.
> > 
> > I'd say that handling WEP reauth/reassoc in the driver is probably fine
> > [1] since many drivers already try to do this, but I believe it's
> > probably inappropriate for anything more than WEP.  It's probably also
> > impossible to do with any sort of more-than-WEP roaming, maybe even WEP
> > roaming.
> > 
> > Dan
> > 
> > [1] with a suitable timeout or #tries clamp so it doesn't try forever.
> > airo does the auto_wep thing twice before failing and sending IWAP
> > 00:00:... I believe.
> > 
> >>> Dan
> >>>
> >>> [1] if the auth mode (open or shared-key) doesn't work, airo schedules a
> >>> timer and bumps the auth mode to the other one automatically, and tries
> >>> reassociation.
> 
> Thanks for the educational discourse here. I have quite a bit of food for 
> thought.
> 
> First of all, my problem is quite likely caused by a buggy AP. It is a 
> Linksys WRT54G V5, which is 
> one of those with a VxWorks kernel, not Linux. I have already reported one 
> bug to Linksys, which 
> they have neither acknowledged nor fixed! In that case, SoftMAC had to be 
> modified as a work-around.
> 
> I don't know why the deauthentication is being sent. The reason is not 
> logged, which will be my 
> first change in the code. The second place to look is why SoftMAC reports the 
> network is unknown 
> when the MAC printed is that of my AP.
> 
> Once I know more about the above points, I'll likely be back with more 
> questions. Once I get the 
> response to the deauthentication to be better behaved, I will retry Michael's 
> patch. The main 
> difficulty in all of this is that it happens even less frequently than the 
> NETDEV WATCHDOG timeouts, 
> which were bad enough to troubleshoot.

You could try to capture such a deauth packet once you got one
from the AP and inject it for testing from another machine.
Injecting can be done with my crappy sysfs interface (search archives)
or with nl80211. My sysfs patch is probably easier to use, for now.
But you could also patch the driver and hardcode the packet into some
routine that executes on some user triggered event (Some private WX, some
sysfs file, etc...)
Modifying the driver to inject the frame is probably easiest.

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: softmac mtu

On Wednesday 27 September 2006 15:55, Johannes Berg wrote:
> On Wed, 2006-09-27 at 15:57 +0200, [EMAIL PROTECTED] wrote:
> 
> > Also I wonder what should be the max mtu.
> 
> 2304, I think, as that's
> synonym sMaxMsduLng Integer = 2304; /* max octets in an MSDU */
> 
> But maybe I'm interpreting the spec wrongly?

Yes, I think so. ;)

I am pretty sure this is the maximum _fragment_ size.
But each packet (which max size is defined by the MTU) can
be fragmented. I don't know if there's a limit on the max
number of frags.

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] softmac: Fix WX and association related races

2006-09-28 Thread Michael Wu

On Thursday 28 September 2006 11:16, Larry Finger wrote:
> First of all, my problem is quite likely caused by a buggy AP. It is a
> Linksys WRT54G V5, which is one of those with a VxWorks kernel, not Linux.
> I have already reported one bug to Linksys, which they have neither
> acknowledged nor fixed! In that case, SoftMAC had to be modified as a
> work-around.
>
These APs are truly bad. Hacking linux into it (DD-WRT) helps a bit, but 
wireless often seems to fail *completely* at times.

> I don't know why the deauthentication is being sent. The reason is not
> logged, which will be my first change in the code. The second place to look
> is why SoftMAC reports the network is unknown when the MAC printed is that
> of my AP.
>
The deauth reason code is usually 6 or 7.. IIRC, it is 6: Class 2 Frame from 
Non Authenticated STA. The AP just forgets you're associated. However, I 
think that was from when I had a v3 WRT54G.

I made sure the old adm8211 softmac stack had a very good set of printks to 
report these sort of things. :) Many APs do funny things..

-Michael Wu


pgpar98uW1wrk.pgp
Description: PGP signature

Re: softmac mtu

On Thu, Sep 28, 2006 at 05:35:17PM +0200, Michael Buesch wrote:
> On Wednesday 27 September 2006 15:55, Johannes Berg wrote:
> > On Wed, 2006-09-27 at 15:57 +0200, [EMAIL PROTECTED] wrote:
> > > Also I wonder what should be the max mtu.
> > 
> > 2304, I think, as that's
> > synonym sMaxMsduLng Integer = 2304; /* max octets in an MSDU */
> > 
> > But maybe I'm interpreting the spec wrongly?
> 
> Yes, I think so. ;)
> 
> I am pretty sure this is the maximum _fragment_ size.
> But each packet (which max size is defined by the MTU) can
> be fragmented. I don't know if there's a limit on the max
> number of frags.

No it's not. How about reading the standard.. ;-) Take a look at how
MSDU and MPDU are defined.. MSDU can be fragmented into smaller MPDUs,
but the limit here is indeed for MSDU, not MPDU. In other words,
fragmentation in IEEE 802.11 is different from fragmentation in IP and
it is also used for different purpose.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: softmac mtu

On Thu, 2006-09-28 at 17:35 +0200, Michael Buesch wrote:

> I am pretty sure this is the maximum _fragment_ size.

But then why does it talk of MPDU and MSDU?

from 802.11:

synonym sMaxMsduLng Integer = 2304; /* max octets in an MSDU */

synonym sMaxMpduLng Integer = /* max octets in an MPDU */
  (sMaxMsduLng + sMacHdrLng + sWdsAddLng + sWepAddLng + sCrcLng);

synonym sMinFragLng Integer = 256; /* min value for aMpduMaxLength */
synonym sMaxFragNum Integer =/* maximum fragment number */
  (sMaxMsduLng / (sMinFragLng - sMacHdrLng - sCrcLng));

The last calculation implies that each frame can only be up to
sMaxMsduLng octets long even when fragmented.

also cf. 9.1.4:

   9.1.4 Fragmentation/defragmentation overview

   The process of partitioning a MAC service data unit (MSDU) or a MAC
   management protocol data unit (MMPDU) into smaller MAC level frames,
   MAC protocol data units (MPDUs), is called fragmentation.
   Fragmentation creates MPDUs smaller than the original MSDU or MMPDU
   length to increase reliability, by increasing the probability of
   successful transmission of the MSDU or MMPDU in cases where channel
   characteristics limit reception reliability for longer frames.

IOW, I read it as an MSDU is the data that is supposed to be transmitted
over the link and that can be at most 2304 bytes long, and then it may
be fragmented or not and is then copied into (an) MPDU(s).

> But each packet (which max size is defined by the MTU) can
> be fragmented. I don't know if there's a limit on the max
> number of frags.

There's only a 4 bit fragment counter ;) However, see above.

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

Re: [PATCH] softmac: Fix WX and association related races

Michael Wu wrote:

On Thursday 28 September 2006 11:16, Larry Finger wrote:

First of all, my problem is quite likely caused by a buggy AP. It is a
Linksys WRT54G V5, which is one of those with a VxWorks kernel, not Linux.
I have already reported one bug to Linksys, which they have neither
acknowledged nor fixed! In that case, SoftMAC had to be modified as a
work-around.

These APs are truly bad. Hacking linux into it (DD-WRT) helps a bit, but
wireless often seems to fail *completely* at times.

I had very good luck with my first AP, a Linksys WRT54G V1, that I bought a second when the power
supply failed in the first. Little did I know that a VxWorks license costs less than the extra
memory needed to run Linux. Or was it to defeat the open-source alternatives for the AP?

I don't know why the deauthentication is being sent. The reason is not
logged, which will be my first change in the code. The second place to look
is why SoftMAC reports the network is unknown when the MAC printed is that
of my AP.

The deauth reason code is usually 6 or 7.. IIRC, it is 6: Class 2 Frame from
Non Authenticated STA. The AP just forgets you're associated. However, I
think that was from when I had a v3 WRT54G.

I already have modified SoftMAC to log the reason. Now I have to wait for the
event to happen.

I made sure the old adm8211 softmac stack had a very good set of printks to
report these sort of things. :) Many APs do funny things..

Thanks for the tip. It is unfortunate that the Linux code has to work around all the closed-source
other stuff!

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

Re: kernel: TKIP: replay detected:

On Mon, Sep 25, 2006 at 10:50:00AM -0400, John W. Linville wrote:
> On Sun, Sep 24, 2006 at 12:40:53PM +0200, Elimar Riesebieter wrote:

> > My sylog is filled up with thousands of:
> > Sep 21 18:18:00 aragorn kernel: TKIP: replay detected: \
> > STA=XX:XX:BB:LL:KK:00 previous TSC BLAa received TSC BLAa

> Opinion seems to be running that these messages are useless and should
> be removed.  Anyone disagree?

Yes, I disagree (again). In most cases, these are indication of an
implementation error. The problem here is that this issue may be at the
end of the connection. Anyway, if we are seeing large numbers of replays
detected with the same TSC/PN, I would suggest verifying that the IEEE
802.11 duplicate detection is working correctly in the driver that is
reporting these replays.

TKIP/CCMP are required to use incrementing TSC/PN for each frame. When a
directed IEEE 802.11 frame is not acknowledged, it will be retransmitted
(up to a certain limit). This retransmitted frame will use the same
TSC/PN. However, the duplicate detection routine in the receiver
(something that happens before TKIP/CCMP processing) should catch these
cases since the frames from the same source address that use the same
seq# and fragm# should be dropped at that layer.

If it can be shown, that these errors are indeed caused by a broken
transmitter (and that transmitter is not a Linux device for which we
control the driver code ;-), I would be much more willing to accept
patches that silence these messages (as long as the replay statistics
are easily available in other ways) by default, but I would still not
remove them completely.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re the default linux tcp algorithm being changed from bic to cubic.

2006-09-28 Thread Douglas Leith


Stephen Hemminger wrote:

On Thu, 28 Sep 2006 11:07:18 +0100
Douglas Leith <[EMAIL PROTECTED]> wrote:


Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Steve,

I think we're all conscious of the fact that recent history contains 
quite a number of proposals for changes to tcp's congestion control 
algorithm for high bandwidth-delay product paths that on closer 
inspection have proved problematic in one way or another.   It seems to 
be a hard problem to solve, so maybe that's fair enough and hopefully 
we'll end up with a workable solution soon.


Where I'm coming from here though is that bic was made the linux default 
a year or so ago at a time when there were essentially no tests 
available on its performance other than the infocom paper by Injong. 
Subsequent tests have since highlighted a bunch of issues with bic.  To 
my knowledge, we're currently in a similar situation with cubic as we 
were with bic back then i.e. essentially no independent tests 
investigating its behaviour.


Of course I know Injong has posted some test results, but these are 
hardly independent as he's the author of both bic and cubic.  Have there 
perhaps been private tests carried out (e.g. by osdl) ?  If so, would it 
be possible to make them public ?  If not, well that would be good to 
know too.


My tests have been limited and showed no difference. It is worthy
of more discussion as to what is best. Could you rerun your tests?


Unfortunately we haven't really looked at cubic at all to date as I 
didn't appreciate it was being seriously considered for the new default 
until Ian's post a few days ago.  It'll take a little time to free up 
some bandwidth in people's time here, but we'd be happy to rerun the 
previous tests with cubic as a priority and generally try to have an 
initial poke around.


Doug

Hamilton Institute
www.hamilton.ie
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re the default linux tcp algorithm being changed from bic to cubic.

On Thu, 28 Sep 2006 11:07:18 +0100
Douglas Leith <[EMAIL PROTECTED]> wrote:

> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> Steve,
> 
> I think we're all conscious of the fact that recent history contains 
> quite a number of proposals for changes to tcp's congestion control 
> algorithm for high bandwidth-delay product paths that on closer 
> inspection have proved problematic in one way or another.   It seems to 
> be a hard problem to solve, so maybe that's fair enough and hopefully 
> we'll end up with a workable solution soon.
> 
> Where I'm coming from here though is that bic was made the linux default 
> a year or so ago at a time when there were essentially no tests 
> available on its performance other than the infocom paper by Injong. 
> Subsequent tests have since highlighted a bunch of issues with bic.  To 
> my knowledge, we're currently in a similar situation with cubic as we 
> were with bic back then i.e. essentially no independent tests 
> investigating its behaviour.
> 
> Of course I know Injong has posted some test results, but these are 
> hardly independent as he's the author of both bic and cubic.  Have there 
> perhaps been private tests carried out (e.g. by osdl) ?  If so, would it 
> be possible to make them public ?  If not, well that would be good to 
> know too.
> 
> Doug
> 
> Hamilton Institute
> www.hamilton.ie

To get some exposure, how about moving the cubic patch off to -mm
kernel tree for one release, and leave BIC as the default for 2.6.19
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: softmac mtu

On Thu, Sep 28, 2006 at 05:47:12PM +0200, Johannes Berg wrote:
> On Thu, 2006-09-28 at 17:35 +0200, Michael Buesch wrote:
> 
> > I am pretty sure this is the maximum _fragment_ size.
> 
> But then why does it talk of MPDU and MSDU?

Maybe because your understanding is closer to what the standard says..
;-)

> IOW, I read it as an MSDU is the data that is supposed to be transmitted
> over the link and that can be at most 2304 bytes long, and then it may
> be fragmented or not and is then copied into (an) MPDU(s).

Yes.

> > But each packet (which max size is defined by the MTU) can
> > be fragmented. I don't know if there's a limit on the max
> > number of frags.
> 
> There's only a 4 bit fragment counter ;) However, see above.

And 4 bits is quite enough for sending the maximum number of fragments
which is currently about 10 (256 octet min frag len and 2304 max MSDU
len with some extra needed to cover the extra header in each fragment).

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ieee80211: quiet TKIP and CCMP replay messages for identical TSCs

On Mon, Sep 25, 2006 at 10:49:12AM -0500, Larry Finger wrote:

> When using TKIP and CCMP for wireless encryption with ieee80211, the logs get 
> filled with useless
> replay messages where the previous and received TSC are identical. This 
> change deletes
> the log message for this case, but still prints the message when there are 
> major differences
> in the TSC's.

NAK.

These are not useless messages; they are more or less always indication
of a broken implementation. I have nothing against hiding the messages
by default, but there should be an easy mechanism for noticing that this
is the reason for connection not working..

> --- wireless-2.6.orig/net/ieee80211/ieee80211_crypt_tkip.c
> @@ -394,7 +394,7 @@ static inline int tkip_replay_check(u32 
> - (iv32_n == iv32_o && iv16_n <= iv16_o))
> + (iv32_n == iv32_o && iv16_n < iv16_o))

> --- wireless-2.6.orig/net/ieee80211/ieee80211_crypt_ccmp.c
> @@ -287,7 +287,7 @@ static inline int ccmp_replay_check(u8 *
> - (iv32_n == iv32_o && iv16_n <= iv16_o))
> + (iv32_n == iv32_o && iv16_n < iv16_o))

These changes would break replay protection and must not be applied.
This is opening a security problem, not just limiting when something is
being printed out.

I would be more open to adding this extra condition for just the printk,
i.e., changing net_ratelimit() to net_ratelimit() && (iv32 and iv16 are
same). Even this is a case that should not really happen unless
something is broken since IEEE 802.11 duplicate detection should have
filtered the frames before (and it should be fixed if it did not do its
job correctly).

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PATCH] NET: Fixes for net-2.6.19

On Wed, 27 Sep 2006 22:44:44 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:

> From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
> Date: Tue, 19 Sep 2006 00:08:00 +0900 (JST)
> 
> > [XFRM]: Do not add a state whose SPI is zero to the SPI hash.
> > 
> > SPI=0 is used for acquired IPsec SA and MIPv6 RO state.
> > Such state should not be added to the SPI hash
> > because we do not care about it on deleting path.
> > 
> > Signed-off-by: Masahide NAKAMURA <[EMAIL PROTECTED]>
> > Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
> 
> Patch applied, thank you.
> 
> But the rest of these patches need more thought about these header
> file issues.
> 
> > [NET]: Move netlink interface bits to linux/if_link.h.
> > 
> > Moving netlink interface bits to linux/if.h is rather troublesome for
> > applications including both linux/if.h (which was changed to be included
> > from linux/rtnetlink.h automatically) and net/if.h.
> > 
> > Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
> 
> If it is illegal for user to include kernel's linux/if.h (by any
> means) if he uses net/if.h from userland headers, then he should
> also avoid including the kernel's rtnetlink.h header too.
> 
> I understand the issue, in that net/if.h defines macros that
> linux/if.h defines as well so there are conflicts (even though
> in the end the same exact values are used).
> 
> What I see happening is that the troublesome interfaces move from
> linux/if.h to a new file named linux/if_addr.h, then this gets
> included again to linux/rtnetlink.h but only for userspace with
> some messy ifdefs.
> 
> These kinds of things don't go away, they stay around forever once
> you decide to support them.
> 
> Actually, what I'm going to do is apply:
> 
> [NET]: Move netlink interface bits to linux/if_link.h.
> [NET] KBUILD: Add missing entries for new net headers.
> 
> And leave the rest for now.
> 

Please figure out how to keep rtnetlink.h useful from user space.
I tried putting the current sanitized version of rtnetlink.h into
iproute2 and the build fails. 

-- 
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 7222] New: sky2 throws a lot of "pci express error" in 2.6.18-mm2 on amd64

2006-09-28 Thread Andrew Morton

On Thu, 28 Sep 2006 05:10:43 -0700
[EMAIL PROTECTED] wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=7222
> 
>Summary: sky2 throws a lot of "pci express error" in 2.6.18-mm2
> on amd64
> Kernel Version: 2.6.18-mm2
> Status: NEW
>   Severity: normal
>  Owner: [EMAIL PROTECTED]
>  Submitter: [EMAIL PROTECTED]
> 
> 
> Most recent kernel where this bug did not occur: 2.6.18-mm1
> Distribution: Gentoo Linux
> Hardware Environment: Asus P5W DH Deluxe
> Software Environment:
> Problem Description: kernel throws a lot of "pci express error"s
> 
> Steps to reproduce:
> compile in sky2 driver in amd64 kernel (2.6.18-mm2),
> boot into system => errors appear:
> 
> sky2 v1.9 addr 0xebdfc000 irq 19 Yukon-EC (0xb6) rev 2
> sky2 eth0: addr 00:17:31:e8:f3:53
> ACPI: PCI Interrupt :03:00.0[A] -> GSI 16 (level, low) -> IRQ 16
> PCI: Setting latency timer of device :03:00.0 to 64
> sky2 v1.9 addr 0xebcfc000 irq 16 Yukon-EC (0xb6) rev 2
> sky2 eth1: addr 00:17:31:ee:e4:18
> [...]
> sky2 :04:00.0: pci express error (0x100407)
> [...]
> sky2 :03:00.0: pci express error (0x100407)
> [...]
> sky2 :04:00.0: pci express error (0x500547)
> sky2 :03:00.0: pci express error (0x500547)
> sky2 :04:00.0: pci express error (0x500547)
> sky2 :03:00.0: pci express error (0x500547)
> sky2 :04:00.0: pci express error (0x500547)
> sky2 :03:00.0: pci express error (0x500547)
> Losing some ticks... checking if CPU frequency changed.
> sky2 :04:00.0: pci express error (0x500547)
> sky2 :03:00.0: pci express error (0x500547)
> 
> this error occurs during the whole runtime of the kernel ...
> 
> I don't know if this severe, so I didn't let that kernel run long ...
> 
> network-functionality doesn't seem to be impaired:
> ping -c 3 www.google.com
> works & I can surf with links -g www.google.com
> 

I would be suspecting that something went wrong with "[PATCH] sky2: use
standard pci register capabilties for error register".
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc

2006-09-28 Thread Injong Rhee

Sure. I don't mind doing this test. I am currently working with Doug Leith 
to get to the bottom of this difference. So when we get to the PFLDnet, we 
should have some more findings on this. But I am up for this challenge.

- Original Message - 
From: "Lachlan Andrew" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Cc: "Douglas Leith" <[EMAIL PROTECTED]>; ; 
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Injong Rhee" 
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>

Sent: Wednesday, September 27, 2006 7:20 PM
Subject: Re: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc

Greetings all,

On 23/09/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Just i was pondering why we got different results and try to see if we 
can

come to some understanding on this different results we got. Who knows we
together might run into some fundamental research issues regarding
testing.

Since many interested parties will be around LA for PFLDnet, how about
getting together after that (Friday 9 Feb) to re-run some of the
disputed tests on one set of hardware, with everyone present to debate
the results?

You're all welcome to come to Caltech to do the testing.  We can
provide a few servers, dummynets and Gigabit switches.  Everyone is
welcome to bring their scripts, and any other hardware they need.

If there is interest, we could also have things like a round-table
discussion of the benefits of testing with different file-length
distributions (like long lived flows to understand what is happening
vs a range of flows to test suitability for deployment), and the
benefits of repeating other people's tests vs testing in as many
scenarios as possible.

Who is interested in coming?

Cheers,
Lachlan

--
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820Fax: +1 (626) 568-3603

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

Re: [PATCH] softmac: Fix WX and association related races

2006-09-28 Thread Jason Lunz

On Thu, Sep 28, 2006 at 10:52:24AM -0500, Larry Finger wrote:
> I had very good luck with my first AP, a Linksys WRT54G V1, that I
> bought a second when the power supply failed in the first. Little did
> I know that a VxWorks license costs less than the extra memory needed
> to run Linux. Or was it to defeat the open-source alternatives for the
> AP?

last I checked, linksys (cisco?) still sells the linux-compatible
version as the WRT54GL. <- note the extra 'L'.

Jason

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

Stability of various TCP protocols [CUBIC, BIC, HTCP, HSTCP, STCP]

2006-09-28 Thread Injong Rhee



Hi,
I'd like to report on a measurement study regarding the stability of various 
TCP variant protocols. Although we can find quite a bit of work on fairness 
and convergence of protocols (including some theoretical studies on the 
topic as well), there is relatively little work on measuring the stability 
of protocols and its impact on protocol performance and overall health of 
the networks (e.g., the overall queue fluctions and link utilization). We 
have measured the degree of rate oscillation and fluctuation of protocols to 
have some understanding of protocol stability. We would like to share our 
results with you to get some feedback from the community.


We have some theoretical results and also experimental results. Here is the 
link to the experimental results. You can find links to all of our 
experimental data that include results from several hundred experiments.


http://netsrv.csc.ncsu.edu/convex-ordering/

If you need our report on theoretical results,  we can e-mail you the 
report.
Injong Rhee 


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

Re: softmac mtu

2006-09-28 Thread Daniel Drake


[EMAIL PROTECTED] wrote:

I have a patch for 802.11 linux stack.
It works for mtu like 2000 but if the packet is fragmented (with mtu = 3000 for
example) my usb dongle (zd1211) crash (doesn't work anymore until I replug it).
I need to investigate a bit.


zd1211rw requires explicit support for large frames due to the USB 
protocol in use. This is supported by the vendor driver but not zd1211rw 
just yet.


Daniel

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

Re: [RFC][PATCH 1/3] enable bonding to enslave non ARPHRD_ETHER netdevices

2006-09-28 Thread Jay Vosburgh

Or Gerlitz <[EMAIL PROTECTED]> wrote:

>On 9/26/06, Jay Vosburgh <[EMAIL PROTECTED]> wrote:
>> Or Gerlitz <[EMAIL PROTECTED]> wrote:
>> [...]
>> +   bond->dev->mtu  = new_active->dev->mtu;
>>
>> This won't generate a NETDEV_CHANGEMTU notifier event.
>
>What is actually the trigger for the event with the current impl? is
>the code that actually calls dev_set_mtu() on the bonding device or
>dev_set_mtu() itself?

My comment wasn't quite totally thought out; pretend you didn't
see it.

I think what would be better overall is to handle the mtu for
this case the way bonding handles the mtu for other slave devices.
Normally, the mtu is pushed to the slaves from the bonding master, not
the other way around.  So, you don't want to assign the master's mtu
here; the slave mtu should already be up to date (and set to whatever
the master's mtu is via the usual mechanism, bond_change_mtu for
changes, or set in the slave at enslavement time).

[...]
>So at the bottom line, i would go on enhancing my patch not to allow
>bonding together devices of different types or at least if you don't
>mind, not to allow putting ARPHRD_INFINIBAND with
>non-ARPHRD_INFINIBAND devices in the same bond.

I think this (disallowing bonding of dissimilar ARPHRD types) is
the way to go, at least in the short term.  Get it to work for the
common case first, then deal with the fringe stuff later.

-J

---
-Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] softmac: Fix WX and association related races


Jason Lunz wrote:

On Thu, Sep 28, 2006 at 10:52:24AM -0500, Larry Finger wrote:

I had very good luck with my first AP, a Linksys WRT54G V1, that I
bought a second when the power supply failed in the first. Little did
I know that a VxWorks license costs less than the extra memory needed
to run Linux. Or was it to defeat the open-source alternatives for the
AP?


last I checked, linksys (cisco?) still sells the linux-compatible
version as the WRT54GL. <- note the extra 'L'.


I know, but have decided to stay with V5 (and bitch a lot) as others are likely to suffer from the 
same problems as I do. As many of them would never try alternate firmware, we need to provide the 
workarounds. If I'm using one of the brain-dead APs, I get the symptoms first hand and can tell when 
they are fixed.


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

Re: [PATCH] softmac: Fix WX and association related races

On Thursday 28 September 2006 19:04, Larry Finger wrote:
> Jason Lunz wrote:
> > On Thu, Sep 28, 2006 at 10:52:24AM -0500, Larry Finger wrote:
> >> I had very good luck with my first AP, a Linksys WRT54G V1, that I
> >> bought a second when the power supply failed in the first. Little did
> >> I know that a VxWorks license costs less than the extra memory needed
> >> to run Linux. Or was it to defeat the open-source alternatives for the
> >> AP?
> > 
> > last I checked, linksys (cisco?) still sells the linux-compatible
> > version as the WRT54GL. <- note the extra 'L'.
> 
> I know, but have decided to stay with V5 (and bitch a lot) as others are 
> likely to suffer from the 
> same problems as I do. As many of them would never try alternate firmware, we 
> need to provide the 
> workarounds. If I'm using one of the brain-dead APs, I get the symptoms first 
> hand and can tell when 
> they are fixed.

Well. You say that it works with your AP and without my patch, but
not with the patch. I'd say it works by pure luck. I don't think
my patch changes any semantics. It just properly protects some
parts from racing. Maybe you actually benefit from these races
and softmac magically "races you the correct result" ;)

Or do you notice something that changes semantics?

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: simplify microsecond rtt sampling

On Thu, 28 Sep 2006 13:47:28 +0100
John Heffner <[EMAIL PROTECTED]> wrote:

> Sigh.  Here's one that's not corrupted.  And for the record:
> 
> 
> This changes the microsecond RTT sampling so that samples are taken in 
> the same way that RTT samples are taken for the RTO calculator: on the 
> last segment acknowledged, and only when the segment hasn't been 
> retransmitted.
> 
> 
> Signed-off-by: John Heffner <[EMAIL PROTECTED]>

Looks ok. I wish skbuff timestamp was converted to ktime.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] softmac: Fix WX and association related races

Michael Buesch wrote:

On Thursday 28 September 2006 19:04, Larry Finger wrote:

Jason Lunz wrote:

On Thu, Sep 28, 2006 at 10:52:24AM -0500, Larry Finger wrote:

I had very good luck with my first AP, a Linksys WRT54G V1, that I
bought a second when the power supply failed in the first. Little did
I know that a VxWorks license costs less than the extra memory needed
to run Linux. Or was it to defeat the open-source alternatives for the
AP?

last I checked, linksys (cisco?) still sells the linux-compatible
version as the WRT54GL. <- note the extra 'L'.
I know, but have decided to stay with V5 (and bitch a lot) as others are likely to suffer from the
same problems as I do. As many of them would never try alternate firmware, we need to provide the
workarounds. If I'm using one of the brain-dead APs, I get the symptoms first hand and can tell when
they are fixed.

Well. You say that it works with your AP and without my patch, but
not with the patch. I'd say it works by pure luck. I don't think
my patch changes any semantics. It just properly protects some
parts from racing. Maybe you actually benefit from these races
and softmac magically "races you the correct result" ;)

Or do you notice something that changes semantics?

No, only that the system recovers w/o your patch, and not with it. It could very well race to the
correct point. ATM, I have your patch back in and I'm trying to get more diagnostics in the logs.
I'll let you know.

Larry

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

Re: [PATCH] softmac: Fix WX and association related races

On Thu, Sep 28, 2006 at 05:13:20PM +0200, Michael Buesch wrote:
> On Thursday 28 September 2006 16:52, Dan Williams wrote:
> > As a counterpoint, does every developer _really_ want to run
> > wpa_supplicant just to use a WEP-encrypted connection where you may
> > occasionally get kicked off?
> 
> I think that's the way we want to take. Even for unencrypted networks,
> probably. We want as much as possible of the high level MAC
> implementation in userspace. Remember the summit and Simon's talk?
> It was a good talk and made a lot of sense.

I don't know whether every developer wants to run a userspace tool for
that, but taken into account that I'm planning on focusing on the MLME
code in wpa_supplicant instead of fine tuning similar code in kernel, it
should be quite obvious what I would be voting for ;-).

> This userspace implementation should probably renamed from wpa_supplicant
> to wireless_supplicant or whatever.

Yeah.. wpa_supplicant does not really describe the exact set of
functionality in the program. Though, I'm not planning on renaming it
just for the sake of having a better name. Then again, there are plans
on merging (with build time options) wpa_supplicant and hostapd
functionality, so there is a good point for renaming the end result to
something else. At this point, it shouldn't have "supplicant" in the name
either since it will be possible to include both supplicant and
authenticator functionality into the same program (e.g., for IEEE
802.11i IBSS).

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] [PATCH 3/3] enable IP multicast when bonding IPoIB devices

2006-09-28 Thread Jay Vosburgh

Or Gerlitz <[EMAIL PROTECTED]> wrote:

>On 9/27/06, Jay Vosburgh <[EMAIL PROTECTED]> wrote:
>> Or Gerlitz <[EMAIL PROTECTED]> wrote:
[...]
>> You almost want to have some kind of call to induce a reload
>> from scratch of the multicast filter settings (along with whatever else
>> might be necessary to alter the hardware type on the fly), to be called
>> by bonding at the time the first slave is added (since slave adds happen
>> in user context, and can therefore hold rtnl as required by most of the
>> multicast address handling code).  That seems less hassle than having to
>> specify the hardware type and address length at module load time.
>
>I agree that it would be better to avoid doing it this way.

Actually, it would be ideal to do it this way in all cases, as
the change of hardware type is the biggest hurdle to cross-hardware
bonding instances.  The current infrastructure simply won't allow it,
though, since bonding failover events usually occur in a timer context
(if memory serves, timers run in softirq and can't acquire rtnl).

[...]
>> Other random thoughts on how to resolve this include modifying
>> bonding to accept slaves when the master is down (which would also
>> require changes to the initscripts that normally configure bonding), so
>> that the initial setting of the, e.g., 224.0.0.1 multicast hardware
>> address happens to the already-changed hardware type.
>
>OK, this is a direction i would like to check. Can be nice if you
>provide me with a 1-2 liner of directions on what need to be changed
>to enable bonding to accept slaves when it down.

I don't think right offhand this would be a particularly
difficult change; the "up" operation for bonding mostly just starts up
various timers.  A few minutes poking around doesn't reveal anything
obvious that would hinder enslaving with the master down.  You'll have
to change ifenslave and the sysfs code to allow enslaves with the master
down; that might be all that's needed for bonding itself.  Changing
/sbin/ifup and friends is a separate problem.

-J

---
-Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATH] Allow mtu bigger than 1500 for ieee80211

2006-09-28 Thread matthieu castet


Hi

this patch allow to set the mtu between 1500 and 2304 (max octets in an 
MSDU) for devices using ieee80211 linux stack.


Signed-off-by: Matthieu CASTET <[EMAIL PROTECTED]>
Index: linux/net/ieee80211/ieee80211_module.c
===
--- linux.orig/net/ieee80211/ieee80211_module.c 2006-09-26 19:27:26.0 
+0200
+++ linux/net/ieee80211/ieee80211_module.c  2006-09-28 19:50:53.0 
+0200
@@ -118,6 +118,14 @@
  &ieee->network_free_list);
 }
 
+static int ieee80211_change_mtu(struct net_device *dev, int new_mtu)
+{
+   if ((new_mtu < 68) || (new_mtu > IEEE80211_DATA_LEN))
+   return -EINVAL;
+   dev->mtu = new_mtu;
+   return 0;
+}
+
 struct net_device *alloc_ieee80211(int sizeof_priv)
 {
struct ieee80211_device *ieee;
@@ -133,6 +141,7 @@
}
ieee = netdev_priv(dev);
dev->hard_start_xmit = ieee80211_xmit;
+   dev->change_mtu = ieee80211_change_mtu;
 
ieee->dev = dev;

Re: softmac mtu

2006-09-28 Thread matthieu castet


Johannes Berg wrote:

On Wed, 2006-09-27 at 19:17 +0200, matthieu castet wrote:



2304, I think, as that's
synonym sMaxMsduLng Integer = 2304; /* max octets in an MSDU */



Yes but if it is bigger the frame get framented at the 802.11 layer : in 
theory we could put mtu (IP max packet size) a big as we want [1].



No, you're confusing MPDU and MSDU. Or I am :) Please try to read the
spec as well.


Right,

Thanks for the clarification.


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

[RFC] let mortals use ethtool


There is no reason to not allow non-admin users to query network
statistics and settings.


--- linux-2.6.orig/net/core/ethtool.c
+++ linux-2.6/net/core/ethtool.c
@@ -806,13 +806,6 @@ int dev_ethtool(struct ifreq *ifr)
int rc;
unsigned long old_features;
 
-   /*
-* XXX: This can be pushed down into the ethtool_* handlers that
-* need it.  Keep existing behaviour for the moment.
-*/
-   if (!capable(CAP_NET_ADMIN))
-   return -EPERM;
-
if (!dev || !netif_device_present(dev))
return -ENODEV;
 
@@ -822,6 +815,33 @@ int dev_ethtool(struct ifreq *ifr)
if (copy_from_user(ðcmd, useraddr, sizeof (ethcmd)))
return -EFAULT;
 
+   /* Allow some commands to be done by anyone */
+   switch(ethcmd) {
+   case ETHTOOL_GSET:
+   case ETHTOOL_GDRVINFO:
+   case ETHTOOL_GREGS:
+   case ETHTOOL_GWOL:
+   case ETHTOOL_GMSGLVL:
+   case ETHTOOL_GLINK:
+   case ETHTOOL_GCOALESCE:
+   case ETHTOOL_GRINGPARAM:
+   case ETHTOOL_GPAUSEPARAM:
+   case ETHTOOL_GRXCSUM:
+   case ETHTOOL_GTXCSUM:
+   case ETHTOOL_GSG:
+   case ETHTOOL_GSTRINGS:
+   case ETHTOOL_PHYS_ID:
+   case ETHTOOL_GSTATS:
+   case ETHTOOL_GTSO:
+   case ETHTOOL_GPERMADDR:
+   case ETHTOOL_GUFO:
+   case ETHTOOL_GGSO:
+   break;
+   default:
+   if (!capable(CAP_NET_ADMIN))
+   return -EPERM;
+   }
+
if(dev->ethtool_ops->begin)
if ((rc = dev->ethtool_ops->begin(dev)) < 0)
return rc;
@@ -947,6 +967,10 @@ int dev_ethtool(struct ifreq *ifr)
return rc;
 
  ioctl:
+   /* Keep existing behaviour for the moment.   */
+   if (!capable(CAP_NET_ADMIN))
+   return -EPERM;
+
if (dev->do_ioctl)
return dev->do_ioctl(dev, ifr, SIOCETHTOOL);
return -EOPNOTSUPP;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] let mortals use ethtool

2006-09-28 Thread James Morris

On Thu, 28 Sep 2006, Stephen Hemminger wrote:

> 
> There is no reason to not allow non-admin users to query network
> statistics and settings.

Acked-by: James Morris <[EMAIL PROTECTED]>



-- 
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] let mortals use ethtool

2006-09-28 Thread Auke Kok


Stephen Hemminger wrote:

There is no reason to not allow non-admin users to query network
statistics and settings.


--- linux-2.6.orig/net/core/ethtool.c
+++ linux-2.6/net/core/ethtool.c
@@ -806,13 +806,6 @@ int dev_ethtool(struct ifreq *ifr)
int rc;
unsigned long old_features;
 
-	/*

-* XXX: This can be pushed down into the ethtool_* handlers that
-* need it.  Keep existing behaviour for the moment.
-*/
-   if (!capable(CAP_NET_ADMIN))
-   return -EPERM;
-
if (!dev || !netif_device_present(dev))
return -ENODEV;
 
@@ -822,6 +815,33 @@ int dev_ethtool(struct ifreq *ifr)

if (copy_from_user(ðcmd, useraddr, sizeof (ethcmd)))
return -EFAULT;
 
+	/* Allow some commands to be done by anyone */

+   switch(ethcmd) {
+   case ETHTOOL_GSET:
+   case ETHTOOL_GDRVINFO:
+   case ETHTOOL_GREGS:
+   case ETHTOOL_GWOL:
+   case ETHTOOL_GMSGLVL:
+   case ETHTOOL_GLINK:
+   case ETHTOOL_GCOALESCE:
+   case ETHTOOL_GRINGPARAM:
+   case ETHTOOL_GPAUSEPARAM:
+   case ETHTOOL_GRXCSUM:
+   case ETHTOOL_GTXCSUM:
+   case ETHTOOL_GSG:
+   case ETHTOOL_GSTRINGS:
+   case ETHTOOL_PHYS_ID:


PHYS_ID pokes in hardware and makes it jump through hoops, in the case of some hardware 
this could create a local DOS attack (e1000 suffers fromt his, probably more if not all) 
where the NIC might stop receiving packets, or the big lock is help indefinately.


Not a good idea

The other ones are fine I think.

Auke



+   case ETHTOOL_GSTATS:
+   case ETHTOOL_GTSO:
+   case ETHTOOL_GPERMADDR:
+   case ETHTOOL_GUFO:
+   case ETHTOOL_GGSO:
+   break;
+   default:
+   if (!capable(CAP_NET_ADMIN))
+   return -EPERM;
+   }
+
if(dev->ethtool_ops->begin)
if ((rc = dev->ethtool_ops->begin(dev)) < 0)
return rc;
@@ -947,6 +967,10 @@ int dev_ethtool(struct ifreq *ifr)
return rc;
 
  ioctl:

+   /* Keep existing behaviour for the moment.   */
+   if (!capable(CAP_NET_ADMIN))
+   return -EPERM;
+
if (dev->do_ioctl)
return dev->do_ioctl(dev, ifr, SIOCETHTOOL);
return -EOPNOTSUPP;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: [PATCH 0/1] atl1: New driver, Attansic L1 Gigabit Ethernet

2006-09-28 Thread Francois Romieu

Jay Cliburn <[EMAIL PROTECTED]> :
[...]
> You will note that it's in a directory called "obsolete."  That's
> because it is undergoing significant rework based on shemminger's
> comments and other considerations.
> 
> A new version will be posted in the upcoming days.

Nice.

Whishlist:
- __iomem annotations;
- less MixedCase;
- less typedef;
- more vowels or less drv (drvrrd, drvtrd, drvtxf, grmbl);
- DMA_xxBIT_MASK may help;
- request_irq(... IRQF_SHARED, ...).

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

Re: [RFC] let mortals use ethtool

2006-09-28 Thread Michael Chan

On Thu, 2006-09-28 at 12:25 -0700, Stephen Hemminger wrote:

> + /* Allow some commands to be done by anyone */
> + switch(ethcmd) {
> + case ETHTOOL_GSET:
> + case ETHTOOL_GDRVINFO:
> + case ETHTOOL_GREGS:
> + case ETHTOOL_GWOL:
> + case ETHTOOL_GMSGLVL:
> + case ETHTOOL_GLINK:
> + case ETHTOOL_GCOALESCE:
> + case ETHTOOL_GRINGPARAM:
> + case ETHTOOL_GPAUSEPARAM:
> + case ETHTOOL_GRXCSUM:
> + case ETHTOOL_GTXCSUM:
> + case ETHTOOL_GSG:
> + case ETHTOOL_GSTRINGS:
> + case ETHTOOL_PHYS_ID:
> + case ETHTOOL_GSTATS:
> + case ETHTOOL_GTSO:
> + case ETHTOOL_GPERMADDR:
> + case ETHTOOL_GUFO:
> + case ETHTOOL_GGSO:

I'm against letting normal users do ETHTOOL_GREGS and ETHTOOL_PHYS_ID.
Dumping 64K worth of registers and blinking the LEDs should be
restricted.  But I have no problem doing these checks in the driver if
necessary.

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

Re: [RFC] let mortals use ethtool


Stephen Hemminger wrote:

There is no reason to not allow non-admin users to query network
statistics and settings.


NAK.

Some functions in the past didn't like getting hit rapidly in succession.

I would agree to this, but only after an exhaustive audit of each driver 
and each sub-ioctl.  Right now, I only have confidence in GDRVINFO 
probably being safe -- but still that requires an audit, since in rare 
cases the driver may be poking firmware and eeprom areas.


Finally, I fixed a buffer overflow in ethtool version 5, so an audit to 
make sure overflows cannot affect the kernel is basically _required_.


Jeff




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

Re: [RFC] let mortals use ethtool


Michael Chan wrote:

On Thu, 2006-09-28 at 12:25 -0700, Stephen Hemminger wrote:


+   /* Allow some commands to be done by anyone */
+   switch(ethcmd) {
+   case ETHTOOL_GSET:
+   case ETHTOOL_GDRVINFO:
+   case ETHTOOL_GREGS:
+   case ETHTOOL_GWOL:
+   case ETHTOOL_GMSGLVL:
+   case ETHTOOL_GLINK:
+   case ETHTOOL_GCOALESCE:
+   case ETHTOOL_GRINGPARAM:
+   case ETHTOOL_GPAUSEPARAM:
+   case ETHTOOL_GRXCSUM:
+   case ETHTOOL_GTXCSUM:
+   case ETHTOOL_GSG:
+   case ETHTOOL_GSTRINGS:
+   case ETHTOOL_PHYS_ID:
+   case ETHTOOL_GSTATS:
+   case ETHTOOL_GTSO:
+   case ETHTOOL_GPERMADDR:
+   case ETHTOOL_GUFO:
+   case ETHTOOL_GGSO:


I'm against letting normal users do ETHTOOL_GREGS and ETHTOOL_PHYS_ID.
Dumping 64K worth of registers and blinking the LEDs should be
restricted.  But I have no problem doing these checks in the driver if
necessary.


It is because of issues like these that we should not open up the entire 
list above, all at once.  Each sub-ioctl needs careful consideration and 
driver auditing.


Jeff



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

Re: [RFC] let mortals use ethtool


James Morris wrote:

On Thu, 28 Sep 2006, Michael Chan wrote:


I'm against letting normal users do ETHTOOL_GREGS and ETHTOOL_PHYS_ID.
Dumping 64K worth of registers and blinking the LEDs should be
restricted.


Out of curiosity -- why?


In the past, dumping certain tg3 registers has led to lock-ups, for one.

Also, blindly dumping registers can negatively affect driver operation, 
for the case where reading registers has side effects, such as PHY 
register bit shifting, or read-and-clear registers.


Jeff



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

Re: [RFC] let mortals use ethtool

2006-09-28 Thread James Morris

On Thu, 28 Sep 2006, Michael Chan wrote:

> I'm against letting normal users do ETHTOOL_GREGS and ETHTOOL_PHYS_ID.
> Dumping 64K worth of registers and blinking the LEDs should be
> restricted.

Out of curiosity -- why?



-- 
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] let mortals use ethtool

2006-09-28 Thread Michael Chan

On Thu, 2006-09-28 at 16:35 -0400, Jeff Garzik wrote:
> James Morris wrote:
> > On Thu, 28 Sep 2006, Michael Chan wrote:
> > 
> >> I'm against letting normal users do ETHTOOL_GREGS and ETHTOOL_PHYS_ID.
> >> Dumping 64K worth of registers and blinking the LEDs should be
> >> restricted.
> > 
> > Out of curiosity -- why?
> 
> In the past, dumping certain tg3 registers has led to lock-ups, for one.
> 
> Also, blindly dumping registers can negatively affect driver operation, 
> for the case where reading registers has side effects, such as PHY 
> register bit shifting, or read-and-clear registers.
> 

That's right.  For the LED blinking part, you don't want normal users to
override the normal functions of LEDs which are to indicate link, speed,
traffic, etc.

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

Re: [RFC] let mortals use ethtool

Another example:  registers often have sensitive information such as WoL 
passwords or WEP keys stored in them.



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

[PATCH] 2.6.18 atmel iwlist stats patch

2006-09-28 Thread Holden Karau


From: Holden Karau <[EMAIL PROTECTED]> http://www.holdenkarau.com

I have made a small patch for the atmel driver [included in the 2.6.18
kernel] to output signal strength information as part of iwlist scan
[before it did not output any signal strength related information].
Signed-off-by: Holden Karau <[EMAIL PROTECTED]> http://www.holdenkarau.com
--
The output of iwlist scan is frequently used by user space utilites to
chose which wireless network to connect to based on the reported
signal strength, so I think this could be useful [of course I could be
horribly wrong about that but *shrugs*]. Incase the patch gets mangled
I've also put it up on at
http://www.holdenkarau.com/~holden/projects/atmel/patches/001-iwlist-stats.patch
And now for the patch:
--- drivers/net/wireless/atmel.c.orig   2006-09-28 14:14:42.0 -0400
+++ drivers/net/wireless/atmel.c2006-09-28 14:14:55.0 -0400
@@ -2345,6 +2345,14 @@ static int atmel_get_scan(struct net_dev
iwe.u.freq.e = 0;
current_ev = iwe_stream_add_event(current_ev, extra +
IW_SCAN_MAX_DATA, &iwe, IW_EV_FREQ_LEN);

+   /* Add quality statistics */
+   iwe.cmd = IWEVQUAL;
+   iwe.u.qual.level = (__u8) priv->BSSinfo[i].RSSI;
+   iwe.u.qual.qual  = iwe.u.qual.level;
+   /* iwe.u.qual.noise  = SOMETHING */
+   current_ev = iwe_stream_add_event(current_ev, extra +
IW_SCAN_MAX_DATA , &iwe, IW_EV_QUAL_LEN);
+
+
iwe.cmd = SIOCGIWENCODE;
if (priv->BSSinfo[i].UsingWEP)
iwe.u.data.flags = IW_ENCODE_ENABLED | IW_ENCODE_NOKEY;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Network problem with 2.6.18-mm1 ?

2006-09-28 Thread Sukadev Bhattiprolu

Thanks. See below for additional info

Auke Kok [EMAIL PROTECTED] wrote:
| Sukadev Bhattiprolu wrote:
| >
| >I am unable to get networking to work with 2.6.18-mm1 on my system.
| >
| >But 2.6.18 kernel on same system works fine. Here is some info about
| >the system/debug attempts. Attached are the lspci output and config.
| >
| >Appreciate any help. Please let me know if you need more info. 
| >
| >Suka
| >
| >System info:
| >
| > x326, 2 CPU (AMD Opteron Processor 250)
| >
| >Kernel info:
| >
| > $ uname -a
| > Linux elm3b166 2.6.18-mm1 #4 SMP PREEMPT Tue Sep 26 18:11:58 PDT 2006
| > x86_64 GNU/Linux
| >
| > Config tokens differing between the 2.6.18 kernel that works and
| > the 2.6.18-mm1 that does not are:
| >
| > Tokens in 2.6.18 but not in 2.6.18-mm1 config
| >
| > CONFIG_SCSI_FC_ATTRS=y
| > CONFIG_SCSI_SATA_SIL=y
| > CONFIG_SCSI_SATA=y
| >
| > Tokens in 2.6.18-mm1 but not in 2.6.18 config
| >
| > CONFIG_PROC_SYSCTL=y
| > CONFIG_SATA_SIL=y 
| > CONFIG_ATA=y 
| > CONFIG_ARCH_POPULATES_NODE_MAP=y
| > CONFIG_CRYPTO_ALGAPI=y
| > CONFIG_MICROCODE_OLD_INTERFACE=y
| > CONFIG_BLOCK=y
| > CONFIG_VIDEO_V4L1_COMPAT=y
| > CONFIG_ZONE_DMA=y
| > CONFIG_FB_DDC=y
| >
| > All drivers compiled into kernel in both cases.
| >
| >Debug info:
| >
| > Checked hardware connections :-) 
| > (Rebooting on 2.6.18 kernel works - consistently)
| > 
| > $ ethtool -i eth0
| > driver: e1000
| > version: 7.2.7-k2
| > firmware-version: N/A
| >
| > $ ip addr
| > seems fine (up, broadcasting etc)
| >
| > $ ip -s link
| > shows no errors/drops/overruns
| >
| > $ ip route
| > shows the correct gw
| >
| > $ ethtool -S eth0
| >
| > shows non-zero tx/rx packets/bytes but *rx_missed_errors*
| > quite large (~138K) and increasing over time
| >
| > $ ping 
| > works fine
| >
| > $ ping 
| > no response.
| >
| > $ tcpdump -i eth0 host 
| > 
| > while pinging gateway, tcpdump shows messages like:
| >
| > 18:03:45.936161 arp who-has  tell 
| >
| >(Config file and lspci output are attached)
| 
| how about dmesg? Perhaps it shows some valuable information.

Am attaching the dmesg.out

| 
| also, since this is a networking problem, please include `ifconfig eth0` 
| and the full output of `ethtool eth0` and `ethtool -S eth0`

$ ifconfig eth0

eth0  Link encap:Ethernet  HWaddr 00:02:B3:9D:D4:D7  
  inet addr:10.0.67.166  Bcast:10.0.67.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:564 errors:0 dropped:5927 overruns:0 frame:0
  TX packets:105 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:100 
  RX bytes:81803 (79.8 KiB)  TX bytes:6720 (6.5 KiB)
  Base address:0x3400 Memory:e824-e826 


$ ethtool eth0

Settings for eth0:
Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full 
100baseT/Half 100baseT/Full 
1000baseT/Full 
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full 
100baseT/Half 100baseT/Full 
1000baseT/Full 
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: umbg
Wake-on: g
Current message level: 0x0007 (7)
Link detected: yes

$ ethtool -S eth0

NIC statistics:
 rx_packets: 564
 tx_packets: 105
 rx_bytes: 81803
 tx_bytes: 6720
 rx_errors: 0
 tx_errors: 0
 tx_dropped: 0
 multicast: 11
 collisions: 0
 rx_length_errors: 0
 rx_over_errors: 0
 rx_crc_errors: 0
 rx_frame_errors: 0
 rx_no_buffer_count: 310
 rx_missed_errors: 5865
 tx_aborted_errors: 0
 tx_carrier_errors: 0
 tx_fifo_errors: 0
 tx_heartbeat_errors: 0
 tx_window_errors: 0
 tx_abort_late_coll: 0
 tx_deferred_ok: 0
 tx_single_coll_ok: 0
 tx_multi_coll_ok: 0
 tx_timeout_count: 0
 rx_long_length_errors: 0
 rx_short_length_errors: 0
 rx_align_errors: 0
 tx_tcp_seg_good: 0
 tx_tcp_seg_failed: 0
 rx_flow_control_xon: 0
 rx_flow_control_xoff: 0
 tx_flow_control_xon: 0
 tx_flow_control_xoff: 0
 rx_long_byte_count: 81803
 rx_csum_offload_good: 0
 rx_csum_offload_errors: 0
 rx_header_split: 0
 alloc_rx_buff_failed: 0

Hope this helps. Let me know if you need more info.

Suka
[0.00] Linux version 2.6.18-mm1 ([EMAIL PROTECTED]) (gcc version 4.

Re: [PATCH] bcm43xx-softmac: fix warning from ignoring returned value from pci_enable_device


Ian McDonald wrote:

On 9/28/06, Larry Finger <[EMAIL PROTECTED]> wrote:
Linus's tree now has a configuration option that prints a warning 
whenever
the returned value of any routine is ignored. This patch fixes the 
only such

warning for bcm43xx.


Can you tell me how to make this check please so I can check my code
in the kernel? I could look it up but obviously you can tell me
quickly :-)


It is the ENABLE_MUST_CHECK option that appeared with the 2.6.18-gitX updates in Linus's tree, where 
I think X was 4 or 6. When this was turned on, there were a LOT of new warnings.


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

Re: [ACRYPTO] New asynchronous crypto layer (acrypto) release.

2006-09-28 Thread Andreas Jellinghaus


Evgeniy Polyakov wrote:

Hello.

I'm pleased to announce asynchronous crypto layer (acrypto) [1] release 
for 2.6.18 kernel tree. Acrypto allows to handle crypto requests 
asynchronously in hardware.


Combined patchset includes:
 * acrypto core
 * IPsec ESP4 port to acrypto
 * dm-crypt port to acrypto


so I should be able to replace a plain 2.6.18 kernel with one
with this patchset and use dm-crypt'ed partitions (e.g. swap,
encrypted root filesystem) as usual without further changes?

Did anyone test this with success?

Regards, Andreas

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

Re: 2.6.18-mm2

2006-09-28 Thread Andrew Morton


(please always do reply-to-all)

On Thu, 28 Sep 2006 17:50:31 + (UTC)
"Steve Fox" <[EMAIL PROTECTED]> wrote:

> On Thu, 28 Sep 2006 01:46:23 -0700, Andrew Morton wrote:
> 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18/2.6.18-mm2/
> 
> Panic on boot. This machine booted 2.6.18-mm1 fine. em64t machine.
> 
> TCP bic registered
> TCP westwood registered
> TCP htcp registered
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> Unable to handle kernel paging request at  RIP: 
>  [] packet_notifier+0x163/0x1a0
> PGD 203027 PUD 2b031067 PMD 0 
> Oops:  [1] SMP 
> last sysfs file: 
> CPU 0 
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.18-mm2-autokern1 #1
> RIP: 0010:[]  [] 
> packet_notifier+0x163/0x1a0
> RSP: :810bffcbde90  EFLAGS: 00010286
> RAX:  RBX: 810bff4a1000 RCX: 
> RDX: 810bff4a1000 RSI: 0005 RDI: 8055f5e0
> RBP:  R08: 7616 R09: 000e
> R10: 0006 R11: 803373f0 R12: 
> R13: 0005 R14: 810bff4a1000 R15: 
> FS:  () GS:805d8000() knlGS:
> CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
> CR2:  CR3: 00201000 CR4: 06e0
> Process swapper (pid: 1, threadinfo 810bffcbc000, task 810bffcbb510)
> Stack:  810bff4a1000 8055f4c0  810bffcbdef0
>   8042736e  
>   8061c68d 806260f0 80207182
> Call Trace:
>  [] register_netdevice_notifier+0x3e/0x70
>  [] packet_init+0x2d/0x53
>  [] init+0x162/0x330
>  [] child_rip+0xa/0x12
>  [] acpi_ds_init_one_object+0x0/0x82
>  [] init+0x0/0x330
>  [] child_rip+0x0/0x12
> 
> 
> Code: 48 8b 45 00 0f 18 08 49 83 fd 02 4c 8d 65 f8 0f 84 f8 fe ff 
> RIP  [] packet_notifier+0x163/0x1a0
>  RSP 
> CR2: 
>  <0>Kernel panic - not syncing: Attempted to kill init!
> 

I'm really struggling to work out what went wrong there.  Comparing your
miserable 20 bytes of code to my object code makes me think that this:

struct packet_sock *po = pkt_sk(sk);

returned -1, perhaps in %ebp.  But it's all very crude.

Perhaps you could compile that kernel with CONFIG_DEBUG_INFO, rerun it (the
addresses might change) then have a poke around with `gdb vmlinux' (or
maybe just addr2line) to work out where it's really oopsing?

I don't see much which has changed in that area recently.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Network problem with 2.6.18-mm1 ?

2006-09-28 Thread Jesse Brandeburg


On 9/28/06, Sukadev Bhattiprolu <[EMAIL PROTECTED]> wrote:

Thanks. See below for additional info

Auke Kok [EMAIL PROTECTED] wrote:
| Sukadev Bhattiprolu wrote:
| >
| >I am unable to get networking to work with 2.6.18-mm1 on my system.
| >
| >But 2.6.18 kernel on same system works fine. Here is some info about
| >the system/debug attempts. Attached are the lspci output and config.
| >
| >Appreciate any help. Please let me know if you need more info.


It seems you're having interrupt delivery problems or interrupts are
getting lost.
rx_missed_errors indicates frames that were dropped due to the e1000
adapter's fifo getting full and over flowing.

rx_no_buffer_count: 310
rx_missed_errors: 5865

rx_no_buffer_count indicates that the driver didn't return buffers to
the hardware soon enough, but the hardware was able to store the
packet (at the time of reception) in the fifo to try again.

Both these indicate to me that there is something wrong with
interrupts.  Maybe interrupt sharing

can you possibly try a back to back connection with another linux box
and run tcpdump on both ends then ping?  it will tell us if traffic is
truely getting out and coming in okay.

also please send output of lspci -vv and cat /proc/interrupts

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

Re: Bluetooth update for 2.6

2006-09-28 Thread Marcel Holtmann

Hi Dave,

> > > here are the pending patches that didn't make it into the 2.6.18 kernel
> > > release. I have some additional fixes, but all of them need some more
> > > additional testing from my side.
> > 
> > it seems that you haven't pulled in these changes so far. So I didn't
> > rebase the tree and simply pushed some additional ones on top of it. All
> > three of them address the issues we had with non-blocking connects.
> 
> I applied all of your fixes into my tree, sorry for taking so long.

no big problem. If you haven't synced with Linus yet, then I have two
small additional fixes that should go in with the others.

Regards

Marcel


Please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git

This will update the following files:

 net/bluetooth/hci_event.c |8 
 net/bluetooth/hci_sysfs.c |2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

through these ChangeSets:

Marcel Holtmann <[EMAIL PROTECTED]> Thu, 28 Sep 2006 20:23:29 +0200 

[Bluetooth] Fix section mismatch of bt_sysfs_cleanup()

The bt_sysfs_cleanup() is marked with __exit attribute, but it will
be called from an __init function in the error case. So the __exit
attribute must be removed.

Signed-off-by: Arnaud Patard <[EMAIL PROTECTED]>
Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]>

Marcel Holtmann <[EMAIL PROTECTED]> Tue, 26 Sep 2006 22:18:03 +0200 

[Bluetooth] Don't update disconnect timer for incoming connections

In the case of device pairing the only safe method is to establish
a low-level ACL link. In this case, the remote side should not use
the disconnect timer to give the other side the chance to enter the
PIN code. If the disconnect timer is used, the connection will be
dropped to soon, because it is impossible to identify an actual user
of this link.

Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]>



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

Re: [GIT PATCH] NET: Fixes for net-2.6.19

From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 08:36:45 -0700

> Please figure out how to keep rtnetlink.h useful from user space.
> I tried putting the current sanitized version of rtnetlink.h into
> iproute2 and the build fails. 

Please give the error so I have a chance of fixing this.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Patch] Remove unnecessary check in net/sunrpc/svcsock.c

From: Eric Sesterhenn <[EMAIL PROTECTED]>
Date: Wed, 27 Sep 2006 17:34:49 +0200

> coverity spotted this one as possible dereference in the dprintk(),
> but since there is only one caller of svc_create_socket(), which always
> passes a valid sin, we dont need this check.
> 
> Signed-off-by: Eric Sesterhenn <[EMAIL PROTECTED]>

Applied, thanks Eric.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] tcp-lp: prevent chance for oops

From: "Wong Edison" <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 18:43:58 +0800

> This patch fix the chance for tcp_lp_remote_hz_estimator return 0, if
> 0 < rhz < 64. It also make sure the flag LP_VALID_RHZ is set
> correctly.
> 
> Signed-off-by: Wong Hoi Sing Edison <[EMAIL PROTECTED]>

Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] tcp-lp: prevent chance for oops

From: "Wong Edison" <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 18:43:58 +0800

>   *
> - * Version: $Id: tcp_lp.c,v 1.24 2006/09/05 20:22:53 hswong3i Exp $
> + * Version: $Id: tcp_lp.c,v 1.25 2006/09/22 20:50:27 hswong3i Exp $

BTW, I'm deleting this line from the source file in the tree
because every patch you send doesn't apply cleanly because
your patch is against a different string on this line and we
don't use $Id$ tags in the kernel sources anyways.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel: TKIP: replay detected:


Jouni Malinen wrote:


TKIP/CCMP are required to use incrementing TSC/PN for each frame. When a
directed IEEE 802.11 frame is not acknowledged, it will be retransmitted
(up to a certain limit). This retransmitted frame will use the same
TSC/PN. However, the duplicate detection routine in the receiver
(something that happens before TKIP/CCMP processing) should catch these
cases since the frames from the same source address that use the same
seq# and fragm# should be dropped at that layer.

If it can be shown, that these errors are indeed caused by a broken
transmitter (and that transmitter is not a Linux device for which we
control the driver code ;-), I would be much more willing to accept
patches that silence these messages (as long as the replay statistics
are easily available in other ways) by default, but I would still not
remove them completely.



I added the following patch to bcm43xx:

Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
@@ -460,6 +460,9 @@ static s8 bcm43xx_rssinoise_postprocess(
 }
 #endif

+static u16 prev_frame = 0;
+static u16 prev_seq = 0;
+
 int bcm43xx_rx(struct bcm43xx_private *bcm,
   struct sk_buff *skb,
   struct bcm43xx_rxhdr *rxhdr)
@@ -470,6 +473,7 @@ int bcm43xx_rx(struct bcm43xx_private *b
struct ieee80211_rx_stats stats;
struct ieee80211_hdr_4addr *wlhdr;
u16 frame_ctl;
+   u16 seq_ctl;
int is_packet_for_us = 0;
int err = -EINVAL;
const u16 rxflags1 = le16_to_cpu(rxhdr->flags1);
@@ -544,6 +548,14 @@ int bcm43xx_rx(struct bcm43xx_private *b
}

frame_ctl = le16_to_cpu(wlhdr->frame_ctl);
+   seq_ctl = le16_to_cpu(wlhdr->seq_ctl);
+
+   if ((frame_ctl == prev_frame) && (seq_ctl == prev_seq))
+   return -EINVAL;
+
+   prev_frame = frame_ctl;
+   prev_seq = seq_ctl;
+
if ((frame_ctl & IEEE80211_FCTL_PROTECTED) && !bcm->ieee->host_decrypt) 
{
frame_ctl &= ~IEEE80211_FCTL_PROTECTED;
wlhdr->frame_ctl = cpu_to_le16(frame_ctl);   



By dropping those packets with frame_ctl and seq_ctl the same as the values in the previous packet, 
I was able to cut the number of TKIP replay messages, but some still come through. Is this what you 
had in mind, or is there somewhere else that I should be looking?


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

Re: simplify microsecond rtt sampling

From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 09:36:50 -0700

> On Thu, 28 Sep 2006 13:47:28 +0100
> John Heffner <[EMAIL PROTECTED]> wrote:
> 
> > Sigh.  Here's one that's not corrupted.  And for the record:
> > 
> > 
> > This changes the microsecond RTT sampling so that samples are taken in 
> > the same way that RTT samples are taken for the RTO calculator: on the 
> > last segment acknowledged, and only when the segment hasn't been 
> > retransmitted.
> > 
> > 
> > Signed-off-by: John Heffner <[EMAIL PROTECTED]>
> 
> Looks ok. I wish skbuff timestamp was converted to ktime.

It looks good to me too, applied.

Since this is really a bug fix, I'm goint to push this into
-stable as well.

Thanks a lot.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] let mortals use ethtool

From: Auke Kok <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 12:56:25 -0700

> PHYS_ID pokes in hardware and makes it jump through hoops, in the case of 
> some hardware 
> this could create a local DOS attack (e1000 suffers fromt his, probably more 
> if not all) 
> where the NIC might stop receiving packets, or the big lock is help 
> indefinately.
> 
> Not a good idea
> 
> The other ones are fine I think.

I've applied Stephen's patch with PHYS_ID removed from the
allowed list, thanks for the feedback.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] let mortals use ethtool

2006-09-28 Thread Michael Chan

On Thu, 2006-09-28 at 14:53 -0700, David Miller wrote:

> I've applied Stephen's patch with PHYS_ID removed from the
> allowed list, thanks for the feedback.

Can you remove GREGS as well?  Allowing users to dump all the registers
will be very problematic.

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

Re: [RFC] let mortals use ethtool

From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 13:17:04 -0700

> I'm against letting normal users do ETHTOOL_GREGS and ETHTOOL_PHYS_ID.
> Dumping 64K worth of registers and blinking the LEDs should be
> restricted.  But I have no problem doing these checks in the driver if
> necessary.

Ok I removed PHYS_ID and GREGS from the allowed list.
Any others?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] let mortals use ethtool

From: James Morris <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 16:32:38 -0400 (EDT)

> On Thu, 28 Sep 2006, Michael Chan wrote:
> 
> > I'm against letting normal users do ETHTOOL_GREGS and ETHTOOL_PHYS_ID.
> > Dumping 64K worth of registers and blinking the LEDs should be
> > restricted.
> 
> Out of curiosity -- why?

Reading some registers might have side effects, that's one thing.

Secondarily, looping over reading all of the registers of the chip
might kill performance since the IO accesses compete with the
normal packet sending/receiving operations.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] let mortals use ethtool

From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 16:23:46 -0400

> NAK.
> 
> Some functions in the past didn't like getting hit rapidly in succession.
> 
> I would agree to this, but only after an exhaustive audit of each driver 
> and each sub-ioctl.  Right now, I only have confidence in GDRVINFO 
> probably being safe -- but still that requires an audit, since in rare 
> cases the driver may be poking firmware and eeprom areas.

I think the purely software state ones are safe, such as GDRVINGO,
GSG, GTSO, etc.  This absolutely excludes things like PHYS_ID
and GREGS which almost always have to touch the hardware.

> Finally, I fixed a buffer overflow in ethtool version 5, so an audit to 
> make sure overflows cannot affect the kernel is basically _required_.

Absolutely.

I think we should put in Stephen's change with the obvious PHYS_ID
and GREGS exceptions removed.  We have a lot of time to make sure
everything remaining is kosher for 2.6.19 ok?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] let mortals use ethtool

From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 15:03:40 -0700

> On Thu, 2006-09-28 at 14:53 -0700, David Miller wrote:
> 
> > I've applied Stephen's patch with PHYS_ID removed from the
> > allowed list, thanks for the feedback.
> 
> Can you remove GREGS as well?  Allowing users to dump all the registers
> will be very problematic.

I did, see my subsequent email.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] let mortals use ethtool

David Miller wrote:

From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 13:17:04 -0700

I'm against letting normal users do ETHTOOL_GREGS and ETHTOOL_PHYS_ID.
Dumping 64K worth of registers and blinking the LEDs should be
restricted.  But I have no problem doing these checks in the driver if
necessary.

Ok I removed PHYS_ID and GREGS from the allowed list.
Any others?

GWOL now spits out a password for all users -> security risk.  Ditto 
GEEPROM.  GSET has been known to cause hangs if done in a tight loop, on 
some 10/100 cards, which is now permitted by any user.  At the very 
least, it should be rate-limited.

I wasn't just being obstinate, when requesting an audit.

Jeff

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

Re: Bluetooth update for 2.6

From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 23:14:44 +0200

> > > > here are the pending patches that didn't make it into the 2.6.18 kernel
> > > > release. I have some additional fixes, but all of them need some more
> > > > additional testing from my side.
> > > 
> > > it seems that you haven't pulled in these changes so far. So I didn't
> > > rebase the tree and simply pushed some additional ones on top of it. All
> > > three of them address the issues we had with non-blocking connects.
> > 
> > I applied all of your fixes into my tree, sorry for taking so long.
> 
> no big problem. If you haven't synced with Linus yet, then I have two
> small additional fixes that should go in with the others.

I've applied these 2 changes as patches to my tree, thanks a lot.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] let mortals use ethtool


David Miller wrote:

Secondarily, looping over reading all of the registers of the chip
might kill performance since the IO accesses compete with the
normal packet sending/receiving operations.


This can be true of any ethtool sub-ioctl that beats the registers, if 
run in a tight loop.  PHYs are particularly nasty, because outside of 
hardware problems mentioned in the previous email, many phy read 
routines contain a metric ton of udelay() and mdelay()s.  Now, an 
unpriv'd user can cause the kernel to do tons of in-kernel busy-waits, 
in effect spinning the CPU at their mercy.


Jeff


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

Re: [RFC] let mortals use ethtool

From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 18:25:26 -0400

> GWOL now spits out a password for all users -> security risk.  Ditto 
> GEEPROM.  GSET has been known to cause hangs if done in a tight loop, on 
> some 10/100 cards, which is now permitted by any user.  At the very 
> least, it should be rate-limited.
> 
> I wasn't just being obstinate, when requesting an audit.

Ok, I've removed GSET, GWOL and GSTATS (GEEPROM was not in the
original list in Stephen's patch).  In fact I'll remove
GLINK too as that might touch the hardware as well.

That leaves us with:

case ETHTOOL_GDRVINFO:
case ETHTOOL_GMSGLVL:
case ETHTOOL_GCOALESCE:
case ETHTOOL_GRINGPARAM:
case ETHTOOL_GPAUSEPARAM:
case ETHTOOL_GRXCSUM:
case ETHTOOL_GTXCSUM:
case ETHTOOL_GSG:
case ETHTOOL_GSTRINGS:
case ETHTOOL_GTSO:
case ETHTOOL_GPERMADDR:
case ETHTOOL_GUFO:
case ETHTOOL_GGSO:

Which should be ok.

And once again, take even this list with a grain of salt, we
have until 2.6.19-final to sort this out and audit things.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel: TKIP: replay detected:

On Thu, Sep 28, 2006 at 04:42:10PM -0500, Larry Finger wrote:

> @@ -544,6 +548,14 @@ int bcm43xx_rx(struct bcm43xx_private *b
>   }
> 
>   frame_ctl = le16_to_cpu(wlhdr->frame_ctl);
> + seq_ctl = le16_to_cpu(wlhdr->seq_ctl);
> +
> + if ((frame_ctl == prev_frame) && (seq_ctl == prev_seq))
> + return -EINVAL;
> +
> + prev_frame = frame_ctl;
> + prev_seq = seq_ctl;

> By dropping those packets with frame_ctl and seq_ctl the same as the values 
> in the previous packet, I was able to cut the number of TKIP replay 
> messages, but some still come through. Is this what you had in mind, or is 
> there somewhere else that I should be looking?

This is quite close to what I had in mind and is likely okay for
testing, but would not be generic enough to be something I would like to
see in the main kernel tree. See IEEE 802.11 clause 9.2.9 for the
details of what the receiver needs to do (mainly, the validation of
addr2 and per STA prev_seq is needed for AP and IBSS modes). In
addition, this should really be in the generic IEEE 802.11 code and
there are couple of optimizations which can be used when combining this
with defragmentation (see, e.g., net/d80211/ieee80211.c
ieee80211_rx_h_check).

Did the replay messages still show the same TSC/PN or did you get rid of
all messages that had the same number repeated?

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] let mortals use ethtool

On Thu, 28 Sep 2006 16:23:46 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:

> Stephen Hemminger wrote:
> > There is no reason to not allow non-admin users to query network
> > statistics and settings.
> 
> NAK.
> 
> Some functions in the past didn't like getting hit rapidly in succession.
> 
> I would agree to this, but only after an exhaustive audit of each driver 
> and each sub-ioctl.  Right now, I only have confidence in GDRVINFO 
> probably being safe -- but still that requires an audit, since in rare 
> cases the driver may be poking firmware and eeprom areas.
> 
> Finally, I fixed a buffer overflow in ethtool version 5, so an audit to 
> make sure overflows cannot affect the kernel is basically _required_.
> 
>   Jeff

The first step should be conservative, so why not allow GDRVINFO, and the
various offload setting GTSO, GxSUM, ...

Agreed, that PHY stuff, register area, WOL, are bad. The statistics stuff
also might be a problem for some chips.

-- 
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PATCH] NET: Fixes for net-2.6.19