Re: [PATCH] TCP Offload (TOE) - Chelsio
From: Scott Bardone <[EMAIL PROTECTED]> Date: Thu, 11 Aug 2005 23:16:14 -0700 > - static was removed from functions '__tcp_inherit_port' & '__tcp_v4_hash' > because these are called outside of tcp_ipv4.c from the TOM driver. There is no way you're going to be allowed to call such deep TCP internals from your driver. This would mean that every time we wish to change the data structures and interfaces for TCP socket lookup, your drivers would need to change. This is all looking exactly like the deep dark dungeon I feared TOE support would be. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] TCP Offload (TOE) - Chelsio
"OPEN TOE" submission from Chelsio Communications.
The following items have been addressed:
- cleaned up indentation.
- cleaned up comments.
- cleaned up c-styles.
- using EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL
- removed 2.4 compatibility.
- created TCP_OFFLOAD config option.
- moved #defines to appropriate files.
- removed obfuscating macros.
- included necessary definitions instead of struct.
- made IS_OFFLOADED an inline function instead of macro.
The following items are currently being worked on:
- use sysfs instead of procfs.
- addressing the use of semaphores in 'register_tom'.
- use RCU, need to look at this.
- use inline function instead of TOEDEV macro, requires some work.
Comments:
- static was removed from functions '__tcp_inherit_port' & '__tcp_v4_hash'
because these are called outside of tcp_ipv4.c from the TOM driver.
Signed-off-by: Scott Bardone <[EMAIL PROTECTED]>
diff -Naur linux-2.6.13-rc6-git3/include/linux/netdevice.h
linux-2.6.13-rc6-git3.patched/include/linux/netdevice.h
--- linux-2.6.13-rc6-git3/include/linux/netdevice.h 2005-08-07
11:18:56.0 -0700
+++ linux-2.6.13-rc6-git3.patched/include/linux/netdevice.h 2005-08-11
21:28:36.0 -0700
@@ -408,6 +408,9 @@
#define NETIF_F_VLAN_CHALLENGED1024/* Device cannot handle VLAN
packets */
#define NETIF_F_TSO2048/* Can offload TCP/IP segmentation */
#define NETIF_F_LLTX 4096/* LockLess TX */
+#ifdef CONFIG_TCP_OFFLOAD
+#define NETIF_F_TCPIP_OFFLOAD 65536 /* Can offload TCP/IP */
+#endif
/* Called after device is detached from network. */
void(*uninit)(struct net_device *dev);
diff -Naur linux-2.6.13-rc6-git3/include/linux/tcp_diag.h
linux-2.6.13-rc6-git3.patched/include/linux/tcp_diag.h
--- linux-2.6.13-rc6-git3/include/linux/tcp_diag.h 2005-08-07
11:18:56.0 -0700
+++ linux-2.6.13-rc6-git3.patched/include/linux/tcp_diag.h 2005-08-11
21:28:36.0 -0700
@@ -4,6 +4,11 @@
/* Just some random number */
#define TCPDIAG_GETSOCK 18
+/* TOE API */
+#ifdef CONFIG_TCP_OFFLOAD
+#define TCPDIAG_OFFLOAD 5
+#endif
+
/* Socket identity */
struct tcpdiag_sockid
{
diff -Naur linux-2.6.13-rc6-git3/include/linux/tcp.h
linux-2.6.13-rc6-git3.patched/include/linux/tcp.h
--- linux-2.6.13-rc6-git3/include/linux/tcp.h 2005-08-07 11:18:56.0
-0700
+++ linux-2.6.13-rc6-git3.patched/include/linux/tcp.h 2005-08-11
21:28:36.0 -0700
@@ -235,6 +235,10 @@
return (struct tcp_request_sock *)req;
}
+#ifdef CONFIG_TCP_OFFLOAD
+struct toe_funcs;
+#endif
+
struct tcp_sock {
/* inet_sock has to be the first member of tcp_sock */
struct inet_sockinet;
@@ -342,6 +346,10 @@
struct tcp_func *af_specific; /* Operations which are
AF_INET{4,6} specific */
+#ifdef CONFIG_TCP_OFFLOAD
+ struct toe_funcs*toe_specific; /* Operations overriden by TOEs
*/
+#endif
+
__u32 rcv_wnd;/* Current receiver window */
__u32 rcv_wup;/* rcv_nxt on last window update sent */
__u32 write_seq; /* Tail(+1) of data held in tcp send buffer */
diff -Naur linux-2.6.13-rc6-git3/include/linux/toedev.h
linux-2.6.13-rc6-git3.patched/include/linux/toedev.h
--- linux-2.6.13-rc6-git3/include/linux/toedev.h1969-12-31
16:00:00.0 -0800
+++ linux-2.6.13-rc6-git3.patched/include/linux/toedev.h2005-08-11
22:37:03.94780 -0700
@@ -0,0 +1,126 @@
+/*
+ * *
+ * File: *
+ * toedev.h *
+ * *
+ * Description: *
+ * TOE device definitions. *
+ * *
+ * This program is free software; you can redistribute it and/or modify *
+ * it under the terms of the GNU General Public License, version 2, as *
+ * published by the Free Software Foundation.*
+ * *
+ * You should have received a copy of the GNU General Public License along *
+ * with this program; if not, write to the Free Software Foundation, Inc., *
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. *
+ * *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED*
+ * WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF *
+ * MERCHANTABILITY AND FITNE
Re: Doubt in kernel packet generation
On Fri, Aug 12, 2005 at 09:33:13AM +0530, varun ([EMAIL PROTECTED]) wrote: > Hi all, > > I have a major doubt regarding how to generate my own icmp > packet from the kernel space. That is iam aware of raw sockets and > packet sockets but thats from user space. I want one of my kernel module > to generate a packet using skb and probably add it to the transmit > queue. Can anyone help me in this? Iam new to this group so if question is > irrelevant so please let me know where i can post it to get the answer. net/core/pktgen.c has an excellent example of building network packet in kernelspace. >Varun -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: argh... ;/
On Fri, Aug 05, 2005 at 01:20:59PM -0400, John W. Linville wrote: > Yes. Opening attachments makes them harder to review. Lots of people can't inline patches because they are inflicted with crappy MUAs --- I would much prefer patches as attachments in those cases versus mangled patches. Also, I would arguue any sane MUA would make dealing with reading/openning patches for sensible mime types trivial. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Net vm deadlock fix, version 6
Ahem: + } adjust_memalloc_reserve(-netdev->memalloc_pages); - } Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new iptables ipt_connbytes match
Harald Welte wrote:
+/* 64bit divisor, dividend and result. dynamic precision */
+static u_int64_t div64_64(u_int64_t divisor, u_int64_t dividend)
+{
+ u_int64_t result = divisor;
+
+ if (dividend > 0x) {
+ int first_bit = find_first_bit((unsigned long *) ÷nd,
sizeof(dividend));
+ /* calculate number of bits to shift. shift exactly enough
+* bits to make dividend fit in 32bits. */
+ int num_shift = (64 - 32 - first_bit);
+ /* first bit has to be < 32, since dividend was > 0x */
+ result = result >> num_shift;
+ dividend = dividend >> num_shift;
+ }
+
+ do_div(divisor, dividend);
+
+ return divisor;
+}
This functions looks broken. Divisor and divident are mixed up, the
shifted result variable is not used in the actual division, the
"first bit has to be < 32" assumption is wrong and num_shift is
calculated incorrectly. To find a 32-bit divisor consisting of the
most-significant 32 bits we need to find the highest bit set and
subtract 32 from this, then right-shift by that value if it is larger
than 0. I can send a fixed patch tomorrow but I'm too tired now.
+ case IPT_CONNBYTES_WHAT_PKTS:
I would really prefer the name IPT_CONNBYTES_PKTS :)
Regards
Patrick
-
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: Super TSO performance drop
From: Dmitry Yusupov <[EMAIL PROTECTED]> Date: Thu, 11 Aug 2005 16:30:49 -0700 > But even with new TSO schema, this logic can not send more than > MAX_SKB_FRAGS which at best case ~60K. With old TSO schema. > I thought with SuperTSO we could send >> than 60K. And than it could be > very beneficial for us on some platforms where DMA setup is very cheap, > since we could xmit up to 256 pages at once. Yes, MAX_SKB_FRAGS is the limit. We cannot build larger that just under 64K frame due to IP header length field limitations. We have to encode the total length in the ipv4 header, so there is no way to get around the 16-bit length limitation. - 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: Super TSO performance drop
On Thu, 2005-08-11 at 16:15 -0700, David S. Miller wrote: > From: "Leonid Grossman" <[EMAIL PROTECTED]> > Date: Thu, 11 Aug 2005 19:05:22 -0400 > > > Basically, it looks like with SuperTSO most of the traffic in our tests > > comes down to the driver with mss 0 (TSO is mostly "off"). > > With the original TSO, is was always "on" (see below). > > Could you describe how SuperTSO algorithm for switching TSO "on" and > > "off" works, it seems to be fairly complex for us to mess with? For a > > fast network with extremely low error rate, I'd expect TSO to be on. > > We build packets as large as the user gives us in sendmsg(), > then when ACK's come in openning up the window we either > send as much as we can at that moment, or we defer to wait > for more space so we can build larger TSO frames. But even with new TSO schema, this logic can not send more than MAX_SKB_FRAGS which at best case ~60K. With old TSO schema. I thought with SuperTSO we could send >> than 60K. And than it could be very beneficial for us on some platforms where DMA setup is very cheap, since we could xmit up to 256 pages at once. > The logic for that decision is in: > > net/ipv4/tcp_output.c:tcp_tso_should_defer() ok, I'll take a look. > Keep also in mind that if there is packet loss, TSO is disabled > completely. I'll double check that too. Thanks! Dima - 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: Super TSO performance drop
From: "Leonid Grossman" <[EMAIL PROTECTED]> Date: Thu, 11 Aug 2005 19:05:22 -0400 > Basically, it looks like with SuperTSO most of the traffic in our tests > comes down to the driver with mss 0 (TSO is mostly "off"). > With the original TSO, is was always "on" (see below). > Could you describe how SuperTSO algorithm for switching TSO "on" and > "off" works, it seems to be fairly complex for us to mess with? For a > fast network with extremely low error rate, I'd expect TSO to be on. We build packets as large as the user gives us in sendmsg(), then when ACK's come in openning up the window we either send as much as we can at that moment, or we defer to wait for more space so we can build larger TSO frames. The logic for that decision is in: net/ipv4/tcp_output.c:tcp_tso_should_defer() Keep also in mind that if there is packet loss, TSO is disabled completely. - 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: Super TSO performance drop
> -Original Message- > From: David S. Miller [mailto:[EMAIL PROTECTED] > Sent: Friday, August 05, 2005 1:19 AM > To: Leonid Grossman > Cc: netdev@vger.kernel.org > Subject: Re: Super TSO performance drop > I'm not talking about the application, I'm talking about the > new kernel segmenting engine. You will need to actively > investigate the kernel issues, is what I'm trying to say. > Hi David, Basically, it looks like with SuperTSO most of the traffic in our tests comes down to the driver with mss 0 (TSO is mostly "off"). With the original TSO, is was always "on" (see below). Could you describe how SuperTSO algorithm for switching TSO "on" and "off" works, it seems to be fairly complex for us to mess with? For a fast network with extremely low error rate, I'd expect TSO to be on. Leonid -- Hi Leonid, I found that original TSO will always fill in 64K IP payload no matter what block size application uses. With SuperTSO situation is different, especially with bigger block sizes. With 1M block sizes, TSO special function is enabled only 20% of the time... This is obviously causing performance degradation. Bellow is a typical printout: original TSO, 1024k payload, 2 threads (most of the time): - [ 2890.043854] mss 9560 frg_cnt 14 frg0 1600 frg1 4096 frg2 4096 frg3 4096 frg4 4096 frg5 4096 frg6 4096 frg7 4096 frg8 4096 frg9 4096 frg10 4096 frg11 4096 frg12 4096 frg13 3040 total 57414 Super TSO, 1024k payload, 2 threads (most of the time): [ 288.594989] mss 0 frg_cnt 3 frg0 2624 frg1 4096 frg1 2840 total 9614 Dima - 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] Make skb->protocol __be16
From: Alexey Dobriyan <[EMAIL PROTECTED]> Date: Thu, 11 Aug 2005 19:49:48 +0400 > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> Applied, but I may defer this to 2.6.14, we'll see. Also, please properly "-p1" root your patch next time. > --- linux.orig/linux-sparse/include/linux/skbuff.h2005-08-11 > 14:15:21.0 +0400 > +++ linux/linux-sparse/include/linux/skbuff.h 2005-08-11 16:46:03.0 > +0400 Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] fix NF_QUEUE_NR() macro
On Fri, Aug 12, 2005 at 07:46:55AM +1000, Herbert Xu wrote: > Ingo Oeser <[EMAIL PROTECTED]> wrote: > > > > What about using a brace more: > > > >>diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h > >>--- a/include/linux/netfilter.h > >>+++ b/include/linux/netfilter.h > >>@@ -29,7 +29,7 @@ > >> #define NF_VERDICT_QMASK 0x > >> #define NF_VERDICT_QBITS 16 > >> > >>-#define NF_QUEUE_NR(x) ((x << NF_VERDICT_QBITS) & NF_VERDICT_QMASK || > >>NF_QUEUE) > >>+#define NF_QUEUE_NR(x) ((x << NF_VERDICT_QBITS) & NF_VERDICT_QMASK | > >>NF_QUEUE) > > > > #define NF_QUEUE_NR(x) ((x << NF_VERDICT_QBITS) & (NF_VERDICT_QMASK | > > NF_QUEUE)) > > Actually, these two versions are different. & is higher than | so > Harald's version is actually > > #define NF_QUEUE_NR(x) (((x << NF_VERDICT_QBITS) & NF_VERDICT_QMASK) | > NF_QUEUE) > > Which is it? the latter. So my original patch is right (and is also confirmed to work in tests by some users and myself), I 'just' didn't review Ingo's alternative line (embarrassing). We have that saying in german: "I didn't see the wood because of all the trees". Somehow I feel like that now... -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie pgpZyZ608FBZ4.pgp Description: PGP signature
Re: [PATCH 2/2] fix NF_QUEUE_NR() macro
From: Herbert Xu <[EMAIL PROTECTED]> Date: Fri, 12 Aug 2005 07:46:55 +1000 > Actually, these two versions are different. & is higher than | so > Harald's version is actually > > #define NF_QUEUE_NR(x) (((x << NF_VERDICT_QBITS) & NF_VERDICT_QMASK) | > NF_QUEUE) > > Which is it? It's the former that is the intended version. I put Harald's patch in as-is, if people want to pretty it up please do so with a follow-on patch but I really don't think it matters :-) - 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] add new iptables ipt_connbytes match
From: Harald Welte <[EMAIL PROTECTED]>
Date: Thu, 11 Aug 2005 22:03:49 +0200
> +struct ipt_connbytes_info
> +{
> + struct {
> + u_int64_t from; /* count to be matched */
> + u_int64_t to; /* count to be matched */
> + } count;
> + u_int8_t what; /* ipt_connbytes_what */
> + u_int8_t direction; /* ipt_connbytes_direction */
> +};
Won't work in x86 --> x86_64 compat environments.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Net vm deadlock fix, version 6
Hi,
This version corrects a couple of bugs previously noted and ties up some loose
ends in the e1000 driver. Some versions of this driver support packet
splitting into multiple pages, with just the protocol header in the skb
itself. This is a very good thing because it avoids the high order page
fragmentation problem. Though this is something that probably needs to be
pushed down into generic skb allocation, for now the driver handles it
explicitly with the help of a new memalloc_page function that just gets a page
from the memalloc reserve if normal allocation fails. This does not need
separate reserve accounting because such pages are allocated per-skb.
While I was in there, I could not resist cleaning up some non-orthogonality in
the 64K overlap handling (e1000 people, please check my work). The result is
that with the new memalloc handling, the source stayed the same size. Code
size is another question. I have added a number of new inlines. I suspect
that inlining the skb allocation functions in general doesn't buy anything,
but this needs to be checked. Anyway, we now have a pretty good picture of
the full per-driver damage of closing this hole, and it is not much.
I still haven't looked at the various hooks in the packet delivery path, but
it's coming up pretty soon. There are other wrinkles too, like the fact that
there can actually be many block devices mapped over the same network
interface. I have to ponder what is best to do so they can't wedge each
other, and so that the SOCK_MEMALLOC bit doesn't get cleared prematurely.
Anyway, progress marches on.
diff -up --recursive 2.6.12.3.clean/drivers/net/e1000/e1000_main.c
2.6.12.3/drivers/net/e1000/e1000_main.c
--- 2.6.12.3.clean/drivers/net/e1000/e1000_main.c 2005-07-15
17:18:57.0 -0400
+++ 2.6.12.3/drivers/net/e1000/e1000_main.c 2005-08-11 17:42:12.0
-0400
@@ -309,6 +309,16 @@ e1000_up(struct e1000_adapter *adapter)
e1000_phy_reset(&adapter->hw);
}
+ netdev->memalloc_pages = estimate_skb_pages(netdev->rx_reserve,
+ adapter->rx_buffer_len + NET_IP_ALIGN);
+ if (adapter->rx_ps)
+ netdev->memalloc_pages += PS_PAGE_BUFFERS * netdev->rx_reserve;
+ if ((err = adjust_memalloc_reserve(netdev->memalloc_pages))) {
+ DPRINTK(PROBE, ERR,
+ "Unable to allocate rx reserve Error: %d\n", err);
+ return err;
+ }
+
e1000_set_multi(netdev);
e1000_restore_vlan(adapter);
@@ -386,6 +396,7 @@ e1000_down(struct e1000_adapter *adapter
mii_reg |= MII_CR_POWER_DOWN;
e1000_write_phy_reg(&adapter->hw, PHY_CTRL, mii_reg);
mdelay(1);
+ adjust_memalloc_reserve(-netdev->memalloc_pages);
}
}
@@ -3116,34 +3127,29 @@ e1000_alloc_rx_buffers(struct e1000_adap
buffer_info = &rx_ring->buffer_info[i];
while(!buffer_info->skb) {
- skb = dev_alloc_skb(bufsz);
+ skb = dev_memalloc_skb(netdev, bufsz);
- if(unlikely(!skb)) {
+ if(unlikely(!skb))
/* Better luck next round */
break;
- }
/* Fix for errata 23, can't cross 64kB boundary */
if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) {
struct sk_buff *oldskb = skb;
DPRINTK(RX_ERR, ERR, "skb align check failed: %u bytes "
"at %p\n", bufsz, skb->data);
- /* Try again, without freeing the previous */
- skb = dev_alloc_skb(bufsz);
+ /* Try again, then free previous */
+ skb = dev_memalloc_skb(netdev, bufsz);
+ dev_memfree_skb(oldskb);
+
/* Failed allocation, critical failure */
- if (!skb) {
- dev_kfree_skb(oldskb);
+ if (!skb)
break;
- }
+ /* give up */
if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) {
- /* give up */
- dev_kfree_skb(skb);
- dev_kfree_skb(oldskb);
+ dev_memfree_skb(skb);
break; /* while !buffer_info->skb */
- } else {
- /* Use new allocation */
- dev_kfree_skb(oldskb);
}
}
/* Make buffer alignment 2 beyond a 16 byte boundary
@@ -3152,8 +3158,6 @@ e1000_alloc_rx_buffers(struct e1000_adap
*/
skb_reserve(skb, NET_IP_ALIGN);
- skb->dev = netdev;
-
buf
Re: [PATCH 1/2] make nf_log compile with PROC_FS == n
From: Harald Welte <[EMAIL PROTECTED]> Date: Thu, 11 Aug 2005 09:12:43 +0200 > [NETFILTER] Fix compilation when no PROC_FS enabled > > Signed-off-by: Harald Welte <[EMAIL PROTECTED]> 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] fix NF_QUEUE_NR() macro
From: Harald Welte <[EMAIL PROTECTED]> Date: Thu, 11 Aug 2005 09:13:21 +0200 > [NETFILTER] Fix NF_QUEUE_NR() macro > > I obviously wanted to use bitwise-or, not logical or. > > Signed-off-by: Harald Welte <[EMAIL PROTECTED]> 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] Gianfar PHY Layer Update
Hmmm I just did an update, and tried applying first the PHY Layer patch, and then the Gianfar PHY Layer patch. It worked fine for me. Did you apply the the 7/28 patch: [PATCH] sysfs feature enablement for gianfar? Because that patch would screw up the PHY patch for gianfar (I sent an update to the sysfs patch to make it apply over this patch on 8/3, shortly after I sent this patch). drivers/net/gianfar_mii.c is a new file, and is created by the patch, so this is quite confusing to me. Any ideas? On Aug 10, 2005, at 23:13, Jeff Garzik wrote: not applied: Applying 'Gianfar PHY Layer Update' error: patch failed: drivers/net/gianfar.c:393 error: drivers/net/gianfar.c: patch does not apply error: drivers/net/gianfar_mii.c: No such file or directory - 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] fix NF_QUEUE_NR() macro
Ingo Oeser <[EMAIL PROTECTED]> wrote:
>
> What about using a brace more:
>
>>diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h
>>--- a/include/linux/netfilter.h
>>+++ b/include/linux/netfilter.h
>>@@ -29,7 +29,7 @@
>> #define NF_VERDICT_QMASK 0x
>> #define NF_VERDICT_QBITS 16
>>
>>-#define NF_QUEUE_NR(x) ((x << NF_VERDICT_QBITS) & NF_VERDICT_QMASK ||
>>NF_QUEUE)
>>+#define NF_QUEUE_NR(x) ((x << NF_VERDICT_QBITS) & NF_VERDICT_QMASK |
>>NF_QUEUE)
>
> #define NF_QUEUE_NR(x) ((x << NF_VERDICT_QBITS) & (NF_VERDICT_QMASK |
> NF_QUEUE))
Actually, these two versions are different. & is higher than | so
Harald's version is actually
#define NF_QUEUE_NR(x) (((x << NF_VERDICT_QBITS) & NF_VERDICT_QMASK) | NF_QUEUE)
Which is it?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] xfrm: do not use large arrays in BSS
Balazs Scheidler <[EMAIL PROTECTED]> wrote:
>
> Shall I panic in this case?
Yes please. Just panic at the spot where the allocation fails
rather than going up. BTW, you should CC davem if you'd like
to see your patch included.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: [resend][PATCH net-drivers-2.6 1/9] ixgb: Set RXDCTL:PTHRESH/HTHRESH to zero
applied patches 1-9 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[resend][PATCH net-drivers-2.6 9/9] ixgb: Driver version, white space, comments
Driver version, white space, comments & added Module_version Patch from
linville
Signed-off-by: Mallikarjuna R Chilakala <[EMAIL PROTECTED]>
Signed-off-by: Ganesh Venkatesan <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
diff -up netdev-2.6/drivers/net/ixgb/ixgb_ethtool.c
netdev-2.6.new/drivers/net/ixgb/ixgb_ethtool.c
--- netdev-2.6/drivers/net/ixgb/ixgb_ethtool.c 2005-08-05 09:25:28.0
-0700
+++ netdev-2.6.new/drivers/net/ixgb/ixgb_ethtool.c 2005-08-05
09:25:38.0 -0700
@@ -271,7 +271,8 @@ ixgb_get_regs_len(struct net_device *net
uint8_t i;
/* the 1 (one) below indicates an attempt at versioning, if the
-* interface in ethtool or the driver this 1 should be incremented */
+* interface in ethtool or the driver changes, this 1 should be
+* incremented */
regs->version = (1<<24) | hw->revision_id << 16 | hw->device_id;
/* General Registers */
diff -up netdev-2.6/drivers/net/ixgb/ixgb_main.c
netdev-2.6.new/drivers/net/ixgb/ixgb_main.c
--- netdev-2.6/drivers/net/ixgb/ixgb_main.c 2005-08-05 09:25:28.0
-0700
+++ netdev-2.6.new/drivers/net/ixgb/ixgb_main.c 2005-08-05 09:25:43.0
-0700
@@ -29,6 +29,11 @@
#include "ixgb.h"
/* Change Log
+ * 1.0.96 04/19/05
+ * - Make needlessly global code static -- [EMAIL PROTECTED]
+ * - ethtool cleanup -- [EMAIL PROTECTED]
+ * - Support for MODULE_VERSION -- [EMAIL PROTECTED]
+ * - add skb_header_cloned check to the tso path -- [EMAIL PROTECTED]
* 1.0.88 01/05/05
* - include fix to the condition that determines when to quit NAPI - Robert
Olsson
* - use netif_poll_{disable/enable} to synchronize between NAPI and i/f
up/down
@@ -47,10 +47,9 @@ char ixgb_driver_string[] = "Intel(R) PR
#else
#define DRIVERNAPI "-NAPI"
#endif
-
-#define DRV_VERSION "1.0.95-k2"DRIVERNAPI
+#define DRV_VERSION"1.0.100-k2"DRIVERNAPI
char ixgb_driver_version[] = DRV_VERSION;
-char ixgb_copyright[] = "Copyright (c) 1999-2005 Intel Corporation.";
+static char ixgb_copyright[] = "Copyright (c) 1999-2005 Intel Corporation.";
/* ixgb_pci_tbl - PCI Device ID Table
*
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[resend][PATCH net-drivers-2.6 8/9] ixgb: Redefined buffer_info-dma to be dma_addr_t instead of uint64
Redefined buffer_info-dma to be dma_addr_t instead of uint64
Signed-off-by: Mallikarjuna R Chilakala <[EMAIL PROTECTED]>
Signed-off-by: Ganesh Venkatesan <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
diff -up netdev-2.6/drivers/net/ixgb/ixgb.h
netdev-2.6.new/drivers/net/ixgb/ixgb.h
--- netdev-2.6/drivers/net/ixgb/ixgb.h 2005-08-05 09:25:28.0 -0700
+++ netdev-2.6.new/drivers/net/ixgb/ixgb.h 2005-08-05 09:25:32.0
-0700
@@ -119,7 +119,7 @@ struct ixgb_adapter;
* so a DMA handle can be stored along with the buffer */
struct ixgb_buffer {
struct sk_buff *skb;
- uint64_t dma;
+ dma_addr_t dma;
unsigned long time_stamp;
uint16_t length;
uint16_t next_to_watch;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[resend][PATCH net-drivers-2.6 7/9] ixgb: Remove unused functions
Remove unused functions, render some variable static instead of global - based
on patch from Adrian Bunk
Signed-off-by: Mallikarjuna R Chilakala <[EMAIL PROTECTED]>
Signed-off-by: Ganesh Venkatesan <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
diff -up netdev-2.6/drivers/net/ixgb/ixgb_ee.c
netdev-2.6.new/drivers/net/ixgb/ixgb_ee.c
--- netdev-2.6/drivers/net/ixgb/ixgb_ee.c 2005-08-05 09:25:28.0
-0700
+++ netdev-2.6.new/drivers/net/ixgb/ixgb_ee.c 2005-08-05 09:25:34.0
-0700
@@ -565,24 +565,6 @@ ixgb_check_and_get_eeprom_data (struct i
}
}
-/**
- * return the compatibility flags from EEPROM
- *
- * hw - Struct containing variables accessed by shared code
- *
- * Returns:
- * compatibility flags if EEPROM contents are valid, 0 otherwise
-
**/
-uint16_t
-ixgb_get_ee_compatibility(struct ixgb_hw *hw)
-{
- struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;
-
- if(ixgb_check_and_get_eeprom_data(hw) == TRUE)
- return (le16_to_cpu(ee_map->compatibility));
-
- return(0);
-}
/**
* return the Printed Board Assembly number from EEPROM
@@ -602,81 +579,6 @@ ixgb_get_ee_compatibility(struct ixgb_hw
return(0);
}
-/**
- * return the Initialization Control Word 1 from EEPROM
- *
- * hw - Struct containing variables accessed by shared code
- *
- * Returns:
- * Initialization Control Word 1 if EEPROM contents are valid, 0
otherwise
-
**/
-uint16_t
-ixgb_get_ee_init_ctrl_reg_1(struct ixgb_hw *hw)
-{
- struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;
-
- if(ixgb_check_and_get_eeprom_data(hw) == TRUE)
- return (le16_to_cpu(ee_map->init_ctrl_reg_1));
-
- return(0);
-}
-
-/**
- * return the Initialization Control Word 2 from EEPROM
- *
- * hw - Struct containing variables accessed by shared code
- *
- * Returns:
- * Initialization Control Word 2 if EEPROM contents are valid, 0
otherwise
-
**/
-uint16_t
-ixgb_get_ee_init_ctrl_reg_2(struct ixgb_hw *hw)
-{
- struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;
-
- if(ixgb_check_and_get_eeprom_data(hw) == TRUE)
- return (le16_to_cpu(ee_map->init_ctrl_reg_2));
-
- return(0);
-}
-
-/**
- * return the Subsystem Id from EEPROM
- *
- * hw - Struct containing variables accessed by shared code
- *
- * Returns:
- * Subsystem Id if EEPROM contents are valid, 0 otherwise
-
**/
-uint16_t
-ixgb_get_ee_subsystem_id(struct ixgb_hw *hw)
-{
- struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;
-
- if(ixgb_check_and_get_eeprom_data(hw) == TRUE)
- return (le16_to_cpu(ee_map->subsystem_id));
-
- return(0);
-}
-
-/**
- * return the Sub Vendor Id from EEPROM
- *
- * hw - Struct containing variables accessed by shared code
- *
- * Returns:
- * Sub Vendor Id if EEPROM contents are valid, 0 otherwise
-
**/
-uint16_t
-ixgb_get_ee_subvendor_id(struct ixgb_hw *hw)
-{
- struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;
-
- if(ixgb_check_and_get_eeprom_data(hw) == TRUE)
- return (le16_to_cpu(ee_map->subvendor_id));
-
- return(0);
-}
/**
* return the Device Id from EEPROM
@@ -694,81 +683,6 @@ ixgb_get_ee_device_id(struct ixgb_hw *hw
if(ixgb_check_and_get_eeprom_data(hw) == TRUE)
return (le16_to_cpu(ee_map->device_id));
- return(0);
-}
-
-/**
- * return the Vendor Id from EEPROM
- *
- * hw - Struct containing variables accessed by shared code
- *
- * Returns:
- * Device Id if EEPROM contents are valid, 0 otherwise
-
**/
-uint16_t
-ixgb_get_ee_vendor_id(struct ixgb_hw *hw)
-{
- struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;
-
- if(ixgb_check_and_get_eeprom_data(hw) == TRUE)
- return
[resend][PATCH net-drivers-2.6 6/9] ixgb: Ethtool cleanup patch from Stephen Hemminger
Ethtool cleanup patch from Stephen Hemminger * use ADVERTISED_xxx fields when setting advertised fields Signed-off-by: Mallikarjuna R Chilakala <[EMAIL PROTECTED]> Signed-off-by: Ganesh Venkatesan <[EMAIL PROTECTED]> Signed-off-by: John Ronciak <[EMAIL PROTECTED]> diff -up netdev-2.6/drivers/net/ixgb/ixgb_ethtool.c netdev-2.6.new/drivers/net/ixgb/ixgb_ethtool.c --- netdev-2.6/drivers/net/ixgb/ixgb_ethtool.c 2005-08-05 09:25:28.0 -0700 +++ netdev-2.6.new/drivers/net/ixgb/ixgb_ethtool.c 2005-08-05 09:25:38.0 -0700 @@ -101,7 +101,7 @@ static struct ixgb_stats ixgb_gstrings_s struct ixgb_adapter *adapter = netdev_priv(netdev); ecmd->supported = (SUPPORTED_1baseT_Full | SUPPORTED_FIBRE); - ecmd->advertising = (SUPPORTED_1baseT_Full | SUPPORTED_FIBRE); + ecmd->advertising = (ADVERTISED_1baseT_Full | ADVERTISED_FIBRE); ecmd->port = PORT_FIBRE; ecmd->transceiver = XCVR_EXTERNAL; - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[resend][PATCH net-drivers-2.6 5/9] ixgb: Fix data output by ethtool -d
Fix data output by ethtool -d
Signed-off-by: Mallikarjuna R Chilakala <[EMAIL PROTECTED]>
Signed-off-by: Ganesh Venkatesan <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
diff -up netdev-2.6/drivers/net/ixgb/ixgb_ethtool.c
netdev-2.6.new/drivers/net/ixgb/ixgb_ethtool.c
--- netdev-2.6/drivers/net/ixgb/ixgb_ethtool.c 2005-08-05 09:25:28.0
-0700
+++ netdev-2.6.new/drivers/net/ixgb/ixgb_ethtool.c 2005-08-05
09:25:38.0 -0700
@@ -301,7 +301,8 @@ ixgb_get_regs(struct net_device *netdev,
*reg++ = IXGB_READ_REG(hw, RAIDC); /* 19 */
*reg++ = IXGB_READ_REG(hw, RXCSUM); /* 20 */
- for (i = 0; i < IXGB_RAR_ENTRIES; i++) {
+ /* there are 16 RAR entries in hardware, we only use 3 */
+ for(i = 0; i < 16; i++) {
*reg++ = IXGB_READ_REG_ARRAY(hw, RAL, (i << 1)); /*21,...,51 */
*reg++ = IXGB_READ_REG_ARRAY(hw, RAH, (i << 1)); /*22,...,52 */
}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[resend][PATCH net-drivers-2.6 3/9] ixgb: Use netdev_priv() instead of netdev->priv
Use netdev_priv() instead of netdev->priv
Signed-off-by: Mallikarjuna R Chilakala <[EMAIL PROTECTED]>
Signed-off-by: Ganesh Venkatesan <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
diff -up netdev-2.6/drivers/net/ixgb/ixgb_ethtool.c
netdev-2.6.new/drivers/net/ixgb/ixgb_ethtool.c
--- netdev-2.6/drivers/net/ixgb/ixgb_ethtool.c 2005-08-05 09:25:28.0
-0700
+++ netdev-2.6.new/drivers/net/ixgb/ixgb_ethtool.c 2005-08-05
09:25:38.0 -0700
@@ -98,7 +98,7 @@ static struct ixgb_stats ixgb_gstrings_s
static int
ixgb_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
{
- struct ixgb_adapter *adapter = netdev->priv;
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
ecmd->supported = (SUPPORTED_1baseT_Full | SUPPORTED_FIBRE);
ecmd->advertising = (SUPPORTED_1baseT_Full | SUPPORTED_FIBRE);
@@ -120,7 +126,7 @@ ixgb_get_settings(struct net_device *net
static int
ixgb_set_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
{
- struct ixgb_adapter *adapter = netdev->priv;
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
if(ecmd->autoneg == AUTONEG_ENABLE ||
ecmd->speed + ecmd->duplex != SPEED_1 + DUPLEX_FULL)
@@ -146,7 +143,7 @@ ixgb_set_settings(struct net_device *net
ixgb_get_pauseparam(struct net_device *netdev,
struct ethtool_pauseparam *pause)
{
- struct ixgb_adapter *adapter = netdev->priv;
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
struct ixgb_hw *hw = &adapter->hw;
pause->autoneg = AUTONEG_DISABLE;
@@ -165,7 +161,7 @@ ixgb_get_pauseparam(struct net_device *n
ixgb_set_pauseparam(struct net_device *netdev,
struct ethtool_pauseparam *pause)
{
- struct ixgb_adapter *adapter = netdev->priv;
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
struct ixgb_hw *hw = &adapter->hw;
if(pause->autoneg == AUTONEG_ENABLE)
@@ -197,7 +181,8 @@ ixgb_set_pauseparam(struct net_device *n
static uint32_t
ixgb_get_rx_csum(struct net_device *netdev)
{
- struct ixgb_adapter *adapter = netdev->priv;
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
+
return adapter->rx_csum;
}
@@ -204,7 +181,8 @@
static int
ixgb_set_rx_csum(struct net_device *netdev, uint32_t data)
{
- struct ixgb_adapter *adapter = netdev->priv;
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
+
adapter->rx_csum = data;
if(netif_running(netdev)) {
@@ -262,7 +249,7 @@ ixgb_get_regs_len(struct net_device *net
ixgb_get_regs(struct net_device *netdev,
struct ethtool_regs *regs, void *p)
{
- struct ixgb_adapter *adapter = netdev->priv;
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
struct ixgb_hw *hw = &adapter->hw;
uint32_t *reg = p;
uint32_t *reg_start = reg;
@@ -407,7 +396,7 @@ ixgb_get_eeprom_len(struct net_device *n
ixgb_get_eeprom(struct net_device *netdev,
struct ethtool_eeprom *eeprom, uint8_t *bytes)
{
- struct ixgb_adapter *adapter = netdev->priv;
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
struct ixgb_hw *hw = &adapter->hw;
uint16_t *eeprom_buff;
int i, max_len, first_word, last_word;
@@ -455,7 +445,7 @@ geeprom_error:
ixgb_set_eeprom(struct net_device *netdev,
struct ethtool_eeprom *eeprom, uint8_t *bytes)
{
- struct ixgb_adapter *adapter = netdev->priv;
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
struct ixgb_hw *hw = &adapter->hw;
uint16_t *eeprom_buff;
void *ptr;
@@ -513,7 +504,7 @@ ixgb_set_eeprom(struct net_device *netde
ixgb_get_drvinfo(struct net_device *netdev,
struct ethtool_drvinfo *drvinfo)
{
- struct ixgb_adapter *adapter = netdev->priv;
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
strncpy(drvinfo->driver, ixgb_driver_name, 32);
strncpy(drvinfo->version, ixgb_driver_version, 32);
@@ -528,7 +518,7 @@ ixgb_get_drvinfo(struct net_device *netd
ixgb_get_ringparam(struct net_device *netdev,
struct ethtool_ringparam *ring)
{
- struct ixgb_adapter *adapter = netdev->priv;
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
struct ixgb_desc_ring *txdr = &adapter->tx_ring;
struct ixgb_desc_ring *rxdr = &adapter->rx_ring;
@@ -546,7 +534,7 @@ ixgb_get_ringparam(struct net_device *ne
ixgb_set_ringparam(struct net_device *netdev,
struct ethtool_ringparam *ring)
{
- struct ixgb_adapter *adapter = netdev->priv;
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
struct ixgb_desc_ring *txdr = &adapter->tx_ring;
struct ixgb_desc_ring *rxdr = &adapter->rx_ring;
struct ixgb_desc_ring tx_old, tx_new, rx_old, rx_new;
@@ -628,7 +614,7 @@ ixgb_led_blink_callba
[resend][PATCH net-drivers-2.6 1/9] ixgb: Set RXDCTL:PTHRESH/HTHRESH to zero
Set RXDCTL:PTHRESH/HTHRESH to zero
Signed-off-by: Mallikarjuna R Chilakala <[EMAIL PROTECTED]>
Signed-off-by: Ganesh Venkatesan <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
diff -up netdev-2.6/drivers/net/ixgb/ixgb_main.c
netdev-2.6.new/drivers/net/ixgb/ixgb_main.c
--- netdev-2.6/drivers/net/ixgb/ixgb_main.c 2005-08-05 09:25:28.0
-0700
+++ netdev-2.6.new/drivers/net/ixgb/ixgb_main.c 2005-08-05 09:25:43.0
-0700
@@ -145,10 +145,12 @@ MODULE_LICENSE("GPL");
MODULE_VERSION(DRV_VERSION);
/* some defines for controlling descriptor fetches in h/w */
-#define RXDCTL_PTHRESH_DEFAULT 128 /* chip considers prefech below this */
-#define RXDCTL_HTHRESH_DEFAULT 16 /* chip will only prefetch if tail is
- pushed this many descriptors from
head */
#define RXDCTL_WTHRESH_DEFAULT 16 /* chip writes back at this many or
RXT0 */
+#define RXDCTL_PTHRESH_DEFAULT 0 /* chip considers prefech below
+* this */
+#define RXDCTL_HTHRESH_DEFAULT 0 /* chip will only prefetch if
tail
+* is pushed this many
descriptors
+* from head */
/**
* ixgb_init_module - Driver Registration Routine
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[resend][PATCH net-drivers-2.6 0/9] ixgb: driver update
ixgb: driver update Signed-off-by: Mallikarjuna R Chilakala <[EMAIL PROTECTED]> Signed-off-by: Ganesh Venkatesan <[EMAIL PROTECTED]> Signed-off-by: John Ronciak <[EMAIL PROTECTED]> 1. Set RXDCTL:PTHRESH/HTHRESH to zero 2. Dmesg will now no longer fill up with "link up" messages without a corresponding link down message when executing mtu or other ethtool changes. basically a reset operation (down/up cycle) knows the state of the link when starting, so resets that state afterward. 3. Use netdev_priv() instead of netdev->priv 4. Fix Broadcast/Multicast packets received statistics 5. Fix data output by ethtool -d 6. Ethtool cleanup patch from Stephen Hemminger 7. Remove unused functions, render some variable static instead of global 8. Redefined buffer_info-dma to be dma_addr_t instead of uint64 9. Driver version & white space fixes - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[resend][PATCH net-drivers-2.6 2/9] ixgb: Fix unnecessary link state messages
Fix unnecessary link state messages
Signed-off-by: Mallikarjuna R Chilakala <[EMAIL PROTECTED]>
Signed-off-by: Ganesh Venkatesan <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
diff -up netdev-2.6/drivers/net/ixgb/ixgb_ethtool.c
netdev-2.6.new/drivers/net/ixgb/ixgb_ethtool.c
--- netdev-2.6/drivers/net/ixgb/ixgb_ethtool.c 2005-08-05 09:25:28.0
-0700
+++ netdev-2.6.new/drivers/net/ixgb/ixgb_ethtool.c 2005-08-05
09:25:38.0 -0700
@@ -130,6 +130,12 @@ ixgb_get_settings(struct net_device *net
ixgb_down(adapter, TRUE);
ixgb_reset(adapter);
ixgb_up(adapter);
+ /* be optimistic about our link, since we were up before */
+ adapter->link_speed = 1;
+ adapter->link_duplex = FULL_DUPLEX;
+ netif_carrier_on(netdev);
+ netif_wake_queue(netdev);
+
} else
ixgb_reset(adapter);
@@ -177,6 +181,11 @@ ixgb_set_pauseparam(struct net_device *n
if(netif_running(adapter->netdev)) {
ixgb_down(adapter, TRUE);
ixgb_up(adapter);
+ /* be optimistic about our link, since we were up before */
+ adapter->link_speed = 1;
+ adapter->link_duplex = FULL_DUPLEX;
+ netif_carrier_on(netdev);
+ netif_wake_queue(netdev);
} else
ixgb_reset(adapter);
@@ -199,6 +181,11 @@
if(netif_running(netdev)) {
ixgb_down(adapter,TRUE);
ixgb_up(adapter);
+ /* be optimistic about our link, since we were up before */
+ adapter->link_speed = 1;
+ adapter->link_duplex = FULL_DUPLEX;
+ netif_carrier_on(netdev);
+ netif_wake_queue(netdev);
} else
ixgb_reset(adapter);
return 0;
@@ -573,6 +573,11 @@ ixgb_set_ringparam(struct net_device *ne
adapter->tx_ring = tx_new;
if((err = ixgb_up(adapter)))
return err;
+ /* be optimistic about our link, since we were up before */
+ adapter->link_speed = 1;
+ adapter->link_duplex = FULL_DUPLEX;
+ netif_carrier_on(netdev);
+ netif_wake_queue(netdev);
}
return 0;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[resend][PATCH net-drivers-2.6 4/9] ixgb: Fix Broadcast/Multicast packets received statistics
Fix Broadcast/Multicast packets received statistics Signed-off-by: Mallikarjuna R Chilakala <[EMAIL PROTECTED]> Signed-off-by: Ganesh Venkatesan <[EMAIL PROTECTED]> Signed-off-by: John Ronciak <[EMAIL PROTECTED]> diff -up netdev-2.6/drivers/net/ixgb/ixgb_main.c netdev-2.6.new/drivers/net/ixgb/ixgb_main.c --- netdev-2.6/drivers/net/ixgb/ixgb_main.c 2005-08-05 09:25:28.0 -0700 +++ netdev-2.6.new/drivers/net/ixgb/ixgb_main.c 2005-08-05 09:25:43.0 -0700 @@ -1524,7 +1524,8 @@ ixgb_update_stats(struct ixgb_adapter *a multi |= ((u64)IXGB_READ_REG(&adapter->hw, MPRCH) << 32); /* fix up multicast stats by removing broadcasts */ - multi -= bcast; + if(multi >= bcast) + multi -= bcast; adapter->stats.mprcl += (multi & 0x); adapter->stats.mprch += (multi >> 32); - 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] add new iptables ipt_connbytes match
Hi Dave,
please apply to your net-2.6.14 tree:
--
- Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed."-- Paul Vixie
[NETFILTER] Add new iptables "connbytes" match
This patch ads a new "connbytes" match that utilizes the CONFIG_NF_CT_ACCT
per-connection byte and packet counters. Using it you can do things like
packet classification on average packet size within a connection.
Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
---
commit 98a0b5554e6e54a5a5a21b21b212186dc3c2118c
tree 43acbfa60366e1b111272851f1a1745a43a71d74
parent 5896088f554d8c2e7f3226973d1413df339e6b75
author Harald Welte <[EMAIL PROTECTED]> Do, 11 Aug 2005 21:15:45 +0200
committer Harald Welte <[EMAIL PROTECTED]> Do, 11 Aug 2005 21:15:45 +0200
include/linux/netfilter_ipv4/ipt_connbytes.h | 25
net/ipv4/netfilter/Kconfig | 11 ++
net/ipv4/netfilter/Makefile |1
net/ipv4/netfilter/ipt_connbytes.c | 166 ++
4 files changed, 202 insertions(+), 1 deletions(-)
diff --git a/include/linux/netfilter_ipv4/ipt_connbytes.h
b/include/linux/netfilter_ipv4/ipt_connbytes.h
new file mode 100644
--- /dev/null
+++ b/include/linux/netfilter_ipv4/ipt_connbytes.h
@@ -0,0 +1,25 @@
+#ifndef _IPT_CONNBYTES_H
+#define _IPT_CONNBYTES_H
+
+enum ipt_connbytes_what {
+ IPT_CONNBYTES_WHAT_PKTS,
+ IPT_CONNBYTES_WHAT_BYTES,
+ IPT_CONNBYTES_WHAT_AVGPKT,
+};
+
+enum ipt_connbytes_direction {
+ IPT_CONNBYTES_DIR_ORIGINAL,
+ IPT_CONNBYTES_DIR_REPLY,
+ IPT_CONNBYTES_DIR_BOTH,
+};
+
+struct ipt_connbytes_info
+{
+ struct {
+ u_int64_t from; /* count to be matched */
+ u_int64_t to; /* count to be matched */
+ } count;
+ u_int8_t what; /* ipt_connbytes_what */
+ u_int8_t direction; /* ipt_connbytes_direction */
+};
+#endif
diff --git a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig
--- a/net/ipv4/netfilter/Kconfig
+++ b/net/ipv4/netfilter/Kconfig
@@ -386,6 +386,16 @@ config IP_NF_MATCH_CONNMARK
. The module will be called
ipt_connmark.o. If unsure, say `N'.
+config IP_NF_MATCH_CONNBYTES
+ tristate 'Connection byte/packet counter match support'
+ depends on IP_NF_CT_ACCT && IP_NF_IPTABLES
+ help
+ This option adds a `connbytes' match, which allows you to match the
+ number of bytes and/or packets for each direction within a connection.
+
+ If you want to compile it as a module, say M here and read
+ . If unsure, say `N'.
+
config IP_NF_MATCH_HASHLIMIT
tristate 'hashlimit match support'
depends on IP_NF_IPTABLES
@@ -723,6 +733,5 @@ config IP_NF_CONNTRACK_NETLINK
help
This option enables support for a netlink-based userspace interface
-
endmenu
diff --git a/net/ipv4/netfilter/Makefile b/net/ipv4/netfilter/Makefile
--- a/net/ipv4/netfilter/Makefile
+++ b/net/ipv4/netfilter/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_IP_NF_MATCH_TTL) += ipt_ttl
obj-$(CONFIG_IP_NF_MATCH_STATE) += ipt_state.o
obj-$(CONFIG_IP_NF_MATCH_CONNMARK) += ipt_connmark.o
obj-$(CONFIG_IP_NF_MATCH_CONNTRACK) += ipt_conntrack.o
+obj-$(CONFIG_IP_NF_MATCH_CONNBYTES) += ipt_connbytes.o
obj-$(CONFIG_IP_NF_MATCH_TCPMSS) += ipt_tcpmss.o
obj-$(CONFIG_IP_NF_MATCH_REALM) += ipt_realm.o
obj-$(CONFIG_IP_NF_MATCH_ADDRTYPE) += ipt_addrtype.o
diff --git a/net/ipv4/netfilter/ipt_connbytes.c
b/net/ipv4/netfilter/ipt_connbytes.c
new file mode 100644
--- /dev/null
+++ b/net/ipv4/netfilter/ipt_connbytes.c
@@ -0,0 +1,166 @@
+/* Kernel module to match connection tracking byte counter.
+ * GPL (C) 2002 Martin Devera ([EMAIL PROTECTED]).
+ *
+ * 2004-07-20 Harald Welte <[EMAIL PROTECTED]>
+ * - reimplemented to use per-connection accounting counters
+ * - add functionality to match number of packets
+ * - add functionality to match average packet size
+ * - add support to match directions seperately
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Harald Welte <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("iptables match for matching number of pkts/bytes per
connection");
+
+/* 64bit divisor, dividend and result. dynamic precision */
+static u_int64_t div64_64(u_int64_t divisor, u_int64_t dividend)
+{
+ u_int64_t result = divisor;
+
+ if (dividend > 0x) {
+ int first_bit = find_first_bit((unsigned long *) ÷nd,
sizeof(dividend));
+ /* calculate number of bits to shift. shift exactly enough
+* bits to make dividend fit in 32bits. */
+ int num_shift = (64 - 32 - fir
Re: net-2.6.14 to be rebased
On Thu, Aug 11, 2005 at 12:40:48PM -0700, David S. Miller wrote: > What I do is I extract all of the patches out of the net-2.6.14 > tree, then apply them one-by-one into a fresh copy of Linus's tree, > then replace the tree on kernel.org with the new one. ouch. > I even go one step further and combine some patches that logically > belong together, for example build fixes from Andrew Morton I'll > combine with the patch that added the build regression. This is > becomming more and more necessary now that we have more than 110 > patches in net-2.6.14 ok, that makes sense. This is why I never offer or suggest you to pull from my tree (so far). One option might be to create a new local branch (head) for every single patch, and applying incremental fixes into that respective branch... but then there's still no easy way to create one cumulative new patch from the respective changes. > I would suggest folks don't try to do any merging with this tree > when I do that. None of the old tree remains in any form whatsoever > in the new tree, so there isn't anything to merge with. Mh. It still works surprisingly well, netfilter-2.6.14 survived both of your re-base's. > I know this is a pain in the butt, but I absolutely do not want ugly > merge-mania type history graphs in the net-2.6.14 tree just because > I felt like rebasing. And the net-2.6.14 tree touches so many things > that merges wouldn't be that successful anyways :-) Don't say that. the last merge was about 7-10 conflicts that had to be resolved manually, nothing more... [What have I done. I didn't wan to turn netdev into git-users *g*] -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgprXHN3s0VcS.pgp Description: PGP signature
Re: [PATCH 2/2] fix NF_QUEUE_NR() macro
On Thu, Aug 11, 2005 at 04:31:24PM +0200, Ingo Oeser wrote: > Harald Welte wrote: > > Hi Dave, please apply! > > What about using a brace more: I wouldn't mind the extra brace, but I don't want to make this more difficult for Dave. So it's his call whether he would manually edit the line before applying the patch ;) -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie pgpbwA25LdLq4.pgp Description: PGP signature
Re: [PATCH] sockaddr_ll change for IPoIB interface
From: Hal Rosenstock <[EMAIL PROTECTED]> Date: 11 Aug 2005 14:48:37 -0400 > The patch below is to accomodate IPoIB link layer address in the > sockaddr_ll struct so that user space can send and receive IPoIB link > later packets. Unfortunately, IPoIB has 20 bytes LL addresses rather > than the 8 byte MAC addresses (or under) used by other LLs. Two problems. 1) it's a really ugly IPoIB specific hack to extend the sockaddr_ll structure, it won't work for anything else without adding more special tests to that af_packet.c code and 2) you inproperly rooted your patch, so we get stuff like this: > --- af_packet.c.orig 2005-06-29 19:00:53.0 -0400 > +++ af_packet.c 2005-08-05 13:28:49.0 -0400 Please find another way to extend the structure. That's why I didn't respond, this patch was too ugly for words so it went to the bottom of my prioritized list of things to do. - 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-2.6.14 to be rebased
From: Jeff Garzik <[EMAIL PROTECTED]> Date: Thu, 11 Aug 2005 13:22:58 -0400 > Personally, I -hope- it's a merge. It's not, I absolutely do not want those ugly branches in my tree history just because I felt like rebasing. I want a clean tree, and also it gives me the opportunity to combine bug fixes with patches that introduce them which seperately just generate changeset bloat. - 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-2.6.14 to be rebased
From: Harald Welte <[EMAIL PROTECTED]>
Date: Thu, 11 Aug 2005 18:44:30 +0200
> On Tue, Aug 09, 2005 at 06:23:33PM -0700, David S. Miller wrote:
> > I want some net bug fixes in Linus's tree to propagate into the
> > net-2.6.14 tree so I plan to rebase it this evening, so please be
> > careful when sync'ing with my tree over the next day.
>
> so what is the actual process of a 'rebase' on your side? Do you just
> pull/update from Linus' current tree and merge it with yours? Or do you
> extract all the patches and apply them to a clean linus-tree?
>
> And what is the designated course of action for somebody (like me), who
> has based his tree on yours? I just do 'cg-update origin' and manually
> go through the changes, clean them up. Finally I chekc with 'cg-diff -r
> origin' whether there were any mistakes during the manual
> cleanup/conflict resolving by making sure it only contains the desired
> netfilter-related changes.
>
> Is that the "best current practise", or would you recomment a different
> course of action?
What I do is I extract all of the patches out of the net-2.6.14
tree, then apply them one-by-one into a fresh copy of Linus's tree,
then replace the tree on kernel.org with the new one.
I even go one step further and combine some patches that logically
belong together, for example build fixes from Andrew Morton I'll
combine with the patch that added the build regression. This is
becomming more and more necessary now that we have more than 110
patches in net-2.6.14
I would suggest folks don't try to do any merging with this tree
when I do that. None of the old tree remains in any form whatsoever
in the new tree, so there isn't anything to merge with.
You need to pull out your patches from the old tree, and add them to
the new tree.
I know this is a pain in the butt, but I absolutely do not want ugly
merge-mania type history graphs in the net-2.6.14 tree just because
I felt like rebasing. And the net-2.6.14 tree touches so many things
that merges wouldn't be that successful anyways :-)
If you keep your .git/ORIG_HEAD sane, you can use a script like the
following to pull your local changes out of a tree one-by-one. It
drops them into a directory called "patches/" at the top-level and
names them 1.diff, 2.diff, 3.diff, etc. with changelogs prepended
to the beginning. I call it "git-mkpatches".
#/bin/sh
mkdir patches/
count="1"
for i in $(git-rev-list HEAD ^ORIG_HEAD | tac)
do
git-diff-tree --pretty -p ${i} > patches/$count.diff
count=$(($count + 1))
done
-
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/2] LSM-IPSec Networking Hooks -- Minor mods
I have made some modifications to the SELinux part of this patch as well. These fall into three categories: (1) removed unnecessary <0 checks on unsigned ints (2) converted sec_ctx variables to uctx since the latter is used for variables of the xfrm_user_sec_ctx data type (3) check for the alg rather than the doi to be SELinux in selinux_sec_ctx_alloc Regards, Trent. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. --- security/selinux/Makefile|2 security/selinux/hooks.c | 20 + security/selinux/include/av_perm_to_string.h |2 security/selinux/include/av_permissions.h|2 security/selinux/include/xfrm.h | 19 + security/selinux/xfrm.c | 445 +++ selinux/include/av_inherit.h |0 selinux/include/class_to_string.h|0 selinux/include/common_perm_to_string.h |0 selinux/include/flask.h |0 selinux/include/initial_sid_to_string.h |0 11 files changed, 490 insertions(+) diff -puN security/selinux/hooks.c~lsm-selinux-nethooks security/selinux/hooks.c --- linux-2.6.13-rc4-xfrm/security/selinux/hooks.c~lsm-selinux-nethooks 2005-08-10 13:26:45.0 -0400 +++ linux-2.6.13-rc4-xfrm-root/security/selinux/hooks.c 2005-08-10 13:26:45.0 -0400 @@ -73,6 +73,7 @@ #include "avc.h" #include "objsec.h" #include "netif.h" +#include "xfrm.h" #define XATTR_SELINUX_SUFFIX "selinux" #define XATTR_NAME_SELINUX XATTR_SECURITY_P
[PATCH 1/2] LSM-IPSec Networking Hooks -- mods based on Herbert's comments
This patch has been modified based on Herbert's comments. I also
added explicit length checking code to xfrm_user.c based on Herbert's
comments in the rest of the code.
Most of the other modifications are deletions of unnecessary checks
per Herbert's identification.
Regards,
Trent.
==
This patch series implements per packet access control via the
extension of the Linux Security Modules (LSM) interface by hooks in
the XFRM and pfkey subsystems that leverage IPSec security
associations to label packets. Extensions to the SELinux LSM are
included that leverage the patch for this purpose.
This patch implements the changes necessary to the XFRM subsystem,
pfkey interface, ipv4/ipv6, and xfrm_user interface to restrict a
socket to use only authorized security associations (or no security
association) to send/receive network packets.
Patch purpose:
The patch is designed to enable access control per packets based on
the strongly authenticated IPSec security association. Such access
controls augment the existing ones based on network interface and IP
address. The former are very coarse-grained, and the latter can be
spoofed. By using IPSec, the system can control access to remote
hosts based on cryptographic keys generated using the IPSec mechanism.
This enables access control on a per-machine basis or per-application
if the remote machine is running the same mechanism and trusted to
enforce the access control policy.
Patch design approach:
The overall approach is that policy (xfrm_policy) entries set by
user-level programs (e.g., setkey for ipsec-tools) are extended with a
security context that is used at policy selection time in the XFRM
subsystem to restrict the sockets that can send/receive packets via
security associations (xfrm_states) that are built from those
policies.
A presentation available at
www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf
from the SELinux symposium describes the overall approach.
Patch implementation details:
On output, the policy retrieved (via xfrm_policy_lookup or
xfrm_sk_policy_lookup) must be authorized for the security context of
the socket and the same security context is required for resultant
security association (retrieved or negotiated via racoon in
ipsec-tools). This is enforced in xfrm_state_find.
On input, the policy retrieved must also be authorized for the socket
(at __xfrm_policy_check), and the security context of the policy must
also match the security association being used.
The patch has virtually no impact on packets that do not use IPSec.
The existing Netfilter (outgoing) and LSM rcv_skb hooks are used as
before.
Also, if IPSec is used without security contexts, the impact is
minimal. The LSM must allow such policies to be selected for the
combination of socket and remote machine, but subsequent IPSec
processing proceeds as in the original case.
Testing:
The pfkey interface is tested using the ipsec-tools. ipsec-tools have
been modified (a separate ipsec-tools patch is available for version
0.5) that supports assignment of xfrm_policy entries and security
associations with security contexts via setkey and the negotiation
using the security contexts via racoon.
The xfrm_user interface is tested via ad hoc programs that set
security contexts. These programs are also available from me, and
contain programs for setting, getting, and deleting policy for testing
this interface. Testing of sa functions was done by tracing kernel
behavior.
---
include/linux/pfkeyv2.h | 13 ++-
include/linux/security.h | 119 +++
include/linux/xfrm.h | 29 ++
include/net/flow.h |8 +
include/net/xfrm.h | 36 +++-
net/core/flow.c | 11 +-
net/key/af_key.c | 186 +--
net/xfrm/xfrm_policy.c | 79 +++---
net/xfrm/xfrm_state.c| 16 +++
net/xfrm/xfrm_user.c | 200 +--
security/Kconfig | 13 +++
security/dummy.c | 37
ipv4/xfrm4_policy.c |0
ipv6/xfrm6_policy.c |0
14 files changed, 691 insertions(+), 56 deletions(-)
diff -puN include/linux/pfkeyv2.h~lsm-xfrm-nethooks include/linux/pfkeyv2.h
--- linux-2.6.13-rc4-xfrm/include/linux/pfkeyv2.h~lsm-xfrm-nethooks
2005-08-01 16:11:22.0 -0400
+++ linux-2.6.13-rc4-xfrm-root/include/linux/pfkeyv2.h 2005-08-01
16:11:22.0 -0400
@@ -216,6 +216,16 @@ struct sadb_x_nat_t_port {
} __attribute__((packed));
/* sizeof(struct sadb_x_nat_t_port) == 8 */
+/* Generic LSM security context */
+struct sadb_x_sec_ctx {
+ uint16_tsadb_x_sec_len;
+ uint16_tsadb_x_sec_exttype;
+ uint8_t sadb_x_ctx_alg; /* LSMs: e.g., selinux == 1 */
+ uint8_t sadb_x_ctx_doi;
+ uint16_tsadb_x_ctx_len;
+} __attribute__((packed));
+/* sizeof(struct sadb_sec_ctx)
Re: 2.6.13-rc5 panic with tg3, e1000, vlan, tso
From: "Vladimir B. Savkin" <[EMAIL PROTECTED]> Date: Thu, 11 Aug 2005 15:48:36 +0400 > Today my gateway crashed. Known problem, please try Linus's current tree as we've made a bug fix since -rc5 that we think fixes this bug. - 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/tulip: LAN driver for ULI M5261/M5263
[EMAIL PROTECTED] wrote:
Jeff:
I have removed the uli526x support from tulip core driver,check the patch
file for detail,thanks.
Patch applied, thanks!
Alexey:
Here the new patch,please check it, thanks.
(See attached file: patchuli526x)
Please submit a patch -incremental- to the original uli526x.c that you sent.
I have already applied your original patch, so I am unable to apply this
new patch.
Also:
1) Obtain PCI vendor, device IDs from pdev->vendor and pdev->device, not
by reading PCI config registers directly:
//add by clearzhang 2004/7/8
pci_read_config_dword(pdev,0x0,&configval);
m526x_id = configval;
if(configval == 0x526310b9)
{
//printk("is m5263\n");
pci_read_config_dword(pdev,0x0c,&configval);
configval = ((configval & 0x00ff) | 0x8000);
pci_write_config_dword(pdev,0x0c,configval);
}
2) Check return value of pci_alloc_consistent() for failure, and handle
cleanup:
db->desc_pool_ptr = pci_alloc_consistent(pdev, sizeof(struct tx_desc) *
DESC_ALL_CNT + 0x20, &db->desc_pool_dma_ptr);
db->buf_pool_ptr = pci_alloc_consistent(pdev, TX_BUF_ALLOC * TX_DESC_CNT
+ 4, &db->buf_pool_dma_ptr);
3) uli526x_remove_one() should call pci_disable_device()
-
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] sockaddr_ll change for IPoIB interface
Hi,
This is a repost of a patch which was posted last week which appears to
have been lost in the shuffle.
The patch below is to accomodate IPoIB link layer address in the
sockaddr_ll struct so that user space can send and receive IPoIB link
later packets. Unfortunately, IPoIB has 20 bytes LL addresses rather
than the 8 byte MAC addresses (or under) used by other LLs.
There is a similar change to both:
/usr/include/linux/if_packet.h
/usr/include/netpacket/packet.h
as in:
include/linux/if_packet.h below
to increase sll_addr from 8 to 20 bytes.
Thanks.
-- Hal
sockaddr_ll changes to accomodate IPoIB interfaces.
This is due to the fact that the IPoIB link layer
address is 20 bytes rather than 8 bytes. With the current 8 byte
address, it is not possible to send ARPs and RARPs from userspace as the
broadcast and unicast IPoIB addresses cannot be supplied properly.
There is backward compatibility support for those applications built
with the existing structure (prior to this patch).
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
--- include/linux/if_packet.h.orig 2005-06-29 19:00:53.0 -0400
+++ include/linux/if_packet.h 2005-08-05 10:04:06.0 -0400
@@ -8,6 +8,7 @@ struct sockaddr_pkt
unsigned short spkt_protocol;
};
+#define SOCKADDR_LL_COMPAT 12
struct sockaddr_ll
{
unsigned short sll_family;
@@ -16,7 +17,7 @@ struct sockaddr_ll
unsigned short sll_hatype;
unsigned char sll_pkttype;
unsigned char sll_halen;
- unsigned char sll_addr[8];
+ unsigned char sll_addr[20];
};
/* Packet types */
--- af_packet.c.orig2005-06-29 19:00:53.0 -0400
+++ af_packet.c 2005-08-05 13:28:49.0 -0400
@@ -708,8 +708,12 @@ static int packet_sendmsg(struct kiocb *
addr= NULL;
} else {
err = -EINVAL;
- if (msg->msg_namelen < sizeof(struct sockaddr_ll))
- goto out;
+ if (msg->msg_namelen < sizeof(struct sockaddr_ll)) {
+ /* Support for older sockaddr_ll structs */
+ if ((msg->msg_namelen != sizeof(struct sockaddr_ll) -
SOCKADDR_LL_COMPAT) ||
+ (saddr->sll_hatype == ARPHRD_INFINIBAND))
+ goto out;
+ }
ifindex = saddr->sll_ifindex;
proto = saddr->sll_protocol;
addr= saddr->sll_addr;
@@ -937,7 +941,11 @@ static int packet_bind(struct socket *so
*/
if (addr_len < sizeof(struct sockaddr_ll))
- return -EINVAL;
+ /* Support for older sockaddr_ll structs */
+ if ((addr_len != sizeof(struct sockaddr_ll) -
+SOCKADDR_LL_COMPAT) ||
+ (sll->sll_hatype == ARPHRD_INFINIBAND))
+ return -EINVAL;
if (sll->sll_family != AF_PACKET)
return -EINVAL;
-
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-2.6.14 to be rebased
Harald Welte wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Dave! On Tue, Aug 09, 2005 at 06:23:33PM -0700, David S. Miller wrote: I want some net bug fixes in Linus's tree to propagate into the net-2.6.14 tree so I plan to rebase it this evening, so please be careful when sync'ing with my tree over the next day. so what is the actual process of a 'rebase' on your side? Do you just pull/update from Linus' current tree and merge it with yours? Or do you extract all the patches and apply them to a clean linus-tree? Personally, I -hope- it's a merge. git does merges just fine, these days. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: net-2.6.14 to be rebased
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Dave! On Tue, Aug 09, 2005 at 06:23:33PM -0700, David S. Miller wrote: > I want some net bug fixes in Linus's tree to propagate into the > net-2.6.14 tree so I plan to rebase it this evening, so please be > careful when sync'ing with my tree over the next day. so what is the actual process of a 'rebase' on your side? Do you just pull/update from Linus' current tree and merge it with yours? Or do you extract all the patches and apply them to a clean linus-tree? And what is the designated course of action for somebody (like me), who has based his tree on yours? I just do 'cg-update origin' and manually go through the changes, clean them up. Finally I chekc with 'cg-diff -r origin' whether there were any mistakes during the manual cleanup/conflict resolving by making sure it only contains the desired netfilter-related changes. Is that the "best current practise", or would you recomment a different course of action? - -- - - Harald Welte <[EMAIL PROTECTED]>http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC+4BtXaXGVTD0i/8RAkenAJ4opuGH/GDxpdLtX/hV1seYCOl8RQCZAe/W lUn71ubyjlT/VPNBH09hPNg= =2mfC -END PGP SIGNATURE- - 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] Make skb->protocol __be16
There are many instances of
skb->protocol = htons(ETH_P_*);
skb->protocol = __constant_htons(ETH_P_*);
and
skb->protocol = *_type_trans(...);
Most of *_type_trans() are already endian-annotated, so, let's shift attention
on other warnings.
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
linux-sparse/include/linux/skbuff.h |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux/linux-sparse/include/linux/skbuff.h
===
--- linux.orig/linux-sparse/include/linux/skbuff.h 2005-08-11
14:15:21.0 +0400
+++ linux/linux-sparse/include/linux/skbuff.h 2005-08-11 16:46:03.0
+0400
@@ -255,7 +255,7 @@ struct sk_buff {
nohdr:1;
/* 3 bits spare */
__u8pkt_type;
- __u16 protocol;
+ __be16 protocol;
void(*destructor)(struct sk_buff *skb);
#ifdef CONFIG_NETFILTER
-
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] fix NF_QUEUE_NR() macro
Harald Welte wrote: > Hi Dave, please apply! What about using a brace more: >diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h >--- a/include/linux/netfilter.h >+++ b/include/linux/netfilter.h >@@ -29,7 +29,7 @@ > #define NF_VERDICT_QMASK 0x > #define NF_VERDICT_QBITS 16 > >-#define NF_QUEUE_NR(x) ((x << NF_VERDICT_QBITS) & NF_VERDICT_QMASK || >NF_QUEUE) >+#define NF_QUEUE_NR(x) ((x << NF_VERDICT_QBITS) & NF_VERDICT_QMASK | NF_QUEUE) #define NF_QUEUE_NR(x) ((x << NF_VERDICT_QBITS) & (NF_VERDICT_QMASK | NF_QUEUE)) I know we are cool and know operator precedence even after 10 beer, but some people consider it difficult to understand without :-) Regards Ingo Oeser - 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] xfrm: do not use large arrays in BSS
On Thu, 2005-08-11 at 14:44 +0200, Balazs Scheidler wrote: > On Thu, 2005-08-11 at 22:31 +1000, Herbert Xu wrote: > > Balazs Scheidler <[EMAIL PROTECTED]> wrote: > > > > > > I've attached a revised patch, this time with complete error checking, > > > and > > > propagating the error code to the caller. Please apply. > > > > Sorry, but it seems that you've left out the bits that check the > > return value from xfrm_init()? > > > > Damn. I still have to get used to with git. Thanks for the hint. Anyone > know a git description that tells me how to follow a tree and maintain > my own set of patches on top? > > diff --git a/net/ipv4/route.c b/net/ipv4/route.c > --- a/net/ipv4/route.c > +++ b/net/ipv4/route.c > @@ -3201,7 +3201,7 @@ int __init ip_rt_init(void) > #endif > #endif > #ifdef CONFIG_XFRM > - xfrm_init(); > + rc = xfrm_init(); > xfrm4_init(); > #endif > return rc; > > In the meanwhile I found out that the return value of ip_rt_init is never handled, thus the code above is not fully correct, not to mention that xfrm4_init is called even if xfrm_init failed. Shall I panic in this case? -- Bazsi - 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] xfrm: do not use large arrays in BSS
On Thu, 2005-08-11 at 22:31 +1000, Herbert Xu wrote: > Balazs Scheidler <[EMAIL PROTECTED]> wrote: > > > > I've attached a revised patch, this time with complete error checking, and > > propagating the error code to the caller. Please apply. > > Sorry, but it seems that you've left out the bits that check the > return value from xfrm_init()? > Damn. I still have to get used to with git. Thanks for the hint. Anyone know a git description that tells me how to follow a tree and maintain my own set of patches on top? diff --git a/net/ipv4/route.c b/net/ipv4/route.c --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -3201,7 +3201,7 @@ int __init ip_rt_init(void) #endif #endif #ifdef CONFIG_XFRM - xfrm_init(); + rc = xfrm_init(); xfrm4_init(); #endif return rc; -- Bazsi - 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] xfrm: do not use large arrays in BSS
Balazs Scheidler <[EMAIL PROTECTED]> wrote:
>
> I've attached a revised patch, this time with complete error checking, and
> propagating the error code to the caller. Please apply.
Sorry, but it seems that you've left out the bits that check the
return value from xfrm_init()?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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.13-rc5 panic with tg3, e1000, vlan, tso
Vladimir B. Savkin <[EMAIL PROTECTED]> wrote:
>
> Today my gateway crashed.
> I wrote down crash info on a paper.
> It's not complete since only last 25 lines were shown,
> but complete stackdump is here (I omitted hexadecimal values).
>
> Call Trace:
>tcp_write_xmit+318
This should be fixed in rc6. Please give that a go.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] xfrm: do not use large arrays in BSS
On Mon, 2005-08-08 at 16:27 +0200, Balazs Scheidler wrote:
> Is this tiny patchlet worth the trouble of changing
> xfrm_init/xfrm_state_init to return int, and do error checking from
> ip_rt_init() ?
I've attached a revised patch, this time with complete error checking, and
propagating the error code to the caller. Please apply.
Signed-off-by: Balazs Scheidler <[EMAIL PROTECTED]>
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -812,11 +812,11 @@ struct xfrm6_tunnel {
int type, int code, int offset, __u32 info);
};
-extern void xfrm_init(void);
+extern int xfrm_init(void);
extern void xfrm4_init(void);
extern void xfrm6_init(void);
extern void xfrm6_fini(void);
-extern void xfrm_state_init(void);
+extern int xfrm_state_init(void);
extern void xfrm4_state_init(void);
extern void xfrm6_state_init(void);
extern void xfrm6_state_fini(void);
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1338,10 +1338,17 @@ static void __init xfrm_policy_init(void
register_netdevice_notifier(&xfrm_dev_notifier);
}
-void __init xfrm_init(void)
+int __init xfrm_init(void)
{
- xfrm_state_init();
+ int err;
+
+ err = xfrm_state_init();
+ if (err < 0)
+ return err;
+
xfrm_policy_init();
xfrm_input_init();
+
+ return 0;
}
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -35,8 +35,8 @@ static DEFINE_SPINLOCK(xfrm_state_lock);
* Main use is finding SA after policy selected tunnel or transport mode.
* Also, it can be used by ah/esp icmp error handler to find offending SA.
*/
-static struct list_head xfrm_state_bydst[XFRM_DST_HSIZE];
-static struct list_head xfrm_state_byspi[XFRM_DST_HSIZE];
+static struct list_head *xfrm_state_bydst;
+static struct list_head *xfrm_state_byspi;
DECLARE_WAIT_QUEUE_HEAD(km_waitq);
EXPORT_SYMBOL(km_waitq);
@@ -1093,14 +1093,21 @@ error:
EXPORT_SYMBOL(xfrm_init_state);
-void __init xfrm_state_init(void)
+int __init xfrm_state_init(void)
{
int i;
+ xfrm_state_bydst = (struct list_head *) __get_free_pages(GFP_KERNEL,
get_order(sizeof(struct list_head) * XFRM_DST_HSIZE * 2));
+ if (!xfrm_state_bydst)
+ return -ENOMEM;
+
+ xfrm_state_byspi = &xfrm_state_bydst[XFRM_DST_HSIZE];
for (i=0; ihttp://vger.kernel.org/majordomo-info.html
Re: [Fwd: [patch 11/15] ppp: handle misaligned accesses]
I wrote :
> I just noticed something at the end of process_input_packet :
> In the normal case, skb is given to the next stage and ap->rpkt is reset,
> but in the error case, skb is kept, ap->rpkt is not reset, so we keep
> the skb with skb->data aligned for one message and we put another one
> into it :)
>
> Could that not be the culprit ?
Based on my previous observation, here is a revised patch, that replaces
the previous one.
This patch avoids ppp-generated kernel crashes on machines where
unaligned accesses are forbidden, by fixing ppp alignment setting
for reused skb's.
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
--- drivers/net/ppp_async.c 2004/05/07 08:38:32 1.1.1.1
+++ drivers/net/ppp_async.c 2005/08/11 11:21:33
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#define PPP_VERSION"2.4.2"
@@ -846,7 +847,11 @@ process_input_packet(struct asyncppp *ap
/* frame had an error, remember that, reset SC_TOSS & SC_ESCAPE */
ap->state = SC_PREV_ERROR;
if (skb)
+ {
+ /* make skb appear as freshly allocated */
skb_trim(skb, 0);
+ skb_reserve(skb, - skb_headroom(skb));
+ }
}
/* called when the tty driver has data for us. */
@@ -897,10 +902,18 @@ ppp_async_input(struct asyncppp *ap, con
skb = dev_alloc_skb(ap->mru + PPP_HDRLEN + 2);
if (skb == 0)
goto nomem;
+ ap->rpkt = skb;
+ }
+ if (skb->len == 0) {
/* Try to get the payload 4-byte aligned */
+ /* This should match the
+ ** PPP_ALLSTATIONS/PPP_UI/compressed tests
+ ** in process_input_packet,
+ ** but we do not have enough chars here to
+ ** test buf[1] and buf[2].
+ */
if (buf[0] != PPP_ALLSTATIONS)
skb_reserve(skb, 2 + (buf[0] & 1));
- ap->rpkt = skb;
}
if (n > skb_tailroom(skb)) {
/* packet overflowed MRU */
-
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/2] make nf_log compile with PROC_FS == n
Hi Dave, please apply!
--
- Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
[NETFILTER] Fix compilation when no PROC_FS enabled
Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
diff --git a/net/netfilter/nf_log.c b/net/netfilter/nf_log.c
--- a/net/netfilter/nf_log.c
+++ b/net/netfilter/nf_log.c
@@ -166,12 +166,12 @@ int __init netfilter_log_init(void)
{
#ifdef CONFIG_PROC_FS
struct proc_dir_entry *pde;
+
pde = create_proc_entry("nf_log", S_IRUGO, proc_net_netfilter);
-#endif
if (!pde)
return -1;
pde->proc_fops = &nflog_file_ops;
-
+#endif
return 0;
}
pgperqcphy6Ge.pgp
Description: PGP signature
[PATCH 2/2] fix NF_QUEUE_NR() macro
Hi Dave, please apply! -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) [NETFILTER] Fix NF_QUEUE_NR() macro I obviously wanted to use bitwise-or, not logical or. Signed-off-by: Harald Welte <[EMAIL PROTECTED]> --- commit 359a4ba102b661dbd8da28b9dcb3330656a7a963 tree 3d1549cbff8af472bf761322b468ccd0d5be55c2 parent 5d6a0527049e43780fdaef065d0240a3338f92fd author Harald Welte <[EMAIL PROTECTED]> Di, 09 Aug 2005 09:32:02 +0200 committer Harald Welte <[EMAIL PROTECTED]> Di, 09 Aug 2005 09:32:02 +0200 include/linux/netfilter.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h --- a/include/linux/netfilter.h +++ b/include/linux/netfilter.h @@ -29,7 +29,7 @@ #define NF_VERDICT_QMASK 0x #define NF_VERDICT_QBITS 16 -#define NF_QUEUE_NR(x) ((x << NF_VERDICT_QBITS) & NF_VERDICT_QMASK || NF_QUEUE) +#define NF_QUEUE_NR(x) ((x << NF_VERDICT_QBITS) & NF_VERDICT_QMASK | NF_QUEUE) /* only for userspace compatibility */ #ifndef __KERNEL__ pgp3VDBMDfq30.pgp Description: PGP signature
