[PATCH] Olympic (IBM PCI tokenring): handle return codes of register_netdev
Handle return codes of register_netdev().
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
Index: 21-rc7/drivers/net/tokenring/olympic.c
===
--- 21-rc7.orig/drivers/net/tokenring/olympic.c
+++ 21-rc7/drivers/net/tokenring/olympic.c
@@ -264,7 +264,10 @@ static int __devinit olympic_probe(struc
SET_NETDEV_DEV(dev, pdev-dev);
pci_set_drvdata(pdev,dev) ;
- register_netdev(dev) ;
+
+ if (register_netdev(dev))
+ goto op_free_iomap;
+
printk(Olympic: %s registered as:
%s\n,olympic_priv-olympic_card_name,dev-name);
if (olympic_priv-olympic_network_monitor) { /* Must go after
register_netdev as we need the device name */
char proc_name[20] ;
@@ -281,7 +284,8 @@ op_free_iomap:
if (olympic_priv-olympic_lap)
iounmap(olympic_priv-olympic_lap);
- free_netdev(dev);
+ if (dev)
+ free_netdev(dev);
op_release_dev:
pci_release_regions(pdev);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH -mm take4 6/6] add ioctls for adding/removing target
From: Stephen Hemminger [EMAIL PROTECTED] Date: Thu, 19 Apr 2007 22:39:09 -0700 Should't this just be a network ioctl against an UDP (AF_INET, SOCK_DGRAM) socket? Also consider netconsole over IPV6 for future enhancement. If it's on a socket use a socket option :-) - 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 [EMAIL PROTECTED] wrote: The patch works properly on my side. But 1) I'm not sure why you re-wrote alloc/free_pg_vec function, doesn't the current implement work for NOMMU? I know you want to allocate the entire data buffer as one contiguous lump, but is it really necessary? Yes. It's not possible to map the whole buffer otherwise. Think about it! mmap() returns _one_ reference address. In MMU-mode, the non-contiguous physical buffers can be made to appear virtually contiguous by fudging the page tables and using the MMU. This is not possible in NOMMU-mode. The app will expect the buffer to be one contiguous lump in its address space, and will not be able to locate the other segments of the buffer. Actually, what I said is not quite true. It is possible to map the whole buffer otherwise: I could lift the restriction that requires that you map the whole buffer or not at all, and then userspace could stitch the whole lot together itself. This would then require userspace to be bimodal. 2) So the mapped pages doesn't count into NR_FILE_MAPPED, is it a problem? Not really, no - there are no pagetables. Furthermore, issuing the PACKET_RX_RING sockopt does the entire allocation. Any subsequent mmaps on it have little effect. We could do that accounting though if you think it'd be better. I don't suppose it hurts. 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: Getting the new RxRPC patches upstream
David Miller [EMAIL PROTECTED] wrote: I applied already the patches I thought were appropriate, you had some crypto layer changes that you need to work out with Herbert Xu before the rest can be applied. Should the rest of it go via Andrew's tree then? 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] CONFIG_PACKET_MMAP should depend on MMU
On 4/20/07, David Howells [EMAIL PROTECTED] wrote: Aubrey Li [EMAIL PROTECTED] wrote: The patch works properly on my side. But 1) I'm not sure why you re-wrote alloc/free_pg_vec function, doesn't the current implement work for NOMMU? I know you want to allocate the entire data buffer as one contiguous lump, but is it really necessary? Yes. It's not possible to map the whole buffer otherwise. Think about it! mmap() returns _one_ reference address. In MMU-mode, the non-contiguous physical buffers can be made to appear virtually contiguous by fudging the page tables and using the MMU. This is not possible in NOMMU-mode. The app will expect the buffer to be one contiguous lump in its address space, and will not be able to locate the other segments of the buffer. Great explanation, thanks, :-) Actually, what I said is not quite true. It is possible to map the whole buffer otherwise: I could lift the restriction that requires that you map the whole buffer or not at all, and then userspace could stitch the whole lot together itself. This would then require userspace to be bimodal. 2) So the mapped pages doesn't count into NR_FILE_MAPPED, is it a problem? Not really, no - there are no pagetables. Furthermore, issuing the PACKET_RX_RING sockopt does the entire allocation. Any subsequent mmaps on it have little effect. We could do that accounting though if you think it'd be better. I don't suppose it hurts. as checked in packet_set_ring, buffer size must be a multiple of PAGE_SIZE, packet_set_ring if (unlikely(req-tp_block_size (PAGE_SIZE - 1))) So why not use __get_free_pages rather than kmalloc, so that we have pagetables to count? -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: Getting the new RxRPC patches upstream
From: David Howells [EMAIL PROTECTED] Date: Fri, 20 Apr 2007 09:02:07 +0100 David Miller [EMAIL PROTECTED] wrote: I applied already the patches I thought were appropriate, you had some crypto layer changes that you need to work out with Herbert Xu before the rest can be applied. Should the rest of it go via Andrew's tree then? Now that Herbert cleared up the crypto layer issues the only problem left is that there are generic changes in there which are not strictly networking but which your subsequent networking changes depend upon. This is a mess, and makes merging your work into the net-2.6.22 tree more difficult. Is it possible for your changes to be purely networking and not need those changes outside of the networking? I guess one of them was just a symbol export which I could add to the net-2.6.22 tree, but weren't there some more involved non-networking bits in there? - 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 [EMAIL PROTECTED] wrote: as checked in packet_set_ring, buffer size must be a multiple of PAGE_SIZE, packet_set_ring if (unlikely(req-tp_block_size (PAGE_SIZE - 1))) So why not use __get_free_pages rather than kmalloc, Because kmalloc() may be able to get us a smaller chunk of memory. Actually, calling __get_free_pages() might be a better, and then release the excess pages. so that we have pagetables to count? There are no pagetables in NOMMU-mode. 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] CONFIG_PACKET_MMAP should depend on MMU
On Fri, 20 Apr 2007 09:58:52 +0100 David Howells [EMAIL PROTECTED] wrote: Because kmalloc() may be able to get us a smaller chunk of memory. Actually, calling __get_free_pages() might be a better, and then release the excess pages. Interesting, that rings a bell here. I wonder why we dont use this in alloc_large_system_hash(). (if __get_free_pages(GFP_ATOMIC, order) is used instead of alloc_bootmem() or __vmalloc()) We currently loose 1/4 of space on tcp hash table for example, because sizeof(inet_ehash_bucket) is not a power of 2. Is it really possible to allocate an order-10 page, then release part of it (say an order-8 subpage) ? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH -mm take4 2/6] support multiple logging
I started to do some cleanups and fixups here, but abandoned it when it was all getting a bit large. Here are some fixes against this patch: I'm going to fix my patches by following your reviews and send new patches on the LKML and the netdev ML in a few days. Thank you for your comments and reviews. -- Keiichi KII NEC Corporation OSS Promotion Center E-mail: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH -mm take4 2/6] support multiple logging
Please include an update to Documentation/networking/netconsole.txt OK, I update the documnet for the added functions in next patches. Thank you for your comments. -- Keiichi KII NEC Corporation OSS Promotion Center E-mail: [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][IPSEC] fix panic when using inter address familiy IPsec on loopback
Hello,
I send patches to fix panic when using inter
address family IPsec on loopback device.
These patches can be applied to current linux-2.6 and
should also be net-2.6.
Best regards,
Signed-off-by: Kazunori MIYAZAWA [EMAIL PROTECTED]
---
net/ipv4/xfrm4_input.c |6 ++
net/ipv4/xfrm4_mode_tunnel.c |2 ++
net/ipv6/xfrm6_input.c |6 ++
net/ipv6/xfrm6_mode_tunnel.c |1 +
4 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/xfrm4_input.c b/net/ipv4/xfrm4_input.c
index 78e80de..9fcf6d8 100644
--- a/net/ipv4/xfrm4_input.c
+++ b/net/ipv4/xfrm4_input.c
@@ -138,10 +138,8 @@ int xfrm4_rcv_encap(struct sk_buff *skb,
nf_reset(skb);
if (decaps) {
- if (!(skb-dev-flagsIFF_LOOPBACK)) {
- dst_release(skb-dst);
- skb-dst = NULL;
- }
+ dst_release(skb-dst);
+ skb-dst = NULL;
netif_rx(skb);
return 0;
} else {
diff --git a/net/ipv4/xfrm4_mode_tunnel.c b/net/ipv4/xfrm4_mode_tunnel.c
index ceb4376..5115574 100644
--- a/net/ipv4/xfrm4_mode_tunnel.c
+++ b/net/ipv4/xfrm4_mode_tunnel.c
@@ -84,6 +84,8 @@ #endif
top_iph-saddr = x-props.saddr.a4;
top_iph-daddr = x-id.daddr.a4;
+ skb-protocol = htons(ETH_P_IP);
+
memset((IPCB(skb)-opt), 0, sizeof(struct ip_options));
return 0;
}
diff --git a/net/ipv6/xfrm6_input.c b/net/ipv6/xfrm6_input.c
index 31f651f..c53c0d3 100644
--- a/net/ipv6/xfrm6_input.c
+++ b/net/ipv6/xfrm6_input.c
@@ -104,10 +104,8 @@ int xfrm6_rcv_spi(struct sk_buff *skb, _
nf_reset(skb);
if (decaps) {
- if (!(skb-dev-flagsIFF_LOOPBACK)) {
- dst_release(skb-dst);
- skb-dst = NULL;
- }
+ dst_release(skb-dst);
+ skb-dst = NULL;
netif_rx(skb);
return -1;
} else {
diff --git a/net/ipv6/xfrm6_mode_tunnel.c b/net/ipv6/xfrm6_mode_tunnel.c
index 0bc866c..8741bcd 100644
--- a/net/ipv6/xfrm6_mode_tunnel.c
+++ b/net/ipv6/xfrm6_mode_tunnel.c
@@ -80,6 +80,7 @@ static int xfrm6_tunnel_output(struct xf
top_iph-hop_limit = dst_metric(dst-child, RTAX_HOPLIMIT);
ipv6_addr_copy(top_iph-saddr, (struct in6_addr *)x-props.saddr);
ipv6_addr_copy(top_iph-daddr, (struct in6_addr *)x-id.daddr);
+ skb-protocol = htons(ETH_P_IPV6);
return 0;
}
--
1.4.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: Getting the new RxRPC patches upstream
David Miller [EMAIL PROTECTED] wrote: Now that Herbert cleared up the crypto layer issues the only problem left is that there are generic changes in there which are not strictly networking but which your subsequent networking changes depend upon. This is a mess, and makes merging your work into the net-2.6.22 tree more difficult. There are only two non-net patches that AF_RXRPC depends on: (1) The key facility changes. That's all my code anyway, and shouldn't be a problem to merge unless someone else has put some changes in there that I don't know about. (2) try_to_cancel_delayed_work(). I suppose I could use cancel_delayed_work() instead, but that's less efficient as it waits for the timer completion function to finish. And one that AFS depends on: (3) Cache the key in nameidata. I still don't have Al's agreement on this, but it's purely caching, so I could drop that patch for the moment and excise the stuff that uses it from my AFS patches if that would help. Do you class the AFS patches as networking changes? Do you want me to consolidate my patches to make things simpler for you? Do you want me to rebase my patches onto net-2.6.22? I have the following patches, in order, available now, though I haven't yet released the last few (they can all be downloaded from my RH people pages): move-skb-generic.diff (you've got this) timers.diff keys.diff af_rxrpc.diff afs-cleanup.diff af_rxrpc-kernel.diff af_rxrpc-afs.diff af_rxrpc-delete-old.diff af_rxrpc-own-workqueues.diff af_rxrpc-fixes.diff afs-callback-wq.diff afs-vlocation.diff afs-multimount.diff afs-rxrpc-key.diff afs-nameidata-key.diff afs-security.diff afs-doc.diff netlink-support-MSG_TRUNC.diff (you've got this) afs-get-capabilities.diff afs-initcallbackstate3.diff afs-dir-write-support.diff 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] CONFIG_PACKET_MMAP should depend on MMU
Eric Dumazet [EMAIL PROTECTED] wrote: Is it really possible to allocate an order-10 page, then release part of it (say an order-8 subpage) ? Yes. 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: ESP interfamily tunnel bug?
Hi Diego, I was probably misunderstanding your problem. Ok, I used two machines, which were connected to different networks. My topology was [Host1][Router]-[Host2] I configured Host1 and Host2 to communicate by using IPv6 over IPv4 IPsec ESP tunnel mode. And they could communicate with each other. I have never had netowrk unreachable. I used ping6 for the test. The kernel of Host1 was net-2.6 and the kernel of Host2 was linux-2.6. I also tested with dummy adevice and a virtual address. Host1 and Host2 had different addresses whose prefixes did not equal to one in router advertisement they received. I succeeded the test. Those hosts could communicate. So, I could not reproduce the bug. Best regards, Diego Beltrami wrote: On Thu, 19 Apr 2007, Kazunori MIYAZAWA wrote: I'm using a machine and a dummy device. So I'm using loopback communication. Yes, the backtrace is correct. I thought you used loopback communication to test the modes because your configuration showed that the dummy device has some addresses and you did ping from the address to the other address. Is not right? Did you use two or more hosts? If we understood you correctly, you are using a single machine? If yes, we can repeat your problem too. There is something wrong with the loopback, XFRM (and interfamily). However, we were describing a different problem. We were using two separate machines that were in different networks. I do not have enough environment to test today. I'll test it with a couple of machines tomorrow. Diego Beltrami wrote: Hi Kazunori, thanks for reply. In your backtrace I see that there are both input and output functions calls. Is it the right way? One more thing, were your two hosts you used located on the same network? In fact it seems that if the machines are on the same network, this bug doesn't manifest. Thanks, Diego Hello Diego, I tried to reproduce the bug. But I got a panic of the kernel :- I'm using current net-2.6. I suspect that some special routing for loopback is related because I checked with kdb and got the backtrace like fib_sync_down ipv6_rcv netif_receive_skb __mod_timer net_rx_action __do_softirq do_softirq local_bh_enable dev_queue_xmit neigh_resolve_output ip_output xfrm4_output_finish xfrm4_output ip_generic_getfrag ip6_push_pending_frames I think ip_rcv or some IPv4 function should be called between netif_receive_skb and ipv6_rcv. Anyway I could not classify the way to make a panic. I'll trace it. Thank you, Diego Beltrami wrote: Hi, we have discovered a routing related problem in ESP tunnel and beet mode. We don't know whether it is a bug in the XFRM, or just in the way the virtual addresses and the corresponding routes are set-up. We set up a dummy0 device for the virtual addresses: [EMAIL PROTECTED]:~# ip addr show dummy0 5: dummy0: BROADCAST,NOARP,UP,1 mtu 1500 qdisc noqueue link/ether 92:09:fe:11:81:1b brd ff:ff:ff:ff:ff:ff inet6 2001:72:e6d3:1cf3:e11d:5bb0:b99:e85e/28 scope global valid_lft forever preferred_lft forever inet6 2001:74:32e0:df36:e862:3963:523e:dd7d/28 scope global valid_lft forever preferred_lft forever inet6 2001:73:d3a8:8723:d572:7549:7f2c:e590/28 scope global valid_lft forever preferred_lft forever inet6 2001:75:a2e6:aad6:e901:dd1c:ba95:e300/28 scope global valid_lft forever preferred_lft forever inet6 fe80::9009:feff:fe11:811b/64 scope link valid_lft forever preferred_lft forever And then we have routes for the virtual addresses: [EMAIL PROTECTED]:~# ip -6 route 2001:72:e6d3:1cf3:e11d:5bb0:b99:e85e dev dummy0 metric 1024 expires 21334305sec mtu 1500 advmss 1440 metric 10 4294967295 2001:73:d3a8:8723:d572:7549:7f2c:e590 dev dummy0 metric 1024 expires 21334305sec mtu 1500 advmss 1440 metric 10 4294967295 2001:74:32e0:df36:e862:3963:523e:dd7d dev dummy0 metric 1024 expires 21334305sec mtu 1500 advmss 1440 metric 10 4294967295 2001:75:a2e6:aad6:e901:dd1c:ba95:e300 dev dummy0 metric 1024 expires 21334305sec mtu 1500 advmss 1440 metric 10 4294967295 2001:70::/28 dev dummy0 metric 256 expires 21334305sec mtu 1500 advmss 1440 metric 10 4294967295 fe80::/64 dev dummy0 metric 256 expires 21334305sec mtu 1500 advmss 1440 metric 10 4294967295 ff00::/8 dev eth0 metric 256 expires 21325454sec mtu 1500 advmss 1440 metric 10 4294967295 ff00::/8 dev dummy0 metric 256 expires 21334305sec mtu 1500 advmss 1440 metric 10 4294967295 unreachable default dev lo proto none metric -1 error -101 metric 10 255 ...and set-up policies and associations. The virtual IPv6 addresses are inner and IPv4 addresses are outer addresses: [EMAIL PROTECTED]:~/projects/hipl--userspace--2.6# ip xfrm policy show src 2001:76:7d5a:88d7:51af:cdd1:6bf5:3d15/128 dst 2001:74:32e0:df36:e862:3963:523e:dd7d/128 dir in priority 0 tmpl src c1a7:bb82::
Re: [PATCH] CONFIG_PACKET_MMAP should depend on MMU
On 4/20/07, David Howells [EMAIL PROTECTED] wrote: Aubrey Li [EMAIL PROTECTED] wrote: as checked in packet_set_ring, buffer size must be a multiple of PAGE_SIZE, packet_set_ring if (unlikely(req-tp_block_size (PAGE_SIZE - 1))) So why not use __get_free_pages rather than kmalloc, Because kmalloc() may be able to get us a smaller chunk of memory. Actually, calling __get_free_pages() might be a better, and then release the excess pages. so that we have pagetables to count? There are no pagetables in NOMMU-mode. Hmm..., I'm thinking some codes in memory reclaim depend on NR_FILE_MMAPED like follows snip if (zone_page_state(zone, NR_FILE_PAGES) - zone_page_state(zone, NR_FILE_MAPPED) zone-min_unmapped_pages) snip Since we are enabling packet mmap feature, we should take its mapped pages into count of NR_FILE_MAPPED. -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: [1/3] 2.6.21-rc6: known regressions
* Ingo Molnar [EMAIL PROTECTED] wrote: The 6b6b6b6b pattern is POISON_FREE, implying some kind of slab misuse, most likely a use-after-free, although possibly just due to overrunning a slab into the next one or something like that. unfortunately, while being at -rc6 based kernel #445 meanwhile, this incident was the only time i saw this problem. [...] meanwhile i'm at kernel bootup #657, and still this crash did not reoccur. So it could have been some pre-existing sysfs bug that triggers only extremely rarely. I'd suggest that this bug have its priority lowered (to not hold up a v2.6.21 release) - there's no smoking gun and no reproducer. I'll keep an eye on it. Ingo - 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/1] networking: fix sending netlink message when replace route
From: Milan Kocian [EMAIL PROTECTED]
When you replace route via ip r r command the netlink multicast message
is not send. This patch corrects it. NL message is sent with
NLM_F_REPLACE flag. [Bug 8320]
---
--- a/net/ipv4/fib_hash.c 2007-04-18 12:50:11.0 +0200
+++ b/net/ipv4/fib_hash.c 2007-04-19 10:21:04.267136960 +0200
@@ -457,6 +457,8 @@
fib_release_info(fi_drop);
if (state FA_S_ACCESSED)
rt_cache_flush(-1);
+ rtmsg_fib(RTM_NEWROUTE, key, fa, cfg-fc_dst_len,
tb-tb_id,
+ cfg-fc_nlinfo, NLM_F_REPLACE);
return 0;
}
@@ -524,7 +526,7 @@
rt_cache_flush(-1);
rtmsg_fib(RTM_NEWROUTE, key, new_fa, cfg-fc_dst_len, tb-tb_id,
- cfg-fc_nlinfo);
+ cfg-fc_nlinfo, 0);
return 0;
out_free_new_fa:
@@ -590,7 +592,7 @@
fa = fa_to_delete;
rtmsg_fib(RTM_DELROUTE, key, fa, cfg-fc_dst_len,
- tb-tb_id, cfg-fc_nlinfo);
+ tb-tb_id, cfg-fc_nlinfo, 0);
kill_fn = 0;
write_lock_bh(fib_hash_lock);
--- a/net/ipv4/fib_trie.c 2007-04-18 12:50:11.0 +0200
+++ b/net/ipv4/fib_trie.c 2007-04-19 11:41:14.537864656 +0200
@@ -1205,6 +1205,8 @@
fib_release_info(fi_drop);
if (state FA_S_ACCESSED)
rt_cache_flush(-1);
+ rtmsg_fib(RTM_NEWROUTE, htonl(key), new_fa, plen,
tb-tb_id,
+ cfg-fc_nlinfo, NLM_F_REPLACE);
goto succeeded;
}
/* Error if we find a perfect match which
@@ -1256,7 +1258,7 @@
rt_cache_flush(-1);
rtmsg_fib(RTM_NEWROUTE, htonl(key), new_fa, plen, tb-tb_id,
- cfg-fc_nlinfo);
+ cfg-fc_nlinfo, 0);
succeeded:
return 0;
@@ -1599,7 +1601,7 @@
fa = fa_to_delete;
rtmsg_fib(RTM_DELROUTE, htonl(key), fa, plen, tb-tb_id,
- cfg-fc_nlinfo);
+ cfg-fc_nlinfo, 0);
l = fib_find_node(t, key);
li = find_leaf_info(l, plen);
--- a/net/ipv4/fib_semantics.c 2007-04-18 12:50:11.0 +0200
+++ b/net/ipv4/fib_semantics.c 2007-04-19 10:22:06.852622520 +0200
@@ -301,7 +301,8 @@
}
void rtmsg_fib(int event, __be32 key, struct fib_alias *fa,
- int dst_len, u32 tb_id, struct nl_info *info)
+ int dst_len, u32 tb_id, struct nl_info *info,
+ unsigned int nlm_flags)
{
struct sk_buff *skb;
u32 seq = info-nlh ? info-nlh-nlmsg_seq : 0;
@@ -313,7 +314,7 @@
err = fib_dump_info(skb, info-pid, seq, event, tb_id,
fa-fa_type, fa-fa_scope, key, dst_len,
- fa-fa_tos, fa-fa_info, 0);
+ fa-fa_tos, fa-fa_info, nlm_flags);
/* failure implies BUG in fib_nlmsg_size() */
BUG_ON(err 0);
--- a/net/ipv4/fib_lookup.h 2007-04-18 12:50:11.0 +0200
+++ b/net/ipv4/fib_lookup.h 2007-04-19 10:23:11.637773680 +0200
@@ -30,7 +30,8 @@
int dst_len, u8 tos, struct fib_info *fi,
unsigned int);
extern void rtmsg_fib(int event, __be32 key, struct fib_alias *fa,
- int dst_len, u32 tb_id, struct nl_info *info);
+ int dst_len, u32 tb_id, struct nl_info *info,
+ unsigned int nlm_flags);
extern struct fib_alias *fib_find_alias(struct list_head *fah,
u8 tos, u32 prio);
extern int fib_detect_death(struct fib_info *fi, int order,
Signed-off-by: Milan Kocian [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][IPSEC] fix panic when using inter address familiy IPsec on loopback
On Fri, 20 Apr 2007, Kazunori MIYAZAWA wrote: Hello, I send patches to fix panic when using inter address family IPsec on loopback device. These patches can be applied to current linux-2.6 and should also be net-2.6. Looks good to me, although I wonder why the !IFF_LOOPBACK check was there in the first place. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] NetXen: Removal of redundant argument passing
NetXen: Removal of redundant function call parameters and bug fixes.
This patch will remove the redundant paramters which were being passed to
many functions since now adapter-portnum can be used.
Signed-off-by: Mithlesh Thukral [EMAIL PROTECTED]
---
drivers/net/netxen/netxen_nic.h | 33 +++
drivers/net/netxen/netxen_nic_ethtool.c | 10 +-
drivers/net/netxen/netxen_nic_hdr.h |1
drivers/net/netxen/netxen_nic_hw.c | 19 +++-
drivers/net/netxen/netxen_nic_hw.h |4
drivers/net/netxen/netxen_nic_init.c|7 -
drivers/net/netxen/netxen_nic_isr.c |9 +-
drivers/net/netxen/netxen_nic_main.c| 32 +--
drivers/net/netxen/netxen_nic_niu.c | 96 +-
9 files changed, 112 insertions(+), 99 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index b996cb3..923ae6c 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -205,6 +205,7 @@ #define RCV_DESC_TYPE(ID) \
#define MAX_CMD_DESCRIPTORS1024
#define MAX_RCV_DESCRIPTORS16384
+#define MAX_RCV_DESCRIPTORS_1G (MAX_RCV_DESCRIPTORS / 4)
#define MAX_JUMBO_RCV_DESCRIPTORS 1024
#define MAX_LRO_RCV_DESCRIPTORS64
#define MAX_RCVSTATUS_DESCRIPTORS MAX_RCV_DESCRIPTORS
@@ -780,6 +781,7 @@ struct netxen_hardware_context {
struct pci_dev *cmd_desc_pdev;
dma_addr_t cmd_desc_phys_addr;
struct netxen_adapter *adapter;
+ int pci_func;
};
#define RCV_RING_LRO RCV_DESC_LRO
@@ -916,15 +918,15 @@ struct netxen_adapter {
struct netxen_ring_ctx *ctx_desc;
struct pci_dev *ctx_desc_pdev;
dma_addr_t ctx_desc_phys_addr;
- int (*enable_phy_interrupts) (struct netxen_adapter *, int);
- int (*disable_phy_interrupts) (struct netxen_adapter *, int);
+ int (*enable_phy_interrupts) (struct netxen_adapter *);
+ int (*disable_phy_interrupts) (struct netxen_adapter *);
void (*handle_phy_intr) (struct netxen_adapter *);
int (*macaddr_set) (struct netxen_adapter *, netxen_ethernet_macaddr_t);
int (*set_mtu) (struct netxen_adapter *, int);
int (*set_promisc) (struct netxen_adapter *, netxen_niu_prom_mode_t);
int (*unset_promisc) (struct netxen_adapter *, netxen_niu_prom_mode_t);
- int (*phy_read) (struct netxen_adapter *, long phy, long reg, u32 *);
- int (*phy_write) (struct netxen_adapter *, long phy, long reg, u32 val);
+ int (*phy_read) (struct netxen_adapter *, long reg, u32 *);
+ int (*phy_write) (struct netxen_adapter *, long reg, u32 val);
int (*init_port) (struct netxen_adapter *, int);
void (*init_niu) (struct netxen_adapter *);
int (*stop_port) (struct netxen_adapter *);
@@ -970,27 +972,21 @@ static inline void __iomem *pci_base(str
return NULL;
}
-int netxen_niu_xgbe_enable_phy_interrupts(struct netxen_adapter *adapter,
- int port);
-int netxen_niu_gbe_enable_phy_interrupts(struct netxen_adapter *adapter,
-int port);
-int netxen_niu_xgbe_disable_phy_interrupts(struct netxen_adapter *adapter,
- int port);
-int netxen_niu_gbe_disable_phy_interrupts(struct netxen_adapter *adapter,
- int port);
-int netxen_niu_xgbe_clear_phy_interrupts(struct netxen_adapter *adapter,
-int port);
-int netxen_niu_gbe_clear_phy_interrupts(struct netxen_adapter *adapter,
- int port);
+int netxen_niu_xgbe_enable_phy_interrupts(struct netxen_adapter *adapter);
+int netxen_niu_gbe_enable_phy_interrupts(struct netxen_adapter *adapter);
+int netxen_niu_xgbe_disable_phy_interrupts(struct netxen_adapter *adapter);
+int netxen_niu_gbe_disable_phy_interrupts(struct netxen_adapter *adapter);
+int netxen_niu_xgbe_clear_phy_interrupts(struct netxen_adapter *adapter);
+int netxen_niu_gbe_clear_phy_interrupts(struct netxen_adapter *adapter);
void netxen_nic_xgbe_handle_phy_intr(struct netxen_adapter *adapter);
void netxen_nic_gbe_handle_phy_intr(struct netxen_adapter *adapter);
void netxen_niu_gbe_set_mii_mode(struct netxen_adapter *adapter, int port,
long enable);
void netxen_niu_gbe_set_gmii_mode(struct netxen_adapter *adapter, int port,
long enable);
-int netxen_niu_gbe_phy_read(struct netxen_adapter *adapter, long phy, long reg,
+int netxen_niu_gbe_phy_read(struct netxen_adapter *adapter, long reg,
__u32 * readval);
-int netxen_niu_gbe_phy_write(struct netxen_adapter *adapter, long phy,
+int netxen_niu_gbe_phy_write(struct netxen_adapter *adapter,
long reg, __u32 val);
/* Functions available from netxen_nic_hw.c */
@@ -1010,6 +1006,7 @@ int
[PATCH 0/7] NetXen: Make driver use multiple PCI functions
hi All, Thanks Stephen for your suggestion. I am resending the 7 patches after incorporating the suggestion. These patches are with respect to netdev#upstream and we wish their inclusion in 2.6.22 kernel. Out of these the first 2 patches were already accepted into the netdev tree, but we have requested them to be dropped. So we are resending those 2. Please see the following thread for more details : http://www.spinics.net/lists/netdev/msg26805.html 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 5/7] NetXen: Port swap feature for multi port cards
NetXen: Port Swap feature
This patch will allow a port numbers on the card to be swapped in
host driver. This feature is applicable to cards having more than
1 port.
Signed-off by: Milan Bag [EMAIL PROTECTED]
Signed-off by: Mithlesh Thukral [EMAIL PROTECTED]
---
drivers/net/netxen/netxen_nic.h | 21 +
drivers/net/netxen/netxen_nic_ethtool.c | 143 ++---
drivers/net/netxen/netxen_nic_hdr.h |3
drivers/net/netxen/netxen_nic_hw.c | 67
drivers/net/netxen/netxen_nic_hw.h | 63
drivers/net/netxen/netxen_nic_init.c |2
drivers/net/netxen/netxen_nic_isr.c | 29 -
drivers/net/netxen/netxen_nic_main.c | 306 -
drivers/net/netxen/netxen_nic_niu.c | 93 --
drivers/net/netxen/netxen_nic_phan_reg.h |7
10 files changed, 468 insertions(+), 266 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index 923ae6c..1e944d5 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -205,6 +205,7 @@ #define RCV_DESC_TYPE(ID) \
#define MAX_CMD_DESCRIPTORS1024
#define MAX_RCV_DESCRIPTORS16384
+#define MAX_CMD_DESCRIPTORS_HOST (MAX_CMD_DESCRIPTORS / 4)
#define MAX_RCV_DESCRIPTORS_1G (MAX_RCV_DESCRIPTORS / 4)
#define MAX_JUMBO_RCV_DESCRIPTORS 1024
#define MAX_LRO_RCV_DESCRIPTORS64
@@ -303,6 +304,8 @@ #define FLAGS_VLAN_TAGGED 0x10
#define netxen_set_cmd_desc_port(cmd_desc, var)\
((cmd_desc)-port_ctxid |= ((var) 0x0F))
+#define netxen_set_cmd_desc_ctxid(cmd_desc, var) \
+ ((cmd_desc)-port_ctxid |= ((var) 0xF0))
#define netxen_set_cmd_desc_flags(cmd_desc, val) \
((cmd_desc)-flags_opcode = ~cpu_to_le16(0x7f), \
@@ -445,7 +448,7 @@ struct status_desc {
/* Bit pattern: 0-6 lro_count indicates frag sequence,
7 last_frag indicates last frag */
u8 lro;
-} __attribute__ ((aligned(8)));
+} __attribute__ ((aligned(16)));
enum {
NETXEN_RCV_PEG_0 = 0,
@@ -723,6 +726,18 @@ struct netxen_skb_frag {
u32 length;
};
+#define _netxen_set_bits(config_word, start, bits, val){\
+ unsigned long long __tmask = (((1ULL (bits)) - 1) (start));\
+ unsigned long long __tvalue = (val);\
+ (config_word) = ~__tmask; \
+ (config_word) |= (((__tvalue) (start)) __tmask); \
+}
+
+#define _netxen_clear_bits(config_word, start, bits) {\
+ unsigned long long __tmask = (((1ULL (bits)) - 1) (start)); \
+ (config_word) = ~__tmask; \
+}
+
/*Following defines are for the state of the buffers*/
#defineNETXEN_BUFFER_FREE 0
#defineNETXEN_BUFFER_BUSY 1
@@ -767,6 +782,8 @@ struct netxen_hardware_context {
void __iomem *pci_base0;
void __iomem *pci_base1;
void __iomem *pci_base2;
+ unsigned long first_page_group_end;
+ unsigned long first_page_group_start;
void __iomem *db_base;
unsigned long db_len;
@@ -862,6 +879,7 @@ struct netxen_adapter {
struct netxen_adapter *master;
struct net_device *netdev;
struct pci_dev *pdev;
+ struct net_device_stats net_stats;
unsigned char mac_addr[ETH_ALEN];
int mtu;
int portnum;
@@ -1152,4 +1170,5 @@ extern int netxen_rom_fast_read(struct n
extern struct ethtool_ops netxen_nic_ethtool_ops;
+extern int physical_port[];/* physical port # from virtual port.*/
#endif /* __NETXEN_NIC_H_ */
diff --git a/drivers/net/netxen/netxen_nic_ethtool.c
b/drivers/net/netxen/netxen_nic_ethtool.c
index 24c68f4..16fabb3 100644
--- a/drivers/net/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/netxen/netxen_nic_ethtool.c
@@ -40,8 +40,8 @@ #include linux/netdevice.h
#include linux/ethtool.h
#include linux/version.h
-#include netxen_nic_hw.h
#include netxen_nic.h
+#include netxen_nic_hw.h
#include netxen_nic_phan_reg.h
struct netxen_nic_stats {
@@ -379,7 +379,7 @@ netxen_nic_get_regs(struct net_device *d
for (i = 3; niu_registers[mode].reg[i - 3] != -1; i++) {
/* GB: port specific registers */
if (mode == 0 i = 19)
- window = adapter-portnum *
+ window = physical_port[adapter-portnum] *
NETXEN_NIC_PORT_WINDOW;
NETXEN_NIC_LOCKED_READ_REG(niu_registers[mode].
@@ -537,16 +537,43 @@ netxen_nic_get_pauseparam(struct net_dev
{
struct netxen_adapter *adapter = netdev_priv(dev);
__u32 val;
+ int port = physical_port[adapter-portnum];
if (adapter-ahw.board_type == NETXEN_NIC_GBE) {
+ if ((port 0) || (port NETXEN_NIU_MAX_GBE_PORTS))
+ return;
/* get flow control settings */
-
[PATCH 6/7] NetXen: Fixes for Power PC architecture
NetXen: Fix PPC architecture specific bugs
Fixes some issues seen on Big endian machines.
Signed-off by: Milan Bag [EMAIL PROTECTED]
Signed-off by: Mithlesh Thukral [EMAIL PROTECTED]
---
drivers/net/netxen/netxen_nic.h |6 +++---
drivers/net/netxen/netxen_nic_hw.c |3 +--
drivers/net/netxen/netxen_nic_init.c |4 ++--
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index 1e944d5..5095a3f 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 fba8790..2af5a9d 100644
--- a/drivers/net/netxen/netxen_nic_hw.c
+++ b/drivers/net/netxen/netxen_nic_hw.c
@@ -1115,7 +1115,7 @@ void netxen_nic_flash_print(struct netxe
char brd_name[NETXEN_MAX_SHORT_NAME];
struct netxen_new_user_info user_info;
int i, addr = USER_START;
- u32 *ptr32;
+ __le32 *ptr32;
struct netxen_board_info *board_info = (adapter-ahw.boardcfg);
if (board_info-magic != NETXEN_BDINFO_MAGIC) {
@@ -1141,7 +1141,6 @@ void netxen_nic_flash_print(struct netxe
netxen_nic_driver_name);
return;
}
- *ptr32 = le32_to_cpu(*ptr32);
ptr32++;
addr += sizeof(u32);
}
diff --git a/drivers/net/netxen/netxen_nic_init.c
b/drivers/net/netxen/netxen_nic_init.c
index ca3d78b..b75998d 100644
--- a/drivers/net/netxen/netxen_nic_init.c
+++ b/drivers/net/netxen/netxen_nic_init.c
@@ -439,6 +439,7 @@ do_rom_fast_read_words(struct netxen_ada
ret = do_rom_fast_read(adapter, addridx, (int *)bytes);
if (ret != 0)
break;
+ *(int *)bytes = cpu_to_le32(*(int *)bytes);
bytes += 4;
}
@@ -496,8 +497,7 @@ static inline int do_rom_fast_write_word
int timeout = 0;
int data;
- data = *(u32*)bytes;
-
+ data = le32_to_cpu((*(u32*)bytes));
ret = do_rom_fast_write(adapter, addridx, data);
if (ret 0)
return ret;
-
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/7] NetXen: Removal of redundant macros
NetXen: Remove 2 redundant macro definitions from header file. Signed-off by: Mithlesh Thukral [EMAIL PROTECTED] --- drivers/net/netxen/netxen_nic_phan_reg.h |2 -- 1 files changed, 2 deletions(-) diff --git a/drivers/net/netxen/netxen_nic_phan_reg.h b/drivers/net/netxen/netxen_nic_phan_reg.h index cb9acf1..12bcaf9 100644 --- a/drivers/net/netxen/netxen_nic_phan_reg.h +++ b/drivers/net/netxen/netxen_nic_phan_reg.h @@ -100,8 +100,6 @@ #define CRB_JUMBO_BUFFER_CONS NETX #define CRB_CMD_PRODUCER_OFFSET_1 NETXEN_NIC_REG(0x1ac) #define CRB_CMD_CONSUMER_OFFSET_1 NETXEN_NIC_REG(0x1b0) -#define CRB_CMD_PRODUCER_OFFSET_1 NETXEN_NIC_REG(0x1ac) -#define CRB_CMD_CONSUMER_OFFSET_1 NETXEN_NIC_REG(0x1b0) #define CRB_CMD_PRODUCER_OFFSET_2 NETXEN_NIC_REG(0x1b8) #define CRB_CMD_CONSUMER_OFFSET_2 NETXEN_NIC_REG(0x1bc) - 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] sis900: Allocate rx replacement buffer before rx operation
Neil Horman wrote: Hey there- The sis900 driver appears to have a bug in which the receive routine passes the skbuff holding the received frame to the network stack before refilling the buffer in the rx ring. If a new skbuff cannot be allocated, the driver simply leaves a hole in the rx ring, which causes the driver to stop receiving frames and become non-recoverable without an rmmod/insmod according to reporters. This patch reverses that order, attempting to allocate a replacement buffer first, and receiving the new frame only if one can be allocated. If no skbuff can be allocated, the current skbuf in the rx ring is recycled, dropping the current frame, but keeping the NIC operational. Thanks Regards Neil Signed-off-by: Neil Horman [EMAIL PROTECTED] Please CC the net driver maintainer ;-) I'll queue this for review. - 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 7/7] NetXen: Fix for vmalloc issues
NetXen: Fix vmalloc errors on seen on some X86 high end machines. Signed-off by: Milan Bag [EMAIL PROTECTED] Acked-by: Mithlesh Thukral [EMAIL PROTECTED] --- drivers/net/netxen/netxen_nic.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h index 5095a3f..ad6688e 100644 --- a/drivers/net/netxen/netxen_nic.h +++ b/drivers/net/netxen/netxen_nic.h @@ -131,8 +131,8 @@ #define NX_P2_C10x25 #define FIRST_PAGE_GROUP_START 0 #define FIRST_PAGE_GROUP_END 0x10 -#define SECOND_PAGE_GROUP_START0x400 -#define SECOND_PAGE_GROUP_END 0x66BC000 +#define SECOND_PAGE_GROUP_START0x600 +#define SECOND_PAGE_GROUP_END 0x68BC000 #define THIRD_PAGE_GROUP_START 0x70E4000 #define THIRD_PAGE_GROUP_END 0x800 - 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] sis900: Allocate rx replacement buffer before rx operation
Hey there-
The sis900 driver appears to have a bug in which the receive routine
passes the skbuff holding the received frame to the network stack before
refilling the buffer in the rx ring. If a new skbuff cannot be allocated, the
driver simply leaves a hole in the rx ring, which causes the driver to stop
receiving frames and become non-recoverable without an rmmod/insmod according to
reporters. This patch reverses that order, attempting to allocate a replacement
buffer first, and receiving the new frame only if one can be allocated. If no
skbuff can be allocated, the current skbuf in the rx ring is recycled, dropping
the current frame, but keeping the NIC operational.
Thanks Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
sis900.c | 44
1 file changed, 20 insertions(+), 24 deletions(-)
commit b11e33ae6b479f2e7f83b9dc148f0f24d47530bd
Author: Neil Horman [EMAIL PROTECTED]
Date: Mon Feb 12 09:47:45 2007 -0500
fixing buffer refill problem on sis900
diff --git a/drivers/net/sis900.c b/drivers/net/sis900.c
index fb2b530..a6a0f09 100644
--- a/drivers/net/sis900.c
+++ b/drivers/net/sis900.c
@@ -1755,6 +1755,24 @@ static int sis900_rx(struct net_device *net_dev)
} else {
struct sk_buff * skb;
+ pci_unmap_single(sis_priv-pci_dev,
+ sis_priv-rx_ring[entry].bufptr, RX_BUF_SIZE,
+ PCI_DMA_FROMDEVICE);
+
+ /* refill the Rx buffer, what if there is not enought
+* memory for new socket buffer ?? */
+ if ((skb = dev_alloc_skb(RX_BUF_SIZE)) == NULL) {
+ /*
+* Not enough memory to refill the buffer
+* so we need to recycle the old one so
+* as to avoid creating a memory hole
+* in the rx ring
+*/
+ skb = sis_priv-rx_skbuff[entry];
+ sis_priv-stats.rx_dropped++;
+ goto refill_rx_ring;
+ }
+
/* This situation should never happen, but due to
some unknow bugs, it is possible that
we are working on NULL sk_buff :-( */
@@ -1768,9 +1786,6 @@ static int sis900_rx(struct net_device *net_dev)
break;
}
- pci_unmap_single(sis_priv-pci_dev,
- sis_priv-rx_ring[entry].bufptr, RX_BUF_SIZE,
- PCI_DMA_FROMDEVICE);
/* give the socket buffer to upper layers */
skb = sis_priv-rx_skbuff[entry];
skb_put(skb, rx_size);
@@ -1783,33 +1798,14 @@ static int sis900_rx(struct net_device *net_dev)
net_dev-last_rx = jiffies;
sis_priv-stats.rx_bytes += rx_size;
sis_priv-stats.rx_packets++;
-
- /* refill the Rx buffer, what if there is not enought
-* memory for new socket buffer ?? */
- if ((skb = dev_alloc_skb(RX_BUF_SIZE)) == NULL) {
- /* not enough memory for skbuff, this makes a
-* hole on the buffer ring, it is not clear
-* how the hardware will react to this kind
-* of degenerated buffer */
- if (netif_msg_rx_status(sis_priv))
- printk(KERN_INFO %s: Memory squeeze,
- deferring packet.\n,
- net_dev-name);
- sis_priv-rx_skbuff[entry] = NULL;
- /* reset buffer descriptor state */
- sis_priv-rx_ring[entry].cmdsts = 0;
- sis_priv-rx_ring[entry].bufptr = 0;
- sis_priv-stats.rx_dropped++;
- sis_priv-cur_rx++;
- break;
- }
+ sis_priv-dirty_rx++;
+refill_rx_ring:
skb-dev = net_dev;
sis_priv-rx_skbuff[entry] = skb;
sis_priv-rx_ring[entry].cmdsts = RX_BUF_SIZE;
sis_priv-rx_ring[entry].bufptr =
pci_map_single(sis_priv-pci_dev, skb-data,
RX_BUF_SIZE, PCI_DMA_FROMDEVICE);
- sis_priv-dirty_rx++;
}
sis_priv-cur_rx++;
Re: [1/3] 2.6.21-rc6: known regressions
* Linus Torvalds [EMAIL PROTECTED] wrote: [...] I think the hangs that Ingo sees with forcedeth were preceded by mysterious and impossible NULL pointer oopses. Ingo? update: the 'forcedeth NULL pointer oops' problem got resolved by one of these commits: commit 3ba4d093fe8a26f5f2da94411bf8732fa6e9da86 Author: Ayaz Abdulla [EMAIL PROTECTED] Date: Fri Mar 23 05:50:02 2007 -0500 forcedeth: fix tx timeout commit fcc5f2665c81e087fb95143325ed769a41128d50 Author: Ayaz Abdulla [EMAIL PROTECTED] Date: Fri Mar 23 05:49:37 2007 -0500 forcedeth: fix nic poll it never reoccured since this went upstream - so i'd close the NULL dereference bug. furthermore, i havent seen the 'forcedeth interface hangs' problem trigger with recent kernels (havent seen it trigger for the past 2 weeks), but no forcedeth specific change went into the kernel since i last reproduced a hang so either it got fixed by something else, or the hang is very rare. We could lower its priority for v2.6.21. If it ever happens again i'll send another ethtool dump to Ayaz. Ingo - 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/7] NetXen: Multi PCI support for Quad cards
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 | 115 +++--
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, 144 insertions(+), 42 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_hw.c
b/drivers/net/netxen/netxen_nic_hw.c
index a066208..c464bc7 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));
@@ -349,6 +447,7 @@ int netxen_nic_hw_resources(struct netxe
}
memset(addr, 0, sizeof(struct netxen_ring_ctx));
adapter-ctx_desc = (struct netxen_ring_ctx *)addr;
+ adapter-ctx_desc-ctx_id = adapter-portnum;
adapter-ctx_desc-cmd_consumer_offset =
cpu_to_le64(adapter-ctx_desc_phys_addr +
sizeof(struct netxen_ring_ctx));
@@ -419,11 +518,11 @@ int netxen_nic_hw_resources(struct netxe
/* Window = 1 */
writel(lower32(adapter-ctx_desc_phys_addr),
- NETXEN_CRB_NORMALIZE(adapter, CRB_CTX_ADDR_REG_LO));
+ NETXEN_CRB_NORMALIZE(adapter, CRB_CTX_ADDR_REG_LO(func_id)));
Re: [PATCH 2.6.20] networking: bonding documentation fix for multiple bonding interfaces
Alexandra N. Kossovsky [EMAIL PROTECTED] wrote: Fix bonding driver documentation for the case of multiple bonding interfaces. Signed-off-by: Alexandra N. Kossovsky [EMAIL PROTECTED] I don't see a problem with this; users running distros that require the multiple load fru fru still have the documentation supplied with their distro kernel. Acked-by: Jay Vosburgh [EMAIL PROTECTED] -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sis900: Allocate rx replacement buffer before rx operation
Il giorno 20/apr/07, alle ore 15:54, Neil Horman ha scritto: Hey there- The sis900 driver appears to have a bug in which the receive routine passes the skbuff holding the received frame to the network stack before refilling the buffer in the rx ring. If a new skbuff cannot be allocated, the driver simply leaves a hole in the rx ring, which causes the driver to stop receiving frames and become non-recoverable without an rmmod/insmod according to reporters. This patch reverses that order, attempting to allocate a replacement buffer first, and receiving the new frame only if one can be allocated. If no skbuff can be allocated, the current skbuf in the rx ring is recycled, dropping the current frame, but keeping the NIC operational. Yes, I had one report of a user actually hitting this, but it is quite hard to reproduce and I don't have continuos access anymore to my sis900 machine. The patch seems fine by me. Signed-off-by: Neil Horman [EMAIL PROTECTED] Signed-off-by: Daniele Venzano [EMAIL PROTECTED] -- Daniele Venzano http://www.brownhat.org PGP.sig Description: Questa è un messaggio firmato elettronicamente
Re: [RFC][PATCH -mm take4 2/6] support multiple logging
On Fri, 20 Apr 2007 18:51:13 +0900 Keiichi KII [EMAIL PROTECTED] wrote: I started to do some cleanups and fixups here, but abandoned it when it was all getting a bit large. Here are some fixes against this patch: I'm going to fix my patches by following your reviews and send new patches on the LKML and the netdev ML in a few days. Well.. before you can finish this work we need to decide upon what the interface to userspace will be. - The miscdev isn't appropriate - netlink remains a possibility - Stephen suggests an ioctl against a socket and davem suggests socket options, but it's unclear to me how that socket will get bound to netconsole? either way, I agree with the overall thrust of this work: netconsole is useful in production environments, can become more useful and will need runtime configurability. I wonder if we're approaching this in the right way, however... At a high level, netconsole is just a flow of UDP packets between two machines. The kernel already has rich and well-understood ways of creating and configuring such flows. So... instead of creating a brand new way of configuring such a flow via sysfs and ioctl, could we instead create a flow using the existing mechanisms (presumably the socket API) and then transfer the information from that flow over to netconsole by some means?? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH -mm take4 2/6] support multiple logging
On Fri, Apr 20, 2007 at 11:15:26AM -0700, Andrew Morton wrote: On Fri, 20 Apr 2007 18:51:13 +0900 Keiichi KII [EMAIL PROTECTED] wrote: I started to do some cleanups and fixups here, but abandoned it when it was all getting a bit large. Here are some fixes against this patch: I'm going to fix my patches by following your reviews and send new patches on the LKML and the netdev ML in a few days. Well.. before you can finish this work we need to decide upon what the interface to userspace will be. - The miscdev isn't appropriate - netlink remains a possibility - Stephen suggests an ioctl against a socket and davem suggests socket options, but it's unclear to me how that socket will get bound to netconsole? Yeah, that's a bit of a head-scratcher. either way, I agree with the overall thrust of this work: netconsole is useful in production environments, can become more useful and will need runtime configurability. I wonder if we're approaching this in the right way, however... At a high level, netconsole is just a flow of UDP packets between two machines. The kernel already has rich and well-understood ways of creating and configuring such flows. So... instead of creating a brand new way of configuring such a flow via sysfs and ioctl, could we instead create a flow using the existing mechanisms (presumably the socket API) and then transfer the information from that flow over to netconsole by some means?? We don't really have anything that corresponds to netpoll's connections at higher levels. I'm tempted to say we should make this work more like the dummy network device. ie: modprobe netconsole -o netcon1 [params] modprobe netconsole -o netcon2 [params] -- Mathematics is the supreme nostalgia of our time. - 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: Getting the new RxRPC patches upstream
On Fri, 20 Apr 2007 11:41:46 +0100 David Howells [EMAIL PROTECTED] wrote: There are only two non-net patches that AF_RXRPC depends on: (1) The key facility changes. That's all my code anyway, and shouldn't be a problem to merge unless someone else has put some changes in there that I don't know about. (2) try_to_cancel_delayed_work(). I suppose I could use cancel_delayed_work() instead, but that's less efficient as it waits for the timer completion function to finish. There are significant workqueue changes in -mm and I plan to send them in for 2.6.22. I doubt if there's anything in there which directly affects cancel_delayed_work(), but making changes of this nature against 2.6.21 might lead to grief. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH -mm take4 2/6] support multiple logging
On Fri, 20 Apr 2007 13:21:10 -0500 Matt Mackall [EMAIL PROTECTED] wrote: On Fri, Apr 20, 2007 at 11:15:26AM -0700, Andrew Morton wrote: On Fri, 20 Apr 2007 18:51:13 +0900 Keiichi KII [EMAIL PROTECTED] wrote: I started to do some cleanups and fixups here, but abandoned it when it was all getting a bit large. Here are some fixes against this patch: I'm going to fix my patches by following your reviews and send new patches on the LKML and the netdev ML in a few days. Well.. before you can finish this work we need to decide upon what the interface to userspace will be. - The miscdev isn't appropriate - netlink remains a possibility - Stephen suggests an ioctl against a socket and davem suggests socket options, but it's unclear to me how that socket will get bound to netconsole? Yeah, that's a bit of a head-scratcher. either way, I agree with the overall thrust of this work: netconsole is useful in production environments, can become more useful and will need runtime configurability. I wonder if we're approaching this in the right way, however... At a high level, netconsole is just a flow of UDP packets between two machines. The kernel already has rich and well-understood ways of creating and configuring such flows. So... instead of creating a brand new way of configuring such a flow via sysfs and ioctl, could we instead create a flow using the existing mechanisms (presumably the socket API) and then transfer the information from that flow over to netconsole by some means?? We don't really have anything that corresponds to netpoll's connections at higher levels. I'm tempted to say we should make this work more like the dummy network device. ie: modprobe netconsole -o netcon1 [params] modprobe netconsole -o netcon2 [params] The configuration of netconsole's looks like the configuration of routes. Granted you probably have more routes than netconsoles, but the interface issues are similar. Netlink with a small application wouldn't be nice. And having /proc/net/netconsole (read-only) would be good for the netlink impaired. - 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
FYI: Xen or kernel bug? (fwd)
Could be an upstream kernel issue lurking. -- Forwarded message -- Date: Fri, 20 Apr 2007 22:21:26 +0200 From: Mark Stier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: FYI: Xen or kernel bug? Hello, tcp_vegas produces division by zero kernel oopses in dom0 when running a Xen-patched 2.6.16.28 kernel. I have tracked down the problem to line #256 in tcp_vegas.c: presumably due to flaky Xen timing, the rtt seems to get zero from time to time (adding 1 to the rtt variable solves the problem for me). The same should apply to line #140 in tcp_veno.c, too. Best regards, Mark - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - 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: FYI: Xen or kernel bug? (fwd)
On Fri, 20 Apr 2007 16:39:27 -0400 (EDT)
James Morris [EMAIL PROTECTED] wrote:
Could be an upstream kernel issue lurking.
-- Forwarded message --
Date: Fri, 20 Apr 2007 22:21:26 +0200
From: Mark Stier [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: FYI: Xen or kernel bug?
Hello,
tcp_vegas produces division by zero kernel oopses in dom0 when running
a Xen-patched 2.6.16.28 kernel. I have tracked down the problem to
line #256 in tcp_vegas.c: presumably due to flaky Xen timing, the rtt
seems to get zero from time to time (adding 1 to the rtt variable
solves the problem for me). The same should apply to line #140 in
tcp_veno.c, too.
Best regards,
Mark
Something different is happening, it shouldn't be possible to get
zero there? Maybe Xen timing is so bad that you are seeing 32 bit
wraparound.
Given this, rtt can't be zero...
---
static void tcp_vegas_rtt_calc(struct sock *sk, u32 usrtt)
{
struct vegas *vegas = inet_csk_ca(sk);
u32 vrtt = usrtt + 1; /* Never allow zero rtt or baseRTT */
/* Filter to find propagation delay: */
if (vrtt vegas-baseRTT)
vegas-baseRTT = vrtt;
/* Find the min RTT during the last RTT to find
* the current prop. delay + queuing delay:
*/
vegas-minRTT = min(vegas-minRTT, vrtt);
vegas-cntRTT++;
And we must have samples to get there.
static void tcp_vegas_cong_avoid(struct sock *sk, u32 ack,
u32 seq_rtt, u32 in_flight, int flag)
{
...
* If we have 3 samples, we should be OK.
*/
if (vegas-cntRTT = 2) {
/* We don't have enough RTT samples to do the Vegas
* calculation, so we'll behave like Reno.
*/
tcp_reno_cong_avoid(sk, ack, seq_rtt, in_flight, flag);
} else {
u32 rtt, target_cwnd, diff;
/* We have enough RTT samples, so, using the Vegas
* algorithm, we determine if we should increase or
* decrease cwnd, and by how much.
*/
/* Pluck out the RTT we are using for the Vegas
* calculations. This is the min RTT seen during the
* last RTT. Taking the min filters out the effects
* of delayed ACKs, at the cost of noticing congestion
* a bit later.
*/
rtt = vegas-minRTT;
/* Calculate the cwnd we should have, if we weren't
* going too fast.
*
* This is:
* (actual rate in segments) * baseRTT
* We keep it as a fixed point number with
* V_PARAM_SHIFT bits to the right of the binary point.
*/
target_cwnd = ((old_wnd * vegas-baseRTT)
V_PARAM_SHIFT) / rtt;
So how does rtt get to zero?
There is a possible problem if RTT is ever 4294 seconds but if you have that
big a RTT other stuff is happening.
-
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 8342] New: sctp_getsockopt_local_addrs_old() calls copy_to_user() while a spinlock is held
On Mon, 16 Apr 2007 14:34:22 -0700 [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8342 Summary: sctp_getsockopt_local_addrs_old() calls copy_to_user() while a spinlock is held Kernel Version: 2.6.20 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Problem Description: sctp_getsockopt_local_addrs_old() in net/sctp/socket.c calls copy_to_user() while the spinlock addr_lock is held. this should not be done as copy_to_user() might sleep. the call to sctp_copy_laddrs_to_user() while holding the lock is also problematic as it calls copy_to_user() yup. - 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: SIOCGIFCOUNT
From: Andi Kleen [EMAIL PROTECTED] Date: Sat, 21 Apr 2007 00:04:51 +0200 0x8938 is SIOCGIFCOUNT. As far as I can see it is only defined in sockios.h, but not implemented? Should it be removed from the include file or implemented? Unless we can be %100 certain not one build will break by removing it, we should keep it around. I probably will add a dummy compat ioctl entry to shut the JDK up at least. Yes, but please do this generically so that the warning gets quieted on all compat platforms that might hit this. 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
Associating connection tracking with a physical device.
I am trying to NAT routed connections between pairs of devices very much like the etun patch recently posted. As far as I can tell, this is failing because the connection tracking does not take the interface into account. The result is that if you send on etun1a, receive on etun1b, and then route internally to etun2a for transmit, the packet uses the same nfct (printk shows the 'id' of the ct is the same even though the skb-dev has changed.) This appears to make it impossible to NAT on etun2a in this scenario. I believe what is needed to make this work is the addition of some extra fields in the conn-tracking tuple, or perhaps some explicit test for the outgoing netdev. Does that sound like the right approach for enabling NAT in this case? Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/0] Re-try changes for PMTUDISC_PROBE
From: John Heffner [EMAIL PROTECTED] Date: Wed, 18 Apr 2007 21:07:10 -0400 This backs out the the transport layer MTU checks that don't work. As a consequence, I had to back out the PMTUDISC_PROBE patch as well. These patches should fix the problem with ipv6 that the transport layer change tried to address, and re-implement PMTUDISC_PROBE. I think this approach is nicer than the last one, since it doesn't require a bit in struct sk_buff. Since I was rebasing net-2.6.22, here is what I did. I simply elided the two patches you backed out, then I'll add patch 3 and 4, the new one's, on top. This will show up when I publish the rebased net-2.6.22 tree which I hope will happen later this evening. 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: [Bugme-new] [Bug 8330] New: lmc: copy_to/from_user cals while spinlock is held
On Sun, 15 Apr 2007 14:28:42 -0700 [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8330 Summary: lmc: copy_to/from_user cals while spinlock is held Kernel Version: 2.6.20 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Problem Description: the lmc_ioctl() function in drivers/net/wan/lmc/lmc_main.c calls copy_from/to_user() while the spinlock sc-lmc_lock is held. AFAIK this should not be done as copy_from/to_user() might sleep urgh. That function is a study in what not to do while holding a spinlock. Including return without having unlocked it. It is irreparable. - 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: Getting the new RxRPC patches upstream
On 04/20, Andrew Morton wrote: On Fri, 20 Apr 2007 11:41:46 +0100 David Howells [EMAIL PROTECTED] wrote: There are only two non-net patches that AF_RXRPC depends on: (1) The key facility changes. That's all my code anyway, and shouldn't be a problem to merge unless someone else has put some changes in there that I don't know about. (2) try_to_cancel_delayed_work(). I suppose I could use cancel_delayed_work() instead, but that's less efficient as it waits for the timer completion function to finish. There are significant workqueue changes in -mm and I plan to send them in for 2.6.22. I doubt if there's anything in there which directly affects cancel_delayed_work(), but making changes of this nature against 2.6.21 might lead to grief. I think it is better to use cancel_delayed_work(), but change it to use del_timer(). I belive cancel_delayed_work() doesn't need del_timer_sync(). We only care when del_timer() returns true. In that case, if the timer function still runs (possible for single-threaded wqs), it has already passed __queue_work(). Oleg. - 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: Add packet sock option to return orig_dev to userspace when bonded
From: Waskiewicz Jr, Peter P [EMAIL PROTECTED] Date: Thu, 8 Mar 2007 18:17:39 -0800 Peter P. Waskiewicz Jr. [EMAIL PROTECTED] NET: Add packet sock option to return orig_dev to userspace when bonded I'm going to apply this patch (by hand, your email client corrupted the patch massively, adding newlines and whatnot all over the patch). But I'm going to rename the option to be just PACKET_ORIGDEV because although bonding is the only user of this orig_dev decapsulation method, that might not always be true and it'd be a shame to give a special cased name when it is not deserved here. But please do fix your email client for future patch submissions. 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 3/3] Convert to use modern wait queue API
From: [EMAIL PROTECTED] Date: Sun, 11 Mar 2007 22:53:22 + Signed-off-by: Ralf Baechle [EMAIL PROTECTED] I finally applied this one, thanks for waiting so long :) - 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] skbuff: skb_store_bits const is backwards
Getting warnings becuase skb_store_bits has skb as constant,
but the function overwrites it. Looks like const was on the
wrong side.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
include/linux/skbuff.h |4 ++--
net/core/skbuff.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--- net-2.6.22.orig/include/linux/skbuff.h
+++ net-2.6.22/include/linux/skbuff.h
@@ -1491,8 +1491,8 @@ extern __wsumskb_checksum(const
int len, __wsum csum);
extern intskb_copy_bits(const struct sk_buff *skb, int offset,
void *to, int len);
-extern intskb_store_bits(const struct sk_buff *skb, int offset,
- void *from, int len);
+extern intskb_store_bits(struct sk_buff *skb, int offset,
+ const void *from, int len);
extern __wsum skb_copy_and_csum_bits(const struct sk_buff *skb,
int offset, u8 *to, int len,
__wsum csum);
--- net-2.6.22.orig/net/core/skbuff.c
+++ net-2.6.22/net/core/skbuff.c
@@ -1188,7 +1188,7 @@ fault:
* traversing fragment lists and such.
*/
-int skb_store_bits(const struct sk_buff *skb, int offset, void *from, int len)
+int skb_store_bits(struct sk_buff *skb, int offset, const void *from, int len)
{
int i, copy;
int start = skb_headlen(skb);
-
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 4/4] PPPoE: race between interface going down and release()
From: Michal Ostrowski [EMAIL PROTECTED]
Date: Sun, 11 Mar 2007 21:36:56 -0500
Attached below is my take on how to address this problem.
This addresses any concerns you may have had about checking
po-pppoe_dev==NULL,
because accesses to this field are now synchronized with pppoe_hash_lock.
Once we can settle on a fix for this, I'll deal with the SID==0 issue
(trying to do that now would just cause patch conflicts).
This patch doesn't apply becuase in the actual pppoe.c code:
- read_lock_bh(pppoe_hash_lock);
+ write_lock_bh(pppoe_hash_lock);
for (hash = 0; hash PPPOE_HASH_SIZE; hash++) {
struct pppox_sock *po = item_hash_table[hash];
while (po != NULL) {
- if (po-pppoe_dev == dev) {
- struct sock *sk = sk_pppox(po);
-
- sock_hold(sk);
-
- /* We hold a reference to SK, now drop the
- * hash table lock so that we may attempt
- * to lock the socket (which can sleep).
- */
That code doesn't look like that. At the end, instead there is:
sock_hold(sk);
po-pppoe_dev = NULL;
and that goes back all the way to 2.6.12 and beyond before
we moved over to GIT.
So I'm having trouble figuring out what tree you generated
that patch against :-) Perhaps there was an earlier patch
I missed or something.
But I won't second guess and leave it to you to let me know
what I should actually apply.
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: [Bugme-new] [Bug 8057] New: slab corruption running ip6sic
From: Jarek Poplawski [EMAIL PROTECTED]
Date: Mon, 12 Mar 2007 11:24:03 +0100
the ipcomp handler is xfrm6_rcv(), which calls xfrm6_rcv_spi(), which
contrary
to all other handlers returns -1 instead of 0 after calling kfree_skb() on
the
skb. Changing the return value to 0 in xfrm6_input.c:xfrm6_rcv_spi() fixes
the
problem.
But I got no clue at all if this would be a correct fix
I think your diagnose is correct (all return -1 should be
changed to return 0 in xfrm6_input.c).
Unfortunately, that won't work.
The return value logic for proto-handler() is different in
IPV6's ip6_input.c than it is for IPV4's ip_input.c.
IPv4 goes:
ret = ipprot-handler(skb);
if (ret 0) {
protocol = -ret;
goto resubmit;
}
whereas IPV6 goes:
ret = ipprot-handler(skb);
if (ret 0)
goto resubmit;
There was a good reason why things were done differently for
this case, but I don't remember what that reason was.
Anyways, changing -1 to 0 in xfrm6_input.c will break everything
even though it might make this crash go away. :-)))
-
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] skbuff: skb_store_bits const is backwards
From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Apr 2007 16:13:14 -0700 Getting warnings becuase skb_store_bits has skb as constant, but the function overwrites it. Looks like const was on the wrong side. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Also applied, thanks a lot! - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] PPPoE: miscellaneous smaller cleanups
From: Michal Ostrowski [EMAIL PROTECTED] Date: Tue, 13 Mar 2007 09:09:32 -0500 below is a patch that just removes dead code/initializers without any effect (first access is an assignment) that I stumbled accross while reading the source. Signed-off-by: Florian Zumbiehl [EMAIL PROTECTED] Acked-by: Michal Ostrowski [EMAIL PROTECTED] I munged this patch into net-2.6.22, 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/4] PPPOE: race between interface going down and connect()
From: Michal Ostrowski [EMAIL PROTECTED] Date: Tue, 13 Mar 2007 09:09:33 -0500 below you find a patch that (hopefully) fixes a race between an interface going down and a connect() to a peer on that interface. Before, connect() would determine that an interface is up, then the interface could go down and all entries referring to that interface in the item_hash_table would be marked as ZOMBIEs and their references to the device would be freed, and after that, connect() would put a new entry into the hash table referring to the device that meanwhile is down already - which also would cause unregister_netdevice() to wait until the socket has been release()d. This patch does not suffice if we are not allowed to accept connect()s referring to a device that we already acked a NETDEV_GOING_DOWN for (that is: all references are only guaranteed to be freed after NETDEV_DOWN has been acknowledged, not necessarily after the NETDEV_GOING_DOWN already). And if we are allowed to, we could avoid looking through the hash table upon NETDEV_GOING_DOWN completely and only do that once we get the NETDEV_DOWN ... mostrows: pppoe_flush_dev is called on NETDEV_GOING_DOWN and NETDEV_DOWN to deal with this late connect issue. Ideally one would hope to notify users at the NETDEV_GOING_DOWN phase (just to pretend to be nice). However, it is the NETDEV_DOWN scan that takes all the responsibility for ensuring nobody is hanging around at that time. Signed-off-by: Florian Zumbiehl [EMAIL PROTECTED] Acked-by: Michal Ostrowski [EMAIL PROTECTED] Applied to net-2.6.22, 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 3/4] PPPOE: memory leak when socket is release()d before PPPIOCGCHAN has been called on it
From: Michal Ostrowski [EMAIL PROTECTED] Date: Tue, 13 Mar 2007 09:09:34 -0500 below you find a patch that fixes a memory leak when a PPPoE socket is release()d after it has been connect()ed, but before the PPPIOCGCHAN ioctl ever has been called on it. This is somewhat of a security problem, too, since PPPoE sockets can be created by any user, so any user can easily allocate all the machine's RAM to non-swappable address space and thus DoS the system. Is there any specific reason for PPPoE sockets being available to any unprivileged process, BTW? After all, you need a packet socket for the discovery stage anyway, so it's unlikely that any unprivileged process will ever need to create a PPPoE socket, no? Allocating all session IDs for a known AC is a kind of DoS, too, after all - with Juniper ERXes, this is really easy, actually, since they don't ever assign session ids above 8000 ... Signed-off-by: Florian Zumbiehl [EMAIL PROTECTED] Acked-by: Michal Ostrowski [EMAIL PROTECTED] Applied to net-2.6.22 - 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 4/4] PPPOE: Fix device tear-down notification.
From: Michal Ostrowski [EMAIL PROTECTED] Date: Tue, 13 Mar 2007 09:09:35 -0500 pppoe_flush_dev() kicks all sockets bound to a device that is going down. In doing so, locks must be taken in the right order consistently (sock lock, followed by the pppoe_hash_lock). However, the scan process is based on us holding the sock lock. So, when something is found in the scan we must release the lock we're holding and grab the sock lock. This patch fixes race conditions between this code and pppoe_release(), both of which perform similar functions but would naturally prefer to grab locks in opposing orders. Both code paths are now going after these locks in a consistent manner. pppoe_hash_lock protects the contents of the pppox_sock objects that reside inside the hash. Thus, NULL'ing out the pppoe_dev field should be done under the protection of this lock. Signed-off-by: Michal Ostrowski [EMAIL PROTECTED] Aha, this one applies cleanly :-) But I had to edit out some trailing whitespace this patch added, please be mindful of this in the future, thanks! Adds trailing whitespace. diff:48: Adds trailing whitespace. diff:52: * hold the sock lock while doing any unbinding, Adds trailing whitespace. diff:53: * we need to release the lock we're holding. Adds trailing whitespace. diff:81: Adds trailing whitespace. diff:121: __delete_item(po-pppoe_pa.sid, warning: 5 lines add trailing whitespaces. - 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] Get rid of netdev_nit
From: Stephen Hemminger [EMAIL PROTECTED] Date: Tue, 13 Mar 2007 14:26:35 -0700 It isn't any faster to test a boolean global variable than do a simple check for empty list. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] I'll apply this, thanks Stephen. I think the history is that long ago we used to export netdev_nit and we didn't want to export the details of the list implementation too. - 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 4/4] PPPoE: race between interface going down and release()
Hi, This patch doesn't apply becuase in the actual pppoe.c code: [...] So I'm having trouble figuring out what tree you generated that patch against :-) Perhaps there was an earlier patch I missed or something. But I won't second guess and leave it to you to let me know what I should actually apply. That one was against my first try of a fix. So, either you apply that one first and then remove it again by applying that patch ;-) - or just ignore those four patches completely and apply [EMAIL PROTECTED] ff instead. Florian - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] TCP Illinois congestion control (rev3)
From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 4 Apr 2007 08:07:43 -0700 This is an implementation of TCP Illinois invented by Shao Liu at University of Illinois. It is a another variant of Reno which adapts the alpha and beta parameters based on RTT. The basic idea is to increase window less rapidly as delay approaches the maximum. See the papers and talks to get a more complete description. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] I've applied this to net-2.6.22, let me know if there are any follow-on bug fixes I need to add as well. 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 RFC] Clean up sk_buff walkers
From: Jean Delvare [EMAIL PROTECTED] Date: Wed, 4 Apr 2007 18:03:04 +0200 Hmm, no comment? The cleanup seems worth the effort, both for source code readability and binary size. It's still in my patch backlog do not worry :-) I will get to it eventually. - 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] Uninline tcp_done
From: Andi Kleen [EMAIL PROTECTED] Date: Thu, 5 Apr 2007 12:44:03 +0200 The function is quite big and has several call sites and nothing to collapse by compiler optimization on inlining. Besides it's nicer to read in a in .c file. Signed-off-by: Andi Kleen [EMAIL PROTECTED] Applied, thanks Andi. - 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] Eliminate some unnecessary gotos in tcp v4 hash handling
From: Andi Kleen [EMAIL PROTECTED] Date: Thu, 5 Apr 2007 12:48:44 +0200 The compiler eliminates them anyways and this makes the code easier to read and shorter. Signed-off-by: Andi Kleen [EMAIL PROTECTED] It depends upon who you ask :-) For someone trying to verify all code paths lead to foo and therefore release resources and drop locks it's always better to use a goto to some common unwind handler at the end of the function, regardless of what the compiler does with it. When you're doing such an audit, return statements in the middle of the function are red flags and make the audit more difficult. :-) But in these cases it's just straight returns and there are no resources to release so I'll apply this patch, 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] Eliminate some unnecessary gotos in tcp v4 hash handling
From: Andi Kleen [EMAIL PROTECTED] Date: Thu, 5 Apr 2007 12:48:44 +0200 The compiler eliminates them anyways and this makes the code easier to read and shorter. Signed-off-by: Andi Kleen [EMAIL PROTECTED] Actually I won't apply this patch, ever, -ENOCOMPILE. Andi, please spare me with these patches if you won't even bother trying to compile them. It doesn't matter how easy to read the code is if it doesn't build. :-/ I found this build failure just by reviewing your patch for correctness, I didn't even need to give it to the compiler to see that you left the cur = NULL; goto out; case in there yet removed the out label. Don't bother posting the fixed version, I'll ignore it. You just basically proved how pointless this patch is, and how little you yourself even care about it. - 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 4/4] PPPoE: race between interface going down and release()
From: Florian Zumbiehl [EMAIL PROTECTED] Date: Sat, 21 Apr 2007 01:44:05 +0200 This patch doesn't apply becuase in the actual pppoe.c code: [...] So I'm having trouble figuring out what tree you generated that patch against :-) Perhaps there was an earlier patch I missed or something. But I won't second guess and leave it to you to let me know what I should actually apply. That one was against my first try of a fix. So, either you apply that one first and then remove it again by applying that patch ;-) - or just ignore those four patches completely and apply [EMAIL PROTECTED] ff instead. I figured out what happened and put in the 4-patch set later in my backlog, thanks! - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] TCP Illinois congestion control (rev3)
On Fri, 20 Apr 2007 17:08:13 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 4 Apr 2007 08:07:43 -0700 This is an implementation of TCP Illinois invented by Shao Liu at University of Illinois. It is a another variant of Reno which adapts the alpha and beta parameters based on RTT. The basic idea is to increase window less rapidly as delay approaches the maximum. See the papers and talks to get a more complete description. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] I've applied this to net-2.6.22, let me know if there are any follow-on bug fixes I need to add as well. Thanks! I have a new version ready. - 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/7] [IrDA] af_irda: irda_recvmsg_stream cleanup
From: [EMAIL PROTECTED] Date: Thu, 19 Apr 2007 00:32:03 +0300 From: Olaf Kirch [EMAIL PROTECTED] This patch cleans up some code in irda_recvmsg_stream, replacing some homebrew code with prepare_to_wait/finish_wait, and by making the code honor sock_rcvtimeo. Signed-off-by: Olaf Kirch [EMAIL PROTECTED] Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Applied to net-2.6.22, 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/7] [IrDA] af_irda: Silence kernel message in irda_recvmsg_stream
From: [EMAIL PROTECTED] Date: Thu, 19 Apr 2007 00:32:04 +0300 From: Olaf Kirch [EMAIL PROTECTED] This patch silences an IRDA_ASSERT in irda_recvmsg_stream, as described in http://bugzilla.kernel.org/show_bug.cgi?id=7512 irda_disconnect_indication would set sk-sk_err to ECONNRESET, and a subsequent call to recvmsg would print an irritating kernel message and return -1. When a connected socket is closed by the peer, recvmsg should return 0 rather than an error. This patch fixes this. Signed-off-by: Olaf Kirch [EMAIL PROTECTED] Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] There were some conflicts in this one wrt. the sock_orphan() bug fix we put into mainline recently, but I did my best to resolve it when I applied this to net-2.6.22 You can have a look and verify things when I put up my net-2.6.2 tree later this evening. 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 3/7] [IrDA] af_irda: irda_accept cleanup
From: [EMAIL PROTECTED] Date: Thu, 19 Apr 2007 00:32:05 +0300 This patch removes a cut'n'paste copy of wait_event_interruptible from irda_accept. Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Acked-by: Olaf Kirch [EMAIL PROTECTED] Applied to net-2.6.22, 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 4/7] [IrDA] af_irda: IRDA_ASSERT cleanups
From: [EMAIL PROTECTED] Date: Thu, 19 Apr 2007 00:32:06 +0300 In af_irda.c, the multiple IRDA_ASSERT() are either hiding bugs, useless, or returning the wrong value. Let's clean that up. Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Applied to net-2.6.22, 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 5/7] [IrDA] IrDA monitor mode
From: [EMAIL PROTECTED] Date: Thu, 19 Apr 2007 00:32:07 +0300 Through a protocol specific ioctl, one can disable IrDA TX in order to monitor an IrDA link. Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] I'd really rather see IRDA use netlink instead of these wonky ioctls, but whatever, if you want to put this dirty into your stack and you're the maintainer I can't really stop you :-) Applied to net-2.6.22, 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 6/7] [IrDA] Adding carriage returns to mcs7780 debug statements
From: [EMAIL PROTECTED] Date: Thu, 19 Apr 2007 00:32:08 +0300 Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Applied to net-2.6.22, 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 7/7] [IrDA] Misc spelling corrections.
From: [EMAIL PROTECTED] Date: Thu, 19 Apr 2007 00:32:09 +0300 From: Guennadi Liakhovetski [EMAIL PROTECTED] Spelling corrections, from to to too. Signed-off-by: G. Liakhovetski [EMAIL PROTECTED] Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Also applied to net-2.6.22, thanks a lot. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix comments for register_netdev()
From: Borislav Petkov [EMAIL PROTECTED] Date: Wed, 18 Apr 2007 14:49:52 +0200 Correct the function name in the comments supplied with register_netdev() Signed-off-by: Borislav Petkov [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: [GIT PATCH] Exporting IPv6 statistics via netlink.
From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] Date: Thu, 19 Apr 2007 15:42:09 +0900 (JST) [IPV6] SNMP: Netlink interface. [IPV6] SNMP: Move some statistic bits to net/ipv6/proc.c. [IPV4] SNMP: Move some statistic bits to net/ipv4/proc.c. I applied these as patches to my net-2.6.22 tree. 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: [GIT PATCH] Exporting IPv6 statistics via netlink.
From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] Date: Thu, 19 Apr 2007 21:04:54 +0900 (JST) [IPV6] SNMP: Export statistics via netlink without CONFIG_PROC_FS. Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] I applied this to my net-2.6.22 tree, 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 net-2.6.22 1/3] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...)
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 decided to apply this to my net-2.6.22 tree, I'll deal with the tcp-2.6 merge conflicts as best as I can. - 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
