Re: bug in tcp?

[Philip Craig]

Sebastian Kuzminsky wrote:
 Weird.  Why does sending a message from the client make it go again?

The rule that allows packets with an ESTABLISHED state only matches
packets for which the connection is in netfilter's conntrack table.
The connection is removed from the table after the 5 days of idle.
It is only added again if netfilter accepts a packet for that connection.
So the packet from the client will cause it to be added.

 If that's the case, it seems like a simple fix would be to enable TCP
 keepalive in my app, that would keep netfilter from timing out, right?
 That seems better than extending the netfilter timeout.

Yes that would work.

 How do people normally handle this?

Change the timeout or use keepalives.  I can't think of any other way.
The 5 days is a compromise between keeping valid connections and
timing out dead connections.  There will always be connections for
which it times out too fast or too slow.  I don't think there are
any drawbacks to increasing the timeout if you aren't a router,
but as long as there is a timeout, you need keepalives to be sure.

-
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] Fix UDP checksum issue in net poll mode.

[Aubrey Li]

In net poll mode, the current checksum function doesn't consider the
kind of packet which is padded to reach a specific minimum length. I
believe that's the problem causing my test case failed. The following
patch fixed this issue.

Signed-off-by: Aubrey.Li [EMAIL PROTECTED]
---
net/core/netpoll.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 823215d..522e441 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -471,6 +471,13 @@ int __netpoll_rx(struct sk_buff *skb)
if (skb-len  len || len  iph-ihl*4)
goto out;

+   /*
+* Our transport medium may have padded the buffer out.
+* Now We trim to the true length of the frame.
+*/
+   if (pskb_trim_rcsum(skb, len))
+   goto out;
+
if (iph-protocol != IPPROTO_UDP)
goto out;

--
1.5.1
-
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: + ppp_generic-fix-lockdep-warning.patch added to -mm tree

[Jarek Poplawski]

On Wed, Apr 11, 2007 at 12:52:28PM +0400, Yuriy N. Shkandybin wrote:
...
 On Wed, 11 Apr 2007 09:57:33 +0400 Yuriy N. Shkandybin [EMAIL PROTECTED] 
 wrote:
 
 I've tested  2.6.21-rc6-mm1
 Linux vpn1 2.6.21-rc6-mm1 #4 SMP Wed Apr 11 03:34:26 MSD 2007 x86_64
 Intel(R) Pentium(R) D CPU 2.80GHz GenuineIntel GNU/Linux
 
 warn appeares upon first pppoe connection to rp-pppoe server in kernel 
 mode
 
 
 Thanks.  So you're saying that
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/ppp_generic-fix-lockdep-warning.patch
 did not fix anything?
 As i understand this patch already in -mm tree, so I've booted into last mm 
 kernel and received this locked warning.
 Or i've mistaked and should apply this patch manually?

Hi!

Yuriy - thanks for testing my patch ...(pause) Not!

It seems this patch is not visible in this version - probably
is overpatched by something else. But your new log shows there
is another connection between these locks (ppp_xmit_process
and ppp_push instead of ppp_channel_push in - #0), so the
patch is not sufficient (and could be dumped).

I don't know your vlans configuration, but it seems the real
lockup isn't very probable here - it's rather lockdep question.
I think vlan's too broad lockdep class is the main guilty
here, but probably pppoe also could be enhanced: it's making
the things unnecessarily complicated by calling dev_queue_xmit
under ppp_generic's xmit locks. I wonder if there is any reason
against using a tasklet here.

I'll try to find more time to untie this yet - or maybe some
maintainer will find this interesting, too...

Regards,
Jarek P.

PS: sorry for late responding (vacations).
-
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 net-2.6.22 1/3] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...)

[Ilpo Järvinen]

On Mon, 16 Apr 2007, David Miller wrote:
 From: Ilpo_Järvinen [EMAIL PROTECTED]
 Date: Mon, 16 Apr 2007 19:19:02 +0300 (EEST)
 
  [PATCH] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...)
 
 I was trying to spread out the net-2.6.22 tree from the tcp-2.6
 one so that we could do the experimental TCP stuff in the tcp-2.6
 tree and leave other networking changes for net-2.6.22
 
 Putting in TCP cleanups which touch a lot of code into net-2.6.22
 defeats that effort because now there will be all kinds of rejects and
 merge errors people will have to deal with if they clone a net-2.6.22
 tree then pull in tcp-2.6 to do some TCP hacking which is valid.
 
 I suppose we can live with that, and just tell people to just pull
 tcp-2.6 into a fresh linux-2.6 tree straight, but it's going to make
 rebasing difficult for me as well.

 net-2.6.22 is already approaching 350 patches, it's a monster and
 the merge conflicts and rebasing pain are really getting hard to
 deal with.

I fully understand your concerns (I had already though that you might 
rather want to put this kind of thing to tcp-2.6)... It will be almost 
trivial to base it to tcp-2.6 because it's, well, (mostly) automated.
I'll try to get that done today so you'll have less worries... :-)


-- 
 i.

Re: TCP connection stops after high load.

[Robert Iakobashvili]

David,

On 4/16/07, David Miller [EMAIL PROTECTED] wrote:

  Commit: 53cdcc04c1e85d4e423b2822b66149b6f2e52c2c
  Author: John Heffner [EMAIL PROTECTED] Fri, 16 Mar 2007 15:04:03 -0700
 
   [TCP]: Fix tcp_mem[] initialization.
   Change tcp_mem initialization function.  The fraction of total memory
   is now a continuous function of memory size, and independent of page
   size.


 Kernels 2.6.19 and 2.6.20 series are effectively broken right now.
 Don't you wish to patch them?

Can you verify that this patch actually fixes your problem?


Yes, it fixes.

After the patch curl-loader works with patched 2.6.19.7 and
with patched 2.6.20.7 using simulteneous 3000 local connections smothly,
and even better than with referred as a good 2.6.18.3.


Besides that the tcp_mem status for my machine:

kernel tcp_mem
--
2.6.19.7 30724096 6144
2.6.19.7-patched45696   60928   91392
2.6.20.7 30724096 6144
2.6.20.7-patched45696   60928   91392

The patch was applied smothly just with line offsets.

--
Sincerely,
Robert Iakobashvili,
coroberti %x40 gmail %x2e com
...
Navigare necesse est, vivere non est necesse
...
http://curl-loader.sourceforge.net
An open-source HTTP/S, FTP/S traffic
generating, and web testing tool.
-
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 3/7] NetXen: Multi PCI support for Quad cards

[Mithlesh Thukral]

On Monday 16 April 2007 23:19, Stephen Hemminger wrote:
 On Fri, 13 Apr 2007 08:39:31 -0700

 Linsys Contractor Mithlesh Thukral [EMAIL PROTECTED] wrote:
  NetXen: Fix the multi PCI function for cards with more than 2 ports.
  This patch fixes the working of multi PCI capable driver on cards with
  more than 2 ports by adding the addresses for their rings and sizes.
 
  Signed-off by: Mithlesh Thukral [EMAIL PROTECTED]
 
  ---
 
   drivers/net/netxen/netxen_nic_hw.c   |  119 +++--
   drivers/net/netxen/netxen_nic_init.c |4
   drivers/net/netxen/netxen_nic_main.c |   61 +-
   drivers/net/netxen/netxen_nic_phan_reg.h |6 -
   4 files changed, 146 insertions(+), 44 deletions(-)
 
  diff --git a/drivers/net/netxen/netxen_nic_hw.c
  b/drivers/net/netxen/netxen_nic_hw.c index a066208..274a261 100644
  --- a/drivers/net/netxen/netxen_nic_hw.c
  +++ b/drivers/net/netxen/netxen_nic_hw.c
  @@ -140,8 +140,105 @@ struct netxen_recv_crb recv_crb_register
   NETXEN_NIC_REG(0x180),
   /* crb_status_ring_size */
   NETXEN_NIC_REG(0x184),
  -
   },
  +   /*
  +* Instance 3,
  +*/
  +   {
  + {
  +   {
  +   /* crb_rcv_producer_offset: */
  +   NETXEN_NIC_REG(0x1d8),
  +   /* crb_rcv_consumer_offset: */
  +   NETXEN_NIC_REG(0x1dc),
  +   /* crb_gloablrcv_ring: */
  +   NETXEN_NIC_REG(0x1f0),
  +   /* crb_rcv_ring_size */
  +   NETXEN_NIC_REG(0x1f4),
  +   },
  +   /* Jumbo frames */
  +   {
  +   /* crb_rcv_producer_offset: */
  +   NETXEN_NIC_REG(0x1f8),
  +   /* crb_rcv_consumer_offset: */
  +   NETXEN_NIC_REG(0x1fc),
  +   /* crb_gloablrcv_ring: */
  +   NETXEN_NIC_REG(0x200),
  +   /* crb_rcv_ring_size */
  +   NETXEN_NIC_REG(0x204),
  +   },
  +   /* LRO */
  +   {
  +   /* crb_rcv_producer_offset: */
  +   NETXEN_NIC_REG(0x208),
  +   /* crb_rcv_consumer_offset: */
  +   NETXEN_NIC_REG(0x20c),
  +   /* crb_gloablrcv_ring: */
  +   NETXEN_NIC_REG(0x210),
  +   /* crb_rcv_ring_size */
  +   NETXEN_NIC_REG(0x214),
  +   }
  + },
  + /* crb_rcvstatus_ring: */
  + NETXEN_NIC_REG(0x218),
  + /* crb_rcv_status_producer: */
  + NETXEN_NIC_REG(0x21c),
  + /* crb_rcv_status_consumer: */
  + NETXEN_NIC_REG(0x220),
  + /* crb_rcvpeg_state: */
  + NETXEN_NIC_REG(0x224),
  + /* crb_status_ring_size */
  + NETXEN_NIC_REG(0x228),
  +   },
  +   /*
  +* Instance 4,
  +*/
  +   {
  + {
  +   {
  +   /* crb_rcv_producer_offset: */
  +   NETXEN_NIC_REG(0x22c),
  +   /* crb_rcv_consumer_offset: */
  +   NETXEN_NIC_REG(0x230),
  +   /* crb_gloablrcv_ring: */
  +   NETXEN_NIC_REG(0x234),
  +   /* crb_rcv_ring_size */
  +   NETXEN_NIC_REG(0x238),
  +   },
  +   /* Jumbo frames */
  +   {
  +   /* crb_rcv_producer_offset: */
  +   NETXEN_NIC_REG(0x23c),
  +   /* crb_rcv_consumer_offset: */
  +   NETXEN_NIC_REG(0x240),
  +   /* crb_gloablrcv_ring: */
  +   NETXEN_NIC_REG(0x244),
  +   /* crb_rcv_ring_size */
  +   NETXEN_NIC_REG(0x248),
  +   },
  +   /* LRO */
  +   {
  +   /* crb_rcv_producer_offset: */
  +   NETXEN_NIC_REG(0x24c),
  +   /* crb_rcv_consumer_offset: */
  +   NETXEN_NIC_REG(0x250),
  +   /* crb_gloablrcv_ring: */
  +   NETXEN_NIC_REG(0x254),
  +   /* crb_rcv_ring_size */
  +   NETXEN_NIC_REG(0x258),
  +   }
  + },
  + /* crb_rcvstatus_ring: */
  + NETXEN_NIC_REG(0x25c),
  + /* crb_rcv_status_producer: */
  + NETXEN_NIC_REG(0x260),
  + /* crb_rcv_status_consumer: */
  + NETXEN_NIC_REG(0x264),
  + /* crb_rcvpeg_state: */
  + NETXEN_NIC_REG(0x268),
  + /* crb_status_ring_size */
  + NETXEN_NIC_REG(0x26c),
  +   },
   };
 
   u64 ctx_addr_sig_regs[][3] = {
  @@ -294,6 +391,7 @@ int netxen_nic_hw_resources(struct netxe
  u32 card_cmdring = 0;
  struct netxen_recv_context *recv_ctx;
  struct netxen_rcv_desc_ctx *rcv_desc;
  +   int func_id = adapter-portnum;
 
  DPRINTK(INFO, crb_base: %lx %x, NETXEN_PCI_CRBSPACE,
  PCI_OFFSET_SECOND_RANGE(adapter, NETXEN_PCI_CRBSPACE));
  @@ -341,7 +439,7 @@ int netxen_nic_hw_resources(struct netxe
  adapter-ctx_desc_pdev);
 
  printk(KERN_INFO ctx_desc_phys_addr: 0x%llx\n,
  -  (unsigned long long) adapter-ctx_desc_phys_addr);
  +  (u64) adapter-ctx_desc_phys_addr);

 This will give a warning on 64 bit platforms because format doesn't match
 width. You need to cast to (unsigned long long).
Thanks for pointing this out.
I will fix this in a repost of the patch set.

Regards,
Mithlesh Thukral
-
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] KEY: Fix conversion between IPSEC_MODE_xxx and XFRM_MODE_xxx.

[YOSHIFUJI Hideaki / 吉藤英明]

From: Kazunori MIYAZAWA [EMAIL PROTECTED]
Subject: [PATCH] KEY: Fix conversion between IPSEC_MODE_xxx and XFRM_MODE_xxx.

We should not blindly convert between IPSEC_MODE_xxx and XFRM_MODE_xxx just
by incrementing / decrementing because the assumption is not true any longer.

Signed-off-by: Kazunori MIYAZAWA [EMAIL PROTECTED]
Singed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]

diff --git a/net/key/af_key.c b/net/key/af_key.c
index 90deefe..a61e6f6 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -630,6 +630,35 @@ #endif
/* NOTREACHED */
 }
 
+static inline int pfkey_mode_from_xfrm(int mode)
+{
+   switch(mode) {
+   case XFRM_MODE_TRANSPORT:
+   return IPSEC_MODE_TRANSPORT;
+   case XFRM_MODE_TUNNEL:
+   return IPSEC_MODE_TUNNEL;
+   case XFRM_MODE_BEET:
+   return IPSEC_MODE_BEET;
+   default:
+   return -1;
+   }
+}
+
+static inline int pfkey_mode_to_xfrm(int mode)
+{
+   switch(mode) {
+   case IPSEC_MODE_ANY:/*XXX*/
+   case IPSEC_MODE_TRANSPORT:
+   return XFRM_MODE_TRANSPORT;
+   case IPSEC_MODE_TUNNEL:
+   return XFRM_MODE_TUNNEL;
+   case IPSEC_MODE_BEET:
+   return XFRM_MODE_BEET;
+   default:
+   return -1;
+   }
+}
+
 static struct sk_buff * pfkey_xfrm_state2msg(struct xfrm_state *x, int 
add_keys, int hsc)
 {
struct sk_buff *skb;
@@ -651,6 +680,7 @@ #endif
int encrypt_key_size = 0;
int sockaddr_size;
struct xfrm_encap_tmpl *natt = NULL;
+   int mode;
 
/* address family check */
sockaddr_size = pfkey_sockaddr_size(x-props.family);
@@ -928,7 +958,11 @@ #endif
sa2 = (struct sadb_x_sa2 *)  skb_put(skb, sizeof(struct sadb_x_sa2));
sa2-sadb_x_sa2_len = sizeof(struct sadb_x_sa2)/sizeof(uint64_t);
sa2-sadb_x_sa2_exttype = SADB_X_EXT_SA2;
-   sa2-sadb_x_sa2_mode = x-props.mode + 1;
+   if ((mode = pfkey_mode_from_xfrm(x-props.mode))  0) {
+   kfree_skb(skb);
+   return ERR_PTR(-EINVAL);
+   }
+   sa2-sadb_x_sa2_mode = mode;
sa2-sadb_x_sa2_reserved1 = 0;
sa2-sadb_x_sa2_reserved2 = 0;
sa2-sadb_x_sa2_sequence = 0;
@@ -1155,9 +1189,12 @@ static struct xfrm_state * pfkey_msg2xfr
 
if (ext_hdrs[SADB_X_EXT_SA2-1]) {
struct sadb_x_sa2 *sa2 = (void*)ext_hdrs[SADB_X_EXT_SA2-1];
-   x-props.mode = sa2-sadb_x_sa2_mode;
-   if (x-props.mode)
-   x-props.mode--;
+   int mode = pfkey_mode_to_xfrm(sa2-sadb_x_sa2_mode);
+   if (mode  0) {
+   err = -EINVAL;
+   goto out;
+   }
+   x-props.mode = mode;
x-props.reqid = sa2-sadb_x_sa2_reqid;
}
 
@@ -1218,7 +1255,7 @@ static int pfkey_getspi(struct sock *sk,
struct sadb_address *saddr, *daddr;
struct sadb_msg *out_hdr;
struct xfrm_state *x = NULL;
-   u8 mode;
+   int mode;
u32 reqid;
u8 proto;
unsigned short family;
@@ -1233,7 +1270,9 @@ static int pfkey_getspi(struct sock *sk,
return -EINVAL;
 
if ((sa2 = ext_hdrs[SADB_X_EXT_SA2-1]) != NULL) {
-   mode = sa2-sadb_x_sa2_mode - 1;
+   mode = pfkey_mode_to_xfrm(sa2-sadb_x_sa2_mode);
+   if (mode  0)
+   return -EINVAL;
reqid = sa2-sadb_x_sa2_reqid;
} else {
mode = 0;
@@ -1756,6 +1795,7 @@ parse_ipsecrequest(struct xfrm_policy *x
 #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
struct sockaddr_in6 *sin6;
 #endif
+   int mode;
 
if (xp-xfrm_nr = XFRM_MAX_DEPTH)
return -ELOOP;
@@ -1764,7 +1804,9 @@ #endif
return -EINVAL;
 
t-id.proto = rq-sadb_x_ipsecrequest_proto; /* XXX check proto */
-   t-mode = rq-sadb_x_ipsecrequest_mode-1;
+   if ((mode = pfkey_mode_to_xfrm(rq-sadb_x_ipsecrequest_mode))  0)
+   return -EINVAL;
+   t-mode = mode;
if (rq-sadb_x_ipsecrequest_level == IPSEC_LEVEL_USE)
t-optional = 1;
else if (rq-sadb_x_ipsecrequest_level == IPSEC_LEVEL_UNIQUE) {
@@ -1877,7 +1919,7 @@ static struct sk_buff * pfkey_xfrm_polic
return skb;
 }
 
-static void pfkey_xfrm_policy2msg(struct sk_buff *skb, struct xfrm_policy *xp, 
int dir)
+static int pfkey_xfrm_policy2msg(struct sk_buff *skb, struct xfrm_policy *xp, 
int dir)
 {
struct sadb_msg *hdr;
struct sadb_address *addr;
@@ -2014,6 +2056,7 @@ #endif
struct sadb_x_ipsecrequest *rq;
struct xfrm_tmpl *t = xp-xfrm_vec + i;
int req_size;
+   int mode;
 
req_size = sizeof(struct sadb_x_ipsecrequest);
if (t-mode == XFRM_MODE_TUNNEL)
@@ -2027,7 +2070,9 @@ #endif
memset(rq, 0, 

[PATCH 2.6.20] networking: bonding documentation fix for multiple bonding interfaces

[Alexandra N. Kossovsky]

Fix bonding driver documentation for the case of multiple bonding interfaces.

Signed-off-by: Alexandra N. Kossovsky [EMAIL PROTECTED]
---
--- a/Documentation/networking/bonding.txt  2007-04-17 11:29:42.0 
+0400
+++ b/Documentation/networking/bonding.txt  2007-04-17 11:35:54.0 
+0400
@@ -920,40 +920,9 @@
 documented above.
 
To create multiple bonding devices with differing options, it
-is necessary to load the bonding driver multiple times.  Note that
-current versions of the sysconfig network initialization scripts
-handle this automatically; if your distro uses these scripts, no
-special action is needed.  See the section Configuring Bonding
-Devices, above, if you're not sure about your network initialization
-scripts.
-
-   To load multiple instances of the module, it is necessary to
-specify a different name for each instance (the module loading system
-requires that every loaded module, even multiple instances of the same
-module, have a unique name).  This is accomplished by supplying
-multiple sets of bonding options in /etc/modprobe.conf, for example:
-   
-alias bond0 bonding
-options bond0 -o bond0 mode=balance-rr miimon=100
-
-alias bond1 bonding
-options bond1 -o bond1 mode=balance-alb miimon=50
-
-   will load the bonding module two times.  The first instance is
-named bond0 and creates the bond0 device in balance-rr mode with an
-miimon of 100.  The second instance is named bond1 and creates the
-bond1 device in balance-alb mode with an miimon of 50.
-
-   In some circumstances (typically with older distributions),
-the above does not work, and the second bonding instance never sees
-its options.  In that case, the second options line can be substituted
-as follows:
-
-install bond1 /sbin/modprobe --ignore-install bonding -o bond1 \
-   mode=balance-alb miimon=50
+is necessary to use bonding parameters exported by sysfs, documented
+in the section below.
 
-   This may be repeated any number of times, specifying a new and
-unique name in place of bond1 for each subsequent instance.
 
 3.4 Configuring Bonding Manually via Sysfs
 --
-- 
Alexandra N. Kossovsky
OKTET Labs (http://www.oktetlabs.ru/)
-
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] parse ip:port strings correctly in in4_pton

[Jerome Borsboom]

 Jerome Borsboom wrote:
  in4_pton converts a textual representation of an ip4 address into an
  integer representation. However, when the textual representation is of
  in the form ip:port, c.f. 192.168.1.1:5060, and 'delim' is set to -1,
  the function bails out when parsing the colon.
  
  It makes sense to allow the colon as a delimiting character without
  explicitly having to set it through the 'delim' variable as there can be
  no ambiguity in the point where the ip address is completely parsed.
  Furthermore, this function is indeed called from nf_conntrack_sip.c in
  this way to parse textual ip:port combinations which fails as stated above.
 
 
 What about IPv6? in6_pton behaves similar and is also used by
 nf_conntrack_sip.
 

I have looked a bit more into this. The current behaviour of 
in6_pton is correct. As I said before, the colon is the separator 
within the IPv6 address and hence cannot be used to indicate a tcp 
or udp port. RFC 2732 states that when a tcp or udp port is included 
in an IPv6 URL it must be in the form '[IPv6-address]:port'. Here 
the rectangular braces make clear where the ip-address part ends and 
the port part begins. However, in[46]_pton are made to only change 
the representation of an ip-address and do not and should not bother 
about any other stuff like the rectangular braces in an IPv6 
reference or the colon in an IPv4+port combination. My patch 
corrects the unnecessary error in the case in an IPv4-address+port 
combination.

Related to this is the fact that nf_conntrack_sip wrongly assumes 
unbraced IPv6 adresses. RFC 3261 states that in all cases where an 
IPv6 reference is used, it should be enclosed in rectangular braces. 
Current behaviour is clearly wrong. I will see if I can come up with 
a patch to correct this error in nf_conntrack_sip.
-
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] CONFIG_PACKET_MMAP should depend on MMU

[Aubrey Li]

On 4/11/07, Robin Getz [EMAIL PROTECTED] wrote:

On Tue 10 Apr 2007 08:55, David Howells pondered:
 Looking at alloc_pg_vec() in af_packet.c, I will place my bets on the
 latter case.  I don't know that this is a problem; it depends on how things
 work, and that I don't know offhand.  If someone can give me a simple test
 program, I would be able to evaluate it better.

Hmm - the only think I have used in the past is tcpdump/libpcap from
http://public.lanl.gov/cpw/

Documentation/networking/packet_mmap.txt also seems to be a little dated, but
does have some code snippets if you wanted to make something lightweight...

Does anyone else on netdev have a small test app?


Here, in the attachment I wrote a small test app. Please correct if
there is anything wrong, and feel free to improve it.

-Aubrey


packet-mmap.tar.gz
Description: GNU Zip compressed data

Re: [NETLINK 01/04]: Switch cb_lock spinlock to mutex and allow to override it

[Patrick McHardy]

David Miller wrote:
 The call signature of netlink_kernel_create() is getting huge.
 It's getting near the time we should pass in a descriotor
 block in the form of a structure to specify all of these
 parameters.


Agreed, I'll take care of that.
-
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 driver tree] qeth: Remove usage of subsys.rwsem

[Cornelia Huck]

Hi,

the current driver tree contains the removal of subsys.rwsem.
Unfortunately, this breaks qeth. However, it should be no problem to
fix the walking of the devices for /proc/qeth:

No need to take subsys.rwsem during walking the devices,
driver_find_devices() should already suffice.

Signed-off-by: Cornelia Huck [EMAIL PROTECTED]

---
 drivers/s390/net/qeth_proc.c |2 --
 1 files changed, 2 deletions(-)

--- linux.orig/drivers/s390/net/qeth_proc.c
+++ linux/drivers/s390/net/qeth_proc.c
@@ -37,7 +37,6 @@ qeth_procfile_seq_start(struct seq_file 
struct device *dev = NULL;
loff_t nr = 0;
 
-   down_read(qeth_ccwgroup_driver.driver.bus-subsys.rwsem);
if (*offset == 0)
return SEQ_START_TOKEN;
while (1) {
@@ -53,7 +52,6 @@ qeth_procfile_seq_start(struct seq_file 
 static void
 qeth_procfile_seq_stop(struct seq_file *s, void* it)
 {
-   up_read(qeth_ccwgroup_driver.driver.bus-subsys.rwsem);
 }
 
 static void *
-
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 0/6] SNMP: new statistics specified in RFC4293

[Mitsuru Chinen]

Hi all,

Let me post a patch set to net-2.6.22 tree for new IPv4 statistics
specified in the updated RFC (RFC4293). All of them (except broadcast
statistics) are already supported in IPv6 stack. However they are not
supported in IPv4 stack yet.

The patch set consists of following 6 patches:

  [PATCH 1/6] SNMP: Add definitions for {In,Out}BcastPkts
  [PATCH 2/6] [IPV4] SNMP: Support InNoRoutes
  [PATCH 3/6] [IPV4] SNMP: Support InTruncatedPkts
  [PATCH 4/6] [IPV4] SNMP: Support InMcastPkts and InBcastPkts
  [PATCH 5/6] [IPV4] SNMP: Support OutMcastPkts and OutBcastPkts
  [PATCH 6/6] [IPV4] SNMP: Display new statistics at /proc/net/snmp

Best Regards,

Mitsuru Chinen [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

[PATCH 1/6] SNMP: Add definitions for {In,Out}BcastPkts

[Mitsuru Chinen]

The updated IP-MIB RFC (RFC4293) specifys new objects, InBcastPkts
and OutBcastPkts. This adds definitions for them.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 include/linux/snmp.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/linux/snmp.h b/include/linux/snmp.h
index 854aa6b..802b3a3 100644
--- a/include/linux/snmp.h
+++ b/include/linux/snmp.h
@@ -40,6 +40,8 @@ enum
IPSTATS_MIB_FRAGCREATES,/* FragCreates */
IPSTATS_MIB_INMCASTPKTS,/* InMcastPkts */
IPSTATS_MIB_OUTMCASTPKTS,   /* OutMcastPkts */
+   IPSTATS_MIB_INBCASTPKTS,/* InBcastPkts */
+   IPSTATS_MIB_OUTBCASTPKTS,   /* OutBcastPkts */
__IPSTATS_MIB_MAX
 };
 
-- 
1.4.3.4

-
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] [IPV4] SNMP: Support InNoRoutes

[Mitsuru Chinen]

An IP datagram which is being discarded because of no routes in the
forwarding path should be counted as InNoRoutes.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 net/ipv4/ip_input.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 324e7e0..63ab523 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -340,6 +340,8 @@ static inline int ip_rcv_finish(struct s
if (unlikely(err)) {
if (err == -EHOSTUNREACH)
IP_INC_STATS_BH(IPSTATS_MIB_INADDRERRORS);
+   else if (err == -ENETUNREACH)
+   IP_INC_STATS_BH(IPSTATS_MIB_INNOROUTES);
goto drop;
}
}
-- 
1.4.3.4

-
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 3/6] [IPV4] SNMP: Support InTruncatedPkts

[Mitsuru Chinen]

An IP datagram which is being discarded because the datagram frame
didn't carry enough data should be counted as InTruncatedPkts.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 net/ipv4/ip_input.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 63ab523..c8c455d 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -416,7 +416,10 @@ int ip_rcv(struct sk_buff *skb, struct n
goto inhdr_error;
 
len = ntohs(iph-tot_len);
-   if (skb-len  len || len  (iph-ihl*4))
+   if (skb-len  len) {
+   IP_INC_STATS_BH(IPSTATS_MIB_INTRUNCATEDPKTS);
+   goto drop;
+   } else if (len  (iph-ihl*4))
goto inhdr_error;
 
/* Our transport medium may have padded the buffer out. Now we know it
-- 
1.4.3.4

-
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 4/6] [IPV4] SNMP: Support InMcastPkts and InBcastPkts

[Mitsuru Chinen]

A received IP multicast datagram should be counted as InMcastPkts.
By the same token, a received IP broadcast datagram should be
counted as InBcastPkts.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 net/ipv4/ip_input.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index c8c455d..9706939 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -329,6 +329,7 @@ drop:
 static inline int ip_rcv_finish(struct sk_buff *skb)
 {
const struct iphdr *iph = ip_hdr(skb);
+   struct rtable *rt;
 
/*
 *  Initialise the virtual path cache for the packet. It describes
@@ -360,6 +361,12 @@ static inline int ip_rcv_finish(struct s
if (iph-ihl  5  ip_rcv_options(skb))
goto drop;
 
+   rt = (struct rtable*)skb-dst;
+   if (rt-rt_type == RTN_MULTICAST)
+   IP_INC_STATS_BH(IPSTATS_MIB_INMCASTPKTS);
+   else if (rt-rt_type == RTN_BROADCAST)
+   IP_INC_STATS_BH(IPSTATS_MIB_INBCASTPKTS);
+
return dst_input(skb);
 
 drop:
-- 
1.4.3.4

-
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 5/6] [IPV4] SNMP: Support OutMcastPkts and OutBcastPkts

[Mitsuru Chinen]

A transmitted IP multicast datagram should be counted as OutMcastPkts.
By the same token, a transmitted IP broadcast datagram should be
counted as OutBcastPkts.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 net/ipv4/ip_output.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 704bc44..4442185 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -160,9 +160,15 @@ EXPORT_SYMBOL_GPL(ip_build_and_send_pkt)
 static inline int ip_finish_output2(struct sk_buff *skb)
 {
struct dst_entry *dst = skb-dst;
+   struct rtable *rt = (struct rtable *)dst;
struct net_device *dev = dst-dev;
int hh_len = LL_RESERVED_SPACE(dev);
 
+   if (rt-rt_type == RTN_MULTICAST)
+   IP_INC_STATS(IPSTATS_MIB_OUTMCASTPKTS);
+   else if (rt-rt_type == RTN_BROADCAST)
+   IP_INC_STATS(IPSTATS_MIB_OUTBCASTPKTS);
+
/* Be paranoid, rather than too clever. */
if (unlikely(skb_headroom(skb)  hh_len  dev-hard_header)) {
struct sk_buff *skb2;
-- 
1.4.3.4

-
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 6/6] [IPV4] SNMP: Display new statistics at /proc/net/snmp

[Mitsuru Chinen]

This displays the statistics specified in the updated IP-MIB RFC
(RFC4293) at /proc/net/snmp. As new statistics are placed as the
last elements, this change wouldn't affect netstat, net-snmp, etc.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 net/ipv4/proc.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index ae68a69..cc4c80a 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -119,6 +119,12 @@ static const struct snmp_mib snmp4_ipsta
SNMP_MIB_ITEM(FragOKs, IPSTATS_MIB_FRAGOKS),
SNMP_MIB_ITEM(FragFails, IPSTATS_MIB_FRAGFAILS),
SNMP_MIB_ITEM(FragCreates, IPSTATS_MIB_FRAGCREATES),
+   SNMP_MIB_ITEM(InNoRoutes, IPSTATS_MIB_INNOROUTES),
+   SNMP_MIB_ITEM(InTruncatedPkts, IPSTATS_MIB_INTRUNCATEDPKTS),
+   SNMP_MIB_ITEM(InMcastPkts, IPSTATS_MIB_INMCASTPKTS),
+   SNMP_MIB_ITEM(OutMcastPkts, IPSTATS_MIB_OUTMCASTPKTS),
+   SNMP_MIB_ITEM(InBcastPkts, IPSTATS_MIB_INBCASTPKTS),
+   SNMP_MIB_ITEM(OutBcastPkts, IPSTATS_MIB_OUTBCASTPKTS),
SNMP_MIB_SENTINEL
 };
 
-- 
1.4.3.4

-
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: intermittant petabyte usage reported with broadcom nic

[Jean-Daniel Pauget]

On Tue, Apr 17, 2007 at 09:43:48AM +1000, CaT wrote:
 On Mon, Apr 16, 2007 at 12:10:51PM -0700, Michael Chan wrote:
  On Sat, 2007-04-14 at 17:20 -0700, Michael Chan wrote:
  
  Here's the debug patch for x86 only that will change the statistics
  memory block to read-only.  If the kernel is corrupting it, you should
  get a page fault that will crash the system.  If you continue to see
  bogus counters, it is definitely a firmware or hardware problem.  Please
  try it and let me know.  Thanks.
[.../...]
 Perhaps Jean-Daniel, who is also experiencing this problem and seemingly
 more frequently then I, has a box that he could run your patch on. I
 think we both run pretty-much the same hardware (Dell [12]950s).
Dell 1950/2950 indeed...

if there is any way to catch that writing without crashing the system 
(even to the price of some slowness) I can test it. if not, I can't 
because all my available targets are remote administrated and involved 
with production processes.
if luckilly one of them gets free, I'll to apply the latest patch you'd 
provide me. I may also try it one day I'm close to those machines, so 
keep me in the list of up to date patches.

-- 
Jean-Daniel Pauget

Tél: +33 (0)2 33 17 20 16
2, rue André PELCA
50580 Denneville-Plage
France

-
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

[BRIDGE] Unaligned access on IA64 when comparing ethernet addresses

[Pavel Emelianov]

From: Evgeny Kravtsunov [EMAIL PROTECTED]

compare_ether_addr() implicitly requires that the addresses
passed are 2-bytes aligned in memory.

This is not true for br_stp_change_bridge_id() and
br_stp_recalculate_bridge_id() in which one of the addresses
is unsigned char *, and thus may not be 2-bytes aligned.

Signed-off-by: Evgeny Kravtsunov [EMAIL PROTECTED]
Signed-off-by: Kirill Korotaev [EMAIL PROTECTED]
Signed-off-by: Pavel Emelianov [EMAIL PROTECTED]

---

--- a/net/bridge/br_stp_if.c2006-09-20 07:42:06.0 +0400
+++ b/net/bridge/br_stp_if.c2007-04-13 12:28:08.0 +0400
@@ -124,7 +124,9 @@ void br_stp_disable_port(struct net_brid
 /* called under bridge lock */
 void br_stp_change_bridge_id(struct net_bridge *br, const unsigned char *addr)
 {
-   unsigned char oldaddr[6];
+   /* should be aligned on 2 bytes for compare_ether_addr() */
+   unsigned short oldaddr_aligned[ETH_ALEN  1];
+   unsigned char *oldaddr = (unsigned char *)oldaddr_aligned;
struct net_bridge_port *p;
int wasroot;
 
@@ -149,11 +151,14 @@ void br_stp_change_bridge_id(struct net_
br_become_root_bridge(br);
 }
 
-static const unsigned char br_mac_zero[6];
+/* should be aligned on 2 bytes for compare_ether_addr() */
+static const unsigned short br_mac_zero_aligned[ETH_ALEN  1];
 
 /* called under bridge lock */
 void br_stp_recalculate_bridge_id(struct net_bridge *br)
 {
+   const unsigned char *br_mac_zero =
+   (const unsigned char *)br_mac_zero_aligned;
const unsigned char *addr = br_mac_zero;
struct net_bridge_port *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

Re: 2.6.20.4: NETDEV WATCHDOG and lockups

[Jarek Poplawski]

On Fri, Apr 06, 2007 at 07:19:25PM +0100, Christian Kujau wrote:
 On Wed, 4 Apr 2007, Christian Kujau wrote:
 Maybe it's a real locking problem. Here are some more
 suggestions for testing (if you don't find anything better):
 - try without SMP, so: 'acpi=off lapic nosmp'
 
 We were able to have our hosting provider to replace the 8139too with a 
 E100, the onboard r8169 stayed of course. After this, the box came back 
 fine...only to lock up again shortly after :(
 
 So again we spoke to our hosting provider and they just took out the 2 
 SATA disks and put them in a completely new system: amd64 dualcore 
 again, 2 GB ram, r8169 onboard NIC, e100 pci-slot NIC. Now booting 
 2.6.20.4 and even 2.6.18-4-k7 (the debian kernel) with IOAPIC eabled 
 seems to work, meaning the box is up since yesterday evening and 
 interrupts are shared. Not equally, but still:
 
 # cat /proc/interrupts
CPU0   CPU1
...
  16:157 575579   IO-APIC-fasteoi   eth0
  17:3812553  1   IO-APIC-fasteoi   eth1
...

Yes! Nobody can deny they are shared. It's a miracle they
don't lockup now!

 While this is a good thing, we now have different problems: our 2nd sata 
 drive is not usable any more, but we again we doubt hardware problems, 
 because this disk has been replaced already back in the old box...
 
 but yes, this seem to be different problems, for the curious among 
 you I've put details here: http://nerdbynature.de/bits/2.6.20.4/db2/

I don't want to waste your time for experiments, so don't
feel obliged to respond or try this all, but here are
some impressions - what I'd do:

- these disk errors look serious and there is no reason
to try anything else without removing such disk and
testing it in some other place,

- the configs are changed, but they sometimes include many
risky options like: X86_MCE, HOTPLUG, ACPI_BATTERY,
ACPI_BUTTON, ACPI_PROCESSOR, ENABLE_MEMORY_HOTPLUG etc.;
I doubt you need IDE at all: probably SATA_VIA and PATA_VIA
should be enough for your disks; with such problems I'd start
with absolute minimum - and no drivers for other models
(BTW - maybe I'm wrong, but isn't AMD64 MK-8?),

- if, with some config, a lockup is expected soon, I'd
turn off any watchdogs, turn on many debugging - e.g.
lockdep, and try to wait and get some oops during a lockup
(sometime it needs a few minutes, sometime SYSRQ is helpful);
without this you could never be sure it'll work or your
hardware would work at half speed with unnecessarily
turned off options.

 Thanks to all who have replied,

And I thank you for cooperation and interesting problems.
But I doubt anybody here is satisfied with anything but:
it's working (and your hardware doesn't look so special
it shouldn't work).

Cheers,
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

Re: [Bugme-new] [Bug 8320] New: replacing route in kernel doesn't send netlink message

[Patrick McHardy]

David Miller wrote:
 From: Patrick McHardy [EMAIL PROTECTED]
 Date: Mon, 16 Apr 2007 06:59:06 +0200
 
 
RTM_DELROUTE + RTM_NEWROUTE seem to be safer, although you're correct
that it might cause userspace to perform some action upon receiving
the DELROUTE message since the update is non-atomic. So I really don't
know, I'm in favour of having notifications for replacements, but I
fear we might break something.
 
 
 We can cry foul about a broken application if an application following
 the API correctly would interpret the new messages correctly.
 
 I think it doesn't make sense to do a delete then a newroute for
 the atomicity issues, and therefore the replace makes the most
 sense as long as existing correct uses of the API would not
 explode on this.


They shouldn't, worst case is that they ignore NLM_F_REPLACE and treat
it as a completely new route, which is at least half way correct and
not really worse than today.

Milan, could you cook up another patch which uses NLM_F_REPLACE?
-
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

[NET]: Get rid of alloc_skb code duplication

[Herbert Xu]

Hi Dave:

[NET]: Get rid of alloc_skb code duplication

The skb initialisation code is shared between alloc_skb and
alloc_skb_from_cache.  Now I don't know what actually uses
the latter so perhaps we could simply get rid of it.

However, if we're to keep it, then let's move the common code
out as they've started diverging.

Signed-off-by: Herbert Xu [EMAIL PROTECTED]

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index fae7f94..db4f526 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -128,6 +128,31 @@ EXPORT_SYMBOL(skb_truesize_bug);
  *
  */
 
+static void init_skb(struct sk_buff *skb, u8 *data, unsigned int size)
+{
+   struct skb_shared_info *shinfo;
+
+   /*
+* See comment in sk_buff definition, just before the 'tail' member
+*/
+   memset(skb, 0, offsetof(struct sk_buff, tail));
+   skb-truesize = size + sizeof(struct sk_buff);
+   atomic_set(skb-users, 1);
+   skb-head = data;
+   skb-data = data;
+   skb_reset_tail_pointer(skb);
+   skb-end = skb-tail + size;
+   /* make sure we initialize shinfo sequentially */
+   shinfo = skb_shinfo(skb);
+   atomic_set(shinfo-dataref, 1);
+   shinfo-nr_frags  = 0;
+   shinfo-gso_size = 0;
+   shinfo-gso_segs = 0;
+   shinfo-gso_type = 0;
+   shinfo-ip6_frag_id = 0;
+   shinfo-frag_list = NULL;
+}
+
 /**
  * __alloc_skb -   allocate a network buffer
  * @size: size to allocate
@@ -147,7 +172,6 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t 
gfp_mask,
int fclone, int node)
 {
struct kmem_cache *cache;
-   struct skb_shared_info *shinfo;
struct sk_buff *skb;
u8 *data;
 
@@ -164,25 +188,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t 
gfp_mask,
if (!data)
goto nodata;
 
-   /*
-* See comment in sk_buff definition, just before the 'tail' member
-*/
-   memset(skb, 0, offsetof(struct sk_buff, tail));
-   skb-truesize = size + sizeof(struct sk_buff);
-   atomic_set(skb-users, 1);
-   skb-head = data;
-   skb-data = data;
-   skb_reset_tail_pointer(skb);
-   skb-end = skb-tail + size;
-   /* make sure we initialize shinfo sequentially */
-   shinfo = skb_shinfo(skb);
-   atomic_set(shinfo-dataref, 1);
-   shinfo-nr_frags  = 0;
-   shinfo-gso_size = 0;
-   shinfo-gso_segs = 0;
-   shinfo-gso_type = 0;
-   shinfo-ip6_frag_id = 0;
-   shinfo-frag_list = NULL;
+   init_skb(skb, data, size);
 
if (fclone) {
struct sk_buff *child = skb + 1;
@@ -233,23 +239,8 @@ struct sk_buff *alloc_skb_from_cache(struct kmem_cache *cp,
data = kmem_cache_alloc(cp, gfp_mask);
if (!data)
goto nodata;
-   /*
-* See comment in sk_buff definition, just before the 'tail' member
-*/
-   memset(skb, 0, offsetof(struct sk_buff, tail));
-   skb-truesize = size + sizeof(struct sk_buff);
-   atomic_set(skb-users, 1);
-   skb-head = data;
-   skb-data = data;
-   skb_reset_tail_pointer(skb);
-   skb-end  = skb-tail + size;
 
-   atomic_set((skb_shinfo(skb)-dataref), 1);
-   skb_shinfo(skb)-nr_frags  = 0;
-   skb_shinfo(skb)-gso_size = 0;
-   skb_shinfo(skb)-gso_segs = 0;
-   skb_shinfo(skb)-gso_type = 0;
-   skb_shinfo(skb)-frag_list = NULL;
+   init_skb(skb, data, size);
 out:
return skb;
 nodata:
-
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 net-2.6.22 1/3] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...)

[Ilpo Järvinen]

On Mon, 16 Apr 2007, David Miller wrote:

 From: Ilpo_Järvinen [EMAIL PROTECTED]
 Date: Mon, 16 Apr 2007 19:19:02 +0300 (EEST)
 
  [PATCH] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...)
 
 I was trying to spread out the net-2.6.22 tree from the tcp-2.6
 one so that we could do the experimental TCP stuff in the tcp-2.6
 tree and leave other networking changes for net-2.6.22

 Putting in TCP cleanups which touch a lot of code into net-2.6.22
 defeats that effort because now there will be all kinds of rejects and
 merge errors people will have to deal with if they clone a net-2.6.22
 tree then pull in tcp-2.6 to do some TCP hacking which is valid.

...to tcp-2.6 this time.

[PATCH] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...)

This is (mostly) automated change using magic:

sed -e '/struct sock \*sk/ N' -e '/struct sock \*sk/ N'
-e '/struct sock \*sk/ N' -e '/struct sock \*sk/ N'
-e 's|struct sock \*sk,[\n\t ]*struct tcp_sock \*tp\([^{]*\n{\n\)|
  struct sock \*sk\1\tstruct tcp_sock *tp = tcp_sk(sk);\n|g'
-e 's|struct sock \*sk, struct tcp_sock \*tp|
  struct sock \*sk|g' -e 's|sk, tp\([^-]\)|sk\1|g'

Fixed four unused variable (tp) warnings that were introduced.

In addition, manually added newlines after local variables and
tweaked function arguments positioning.

$ gcc --version
gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
...
$ codiff -fV built-in.o.old built-in.o.new
net/ipv4/tcp.c:
  tcp_setsockopt |   -5
  tcp_sendpage   |  -16
  tcp_sendmsg|  -12
 3 functions changed, 33 bytes removed

net/ipv4/tcp_input.c:
  tcp_try_undo_recovery |   +3
  tcp_try_undo_dsack|   +2
  tcp_send_dupack   |   +1
  tcp_ack   |  -10
  tcp_event_data_recv   |  -16
  tcp_rcv_state_process |  -10
  tcp_rcv_established   |  -19
 7 functions changed, 6 bytes added, 55 bytes removed, diff: -49

net/ipv4/tcp_output.c:
  update_send_head  |   -9
  tcp_cwnd_validate |   +1
  tcp_write_wakeup  |  -17
  __tcp_push_pending_frames |  -25
  tcp_push_one  |   -8
  tcp_send_fin  |   -4
 6 functions changed, 1 bytes added, 63 bytes removed, diff: -62

built-in.o.new:
 16 functions changed, 7 bytes added, 151 bytes removed, diff: -144

Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
 include/net/tcp.h |   25 +
 include/net/tcp_ecn.h |   11 +++-
 net/ipv4/tcp.c|   39 --
 net/ipv4/tcp_input.c  |  134 +
 net/ipv4/tcp_output.c |   54 +++-
 5 files changed, 152 insertions(+), 111 deletions(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 809e392..29e5740 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -420,9 +420,9 @@ extern __u32 cookie_v4_init_sequence(str
 
 /* tcp_output.c */
 
-extern void __tcp_push_pending_frames(struct sock *sk, struct tcp_sock *tp,
- unsigned int cur_mss, int nonagle);
-extern int tcp_may_send_now(struct sock *sk, struct tcp_sock *tp);
+extern void __tcp_push_pending_frames(struct sock *sk, unsigned int cur_mss,
+ int nonagle);
+extern int tcp_may_send_now(struct sock *sk);
 extern int tcp_retransmit_skb(struct sock *, struct sk_buff *);
 extern void tcp_xmit_retransmit_queue(struct sock *);
 extern void tcp_simple_retransmit(struct sock *);
@@ -479,8 +479,10 @@ static inline void tcp_fast_path_on(stru
__tcp_fast_path_on(tp, tp-snd_wnd  tp-rx_opt.snd_wscale);
 }
 
-static inline void tcp_fast_path_check(struct sock *sk, struct tcp_sock *tp)
+static inline void tcp_fast_path_check(struct sock *sk)
 {
+   struct tcp_sock *tp = tcp_sk(sk);
+
if (skb_queue_empty(tp-out_of_order_queue) 
tp-rcv_wnd 
atomic_read(sk-sk_rmem_alloc)  sk-sk_rcvbuf 
@@ -591,10 +593,10 @@ static inline void tcp_dec_pcount_approx
}
 }
 
-static inline void tcp_packets_out_inc(struct sock *sk, 
-  struct tcp_sock *tp,
+static inline void tcp_packets_out_inc(struct sock *sk,
   const struct sk_buff *skb)
 {
+   struct tcp_sock *tp = tcp_sk(sk);
int orig = tp-packets_out;
 
tp-packets_out += tcp_skb_pcount(skb);
@@ -778,18 +780,21 @@ static inline void tcp_minshall_update(s
tp-snd_sml = TCP_SKB_CB(skb)-end_seq;
 }
 
-static inline void tcp_check_probe_timer(struct sock *sk, struct tcp_sock *tp)
+static inline void tcp_check_probe_timer(struct sock *sk)
 {
+   struct tcp_sock *tp = tcp_sk(sk);
const struct inet_connection_sock *icsk = inet_csk(sk);
+
if (!tp-packets_out  !icsk-icsk_pending)
inet_csk_reset_xmit_timer(sk, ICSK_TIME_PROBE0,
  icsk-icsk_rto, TCP_RTO_MAX);
 }
 
-static inline void tcp_push_pending_frames(struct sock *sk,
-  struct tcp_sock *tp)
+static inline 

Re: + ppp_generic-fix-lockdep-warning.patch added to -mm tree

[Michal Ostrowski]

The xmit function of a PPP channel is a synchronous operation.  If the 
transmission fails, we must notify the caller and let them re-submit the 
skb later.  The return status of dev_queue_xmit is needed to determine 
the return code passed back to the caller and thus the call is made 
synchronously and not in a tasklet.


Looking at the stack traces earlier in this thread, it seems to me that 
even if the PPPoE call was made in a tasklet, this same warning could be 
generated.


--
Michal Ostrowski
[EMAIL PROTECTED]



Jarek Poplawski wrote:

On Wed, Apr 11, 2007 at 12:52:28PM +0400, Yuriy N. Shkandybin wrote:
...
On Wed, 11 Apr 2007 09:57:33 +0400 Yuriy N. Shkandybin [EMAIL PROTECTED] 
wrote:



I've tested  2.6.21-rc6-mm1
Linux vpn1 2.6.21-rc6-mm1 #4 SMP Wed Apr 11 03:34:26 MSD 2007 x86_64
Intel(R) Pentium(R) D CPU 2.80GHz GenuineIntel GNU/Linux

warn appeares upon first pppoe connection to rp-pppoe server in kernel 
mode



Thanks.  So you're saying that
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/ppp_generic-fix-lockdep-warning.patch
did not fix anything?
As i understand this patch already in -mm tree, so I've booted into last mm 
kernel and received this locked warning.

Or i've mistaked and should apply this patch manually?


Hi!

Yuriy - thanks for testing my patch ...(pause) Not!

It seems this patch is not visible in this version - probably
is overpatched by something else. But your new log shows there
is another connection between these locks (ppp_xmit_process
and ppp_push instead of ppp_channel_push in - #0), so the
patch is not sufficient (and could be dumped).

I don't know your vlans configuration, but it seems the real
lockup isn't very probable here - it's rather lockdep question.
I think vlan's too broad lockdep class is the main guilty
here, but probably pppoe also could be enhanced: it's making
the things unnecessarily complicated by calling dev_queue_xmit
under ppp_generic's xmit locks. I wonder if there is any reason
against using a tasklet here.

I'll try to find more time to untie this yet - or maybe some
maintainer will find this interesting, too...

Regards,
Jarek P.

PS: sorry for late responding (vacations).



-
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: [NET]: Get rid of alloc_skb code duplication

[Christoph Hellwig]

On Tue, Apr 17, 2007 at 09:57:46PM +1000, Herbert Xu wrote:
 Hi Dave:
 
 [NET]: Get rid of alloc_skb code duplication
 
 The skb initialisation code is shared between alloc_skb and
 alloc_skb_from_cache.  Now I don't know what actually uses
 the latter so perhaps we could simply get rid of it.

It was put in for Xen, but if you as the resident beat the crap out
of Xen networking guru don't know about it we should probably just
kill it.  Especially as we usually kill dead code pretty fast.

-
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: [NET]: Get rid of alloc_skb code duplication

[Herbert Xu]

On Tue, Apr 17, 2007 at 02:03:47PM +0100, Christoph Hellwig wrote:

 It was put in for Xen, but if you as the resident beat the crap out
 of Xen networking guru don't know about it we should probably just
 kill it.  Especially as we usually kill dead code pretty fast.

Heh, I wasn't touching Xen back then.

That's good news actually.  Xen has now killed their custom alloc_skb
so this is no longer needed.  Besides, even if they needed it they'll
have to patch it in anyway since you've already killed the ifdef that
lets them have a custom alloc_skb :)

[NET]: Get rid of alloc_skb_from_cache

Since this was added originally for Xen, and Xen has recently (~2.6.18)
stopped using this function, we can safely get rid of it.  Good timing
too since this function has started to bit rot.

Signed-off-by: Herbert Xu [EMAIL PROTECTED]

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 691ead8..a9b810d 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -342,9 +342,6 @@ static inline struct sk_buff *alloc_skb_fclone(unsigned int 
size,
return __alloc_skb(size, priority, 1, -1);
 }
 
-extern struct sk_buff *alloc_skb_from_cache(struct kmem_cache *cp,
-   unsigned int size,
-   gfp_t priority);
 extern void   kfree_skbmem(struct sk_buff *skb);
 extern struct sk_buff *skb_clone(struct sk_buff *skb,
 gfp_t priority);
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index fae7f94..2d8707e 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -202,63 +202,6 @@ nodata:
 }
 
 /**
- * alloc_skb_from_cache-   allocate a network buffer
- * @cp: kmem_cache from which to allocate the data area
- *   (object size must be big enough for @size bytes + skb overheads)
- * @size: size to allocate
- * @gfp_mask: allocation mask
- *
- * Allocate a new sk_buff. The returned buffer has no headroom and
- * tail room of size bytes. The object has a reference count of one.
- * The return is the buffer. On a failure the return is %NULL.
- *
- * Buffers may only be allocated from interrupts using a @gfp_mask of
- * %GFP_ATOMIC.
- */
-struct sk_buff *alloc_skb_from_cache(struct kmem_cache *cp,
-unsigned int size,
-gfp_t gfp_mask)
-{
-   struct sk_buff *skb;
-   u8 *data;
-
-   /* Get the HEAD */
-   skb = kmem_cache_alloc(skbuff_head_cache,
-  gfp_mask  ~__GFP_DMA);
-   if (!skb)
-   goto out;
-
-   /* Get the DATA. */
-   size = SKB_DATA_ALIGN(size);
-   data = kmem_cache_alloc(cp, gfp_mask);
-   if (!data)
-   goto nodata;
-   /*
-* See comment in sk_buff definition, just before the 'tail' member
-*/
-   memset(skb, 0, offsetof(struct sk_buff, tail));
-   skb-truesize = size + sizeof(struct sk_buff);
-   atomic_set(skb-users, 1);
-   skb-head = data;
-   skb-data = data;
-   skb_reset_tail_pointer(skb);
-   skb-end  = skb-tail + size;
-
-   atomic_set((skb_shinfo(skb)-dataref), 1);
-   skb_shinfo(skb)-nr_frags  = 0;
-   skb_shinfo(skb)-gso_size = 0;
-   skb_shinfo(skb)-gso_segs = 0;
-   skb_shinfo(skb)-gso_type = 0;
-   skb_shinfo(skb)-frag_list = NULL;
-out:
-   return skb;
-nodata:
-   kmem_cache_free(skbuff_head_cache, skb);
-   skb = NULL;
-   goto out;
-}
-
-/**
  * __netdev_alloc_skb - allocate an skbuff for rx on a specific device
  * @dev: network device to receive on
  * @length: length to allocate
-
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: intermittant petabyte usage reported with broadcom nic

[Roland Dreier]

I actually have a couple of Dell 1950 systems with bnx2 NICs too,
which I use for kernel development (ie one more crash is fine :)

If someone can give me an idea for what kind of load to use, I can try
this patch out to see if it triggers.

 - R.
-
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 3/7] NetXen: Multi PCI support for Quad cards

[Amit Kale]

On Monday 16 April 2007 23:19, Stephen Hemminger wrote:
 On Fri, 13 Apr 2007 08:39:31 -0700

 Linsys Contractor Mithlesh Thukral [EMAIL PROTECTED] wrote:
  NetXen: Fix the multi PCI function for cards with more than 2 ports.
  This patch fixes the working of multi PCI capable driver on cards with
  more than 2 ports by adding the addresses for their rings and sizes.
 
  Signed-off by: Mithlesh Thukral [EMAIL PROTECTED]
 
  ---
 
   drivers/net/netxen/netxen_nic_hw.c   |  119 +++--
   drivers/net/netxen/netxen_nic_init.c |4
   drivers/net/netxen/netxen_nic_main.c |   61 +-
   drivers/net/netxen/netxen_nic_phan_reg.h |6 -
   4 files changed, 146 insertions(+), 44 deletions(-)
 
  diff --git a/drivers/net/netxen/netxen_nic_hw.c
  b/drivers/net/netxen/netxen_nic_hw.c index a066208..274a261 100644
  --- a/drivers/net/netxen/netxen_nic_hw.c
  +++ b/drivers/net/netxen/netxen_nic_hw.c
  @@ -140,8 +140,105 @@ struct netxen_recv_crb recv_crb_register
   NETXEN_NIC_REG(0x180),
   /* crb_status_ring_size */
   NETXEN_NIC_REG(0x184),
  -
   },
  +   /*
  +* Instance 3,
  +*/
  +   {
  + {
  +   {
  +   /* crb_rcv_producer_offset: */
  +   NETXEN_NIC_REG(0x1d8),
  +   /* crb_rcv_consumer_offset: */
  +   NETXEN_NIC_REG(0x1dc),
  +   /* crb_gloablrcv_ring: */
  +   NETXEN_NIC_REG(0x1f0),
  +   /* crb_rcv_ring_size */
  +   NETXEN_NIC_REG(0x1f4),
  +   },
  +   /* Jumbo frames */
  +   {
  +   /* crb_rcv_producer_offset: */
  +   NETXEN_NIC_REG(0x1f8),
  +   /* crb_rcv_consumer_offset: */
  +   NETXEN_NIC_REG(0x1fc),
  +   /* crb_gloablrcv_ring: */
  +   NETXEN_NIC_REG(0x200),
  +   /* crb_rcv_ring_size */
  +   NETXEN_NIC_REG(0x204),
  +   },
  +   /* LRO */
  +   {
  +   /* crb_rcv_producer_offset: */
  +   NETXEN_NIC_REG(0x208),
  +   /* crb_rcv_consumer_offset: */
  +   NETXEN_NIC_REG(0x20c),
  +   /* crb_gloablrcv_ring: */
  +   NETXEN_NIC_REG(0x210),
  +   /* crb_rcv_ring_size */
  +   NETXEN_NIC_REG(0x214),
  +   }
  + },
  + /* crb_rcvstatus_ring: */
  + NETXEN_NIC_REG(0x218),
  + /* crb_rcv_status_producer: */
  + NETXEN_NIC_REG(0x21c),
  + /* crb_rcv_status_consumer: */
  + NETXEN_NIC_REG(0x220),
  + /* crb_rcvpeg_state: */
  + NETXEN_NIC_REG(0x224),
  + /* crb_status_ring_size */
  + NETXEN_NIC_REG(0x228),
  +   },
  +   /*
  +* Instance 4,
  +*/
  +   {
  + {
  +   {
  +   /* crb_rcv_producer_offset: */
  +   NETXEN_NIC_REG(0x22c),
  +   /* crb_rcv_consumer_offset: */
  +   NETXEN_NIC_REG(0x230),
  +   /* crb_gloablrcv_ring: */
  +   NETXEN_NIC_REG(0x234),
  +   /* crb_rcv_ring_size */
  +   NETXEN_NIC_REG(0x238),
  +   },
  +   /* Jumbo frames */
  +   {
  +   /* crb_rcv_producer_offset: */
  +   NETXEN_NIC_REG(0x23c),
  +   /* crb_rcv_consumer_offset: */
  +   NETXEN_NIC_REG(0x240),
  +   /* crb_gloablrcv_ring: */
  +   NETXEN_NIC_REG(0x244),
  +   /* crb_rcv_ring_size */
  +   NETXEN_NIC_REG(0x248),
  +   },
  +   /* LRO */
  +   {
  +   /* crb_rcv_producer_offset: */
  +   NETXEN_NIC_REG(0x24c),
  +   /* crb_rcv_consumer_offset: */
  +   NETXEN_NIC_REG(0x250),
  +   /* crb_gloablrcv_ring: */
  +   NETXEN_NIC_REG(0x254),
  +   /* crb_rcv_ring_size */
  +   NETXEN_NIC_REG(0x258),
  +   }
  + },
  + /* crb_rcvstatus_ring: */
  + NETXEN_NIC_REG(0x25c),
  + /* crb_rcv_status_producer: */
  + NETXEN_NIC_REG(0x260),
  + /* crb_rcv_status_consumer: */
  + NETXEN_NIC_REG(0x264),
  + /* crb_rcvpeg_state: */
  + NETXEN_NIC_REG(0x268),
  + /* crb_status_ring_size */
  + NETXEN_NIC_REG(0x26c),
  +   },
   };
 
   u64 ctx_addr_sig_regs[][3] = {
  @@ -294,6 +391,7 @@ int netxen_nic_hw_resources(struct netxe
  u32 card_cmdring = 0;
  struct netxen_recv_context *recv_ctx;
  struct netxen_rcv_desc_ctx *rcv_desc;
  +   int func_id = adapter-portnum;
 
  DPRINTK(INFO, crb_base: %lx %x, NETXEN_PCI_CRBSPACE,
  PCI_OFFSET_SECOND_RANGE(adapter, NETXEN_PCI_CRBSPACE));
  @@ -341,7 +439,7 @@ int netxen_nic_hw_resources(struct netxe
  adapter-ctx_desc_pdev);
 
  printk(KERN_INFO ctx_desc_phys_addr: 0x%llx\n,
  -  (unsigned long long) adapter-ctx_desc_phys_addr);
  +  (u64) adapter-ctx_desc_phys_addr);

 This will give a warning on 64 bit platforms because format doesn't match
 width. You need to cast to (unsigned long long).

OOPS! We'll do this change.
Thanks.
-Amit
-
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 6/7] NetXen: Fixes for Power PC architecture

[Amit Kale]

On Friday 13 April 2007 21:24, Christoph Hellwig wrote:
 On Fri, Apr 13, 2007 at 08:42:57AM -0700, Linsys Contractor Mithlesh Thukral 
wrote:
  NetXen: Configurable interrupts on PPC architecture
  This patch will add support to add command line argument to specify
  the interrupt type on a PPC machine. Fixes some issues seen on Big endian
  machines.
 
  Signed-off by: Milan Bag [EMAIL PROTECTED]
  Acked-by: Mithlesh Thukral [EMAIL PROTECTED]
 
  ---
 
   drivers/net/netxen/netxen_nic.h  |6 +++---
   drivers/net/netxen/netxen_nic_hw.c   |2 +-
   drivers/net/netxen/netxen_nic_init.c |4 ++--
   drivers/net/netxen/netxen_nic_main.c |6 ++
   4 files changed, 12 insertions(+), 6 deletions(-)
 
  diff --git a/drivers/net/netxen/netxen_nic.h
  b/drivers/net/netxen/netxen_nic.h index 3549c7c..7ba2383 100644
  --- a/drivers/net/netxen/netxen_nic.h
  +++ b/drivers/net/netxen/netxen_nic.h
  @@ -64,9 +64,9 @@ #include asm/pgtable.h
   #include netxen_nic_hw.h
 
   #define _NETXEN_NIC_LINUX_MAJOR 3
  -#define _NETXEN_NIC_LINUX_MINOR 3
  -#define _NETXEN_NIC_LINUX_SUBVERSION 3
  -#define NETXEN_NIC_LINUX_VERSIONID  3.3.3
  +#define _NETXEN_NIC_LINUX_MINOR 4
  +#define _NETXEN_NIC_LINUX_SUBVERSION 2
  +#define NETXEN_NIC_LINUX_VERSIONID  3.4.2
 
   #define NUM_FLASH_SECTORS (64)
   #define FLASH_SECTOR_SIZE (64 * 1024)
  diff --git a/drivers/net/netxen/netxen_nic_hw.c
  b/drivers/net/netxen/netxen_nic_hw.c index 3195fa5..4206125 100644
  --- a/drivers/net/netxen/netxen_nic_hw.c
  +++ b/drivers/net/netxen/netxen_nic_hw.c
  @@ -1141,7 +1141,7 @@ void netxen_nic_flash_print(struct netxe
 netxen_nic_driver_name);
  return;
  }
  -   *ptr32 = le32_to_cpu(*ptr32);
  +   *ptr32 = cpu_to_le32(*ptr32);

 Please add proper __le32 and avoid in-place swapping.  Please use sparse
 to verify that your endianess handling is correct.

Yes. We'll do this.
Thanks.


  +#ifdef CONFIG_PPC
  +static int nx_ppc_msi_enable = 0;  /* by default donot enable msi */
  +module_param(nx_ppc_msi_enable, int, 0644);
  +MODULE_PARM_DESC(nx_ppc_msi_enable, NetXen PPC MSI enable value);
  +#endif /* CONFIG_PPC */

 NACK.  If msi is broken on your card for certain setup disable it
 completely, if ppc msi support is broken fix it there.

Ok. I believe this can be handled through a firmware change, so that driver 
will read MIS parameter from there.
-Amit
-
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 qeth-remove-usage-of-subsys_rwsem.patch added to gregkh-2.6 tree

[gregkh]

This is a note to let you know that I've just added the patch titled

 Subject: qeth: Remove usage of subsys.rwsem

to my gregkh-2.6 tree.  Its filename is

 qeth-remove-usage-of-subsys_rwsem.patch

This tree can be found at 
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/


From [EMAIL PROTECTED]  Tue Apr 17 09:44:49 2007
From: Cornelia Huck [EMAIL PROTECTED]
Date: Tue, 17 Apr 2007 13:01:38 +0200
Subject: qeth: Remove usage of subsys.rwsem
To: Greg K-H [EMAIL PROTECTED], Frank Pavlic [EMAIL PROTECTED]
Cc: Linux Netdev List netdev@vger.kernel.org
Message-ID: [EMAIL PROTECTED]

the current driver tree contains the removal of subsys.rwsem.
Unfortunately, this breaks qeth. However, it should be no problem to
fix the walking of the devices for /proc/qeth:

No need to take subsys.rwsem during walking the devices,
driver_find_devices() should already suffice.

Signed-off-by: Cornelia Huck [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]

---
 drivers/s390/net/qeth_proc.c |2 --
 1 file changed, 2 deletions(-)

--- a/drivers/s390/net/qeth_proc.c
+++ b/drivers/s390/net/qeth_proc.c
@@ -37,7 +37,6 @@ qeth_procfile_seq_start(struct seq_file 
struct device *dev = NULL;
loff_t nr = 0;
 
-   down_read(qeth_ccwgroup_driver.driver.bus-subsys.rwsem);
if (*offset == 0)
return SEQ_START_TOKEN;
while (1) {
@@ -53,7 +52,6 @@ qeth_procfile_seq_start(struct seq_file 
 static void
 qeth_procfile_seq_stop(struct seq_file *s, void* it)
 {
-   up_read(qeth_ccwgroup_driver.driver.bus-subsys.rwsem);
 }
 
 static void *


Patches currently in gregkh-2.6 which might be from [EMAIL PROTECTED] are

driver/driver-core-per-subsystem-multithreaded-probing.patch
driver/driver-core-don-t-fail-attaching-the-device-if-it-cannot-be-bound.patch
driver/driver-core-suppress-uevents-via-filter.patch
driver/driver-core-switch-firmware_class-to-uevent_suppress.patch
driver/uevent-use-add_uevent_var-instead-of-open-coding-it.patch
driver/sysfs-add-sysfs_dirent-s_name.patch
driver/sysfs-add-sysfs_dirent-s_parent.patch
driver/sysfs-consolidate-sysfs_dirent-creation-functions.patch
driver/sysfs-fix-error-handling-in-binattr-write.patch
driver/sysfs-fix-i_ino-handling-in-sysfs.patch
driver/sysfs-flatten-cleanup-paths-in-sysfs_add_link-and-create_dir.patch
driver/sysfs-implement-bin_buffer.patch
driver/sysfs-implement-kobj_sysfs_assoc_lock.patch
driver/sysfs-make-sysfs_dirent-s_element-a-union.patch
driver/sysfs-move-release_sysfs_dirent-to-dir.c.patch
driver/sysfs-reimplement-symlink-using-sysfs_dirent-tree.patch
driver/sysfs-implement-sysfs_dirent-active-reference-and-immediate-disconnect.patch
driver/sysfs-kill-attribute-file-orphaning.patch
driver/sysfs-kill-unnecessary-attribute-owner.patch
driver/sysfs-make-lockdep-ignore-s_active.patch
driver/kobject-kobject_add-reference-leak.patch
driver/qeth-remove-usage-of-subsys_rwsem.patch
-
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: bug in tcp?

[Sebastian Kuzminsky]

Philip Craig [EMAIL PROTECTED] wrote:
 Sebastian Kuzminsky wrote:
  Weird.  Why does sending a message from the client make it go again?
 
 The rule that allows packets with an ESTABLISHED state only matches
 packets for which the connection is in netfilter's conntrack table.
 The connection is removed from the table after the 5 days of idle.
 It is only added again if netfilter accepts a packet for that connection.
 So the packet from the client will cause it to be added.

Why did the packet from the client cause the connection to be added back
to the conntrack table, but the packet from the server did not?


  How do people normally handle this?
 
 Change the timeout or use keepalives.  I can't think of any other way.
 The 5 days is a compromise between keeping valid connections and
 timing out dead connections.  There will always be connections for
 which it times out too fast or too slow.  I don't think there are
 any drawbacks to increasing the timeout if you aren't a router,
 but as long as there is a timeout, you need keepalives to be sure.

Thanks!  I'll add keepalives and rerun the tests, and I expect the
problem to go away.


-- 
Sebastian Kuzminsky
-
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 8338] New: NAT of TCP connections broken

[Patrick McHardy]

Andrew Morton wrote:
On Mon, 16 Apr 2007 13:35:47 -0700 [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8338

I'm using my debian box for sharing internet connection. After update to 
debian's 2.6.20 kernel (and adjusting new kernel configuration for NAT) NAT 
of 
TCP connections stoped working, while ICMP and UDP is working (ping, 
traceroute 
and DNS). When trying to open web page on a PC from my LAN (tried with linux 
and winxp), it sends the request but is unable to receive correct response 
from 
any site. On the router PC www works ok. 

I tried both new Independent connection tracking as well as Dependent 
(obsolete) connection tracking options with no luck.

tcp_window_scaling setting seems to have no effect.


Please send packet dumps from both the incoming and outgoing interfaces.
-
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 2.6] WE-22 : prevent information leak on 64 bit

[Jean Tourrilhes]

On Mon, Apr 02, 2007 at 12:06:50PM +0200, Johannes Berg wrote:
 
 Jean Tourrilhes wrote :
  Johannes Berg discovered that kernel space was leaking to
  userspace on 64 bit platform. He made a first patch to fix that. This
  is an improved version of his patch.
  This was tested on 2.6.21-rc4. Would you mind pushing that
  upstream ?
 
 Just FYI. This patch applies with rejects in net/core/rtnetlink.c and
 net/core/wireless.c to wireless-dev. The changes in those two files can
 be ignored completely since they affect only the removed
 wext-over-netlink interface.
 
 johannes

I'm sorry to have to write this e-mail. But this incident is
completely opposed to the ideal of FreeSoftware/OpenSource and
demonstrate some of the bad politics happening in Linux.

First, I'm the current active maintainer of the
wext-over-netlink interface, and nobody bothered to even 'inform' me
about its removal, let alone consult with me.
This shows a complete lack of courtesy and a total disrespect
to the concept of maintainer, basically some people are just second
class citizens.

Second, there is no technical justification to such decision,
it's just plain politics. I would agree that for the vast majority of
people, this API was useless, as any work in progress. But, it is
maintained (by me), it is not causing any technical issue, for those
people it's not compiled in (i.e. no bloat), it is not causing bugs
and not preventing other code to be merged in the kernel.
Therefore a purely politic decision.

Now, I've got a problem with your attitude in this matter,
Johannes. It's now the second time you remove features from code I
maintain by pure fiat, and you have engaged in a long running FUD
campain about my code. This is totally disgraceful of a Linux
maintainer, and you should know it.
If the only way you have to promote your code is by actively
destroying my code, then you have a real issue. Your code should stand
on its own merit, without the need of attacking other people's work
and playing political tricks.
I hope you will note that I never disparaged your code, I
never prevented its inclusion in Linux and I never attempted to
control the Linux Wireless space and left plenty of space for new
developpers.

You still have a lot to learn, like all of us. You still don't
understand Wireless Extensions (as your FUD shows) and why it's still
so popular despite all its warts. You don't get the value of not
burning bridges with other developpers and professional conduct.

By the way : don't bother replying to this e-mail, nothing
good will come of it.

Have fun...

Jean
-
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: [RFT] e100 driver on ARM

[Lennart Sorensen]

On Mon, Apr 16, 2007 at 11:07:36AM -0400, David Acker wrote:
 Lennart Sorensen wrote:
 Which PCI host controller are you using with the PXA255?  We tried using
 a PXA255 based system with a PCI controller a couple of years ago and
 have to change to a different cpu in the end due to the PCI controller
 simply not being valid PCI.  The PXA255 wasn't designed for PCI, and I
 get the impression that non of the PCI companion chips for it do a good
 enough job to actually add it correctly.
 
 
 Sorry for the delay in responding...my wife and I just had twins!
 
 We are using the IT8152G RISC-to-PCI companion chip.

Well the IT8152G+PXA255 combination used on the SBC we tried a couple of
years ago did not work.  The PCI bus had errors and the SBC maker gave
up trying to fix it.  We switched to a Geode SC1200 based board instead
which works fine PCI wise.

My suspicision (although it is only that) is that the PXA255 trying to
access memory may cause interruptions in PCI bus master transfers, which
is of course not permitted by the PCI spec (at least the way I read it).
We tried it with RTL8139, AMD 972 (both ethernet) as well as a number of
T1/E1 and DDS wan cards from sangoma.  The wan cards had the most issues
with it (they drivers and hardware would get out of sync due to PCI bus
problems), while the ethernet just had occational packet corruption.  I
will certainly never consider using a PXA + ITE pci controller
combination ever again.  Too bad since the performance of the PXA is
amazing.  The PXA chips are not designed to speak to PCI, and the ITE
companion chip doesn't quite do the job of pretending it was.  I would
expect problems if you do pci bus master transfers and/or any kind of
PCI bus traffic load.

--
Len Sorensen
-
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.21 0/3] cxgb3 - bug fixes

[Divy Le Ray]

Hi Jeff,

I'm submitting a set of bug fixes for inclusion in 2.6.21.
The patches are built against Linus'git tree.

Here is a brief description:
- Fix resource usage in low memory conditions,
- PHY interrupts can use any GPIO pin.

Cheers,
Divy
-
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.21 1/2] cxgb3 - Fix low memory conditions

[divy]

From: Divy Le Ray [EMAIL PROTECTED]

Reuse the incoming skb when a clientless abort req is recieved.

The release of RDMA connections HW resources might be deferred in
low memory situations. 
Ensure that no further activity is passed up to the RDMA driver
for these connections.

Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---

 drivers/net/cxgb3/cxgb3_defs.h|5 ++-
 drivers/net/cxgb3/cxgb3_offload.c |   69 +++--
 2 files changed, 55 insertions(+), 19 deletions(-)

diff --git a/drivers/net/cxgb3/cxgb3_defs.h b/drivers/net/cxgb3/cxgb3_defs.h
index e14862b..483a594 100644
--- a/drivers/net/cxgb3/cxgb3_defs.h
+++ b/drivers/net/cxgb3/cxgb3_defs.h
@@ -67,7 +67,10 @@ static inline union listen_entry *stid2e
 static inline struct t3c_tid_entry *lookup_tid(const struct tid_info *t,
   unsigned int tid)
 {
-   return tid  t-ntids ? (t-tid_tab[tid]) : NULL;
+   struct t3c_tid_entry *t3c_tid = tid  t-ntids ?
+   (t-tid_tab[tid]) : NULL;
+
+   return (t3c_tid  t3c_tid-client) ? t3c_tid : NULL;
 }
 
 /*
diff --git a/drivers/net/cxgb3/cxgb3_offload.c 
b/drivers/net/cxgb3/cxgb3_offload.c
index 4864924..199e506 100644
--- a/drivers/net/cxgb3/cxgb3_offload.c
+++ b/drivers/net/cxgb3/cxgb3_offload.c
@@ -508,6 +508,7 @@ void cxgb3_queue_tid_release(struct t3cd
 
spin_lock_bh(td-tid_release_lock);
p-ctx = (void *)td-tid_release_list;
+   p-client = NULL;
td-tid_release_list = p;
if (!p-ctx)
schedule_work(td-tid_release_task);
@@ -623,7 +624,8 @@ static int do_act_open_rpl(struct t3cdev
struct t3c_tid_entry *t3c_tid;
 
t3c_tid = lookup_atid((T3C_DATA(dev))-tid_maps, atid);
-   if (t3c_tid-ctx  t3c_tid-client  t3c_tid-client-handlers 
+   if (t3c_tid  t3c_tid-ctx  t3c_tid-client 
+   t3c_tid-client-handlers 
t3c_tid-client-handlers[CPL_ACT_OPEN_RPL]) {
return t3c_tid-client-handlers[CPL_ACT_OPEN_RPL] (dev, skb,
t3c_tid-
@@ -642,7 +644,7 @@ static int do_stid_rpl(struct t3cdev *de
struct t3c_tid_entry *t3c_tid;
 
t3c_tid = lookup_stid((T3C_DATA(dev))-tid_maps, stid);
-   if (t3c_tid-ctx  t3c_tid-client-handlers 
+   if (t3c_tid  t3c_tid-ctx  t3c_tid-client-handlers 
t3c_tid-client-handlers[p-opcode]) {
return t3c_tid-client-handlers[p-opcode] (dev, skb,
 t3c_tid-ctx);
@@ -660,7 +662,7 @@ static int do_hwtid_rpl(struct t3cdev *d
struct t3c_tid_entry *t3c_tid;
 
t3c_tid = lookup_tid((T3C_DATA(dev))-tid_maps, hwtid);
-   if (t3c_tid-ctx  t3c_tid-client-handlers 
+   if (t3c_tid  t3c_tid-ctx  t3c_tid-client-handlers 
t3c_tid-client-handlers[p-opcode]) {
return t3c_tid-client-handlers[p-opcode]
(dev, skb, t3c_tid-ctx);
@@ -689,6 +691,28 @@ static int do_cr(struct t3cdev *dev, str
}
 }
 
+/*
+ * Returns an sk_buff for a reply CPL message of size len.  If the input
+ * sk_buff has no other users it is trimmed and reused, otherwise a new buffer
+ * is allocated.  The input skb must be of size at least len.  Note that this
+ * operation does not destroy the original skb data even if it decides to reuse
+ * the buffer.
+ */
+static struct sk_buff *cxgb3_get_cpl_reply_skb(struct sk_buff *skb, size_t len,
+  int gfp)
+{
+   if (likely(!skb_cloned(skb))) {
+   BUG_ON(skb-len  len);
+   __skb_trim(skb, len);
+   skb_get(skb);
+   } else {
+   skb = alloc_skb(len, gfp);
+   if (skb)
+   __skb_put(skb, len);
+   }
+   return skb;
+}
+
 static int do_abort_req_rss(struct t3cdev *dev, struct sk_buff *skb)
 {
union opcode_tid *p = cplhdr(skb);
@@ -696,30 +720,39 @@ static int do_abort_req_rss(struct t3cde
struct t3c_tid_entry *t3c_tid;
 
t3c_tid = lookup_tid((T3C_DATA(dev))-tid_maps, hwtid);
-   if (t3c_tid-ctx  t3c_tid-client-handlers 
+   if (t3c_tid  t3c_tid-ctx  t3c_tid-client-handlers 
t3c_tid-client-handlers[p-opcode]) {
return t3c_tid-client-handlers[p-opcode]
(dev, skb, t3c_tid-ctx);
} else {
struct cpl_abort_req_rss *req = cplhdr(skb);
struct cpl_abort_rpl *rpl;
+   struct sk_buff *reply_skb;
+   unsigned int tid = GET_TID(req);
+   u8 cmd = req-status;
+
+   if (req-status == CPL_ERR_RTX_NEG_ADVICE ||
+   req-status == CPL_ERR_PERSIST_NEG_ADVICE)
+   goto out;
 
-   struct sk_buff *skb =
-   alloc_skb(sizeof(struct cpl_abort_rpl), GFP_ATOMIC);
-   if (!skb) {
+   reply_skb = 

[PATCH 2.6.21 2/2] cxgb3 - PHY interrupts and GPIO pins.

[divy]

From: Divy Le Ray [EMAIL PROTECTED]

Remove assumption that PHY interrupts use GPIOs 3 and 5.
Deal with PHY interrupts connected to any GPIO pins.

Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---

 drivers/net/cxgb3/t3_hw.c |   18 --
 1 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index d83f075..fb485d0 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -1523,19 +1523,25 @@ static int mac_intr_handler(struct adapt
  */
 int t3_phy_intr_handler(struct adapter *adapter)
 {
-   static const int intr_gpio_bits[] = { 8, 0x20 };
-
+   u32 mask, gpi = adapter_info(adapter)-gpio_intr;
u32 i, cause = t3_read_reg(adapter, A_T3DBG_INT_CAUSE);
 
for_each_port(adapter, i) {
-   if (cause  intr_gpio_bits[i]) {
-   struct cphy *phy = adap2pinfo(adapter, i)-phy;
-   int phy_cause = phy-ops-intr_handler(phy);
+   struct port_info *p = adap2pinfo(adapter, i);
+
+   mask = gpi - (gpi  (gpi - 1));
+   gpi -= mask;
+
+   if (!(p-port_type-caps  SUPPORTED_IRQ))
+   continue;
+
+   if (cause  mask) {
+   int phy_cause = p-phy.ops-intr_handler(p-phy);
 
if (phy_cause  cphy_cause_link_change)
t3_link_changed(adapter, i);
if (phy_cause  cphy_cause_fifo_error)
-   phy-fifo_errors++;
+   p-phy.fifo_errors++;
}
}
 
-
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] CONFIG_PACKET_MMAP should depend on MMU

[Robin Getz]

On Tue 17 Apr 2007 06:36, Aubrey Li pondered:
 Here, in the attachment I wrote a small test app. Please correct if
 there is anything wrong, and feel free to improve it.

Thanks. 

David - Does this give you what you need?
-
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] CONFIG_PACKET_MMAP should depend on MMU

[David Howells]

Robin Getz [EMAIL PROTECTED] wrote:

 David - Does this give you what you need?

Possibly.  I'll have a look at it tomorrow.

David
-
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 2.6] WE-22 : prevent information leak on 64 bit

[John W. Linville]

On Tue, Apr 17, 2007 at 10:08:20AM -0700, Jean Tourrilhes wrote:
 On Mon, Apr 02, 2007 at 12:06:50PM +0200, Johannes Berg wrote:
  
  Jean Tourrilhes wrote :
 Johannes Berg discovered that kernel space was leaking to
   userspace on 64 bit platform. He made a first patch to fix that. This
   is an improved version of his patch.
 This was tested on 2.6.21-rc4. Would you mind pushing that
   upstream ?
  
  Just FYI. This patch applies with rejects in net/core/rtnetlink.c and
  net/core/wireless.c to wireless-dev. The changes in those two files can
  be ignored completely since they affect only the removed
  wext-over-netlink interface.
  
  johannes
 
   I'm sorry to have to write this e-mail. But this incident is
 completely opposed to the ideal of FreeSoftware/OpenSource and
 demonstrate some of the bad politics happening in Linux.
 
   First, I'm the current active maintainer of the
 wext-over-netlink interface, and nobody bothered to even 'inform' me
 about its removal, let alone consult with me.

Honestly, most of us thought you weren't interested.

   This shows a complete lack of courtesy and a total disrespect
 to the concept of maintainer, basically some people are just second
 class citizens.

I'm sorry that you are upset.  I do not believe any disrespect was
intended.

   Second, there is no technical justification to such decision,
 it's just plain politics. I would agree that for the vast majority of
 people, this API was useless, as any work in progress. But, it is
 maintained (by me), it is not causing any technical issue, for those
 people it's not compiled in (i.e. no bloat), it is not causing bugs
 and not preventing other code to be merged in the kernel.
   Therefore a purely politic decision.

I would not call it politics, but I do not want to split hairs.

This API was controversial and mostly unwelcome from the start.
It was ridiculed as ioctls over netlink at the last kernel summit.
It is widely regarded as less of a solution and more of an extension
to a problem.

One of the objections to having merged the API was that _if_ it were
to gain users then we would have to carry that maintenance burden
ad infinitum.  This fear was already beginning to be confirmed by the
efforts at maintaining WE compatibility in cfg80211.  Since there were
(thankfully) still no users and only compatibility headaches from
maintaining it, Johannes wanted to remove the code, and I consented
to his request.

I wish you would not view this as a personal issue.  Your contributions
are certainly welcome in general.  We just don't see any benefit from
keeping this code around as we move forward.

Again, I am terribly sorry that this was a surprise to you.  I will be
sure to communicate with you directly should another such issue arise.

   By the way : don't bother replying to this e-mail, nothing
 good will come of it.

Hopefully that isn't totally true...

Regards,

John
-- 
John W. Linville
[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: [NET]: Get rid of alloc_skb code duplication

[David Miller]

From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 18 Apr 2007 00:17:43 +1000

 On Tue, Apr 17, 2007 at 02:03:47PM +0100, Christoph Hellwig wrote:
 
  It was put in for Xen, but if you as the resident beat the crap out
  of Xen networking guru don't know about it we should probably just
  kill it.  Especially as we usually kill dead code pretty fast.
 
 Heh, I wasn't touching Xen back then.
 
 That's good news actually.  Xen has now killed their custom alloc_skb
 so this is no longer needed.  Besides, even if they needed it they'll
 have to patch it in anyway since you've already killed the ifdef that
 lets them have a custom alloc_skb :)
 
 [NET]: Get rid of alloc_skb_from_cache
 
 Since this was added originally for Xen, and Xen has recently (~2.6.18)
 stopped using this function, we can safely get rid of it.  Good timing
 too since this function has started to bit rot.
 
 Signed-off-by: Herbert Xu [EMAIL PROTECTED]

Applied.  You missed the arch/x86_64/kernel/functionlist reference
but I took care of that for you :-)

I'm going to push this into 2.6.21 because the sooner this dies
the better, even though it will make for some net-2.6.22 merge
hassles for me.
-
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: [BRIDGE] Unaligned access on IA64 when comparing ethernet addresses

[David Miller]

From: Pavel Emelianov [EMAIL PROTECTED]
Date: Tue, 17 Apr 2007 15:49:30 +0400

 From: Evgeny Kravtsunov [EMAIL PROTECTED]
 
 compare_ether_addr() implicitly requires that the addresses
 passed are 2-bytes aligned in memory.
 
 This is not true for br_stp_change_bridge_id() and
 br_stp_recalculate_bridge_id() in which one of the addresses
 is unsigned char *, and thus may not be 2-bytes aligned.
 
 Signed-off-by: Evgeny Kravtsunov [EMAIL PROTECTED]
 Signed-off-by: Kirill Korotaev [EMAIL PROTECTED]
 Signed-off-by: Pavel Emelianov [EMAIL PROTECTED]

Patch applied, thank you.
-
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] KEY: Fix conversion between IPSEC_MODE_xxx and XFRM_MODE_xxx.

[David Miller]

From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED]
Date: Tue, 17 Apr 2007 17:15:17 +0900 (JST)

 From: Kazunori MIYAZAWA [EMAIL PROTECTED]
 Subject: [PATCH] KEY: Fix conversion between IPSEC_MODE_xxx and XFRM_MODE_xxx.
 
 We should not blindly convert between IPSEC_MODE_xxx and XFRM_MODE_xxx just
 by incrementing / decrementing because the assumption is not true any longer.
 
 Signed-off-by: Kazunori MIYAZAWA [EMAIL PROTECTED]
 Singed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]

Patch applied, thank you.
-
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: TCP connection stops after high load.

[David Miller]

From: Robert Iakobashvili [EMAIL PROTECTED]
Date: Tue, 17 Apr 2007 10:58:04 +0300

 David,
 
 On 4/16/07, David Miller [EMAIL PROTECTED] wrote:
Commit: 53cdcc04c1e85d4e423b2822b66149b6f2e52c2c
Author: John Heffner [EMAIL PROTECTED] Fri, 16 Mar 2007 15:04:03 -0700
   
 [TCP]: Fix tcp_mem[] initialization.
 Change tcp_mem initialization function.  The fraction of total 
memory
 is now a continuous function of memory size, and independent of 
page
 size.
  
  
   Kernels 2.6.19 and 2.6.20 series are effectively broken right now.
   Don't you wish to patch them?
 
  Can you verify that this patch actually fixes your problem?
 
 Yes, it fixes.

Thanks, I will submit it to -stable branch.
-
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] Fix UDP checksum issue in net poll mode.

[David Miller]

From: Aubrey Li [EMAIL PROTECTED]
Date: Tue, 17 Apr 2007 14:53:48 +0800

 In net poll mode, the current checksum function doesn't consider the
 kind of packet which is padded to reach a specific minimum length. I
 believe that's the problem causing my test case failed. The following
 patch fixed this issue.
 
 Signed-off-by: Aubrey.Li [EMAIL PROTECTED]

This looks good, patch applied, thanks Aubrey.
-
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: TCP connection stops after high load.

[David Miller]

From: John Heffner [EMAIL PROTECTED]
Date: Tue, 17 Apr 2007 15:47:58 -0400

 My only reservation in submitting this to -stable is that it will in 
 many cases increase the default tcp_mem values, which in turn can 
 increase the default tcp_rmem values, and therefore the window scale. 
 There will be some set of people with broken firewalls who trigger that 
 problem for the first time by upgrading along the stable branch.  While 
 it's not our fault, it could cause some complaints...

It is a very valid concern.

However this is fixing a problem where we are in the wrong,
whereas the firewall issues are external and should not
block us from being able to fix our own bugs :-)
-
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 1/2] [SCTP] Fix assertion (!atomic_read(sk-sk_rmem_alloc)) failed message

[David Miller]

From: Vlad Yasevich [EMAIL PROTECTED]
Date: Tue, 10 Apr 2007 17:21:23 -0400

 From: Tsutomu Fujii [EMAIL PROTECTED]
 
 In current implementation, LKSCTP does receive buffer accounting for
 data in sctp_receive_queue and pd_lobby. However, LKSCTP don't do
 accounting for data in frag_list when data is fragmented. In addition,
 LKSCTP doesn't do accounting for data in reasm and lobby queue in
 structure sctp_ulpq.
 When there are date in these queue, assertion failed message is printed
 in inet_sock_destruct because sk_rmem_alloc of oldsk does not become 0
 when socket is destroyed.
 
 Signed-off-by: Tsutomu Fujii [EMAIL PROTECTED]
 Signed-off-by: Vlad Yasevich [EMAIL PROTECTED]

Patch applied.
-
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 2/2] [SCTP] Unmap v4mapped addresses during SCTP_BINDX_REM_ADDR operation.

[David Miller]

From: Vlad Yasevich [EMAIL PROTECTED]
Date: Tue, 10 Apr 2007 17:21:24 -0400

 From: Paolo Galtieri [EMAIL PROTECTED]
 
 During the sctp_bindx() call to add additional addresses to the
 endpoint, any v4mapped addresses are converted and stored as regular
 v4 addresses.  However, when trying to remove these addresses, the
 v4mapped addresses are not converted and the operation fails.  This
 patch unmaps the addresses on during the remove operation as well.
 
 Signed-off-by: Paolo Galtieri [EMAIL PROTECTED]
 Signed-off-by: Vlad Yasevich [EMAIL PROTECTED]

Patch applied, thank you.
-
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: [BRIDGE] Unaligned access on IA64 when comparing ethernet addresses

[Stephen Hemminger]

David Miller wrote:

From: Pavel Emelianov [EMAIL PROTECTED]
Date: Tue, 17 Apr 2007 15:49:30 +0400

  

From: Evgeny Kravtsunov [EMAIL PROTECTED]

compare_ether_addr() implicitly requires that the addresses
passed are 2-bytes aligned in memory.

This is not true for br_stp_change_bridge_id() and
br_stp_recalculate_bridge_id() in which one of the addresses
is unsigned char *, and thus may not be 2-bytes aligned.

Signed-off-by: Evgeny Kravtsunov [EMAIL PROTECTED]
Signed-off-by: Kirill Korotaev [EMAIL PROTECTED]
Signed-off-by: Pavel Emelianov [EMAIL PROTECTED]



Patch applied, thank you.
  

I had a better way, I'll fix.
-
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: TCP connection stops after high load.

[Robert Iakobashvili]

 Yes, it fixes.

Thanks, I will submit it to -stable branch.



David and John,
Thanks for your caring and attention.


--
Sincerely,
Robert Iakobashvili,
coroberti %x40 gmail %x2e com
...
Navigare necesse est, vivere non est necesse
...
http://curl-loader.sourceforge.net
An open-source HTTP/S, FTP/S traffic
generating, and web testing tool.
-
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: [BRIDGE] Unaligned access on IA64 when comparing ethernet addresses

[David Miller]

From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 17 Apr 2007 12:55:41 -0700

 David Miller wrote:
  From: Pavel Emelianov [EMAIL PROTECTED]
  Date: Tue, 17 Apr 2007 15:49:30 +0400
 

  From: Evgeny Kravtsunov [EMAIL PROTECTED]
 
  compare_ether_addr() implicitly requires that the addresses
  passed are 2-bytes aligned in memory.
 
  This is not true for br_stp_change_bridge_id() and
  br_stp_recalculate_bridge_id() in which one of the addresses
  is unsigned char *, and thus may not be 2-bytes aligned.
 
  Signed-off-by: Evgeny Kravtsunov [EMAIL PROTECTED]
  Signed-off-by: Kirill Korotaev [EMAIL PROTECTED]
  Signed-off-by: Pavel Emelianov [EMAIL PROTECTED]
  
 
  Patch applied, thank you.

 I had a better way, I'll fix.

You better hurry I want today's fixes I applied out to Linus this
afternoon.
-
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: r8169 2.2LK: Low link speed after suspend

[Peter Missel]

Hello Francois!

Thanks for the quick reply.

  Now after resume, the link is working OK but doesn't come back up to
  normal gigabit operation. ifdown, unloading and reloading the r8169
  module, and then ifup again fixes it.
 
 Can you try 2.6.21-rc7 + (either):
 - http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.21-rc7/r8169-20070416
 -
 http://www.fr.zoreil.com/people/francois/misc/20070416-2.6.21-rc7-r8169-tes
t.patch

Does this patchset work against kernel 2.6.18, or, better yet, is there a 
separate source package that lets me build the current driver on this older 
kernel?

 If it does not work better, please fill an entry for it at
 bugzilla.kernel.org, Cc: it to me and attach the output of a registers dump
 taken from mii-tool before suspend and after a failed resume.

I'll possibly get to trying things out by the end of next week. Until then, 
real life will consume all my spare time.

Thanks so far.

regards,
Peter
-
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: [BRIDGE] Unaligned access on IA64 when comparing ethernet addresses

[Stephen Hemminger]

The previous patch relied on the bridge id being aligned by
the compiler (which happens as a side effect). So please use
this instead.

compare_ether_addr() implicitly requires that the addresses
passed are 2-bytes aligned in memory.

This is not true for br_stp_change_bridge_id() and
br_stp_recalculate_bridge_id() in which one of the addresses
is unsigned char *, and thus may not be 2-bytes aligned.

Signed-off-by: Evgeny Kravtsunov [EMAIL PROTECTED]
Signed-off-by: Kirill Korotaev [EMAIL PROTECTED]
Signed-off-by: Pavel Emelianov [EMAIL PROTECTED]
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]

---

--- linux-2.6.orig/net/bridge/br_stp_if.c   2007-04-16
20:03:04.0 -0700 +++ linux-2.6/net/bridge/br_stp_if.c
2007-04-17 13:25:52.0 -0700 @@ -126,23 +126,22 @@
 /* called under bridge lock */
 void br_stp_change_bridge_id(struct net_bridge *br, const unsigned
char *addr) {
-   unsigned char oldaddr[6];
+   bridge_id old_id;
struct net_bridge_port *p;
int wasroot;
 
wasroot = br_is_root_bridge(br);
 
-   memcpy(oldaddr, br-bridge_id.addr, ETH_ALEN);
+   old_id = br-bridge_id;
memcpy(br-bridge_id.addr, addr, ETH_ALEN);
memcpy(br-dev-dev_addr, addr, ETH_ALEN);
 
list_for_each_entry(p, br-port_list, list) {
-   if (!compare_ether_addr(p-designated_bridge.addr,
oldaddr))
+   if (!compare_ether_addr(p-designated_bridge.addr,
old_id.addr)) memcpy(p-designated_bridge.addr, addr, ETH_ALEN);
 
-   if (!compare_ether_addr(p-designated_root.addr,
oldaddr))
+   if (!compare_ether_addr(p-designated_root.addr,
old_id.addr)) memcpy(p-designated_root.addr, addr, ETH_ALEN);
-
}
 
br_configuration_update(br);
@@ -151,19 +150,17 @@
br_become_root_bridge(br);
 }
 
-static const unsigned char br_mac_zero[6];
-
 /* called under bridge lock */
 void br_stp_recalculate_bridge_id(struct net_bridge *br)
 {
-   const unsigned char *addr = br_mac_zero;
+   static const bridge_id id_zero;
+   const unsigned char *addr = id_zero.addr;
struct net_bridge_port *p;
 
list_for_each_entry(p, br-port_list, list) {
-   if (addr == br_mac_zero ||
+   if (addr == id_zero.addr ||
memcmp(p-dev-dev_addr, addr, ETH_ALEN)  0)
addr = p-dev-dev_addr;
-
}
 
if (compare_ether_addr(br-bridge_id.addr, addr))
--- linux-2.6.orig/net/bridge/br_private.h  2007-04-17
13:26:48.0 -0700 +++ linux-2.6/net/bridge/br_private.h
2007-04-17 13:30:29.0 -0700 @@ -36,7 +36,7 @@
 {
unsigned char   prio[2];
unsigned char   addr[6];
-};
+} __attribute__((aligned(8)));
 
 struct mac_addr
 {
-
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: [BRIDGE] Unaligned access on IA64 when comparing ethernet addresses

[David Miller]

From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 17 Apr 2007 13:37:23 -0700

 The previous patch relied on the bridge id being aligned by
 the compiler (which happens as a side effect). So please use
 this instead.
 
 compare_ether_addr() implicitly requires that the addresses
 passed are 2-bytes aligned in memory.
 
 This is not true for br_stp_change_bridge_id() and
 br_stp_recalculate_bridge_id() in which one of the addresses
 is unsigned char *, and thus may not be 2-bytes aligned.
 
 Signed-off-by: Evgeny Kravtsunov [EMAIL PROTECTED]
 Signed-off-by: Kirill Korotaev [EMAIL PROTECTED]
 Signed-off-by: Pavel Emelianov [EMAIL PROTECTED]
 Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]

bridge_id would be aligned by luck, because it is composed of char's
there is no explicit reason it should be aligned on at least an
unsigned short boundary.

I like the other patch much better, it provided explicit alignment and
is guarenteed to get rid of the problem.

Indeed, I wrote a test program on 32-bit Sparc to validate this:

struct bridge_id {
unsigned char a[6];
unsigned char b[6];
};

extern void bar(unsigned char *, unsigned char *);

void foo(void)
{
unsigned char a;
struct bridge_id b;

bar(b.a[0], a);
}

foo() gets compiled like this:

foo:
save%sp, -120, %sp
add %fp, -21, %o0
callbar, 0
 add%fp, -9, %o1
jmp %i7+8
 restore

See?  The bridge_id (passed in via %o0) is on an odd byte boundary
on the stack.

So your patch isn't fixing the bug at all.

I'm going to apply the original patch, because that one will
actually fix the problem and was actually tested on a system
that saw the problem.
-
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 2.6] WE-22 : prevent information leak on 64 bit

[Jean Tourrilhes]

On Tue, Apr 17, 2007 at 02:34:42PM -0400, John W. Linville wrote:
 On Tue, Apr 17, 2007 at 10:08:20AM -0700, Jean Tourrilhes wrote:
  
  First, I'm the current active maintainer of the
  wext-over-netlink interface, and nobody bothered to even 'inform' me
  about its removal, let alone consult with me.
 
 Honestly, most of us thought you weren't interested.

Please !

 This API was controversial and mostly unwelcome from the start.
 It was ridiculed as ioctls over netlink at the last kernel summit.

Which is complete FUD. In that case, the whole RtNetlink can
be classified as ioctls over netlink.

 One of the objections to having merged the API was that _if_ it were
 to gain users then we would have to carry that maintenance burden
 ad infinitum.

More FUD. It does not add any new commands. The proof is in
the pudding, no change was needed in any driver to support it,
therefore it could not have added any burden on any compatibility
layer.

 Regards,
 
 John

Have fun...

Jean
-
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: [BRIDGE] Unaligned access on IA64 when comparing ethernet addresses

[Eric Dumazet]

David Miller a écrit :

From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 17 Apr 2007 13:37:23 -0700


The previous patch relied on the bridge id being aligned by
the compiler (which happens as a side effect). So please use
this instead.

compare_ether_addr() implicitly requires that the addresses
passed are 2-bytes aligned in memory.

This is not true for br_stp_change_bridge_id() and
br_stp_recalculate_bridge_id() in which one of the addresses
is unsigned char *, and thus may not be 2-bytes aligned.

Signed-off-by: Evgeny Kravtsunov [EMAIL PROTECTED]
Signed-off-by: Kirill Korotaev [EMAIL PROTECTED]
Signed-off-by: Pavel Emelianov [EMAIL PROTECTED]
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]


bridge_id would be aligned by luck, because it is composed of char's
there is no explicit reason it should be aligned on at least an
unsigned short boundary.

I like the other patch much better, it provided explicit alignment and
is guarenteed to get rid of the problem.

Indeed, I wrote a test program on 32-bit Sparc to validate this:

struct bridge_id {
unsigned char a[6];
unsigned char b[6];
};

extern void bar(unsigned char *, unsigned char *);

void foo(void)
{
unsigned char a;
struct bridge_id b;

bar(b.a[0], a);
}

foo() gets compiled like this:

foo:
save%sp, -120, %sp
add %fp, -21, %o0
callbar, 0
 add%fp, -9, %o1
jmp %i7+8
 restore

See?  The bridge_id (passed in via %o0) is on an odd byte boundary
on the stack.

So your patch isn't fixing the bug at all.

I'm going to apply the original patch, because that one will
actually fix the problem and was actually tested on a system
that saw the problem.


I suspect you missed part of Stephen patch :

(maybe some mailer problem...)

--- linux-2.6.orig/net/bridge/br_private.h  2007-04-17
13:26:48.0 -0700 +++ linux-2.6/net/bridge/br_private.h
2007-04-17 13:30:29.0 -0700 @@ -36,7 +36,7 @@
 {
unsigned char   prio[2];
unsigned char   addr[6];
-};
+} __attribute__((aligned(8)));

 struct mac_addr
 {

-
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: [BRIDGE] Unaligned access on IA64 when comparing ethernet addresses

[David Miller]

From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 17 Apr 2007 23:24:36 +0200

 I suspect you missed part of Stephen patch :
 
 (maybe some mailer problem...)

My bad, sorry :(

I pushed the other version of the fix to Linus just now.
I'll put Stephen's version in if he sends me a fixup relative
to that.

Sorry again.

-
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 2.6] WE-22 : prevent information leak on 64 bit

[Roland Dreier]

   This API was controversial and mostly unwelcome from the start.
   It was ridiculed as ioctls over netlink at the last kernel summit.
  
   Which is complete FUD. In that case, the whole RtNetlink can
  be classified as ioctls over netlink.

The problem is that WE over netlink is basically using netlink to
transfer the same binary blobs as the WE ioctls, rather than using
properly structured netlink messages.

   One of the objections to having merged the API was that _if_ it were
   to gain users then we would have to carry that maintenance burden
   ad infinitum.
  
   More FUD. It does not add any new commands. The proof is in
  the pudding, no change was needed in any driver to support it,
  therefore it could not have added any burden on any compatibility
  layer.

The point is that if WE over netlink is used by applications, then the
kernel must maintain that ABI (of WE over netlink) forever.

 - R.
-
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: r8169 2.2LK: Low link speed after suspend

[Francois Romieu]

Peter Missel [EMAIL PROTECTED] :
[...]
 Does this patchset work against kernel 2.6.18, or, better yet, is there a 
 separate source package that lets me build the current driver on this older 
 kernel?

Hardly: the r8169 driver has been modified by ~40 patches from 2.6.18 to now.

There is an ugly hack^W^W quick backport for 2.6.18 at:
http://www.fr.zoreil.com/people/francois/backport/r8169/20070418-00

It compiles but I do not know if it works and I strongly suggest to use
a more recent kernel package anyway.

-- 
Ueimor

Anybody got a battery for my Ultra 10 ?
-
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: r8169 2.2LK: Low link speed after suspend

[Peter Missel]

Hi Francois,

and thanks again for the quick replies.

  Does this patchset work against kernel 2.6.18, or, better yet, is there a
  separate source package that lets me build the current driver on this
  older kernel?

 Hardly: the r8169 driver has been modified by ~40 patches from 2.6.18 to
 now.

 There is an ugly hack^W^W quick backport for 2.6.18 at:
 http://www.fr.zoreil.com/people/francois/backport/r8169/20070418-00

 It compiles but I do not know if it works and I strongly suggest to use
 a more recent kernel package anyway.

I'll do my best - a kernel update is certainly not possible on this particular 
machine, simply because it is a user workstation that is actually being 
used ;)

Also, mii-tool doesn't appear to be included anywhere in this (SuSE 10.2 x64) 
installation, so I'll have to look into building this from source.

Meanwhile, a new bit of information that maybe gives a hint: 

ethtool -d shows reg 0x6C PHY status changes from 0x6b (erroneous 100TX 
link) to 0x73 (correct 1000TX link). What ethtool dumps aren't MII registers, 
so I doubt that this tells us anything useful, but here it is anyway.

Bonne nuit!

Peter
-
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: bug in tcp?

[Philip Craig]

Sebastian Kuzminsky wrote:
 Why did the packet from the client cause the connection to be added back
 to the conntrack table, but the packet from the server did not?

Because the packet from the client was accepted (by a different
iptables rule).

-
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 2.6] WE-22 : prevent information leak on 64 bit

[Michael Buesch]

On Tuesday 17 April 2007 19:08, Jean Tourrilhes wrote:
   I'm sorry to have to write this e-mail. But this incident is
 completely opposed to the ideal of FreeSoftware/OpenSource and
 demonstrate some of the bad politics happening in Linux.
 
   First, I'm the current active maintainer of the
 wext-over-netlink interface, and nobody bothered to even 'inform' me
 about its removal, let alone consult with me.
   This shows a complete lack of courtesy and a total disrespect
 to the concept of maintainer, basically some people are just second
 class citizens.
 
   Second, there is no technical justification to such decision,
 it's just plain politics. I would agree that for the vast majority of
 people, this API was useless, as any work in progress. But, it is
 maintained (by me), it is not causing any technical issue, for those
 people it's not compiled in (i.e. no bloat), it is not causing bugs
 and not preventing other code to be merged in the kernel.
   Therefore a purely politic decision.

It is _only_ about replacing obsolete code by code that obsoleted it.
That happens all the time. Look at the process scheduler and compare
it to 2.4, for example.

We want to reduce the maintainance burden. Nothing more.
If we remove unused code (which WEXT-NL is), then we don't have to
write compatibility code to support it in future.
Why wait with removal until we can't anymore (when people use it)?

   Now, I've got a problem with your attitude in this matter,
 Johannes. It's now the second time you remove features from code I
 maintain by pure fiat, and you have engaged in a long running FUD
 campain about my code. This is totally disgraceful of a Linux
 maintainer, and you should know it.
   If the only way you have to promote your code is by actively
 destroying my code, then you have a real issue. Your code should stand
 on its own merit, without the need of attacking other people's work
 and playing political tricks.
   I hope you will note that I never disparaged your code, I
 never prevented its inclusion in Linux and I never attempted to
 control the Linux Wireless space and left plenty of space for new
 developpers.
 
   You still have a lot to learn, like all of us. You still don't
 understand Wireless Extensions (as your FUD shows) and why it's still
 so popular despite all its warts. You don't get the value of not
 burning bridges with other developpers and professional conduct.

I'd say nobody but you does fully understand WEXT. Somebody might
call that either a design issue, or a documentation issue.
I personally make both issues responsible for this.

-- 
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: [Bugme-new] [Bug 8349] New: Manually set IPv6 default route ignored

[Andrew Morton]

On Tue, 17 Apr 2007 18:45:12 -0700 [EMAIL PROTECTED] wrote:

 http://bugzilla.kernel.org/show_bug.cgi?id=8349
 
Summary: Manually set IPv6 default route ignored
 Kernel Version: 2.6.20.7
 Status: NEW
   Severity: normal
  Owner: [EMAIL PROTECTED]
  Submitter: [EMAIL PROTECTED]
 
 
 Most recent kernel where this bug did *NOT* occur: 2.6.19.5
 Distribution: Debian sid
 Hardware Environment: x86 (Pentium 4/MMX)
 Software Environment: iproute2-ss060323, ifupdown 0.6.8
 
 Problem Description:
 Default routes added to the IPv6 routing table, which are not coming from
 autoconfiguration, seem to be ignored. Subsequently, IPv6 routing is 
 disrupted,
 and for instance calls to connect() fail with an ENETUNREACH error.
 
 Steps to reproduce:
 0. Find an IPv6-enabled box on an IPv6-free network. In the absence of any 
 other
 configuration, the routing table contains the single line:
 fe80::/64 dev eth0 ...
 1. Add a default route:
 ip -6 ro add default via fe80::1 dev eth0
 2. Try to do IPv6, for instance:
 # ping6 2001:4978:1:110:0:ac:ce55:1b1e
 connect: Network is unreachable
 (returns instantly, no packet is sent)
 
 This bug is present in the last stable 2.6.20.7 kernel, and in 2.6.21-rc7. I
 actually came across this bug on a server on a network where IPv6 is routed 
 and
 advertised, but with autoconfiguration disabled on this server. It *seems* to 
 me
 that if the interface is brought up with accept_ra enabled, default routes,
 including the one got from RA and ones input by hand later will work, whereas 
 if
 it is brought up with accept_ra disabled (or no RA is received), the problem
 will occur. Note that routes with a non-null prefix length, such as 3 or 1, 
 work
 fine.
-
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