Re: [RFC] Multiple IPV6 Routing Tables Policy Routing
Hello. In article [EMAIL PROTECTED] (at Thu, 27 Jul 2006 00:11:00 +0200), Thomas Graf [EMAIL PROTECTED] says: It's not final but somewhat working, I'm eager to see comments or patches. I apologize if I've tramped onto anybody's foot by taking this up and submitting it, this isn't meant as an attempt to steal credits but rather to pick up good code and finally get it upstream after a very long while. First of all, Thank you for giving us good starting point. I am interested in this area because I have been spending several month for this release engineering. Well, as you stated, the code is based on the work of MIPL, which is being jointly developed by Helsinki University of Technology (HUT) and USAGI/WIDE Project. Please describe this on your commit logs. Please retain copyright information as well. Thank you very much. -- YOSHIFUJI Hideaki @ USAGI Project [EMAIL PROTECTED] GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA - 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/3] add netdev_alloc_skb
On Wed, Jul 26, 2006 at 03:24:51PM -0700, David Miller wrote: From: Christoph Hellwig [EMAIL PROTECTED] Date: Wed, 26 Jul 2006 13:31:36 +0200 + * %NULL is returned in there is no free memory. Although this function + * allocates memory it can be called from an interrupt. ... + * %NULL is returned in there is no free memory. Looks like a typo in both cases, I think you mean NULL is returned _if_ there not in there Yes, Joe Perches already pointed that out in private. This typo is copy and pasted from the dev_alloc_skb kerneldoc, so this patch fixes up all four occurances: Signed-off-by: Christoph Hellwig [EMAIL PROTECTED] Index: linux-2.6/include/linux/skbuff.h === --- linux-2.6.orig/include/linux/skbuff.h 2006-07-28 09:06:55.0 +0200 +++ linux-2.6/include/linux/skbuff.h2006-07-28 09:07:35.0 +0200 @@ -1076,7 +1076,7 @@ * the headroom they think they need without accounting for the * built in space. The built in space is used for optimisations. * - * %NULL is returned in there is no free memory. + * %NULL is returned if there is no free memory. */ static inline struct sk_buff *__dev_alloc_skb(unsigned int length, gfp_t gfp_mask) @@ -1096,7 +1096,7 @@ * the headroom they think they need without accounting for the * built in space. The built in space is used for optimisations. * - * %NULL is returned in there is no free memory. Although this function + * %NULL is returned if there is no free memory. Although this function * allocates memory it can be called from an interrupt. */ static inline struct sk_buff *dev_alloc_skb(unsigned int length) @@ -1117,7 +1117,7 @@ * the headroom they think they need without accounting for the * built in space. The built in space is used for optimisations. * - * %NULL is returned in there is no free memory. Although this function + * %NULL is returned if there is no free memory. Although this function * allocates memory it can be called from an interrupt. */ static inline struct sk_buff *netdev_alloc_skb(struct net_device *dev, Index: linux-2.6/net/core/skbuff.c === --- linux-2.6.orig/net/core/skbuff.c2006-07-28 09:06:51.0 +0200 +++ linux-2.6/net/core/skbuff.c 2006-07-28 09:07:26.0 +0200 @@ -267,7 +267,7 @@ * the headroom they think they need without accounting for the * built in space. The built in space is used for optimisations. * - * %NULL is returned in there is no free memory. + * %NULL is returned if there is no free memory. */ struct sk_buff *__netdev_alloc_skb(struct net_device *dev, unsigned int length, gfp_t gfp_mask) - 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: [3/4] kevent: AIO, aio_sendfile() implementation.
On Thu, 2006-07-27 at 08:28 -0700, Badari Pulavarty wrote: Sébastien Dugué wrote: On Wed, 2006-07-26 at 09:22 -0700, Badari Pulavarty wrote: Ulrich Drepper wrote: Christoph Hellwig wrote: My personal opinion on existing AIO is that it is not the right design. Benjamin LaHaise agree with me (if I understood him right), I completely agree with that aswell. I agree, too, but the current code is not the last of the line. Suparna has a st of patches which make the current kernel aio code work much better and especially make it really usable to implement POSIX AIO. In Ottawa we were talking about submitting it and Suparna will. We just thought about a little longer timeframe. I guess it could be accelerated since he mostly has the patch done. But I don't know her schedule. Important here is, don't base any decision on the current aio implementation. Ulrich, Suparna mentioned your interest in making POSIX glibc aio work with kernel-aio at OLS. We thought taking a re-look at the (kernel side) work BULL did, would be a nice starting point. I re-based those patches to 2.6.18-rc2 and sent it to Zach Brown for review before sending them out to list. These patches does NOT make AIO any cleaner. All they do is add functionality to support POSIX AIO easier. These are [ PATCH 1/3 ] Adding signal notification for event completion [ PATCH 2/3 ] lio (listio) completion semantics [ PATCH 3/3 ] cancel_fd support Badari, Thanks for refreshing those patches, they have been sitting here for quite some time now and collected dust. I also think Suparna's patchset for doing buffered AIO would be a real plus here. Suparna explained these in the following article: http://lwn.net/Articles/148755/ If you think, this is a reasonable direction/approach for the kernel and you would take care of glibc side of things - I can spend time on these patches, getting them to reasonable shape and push for inclusion. Ulrich, I you want to have a look at how those patches are put to use in libposix-aio, have a look at http://sourceforge.net/projects/paiol. It could be a starting point for glibc. Thanks, Sébastien. Sebastien, Suparna mentioned at Ulrich wants us to concentrate on kernel-side support, so that he can look at glibc side of things (along with other work he is already doing). So, if we can get an agreement on what kind of kernel support is needed - we can focus our efforts on kernel side first and leave glibc enablement to capable hands of Uli :) That's fine with me. Sébastien. -- - Sébastien DuguéBULL/FREC:B1-247 phone: (+33) 476 29 77 70 Bullcom: 229-7770 mailto:[EMAIL PROTECTED] Linux POSIX AIO: http://www.bullopensource.org/posix http://sourceforge.net/projects/paiol - - 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: [3/4] kevent: AIO, aio_sendfile() implementation.
On Thu, 2006-07-27 at 11:44 -0700, Ulrich Drepper wrote: Badari Pulavarty wrote: Before we spend too much time cleaning up and merging into mainline - I would like an agreement that what we add is good enough for glibc POSIX AIO. I haven't seen a description of the interface so far. Would be good if it existed. But I briefly mentioned one quirk in the interface about which Suparna wasn't sure whether it's implemented/implementable in the current interface. If a lio_listio call is made the individual requests are handle just as if they'd be issue separately. I.e., the notification specified in the individual aiocb is performed when the specific request is done. Then, once all requests are done, another notification is made, this time controlled by the sigevent parameter if lio_listio. Another feature which I always wanted: the current lio_listio call returns in blocking mode only if all requests are done. In non-blocking mode it returns immediately and the program needs to poll the aiocbs. What is needed is something in the middle. For instance, if multiple read requests are issued the program might be able to start working as soon as one request is satisfied. I.e., a call similar to lio_listio would be nice which also takes another parameter specifying how many of the NENT aiocbs have to finish before the call returns. You're right here, that definitely would be a plus. -- - Sébastien DuguéBULL/FREC:B1-247 phone: (+33) 476 29 77 70 Bullcom: 229-7770 mailto:[EMAIL PROTECTED] Linux POSIX AIO: http://www.bullopensource.org/posix http://sourceforge.net/projects/paiol - - 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: [3/4] kevent: AIO, aio_sendfile() implementation.
On Thu, 2006-07-27 at 14:02 -0700, Badari Pulavarty wrote: On Thu, 2006-07-27 at 11:44 -0700, Ulrich Drepper wrote: Badari Pulavarty wrote: Before we spend too much time cleaning up and merging into mainline - I would like an agreement that what we add is good enough for glibc POSIX AIO. I haven't seen a description of the interface so far. Would be good if it existed. But I briefly mentioned one quirk in the interface about which Suparna wasn't sure whether it's implemented/implementable in the current interface. Sebastien, could you provide a description of interfaces you are adding ? Since you did all the work, it would be appropriate for you to do it :) I will clean up what description I have and send it soon. Sébastien. -- - Sébastien DuguéBULL/FREC:B1-247 phone: (+33) 476 29 77 70 Bullcom: 229-7770 mailto:[EMAIL PROTECTED] Linux POSIX AIO: http://www.bullopensource.org/posix http://sourceforge.net/projects/paiol - - 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] NetLabel: documentation
From: [EMAIL PROTECTED] Date: Mon, 17 Jul 2006 11:52:25 -0400 +CIPSOv4 Variables: + +cipso_cache_enable - BOOLEAN ... +cipso_cache_bucket_size - INTEGER ... +cipso_rbm_optfmt - BOOLEAN ... +cipso_rbm_structvalid - BOOLEAN ... We need some more information for these entries. First, list the default value these sysctls will have. This is consistent with other entries in this file. If there is a compelling argument to support the default value, please mention it. Second, cipso_cache_bucket_size is still opaque, there is nothing in the description with describes the units this value is specified in, nor in fact what it really controls. Does it say how deep the hash chains of the hash table are allowed to grow to? Otherwise, what does it control and what are the consequences of using different values? - 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] NetLabel: core network changes
From: [EMAIL PROTECTED] Date: Mon, 17 Jul 2006 11:52:26 -0400 @@ -617,6 +618,8 @@ int inet_accept(struct socket *sock, str sock_graft(sk2, newsock); + netlbl_socket_inet_accept(sock, newsock); + newsock-state = SS_CONNECTED; err = 0; release_sock(sk2); This is only true wart I see in the patch set from my perspective. You have security_post_accept_hook(), which gets the parent and the child socket which is all the information you need, and it seems to be invoked at the correct location. So can you please hook into this location using the security level hook we already have? Just check sock-sk-sk_family is PF_INET at the top of that hook if you only want to handle ipv4 sockets, or something like that. Could this work? When preparing and argument stating why this won't work, please suggest a nicer name for this af_inet.c hook or some way to make it more generic and palatable to us. Thanks. - case 0x86: /* Another Commercial Security crap. */ + case IPOPT_CIPSO: I am sad to see this comment disappear :-) - 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] NetLabel: CIPSOv4 engine
From: [EMAIL PROTECTED] Date: Mon, 17 Jul 2006 11:52:27 -0400 + cipso_v4_cache[iter].lock = SPIN_LOCK_UNLOCKED; Please use: spin_lock_init(cipso_v4_cache[iter].lock); - 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] [IPV6] ADDRCONF: Lifetime handling fixes
From: Noriaki TAKAMIYA [EMAIL PROTECTED] Date: Thu, 27 Jul 2006 19:49:29 +0900 (JST) Thu, 27 Jul 2006 11:28:02 +0100 [Subject: Re: [RFC] [IPV6] ADDRCONF: Lifetime handling fixes] wrote... Hugo Santos [EMAIL PROTECTED] wrote... + ifp = ipv6_get_ifaddr(pfx, dev, 1); + if (ifp == NULL) + return -ENOENT; + + if (!valid_lft || (prefered_lft valid_lft)) + return -EINVAL; ^^^ Unreleased ifp? This test should go before ipv6_get_ifaddr. That's right. Thanks. Thank you Takamiya-san. Besides this correction, the rest of the changes look fine to me. I think we should get these fixes into 2.6.18, if you don't mind. So please resubmit with the correction. Thanks again. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sunlance: fix compilation on sparc-UP
From: Alexey Dobriyan [EMAIL PROTECTED] Date: Thu, 27 Jul 2006 13:35:20 +0400 Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] Applied, thanks Alexey. - 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] [IPV6] ADDRCONF: Lifetime handling fixes
In article [EMAIL PROTECTED] (at Fri, 28 Jul 2006 01:11:03 -0700 (PDT)), David Miller [EMAIL PROTECTED] says: Besides this correction, the rest of the changes look fine to me. I think we should get these fixes into 2.6.18, if you don't mind. So please resubmit with the correction. Okay. I'll do this soon. --yoshfuji - 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] Multiple IPV6 Routing Tables Policy Routing
From: YOSHIFUJI Hideaki [EMAIL PROTECTED] Date: Fri, 28 Jul 2006 15:10:09 +0900 (JST) Well, as you stated, the code is based on the work of MIPL, which is being jointly developed by Helsinki University of Technology (HUT) and USAGI/WIDE Project. Please describe this on your commit logs. Please retain copyright information as well. Ok. Thomas could you please respin the patches with: 1) Updated credits, based upon Yoshifuji's feedback 2) Fixes for the small issues Patrick pointer out in his review 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/3] add netdev_alloc_skb
From: Christoph Hellwig [EMAIL PROTECTED] Date: Fri, 28 Jul 2006 09:08:51 +0200 Yes, Joe Perches already pointed that out in private. This typo is copy and pasted from the dev_alloc_skb kerneldoc, so this patch fixes up all four occurances: Signed-off-by: Christoph Hellwig [EMAIL PROTECTED] Please respin your original patch with this fixup, thanks a lot Christoph. - 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: Netchannles: first stage has been completed. Further ideas.
From: Stephen Hemminger [EMAIL PROTECTED] Date: Thu, 27 Jul 2006 11:54:19 -0700 I think we sell our existing stack short. I agree. There are lots of opportunities left to look more closely at actual real performance bottlenecks and improve incrementally. But it requires, tools, time, faster net hardware, and some creative insight. I guess it just isn't as cool. We are in fact suggesting some ideas that address the current stack issues along the way. Witness the discussion we had about the tcp_ack() costs wrt. pruning the retransmit queue and tagging packets for SACK, I'm working on a new data structure and layout to cure all that stuff. But I think we can do better. Jamal said to me one email, If even only half of Van's numbers are real, this is really exciting. Rusty and Alexey are looking at the problem from another direction. Go back to the unified flow cache, implement all the hair to do that, and then we can look at netchannels because they will be so much more straight forward at that point. - 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/3] add netdev_alloc_skb
On Fri, Jul 28, 2006 at 01:24:24AM -0700, David Miller wrote: From: Christoph Hellwig [EMAIL PROTECTED] Date: Fri, 28 Jul 2006 09:08:51 +0200 Yes, Joe Perches already pointed that out in private. This typo is copy and pasted from the dev_alloc_skb kerneldoc, so this patch fixes up all four occurances: Signed-off-by: Christoph Hellwig [EMAIL PROTECTED] Please respin your original patch with this fixup, thanks a lot Christoph. We need a fixup patch for the existing wrong comments on dev_alloc_skb anyway - but if you prefer to respin the netdev_alloc_skb and have another patch to fixup the original comments I can do that aswell. - 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/3] add netdev_alloc_skb
From: Christoph Hellwig [EMAIL PROTECTED] Date: Fri, 28 Jul 2006 10:27:12 +0200 We need a fixup patch for the existing wrong comments on dev_alloc_skb anyway - but if you prefer to respin the netdev_alloc_skb and have another patch to fixup the original comments I can do that aswell. I intend to, for everyone's convenience, put the addition of netdev_alloc_skb() into 2.6.18. - 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: Regarding offloading IPv6 addrconf and ndisc
A couple of basic questions: 1. Can we just proceed assuming it is non-secure until a later time when the certificate path is established? This is not something which is described in the standard. In fact, processing the RA without a certificate path to the router already assumes the host is configured to so do (assuming unverified messages are treated as normal non-secure ones). Treating it as non-secure would allow an attacker to temporarily receive packets from the host if it has no secure router to be used (in the same or other interfaces). This may allow it to retrieve some of the user's info (think web-login portal) and it just has to be on-link (typical NDP attack). A solution would be not to assume it is non-secure, but instead cache or drop the RA and initiate the process to obtain a certificate path. This however does not allow the kind of behaviour that Dave described in one of is earlier e-mails, where packets are processed in order. Also, the host cache needs to hold X.509v3 certificates, and even if a lighter crypto-hash based check is available (if CGAs are used as well, to make sure the packets come from the packet's source address), hosts will end up having to perform RSA signature checks. 2. What if user process dies? or gets overwhelmed? One of the assumptions of the any well designed kernel is that the system should never hang because some user application died or waited for ever. Of course that this is a real problem. However, if the control daemon dies the kernel won't die. Depending on the implementation -- you might temporarily get out of addresses, if the addresses are flushed when the control daemon dies, etc. But, just like a routing daemon is critical to a router, this control application would also be critical to the host's connectivity. And if it dies, it needs to be restarted. The application might be itself complex, but in the end we moved this complexity away from the kernel. Hugo signature.asc Description: Digital signature
Re: 2.6.18-rc2-mm1
On 27/07/2006 8:56 p.m., Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/ - git-klibc has been dropped due to very bad parallel-make problems. - Added a new line to the boilerplate, below! - Added Sam's lxdialog tree, as git-lxdialog.patch. You no longer need x-ray spectacles to read the menuconfig screens. - Lots of random patches. Many of them are bugfixes and I shall, as usual, go through them all identifying 2.6.18 material. But I can miss things, so please don't be afraid to point 2.6.18 candidates out to me. I also have, as usual, a number of bugfixes agains the git trees. I'll send these to the maintainers until they stick and then I lose track of them. So don't be afraid to send reminders to the subsystem maintainers either. Still seeing breakage with the e1000/NAT. Now the problem isn't so much that the bug exists, but that unlike in -rc1-mm2, the trace scrolls over and over and over (with some variation down into it) until the kernel completely panics and the box has to be rebooted. http://www.ussg.iu.edu/hypermail/linux/kernel/0607.1/2689.html from Herbert Xu talks about the original problem. It's a regression from the previous -mm whereby the trace would print out just once. Starting Dovecot Imap: [ OK ] Starting clamd: [ OK ] Starting amavisd: BUG: warning at net/core/dev.c:1168/skb_checksum_help() Call Trace: [80269c65] show_trace+0xb5/0x324 [80269ee9] dump_stack+0x15/0x1c [8043d4e8] skb_checksum_help+0x63/0x13b [8802f35f] :iptable_nat:ip_nat_fn+0x5f/0x1d2 [8802f71b] :iptable_nat:ip_nat_local_fn+0x33/0xbc [80234c9e] nf_iterate+0x5a/0x9b [80258960] nf_hook_slow+0x60/0xcd [80235174] ip_queue_xmit+0x444/0x4c0 [8022157f] tcp_transmit_skb+0x68f/0x6cf [80233b67] __tcp_push_pending_frames+0x867/0x95a [8021b9fc] tcp_rcv_established+0x72c/0x7c4 [8023c60e] tcp_v4_do_rcv+0x2e/0x317 [8022719c] tcp_v4_rcv+0x9fc/0xa79 [80235389] ip_local_deliver+0x199/0x270 [802363c3] ip_rcv+0x4d3/0x52b [8021fdcb] netif_receive_skb+0x1eb/0x27b [803c9491] e1000_clean_rx_irq_ps+0x5c1/0x6a0 [803c7b45] e1000_clean+0x325/0x45b [8020c9b7] net_rx_action+0x8e/0x147 [80211663] __do_softirq+0x78/0x105 [80260716] call_softirq+0x1e/0x28 DWARF2 unwinder stuck at call_softirq+0x1e/0x28 Leftover inexact backtrace: IRQ [8026b679] do_softirq+0x39/0xa4 [802888b8] irq_exit+0x58/0x5a [8026b798] do_IRQ+0xb4/0xbe [8025f9a1] ret_from_intr+0x0/0xf EOI1Unable to handle kernel paging request at 8280 RIP: [80269e6f] show_trace+0x2bf/0x324 PGD 203027 PUD 205027 PMD 0 Oops: [1] SMP last sysfs file: /class/net/sit0/address CPU 0 Modules linked in: hidp rfcomm l2cap bluetooth ipv6 ip_gre iptable_filter iptable_nat ip_nat ip_conntrack nfnetlink iptable_mangle ip_tables binfmt_misc iTCO_wdt i2c_i801 serio_raw Pid: 2127, comm: imap Not tainted 2.6.18-rc2-mm1 #1 RIP: 0010:[80269e6f] [80269e6f] show_trace+0x2bf/0x324 RSP: :806366f0 EFLAGS: 00010206 RAX: RBX: RCX: 0004 RDX: 0010 RSI: 81003d95c840 RDI: 81003d95c140 RBP: 806367f0 R08: 0001 R09: 0001 R10: 0002 R11: 0001 R12: 8279 R13: R14: R15: 80907000 FS: 2ab5ab544860() GS:808b2000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 8280 CR3: 29dea000 CR4: 06e0 Process imap (pid: 2127, threadinfo 810029e62000, task 81003d95c140) Stack: 806cec48 80636fc0 0001 81002c9d78f8 7f571020 810029e63f58 80636f80 0046 Call Trace: [80269ee9] dump_stack+0x15/0x1c [8043d4e8] skb_checksum_help+0x63/0x13b [8802f35f] :iptable_nat:ip_nat_fn+0x5f/0x1d2 [8802f71b] :iptable_nat:ip_nat_local_fn+0x33/0xbc [80234c9e] nf_iterate+0x5a/0x9b [80258960] nf_hook_slow+0x60/0xcd [80235174] ip_queue_xmit+0x444/0x4c0 [8022157f] tcp_transmit_skb+0x68f/0x6cf [80233b67] __tcp_push_pending_frames+0x867/0x95a [8021b9fc] tcp_rcv_established+0x72c/0x7c4 [8023c60e] tcp_v4_do_rcv+0x2e/0x317 [8022719c] tcp_v4_rcv+0x9fc/0xa79 [80235389] ip_local_deliver+0x199/0x270 [802363c3] ip_rcv+0x4d3/0x52b [8021fdcb] netif_receive_skb+0x1eb/0x27b [803c9491] e1000_clean_rx_irq_ps+0x5c1/0x6a0 [803c7b45] e1000_clean+0x325/0x45b [8020c9b7] net_rx_action+0x8e/0x147 [80211663] __do_softirq+0x78/0x105 [80260716]
Re: [PATCHv2 2.6.18-rc1-mm2 1/3] net: UDP-Lite generic support
Hi David, thank you very much for taking time to revise the code and for the detailed comments. | The amount of code duplication is absolutely enormous and | totally unnecessary. You are right. So far I thought it better to keep UDP and UDP-Lite separate but an intelligent code integration does seem the better way. snip | It's mostly clerical work, but it will mean that we will have one | copy of all this code and as a result we won't even need a config | option for UDP-Lite. I will start with the v4-side and post a small RFC patch to see whether I got the concepts right. (Due to vacation, this will not before mid/end of August.) Best regards Gerrit - 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: [PATCHv2 2.6.18-rc1-mm2 1/3] net: UDP-Lite generic support
From: Gerrit Renker [EMAIL PROTECTED] Date: Fri, 28 Jul 2006 09:19:55 +0100 I will start with the v4-side and post a small RFC patch to see whether I got the concepts right. (Due to vacation, this will not before mid/end of August.) Ok, I look forward to reviewing 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 1/3] add netdev_alloc_skb
On Fri, Jul 28, 2006 at 01:28:32AM -0700, David Miller wrote:
From: Christoph Hellwig [EMAIL PROTECTED]
Date: Fri, 28 Jul 2006 10:27:12 +0200
We need a fixup patch for the existing wrong comments on dev_alloc_skb
anyway - but if you prefer to respin the netdev_alloc_skb and have
another patch to fixup the original comments I can do that aswell.
I intend to, for everyone's convenience, put the addition of
netdev_alloc_skb() into 2.6.18.
Here is the requested fixed up version:
Index: linux-2.6/include/linux/skbuff.h
===
--- linux-2.6.orig/include/linux/skbuff.h 2006-07-26 13:27:07.0
+0200
+++ linux-2.6/include/linux/skbuff.h2006-07-28 10:41:00.0 +0200
@@ -1104,6 +1104,28 @@
return __dev_alloc_skb(length, GFP_ATOMIC);
}
+extern struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
+ unsigned int length, gfp_t gfp_mask);
+
+/**
+ * netdev_alloc_skb - allocate an skbuff for rx on a specific device
+ * @dev: network device to receive on
+ * @length: length to allocate
+ *
+ * Allocate a new sk_buff and assign it a usage count of one. The
+ * buffer has unspecified headroom built in. Users should allocate
+ * the headroom they think they need without accounting for the
+ * built in space. The built in space is used for optimisations.
+ *
+ * %NULL is returned if there is no free memory. Although this function
+ * allocates memory it can be called from an interrupt.
+ */
+static inline struct sk_buff *netdev_alloc_skb(struct net_device *dev,
+ unsigned int length)
+{
+ return __netdev_alloc_skb(dev, length, GFP_ATOMIC);
+}
+
/**
* skb_cow - copy header of skb when it is required
* @skb: buffer to cow
Index: linux-2.6/net/core/skbuff.c
===
--- linux-2.6.orig/net/core/skbuff.c2006-07-26 13:27:07.0 +0200
+++ linux-2.6/net/core/skbuff.c 2006-07-28 10:41:09.0 +0200
@@ -256,6 +256,29 @@
goto out;
}
+/**
+ * __netdev_alloc_skb - allocate an skbuff for rx on a specific device
+ * @dev: network device to receive on
+ * @length: length to allocate
+ * @gfp_mask: get_free_pages mask, passed to alloc_skb
+ *
+ * Allocate a new sk_buff and assign it a usage count of one. The
+ * buffer has unspecified headroom built in. Users should allocate
+ * the headroom they think they need without accounting for the
+ * built in space. The built in space is used for optimisations.
+ *
+ * %NULL is returned if there is no free memory.
+ */
+struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
+ unsigned int length, gfp_t gfp_mask)
+{
+ struct sk_buff *skb;
+
+ skb = alloc_skb(length + NET_SKB_PAD, gfp_mask);
+ if (likely(skb))
+ skb_reserve(skb, NET_SKB_PAD);
+ return skb;
+}
static void skb_drop_list(struct sk_buff **listp)
{
@@ -2042,6 +2065,7 @@
EXPORT_SYMBOL(kfree_skb);
EXPORT_SYMBOL(__pskb_pull_tail);
EXPORT_SYMBOL(__alloc_skb);
+EXPORT_SYMBOL(__netdev_alloc_skb);
EXPORT_SYMBOL(pskb_copy);
EXPORT_SYMBOL(pskb_expand_head);
EXPORT_SYMBOL(skb_checksum);
-
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] [IPV6] ADDRCONF: Lifetime handling fixes
In article [EMAIL PROTECTED] (at Fri, 28 Jul 2006 17:18:18 +0900 (JST)),
YOSHIFUJI Hideaki [EMAIL PROTECTED] says:
In article [EMAIL PROTECTED] (at Fri, 28 Jul 2006 01:11:03 -0700 (PDT)),
David Miller [EMAIL PROTECTED] says:
Besides this correction, the rest of the changes look fine to me.
I think we should get these fixes into 2.6.18, if you don't mind.
So please resubmit with the correction.
Okay. I'll do this soon.
Here it is.
Changesets, on top of 2.6.18-rc2, are available on
branch addr-lifetime-20060728b at:
git://git.skbuff.net/gitroot/yoshfuji/linux-2.6.18-rc2-addr-lifetime
Regards,
HEADLINES
-
[IPV6] ADDRCONF: Check payload length for IFA_LOCAL attribute in
RTM_{ADD,DEL}MSG message
[IPV6] ADDRCONF: Allow user-space to specify address lifetime
[IPV6] ADDRCONF: Do not verify an address with infinity lifetime
[IPV6] ADDRCONF: Support get operation of single address
[IPV6] ADDRCONF: NLM_F_REPLACE support for RTM_NEWADDR
DIFFSTAT
net/ipv6/addrconf.c | 174 +--
1 files changed, 166 insertions(+), 8 deletions(-)
CHANGESETS
--
commit 27fb40230b30534bdc08736d64cab179038591bc
Author: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Date: Fri Jul 28 18:12:09 2006 +0900
[IPV6] ADDRCONF: Check payload length for IFA_LOCAL attribute in
RTM_{ADD,DEL}MSG message
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2316a43..81702b9 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2853,7 +2853,8 @@ inet6_rtm_deladdr(struct sk_buff *skb, s
pfx = RTA_DATA(rta[IFA_ADDRESS-1]);
}
if (rta[IFA_LOCAL-1]) {
- if (pfx memcmp(pfx, RTA_DATA(rta[IFA_LOCAL-1]),
sizeof(*pfx)))
+ if (RTA_PAYLOAD(rta[IFA_LOCAL-1]) sizeof(*pfx) ||
+ (pfx memcmp(pfx, RTA_DATA(rta[IFA_LOCAL-1]),
sizeof(*pfx
return -EINVAL;
pfx = RTA_DATA(rta[IFA_LOCAL-1]);
}
@@ -2877,7 +2878,8 @@ inet6_rtm_newaddr(struct sk_buff *skb, s
pfx = RTA_DATA(rta[IFA_ADDRESS-1]);
}
if (rta[IFA_LOCAL-1]) {
- if (pfx memcmp(pfx, RTA_DATA(rta[IFA_LOCAL-1]),
sizeof(*pfx)))
+ if (RTA_PAYLOAD(rta[IFA_LOCAL-1]) sizeof(*pfx) ||
+ (pfx memcmp(pfx, RTA_DATA(rta[IFA_LOCAL-1]),
sizeof(*pfx
return -EINVAL;
pfx = RTA_DATA(rta[IFA_LOCAL-1]);
}
---
commit 336f472519a05ea493c5ad24de2c39e2c80003a0
Author: Noriaki TAKAMIYA [EMAIL PROTECTED]
Date: Fri Jul 28 18:12:10 2006 +0900
[IPV6] ADDRCONF: Allow user-space to specify address lifetime
Based on MIPL2 kernel patch.
Signed-off-by: Noriaki TAKAMIYA [EMAIL PROTECTED]
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 81702b9..c064188 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1869,15 +1869,21 @@ err_exit:
/*
* Manual configuration of address on an interface
*/
-static int inet6_addr_add(int ifindex, struct in6_addr *pfx, int plen)
+static int inet6_addr_add(int ifindex, struct in6_addr *pfx, int plen,
+ __u32 prefered_lft, __u32 valid_lft)
{
struct inet6_ifaddr *ifp;
struct inet6_dev *idev;
struct net_device *dev;
+ __u8 ifa_flags = 0;
int scope;
ASSERT_RTNL();
+ /* check the lifetime */
+ if (!valid_lft || prefered_lft valid_lft)
+ return -EINVAL;
+
if ((dev = __dev_get_by_index(ifindex)) == NULL)
return -ENODEV;
@@ -1889,10 +1895,29 @@ static int inet6_addr_add(int ifindex, s
scope = ipv6_addr_scope(pfx);
- ifp = ipv6_add_addr(idev, pfx, plen, scope, IFA_F_PERMANENT);
+ if (valid_lft == INFINITY_LIFE_TIME)
+ ifa_flags |= IFA_F_PERMANENT;
+ else if (valid_lft = 0x7FFF/HZ)
+ valid_lft = 0x7FFF/HZ;
+
+ if (prefered_lft == 0)
+ ifa_flags |= IFA_F_DEPRECATED;
+ else if ((prefered_lft = 0x7FFF/HZ)
+(prefered_lft != INFINITY_LIFE_TIME))
+ prefered_lft = 0x7FFF/HZ;
+
+ ifp = ipv6_add_addr(idev, pfx, plen, scope, ifa_flags);
+
if (!IS_ERR(ifp)) {
+ spin_lock(ifp-lock);
+ ifp-valid_lft = valid_lft;
+ ifp-prefered_lft = prefered_lft;
+ ifp-tstamp = jiffies;
+ spin_unlock(ifp-lock);
+
addrconf_dad_start(ifp, 0);
in6_ifa_put(ifp);
+ addrconf_verify(0);
return 0;
}
@@ -1945,7 +1970,8 @@ int addrconf_add_ifaddr(void __user *arg
return -EFAULT;
rtnl_lock();
- err = inet6_addr_add(ireq.ifr6_ifindex, ireq.ifr6_addr,
Re: [RESEND 3/5] [NET]: Protocol Independant Policy Routing Rules Framework
On Fri, 2006-07-28 at 00:58 +0200, Patrick McHardy wrote:
+int fib_rules_lookup(struct fib_rules_ops *ops, struct flowi *fl,
+int flags, struct fib_lookup_arg *arg)
+{
+ struct fib_rule *rule;
+ int err;
+
+ rcu_read_lock();
+
+ list_for_each_entry(rule, ops-rules_list, list) {
Shouldn't that be list_for_each_entry_rcu?
Yes that's correct, it should.
+ if (rule-ifname[0] (rule-ifindex != fl-iif))
+ continue;
+
+ if (!ops-match(rule, fl, flags))
+ continue;
+
+ rcu_read_unlock();
+
+ err = ops-action(rule, fl, flags, arg);
+ if (err != -EAGAIN) {
+ fib_rule_get(rule);
+ arg-rule = rule;
+ goto out;
+ }
+ }
+
+ err = -ENETUNREACH;
+out:
+ rcu_read_unlock();
rcu_read_unlock might get called multiple times in the list iteration
and once again here.
Yes, the rcu_read_unlock() in the list iteration is misplaced, it
shouldn't be there. Besides the unbalanced lock/unlocks it suffers from
the general issue described below
As a somewhat related note, I've just digged a bit through RCU land,
talked to dipankar and mckenney, and discovered that rcu_read_lock() /
rcu_read_unlock() aren't strictly needed in softirqs since preempt is
already disabled in softirqs. This means that you can use the result of
the rcu read-side critical outside of the rcu_read_lock() /
rcu_read_unlock() section. BUT this changes with the -rt kernel where
softirqs are preemptable and where rcu_read_lock() / rcu_read_unlock()
doesn't disable/enable preempt anymore, which means the rcu read-side
critical section is also preemptable. This means that we can get
preempted in the read-side critical section but the resulting grace
period won't occur until rcu_read_unlock() is called, which means that
using results of an read-side critical section outside of the critical
section is just not going to work in softirqs in -rt kernels.
I'm sure Ingo has reviewed the RCU usage in softirqs but I don't know if
there's been any changes in this area after his review.
--
/Martin
signature.asc
Description: This is a digitally signed message part
PATCH Fix bonding active-backup behavior for VLAN interfaces
diff -rU3 linux-2.6.17.7/net/core/dev.c linux-2.6.17.7-wapper/net/core/dev.c
--- linux-2.6.17.7/net/core/dev.c 2006-07-25 05:36:01.0 +0200
+++ linux-2.6.17.7-wapper/net/core/dev.c2006-07-27 20:16:36.0
+0200
@@ -88,6 +88,7 @@
#include linux/sockios.h
#include linux/errno.h
#include linux/interrupt.h
+#include linux/if_bonding.h
#include linux/if_ether.h
#include linux/netdevice.h
#include linux/etherdevice.h
@@ -1518,37 +1519,6 @@
EXPORT_SYMBOL(netif_rx_ni);
-static inline struct net_device *skb_bond(struct sk_buff *skb)
-{
- struct net_device *dev = skb-dev;
-
- if (dev-master) {
- /*
-* On bonding slaves other than the currently active
-* slave, suppress duplicates except for 802.3ad
-* ETH_P_SLOW and alb non-mcast/bcast.
-*/
- if (dev-priv_flags IFF_SLAVE_INACTIVE) {
- if (dev-master-priv_flags IFF_MASTER_ALB) {
- if (skb-pkt_type != PACKET_BROADCAST
- skb-pkt_type != PACKET_MULTICAST)
- goto keep;
- }
-
- if (dev-master-priv_flags IFF_MASTER_8023AD
- skb-protocol == __constant_htons(ETH_P_SLOW))
- goto keep;
-
- kfree_skb(skb);
- return NULL;
- }
-keep:
- skb-dev = dev-master;
- }
-
- return dev;
-}
-
static void net_tx_action(struct softirq_action *h)
{
struct softnet_data *sd = __get_cpu_var(softnet_data);
--
---
Christophe Devriese EURiD
Network Adminstrator / Developer
[EMAIL PROTECTED]
http://www.eth1.org --
-
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: Hello, We have IP100A Linux driver need to submit to 2.6.x kernel
On Fri, 2006-07-28 at 09:55 +0800, Jesse Huang wrote: Hi Francois: Sorry, I don't know this patch before. IP100A is a new version of IP100 (sundance.c). I don't know what is you suggestion of IP100A driver? Should I... 1. Only updata sundance.c to support IP100A 2. Release ip100a.c which support ip100(sundance) to kernel 2.6.x and ask to remove sundance.c. 3. Release ip100a.c with sundance.c both to kernel 2.6.x We hope to use IP100a.c as our product driver, so 2. and 3. will better for IC Plus. But we will still follow your suggestion, if you feel 1. was better for kernel. Hello, in general the policy for Linux is that if adding support for a new device is only minor changes to an existing driver, it is better to update this existing driver with those changes. The reason for that is that this makes it possible to share bugfixes and testing between both devices. Now there is a point where it no longer makes sense to share, for example when the devices are really very, very different. Greetings, Arjan van de Ven - 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
r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
Hi! We're currently working on getting the Thecus n2100 supported in 2.6. http://www.thecus.com/products_over.php?cid=1pid=1 Amongst other nice goodies, it has two on-board RTL8110SB gigabit controllers. The realtek-supplied 'r1000' driver kind of sort of works, if you don't mind the machine hanging or crashing if you unplug the cable at the wrong moment. The in-kernel 'r8169' drivers in 2.6.17 and 2.6.18-rc2 appear to work initially, but they don't actually seem to transmit any packets on the wire, nor do they receive any. Boot logs from 2.6.17 and 2.6.18-rc2 attached. Apart from the MAC address for eth1 being incorrect (boot loader bug, being worked on) there don't seem to be any strange messages or errors. It doesn't seem to be a PHY configuration issue -- with a custom program to dump the MDIO registers (is there any reason r8169 doesn't support mii-tool, by the way? will you take a patch to add that?), we get the following results, with only minor differences that shouldn't be causing this issue: r1000 1000 796d 001c c913 0de1 45e1 0007 2001 0008 45e1 0300 1007 f880 3000 0010 0060 6c00 2d40 0060 0400 2108 0018 2740 8c00 0040 0162 846c 0123 r8169 1000 796d 001c c913 0de1 45e1 0007 2001 0008 45e1 0200 1007 f880 3000 0010 0060 6c00 2c40 0060 0400 2108 0018 2740 8c00 0040 0162 846c 0123 Just wondering if you've seen this kind of behavior before before I dig into it further? I'm pretty sure the hardware is okay, since r1000 works, and the on-board SATA and UHCI/EHCI USB work fine as well. cheers, Lennert 2.6.18-rc2, r8169 = Using base address 0x00218000 and length 0x0017e3a8 Uncompressing Linux. Linux version 2.6.18-rc2 ([EMAIL PROTECTED]) (gcc version 4.0.1) #6 We6 CPU: XScale-80219 [69052e30] revision 0 (ARMv5TE), cr=397f Machine: Thecus N2100 Memory policy: ECC disabled, Data cache writeback CPU0: D VIVT undefined 5 cache CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets Built 1 zonelists. Total pages: 32768 Kernel command line: console=ttyS0,115200 root=/dev/nfs ip=bootp mem=128M PID hash table entries: 1024 (order: 10, 4096 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 128MB = 128MB total Memory: 126592KB available (2681K code, 459K data, 104K init) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 PCI: bus0: Fast back to back transfers disabled SCSI subsystem initialized NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 4096 bind 2048) TCP reno registered NetWinder Floating Point Emulator V0.97 (double precision) Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc. SGI XFS with ACLs, security attributes, no debug enabled io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0xfe80 (irq = 0) is a 16550A RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize Intel(R) PRO/1000 Network Driver - version 7.1.9-k2-NAPI Copyright (c) 1999-2006 Intel Corporation. e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation r8169 Gigabit Ethernet driver 2.2LK loaded eth0: RTL8169 at 0xc8850200, 00:14:fd:10:27:72, IRQ 27 r8169 Gigabit Ethernet driver 2.2LK loaded eth1: RTL8169 at 0xc8852300, 00:14:fd:10:00:00, IRQ 28 physmap platform flash device: 0100 at f000 physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x0031 Using buffer write method cfi_cmdset_0001: Erase suspend on write enabled cmdlinepart partition parsing not available Searching for RedBoot partition table in physmap-flash.0 at offset 0xfe 6 RedBoot partitions found on MTD device physmap-flash.0 Creating 6 MTD partitions on physmap-flash.0: 0x-0x0004 : RedBoot 0x0004-0x00d4 : ramdisk 0x00d4-0x00ea : kernel 0x00ea-0x00fc : user 0x00fc-0x00fc1000 : RedBoot config 0x00fe-0x0100 : FIS directory mice: PS/2 mouse device common for all mice i2c /dev entries driver md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: bitmap version 4.39 device-mapper: ioctl: 4.7.0-ioctl (2006-06-24)
Re: [RESEND 3/5] [NET]: Protocol Independant Policy Routing Rules Framework
* Patrick McHardy [EMAIL PROTECTED] 2006-07-28 01:30
+int fib_rules_lookup(struct fib_rules_ops *ops, struct flowi *fl,
+int flags, struct fib_lookup_arg *arg)
+{
+ struct fib_rule *rule;
+ int err;
+
+ rcu_read_lock();
+
+ list_for_each_entry(rule, ops-rules_list, list) {
+ if (rule-ifname[0] (rule-ifindex != fl-iif))
+ continue;
ifindex may be unset even if ifname is set (in case the interface
does not exist yet). In that case it will match falsely on
locally generated packets.
Then rule-ifindex would be -1 and it shouldn't match but I
changed it, it makes more sense.
+static void notify_rule_change(int event, struct fib_rule *rule,
+ struct fib_rules_ops *ops)
+{
+ int size = nlmsg_total_size(sizeof(struct fib_rule_hdr) + 128);
+ struct sk_buff *skb = alloc_skb(size, GFP_KERNEL);
+
+ if (skb == NULL)
+ netlink_set_err(rtnl, 0, RTNLGRP_IPV4_RULE, ENOBUFS);
+ else if (fib_nl_fill_rule(skb, rule, 0, 0, event, 0, ops) 0) {
+ kfree_skb(skb);
+ netlink_set_err(rtnl, 0, RTNLGRP_IPV4_RULE, EINVAL);
+ } else
+ netlink_broadcast(rtnl, skb, 0, RTNLGRP_IPV4_RULE, GFP_KERNEL);
+}
Shouldn't different families use different groups? Userspace
might (rightfully, I think) expect not to see anything but
IPv4 rules on RTNLGRP_IPV4_RULE.
Right, I've added ops-nlgroup to fix this. Naturally I also
fixed all the other issues you brought up, I have the feeling
that there are more bugs, will look at the code again with
some distance in a few days.
-
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] Multiple IPV6 Routing Tables Policy Routing
* YOSHIFUJI Hideaki / ?$B5HF#1QL@ [EMAIL PROTECTED] 2006-07-28 15:10 Well, as you stated, the code is based on the work of MIPL, which is being jointly developed by Helsinki University of Technology (HUT) and USAGI/WIDE Project. Please describe this on your commit logs. Please retain copyright information as well. Please tell me which copyright I missed? - 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
FACK and CWND
Hi there, A question related to TCP-FACK, which is a default in Linux: In FACK, the holes between SACK blocks are considered as loss. To a sender, when SACK comes in, loss_out would be non-zero. According to linux-2.6.17.7/net/ipv4/tcp_input.c, function tcp_time_to_recover(), this non-zero loss_out will send the sender into Recovery state, in which, CWND could be reduced. In one word, it seems that, FACK would allow SACK holes to reduce CWND. However, in the paper Congestion Control in Linux TCP, Section 3, subsection Recovery, it says that Recovery state is triggered by sufficient amount of successive duplicate ACK, to my understand, that means 3-dup. And in Section 3, subsection Disorder, it is also mentioned, SACK cause the sender move into this state. Therefore, I suppose it means SACK holes won't reduce CWND, they merely trigger fast_retrans and fast_recover. Even in the net/ipv4/tcp_input.c file, in the large block of comment right above the function tcp_time_to_recover(), it is also mentioned, CWND should only changed by claasic VJ rules, which again means, CWND should only changes to 3-dup (or timeout). So, which is correct? The implementation, or the document? Or most probabally, am I wrong somewhere? Thank you guys! malin - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
Lennert Buytenhek [EMAIL PROTECTED] : [...] We're currently working on getting the Thecus n2100 supported in 2.6. http://www.thecus.com/products_over.php?cid=1pid=1 I should really write some wish-list one day... Amongst other nice goodies, it has two on-board RTL8110SB gigabit controllers. The realtek-supplied 'r1000' driver kind of sort of works, Ok. That's good to know. The in-kernel 'r8169' drivers in 2.6.17 and 2.6.18-rc2 appear to work initially, but they don't actually seem to transmit any packets on the wire, nor do they receive any. Boot logs from 2.6.17 and 2.6.18-rc2 attached. Apart from the MAC address for eth1 being incorrect (boot loader bug, being worked on) there don't seem to be any strange messages or errors. Can you send: - the output of 'lspci -vvx' - the content of /proc/interrupts - an ethtool dump of the registers. I don't know if Realtek's driver support but it can help even the in-kernel driver It doesn't seem to be a PHY configuration issue -- with a custom program to dump the MDIO registers (is there any reason r8169 doesn't support mii-tool, by the way? will you take a patch to add that?), we get the I had written it once, with some rework of the mii functions in the driver. It was hit by conflicts generated by various changes as well as higher priority bugs/features requests. You can send your code or I can resurrect it at your option. [...] Just wondering if you've seen this kind of behavior before before I dig into it further? I'm pretty sure the hardware is okay, since r1000 works, and the on-board SATA and UHCI/EHCI USB work fine as well. I have had a few success reports with the 8110 (and failures too, see http://bugzilla.kernel.org/show_bug.cgi?id=5284) but I have not received reports for this behavior lately. Complete lack of Rx/Tx activity have been observed due to some irq problems. It does not seem to be the issue here. -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Create IP100A Driver
Jesse Huang wrote: Hi John: I will try mutt or mail when i want to send next patch. Most different of ip100a.c and sundance.c are almost same only fix some bugs. The different of ip100a and ip100 is in phy. We can use one driver to support those two device, I want to know what is better for kernel: 1. Only updata sundance.c to support IP100A 2. Release ip100a.c which support ip100(sundance) to kernel 2.6.x and ask to remove sundance.c. 3. Release ip100a.c with sundance.c both to kernel 2.6.x We hope to use IP100a.c as our product driver, so 2. and 3. will better for IC Plus. But we will still follow your suggestion, if you feel 1. was better for kernel. Although it is occasionally OK to duplicate a driver, I do not see a compelling case with ip100a. The stronger case for a single codebase is won on the strengths of lower long-term maintenance costs, increased strength of review, doesn't break existing sundance driver uses, and re-use of existing testing benefits. If you feel strongly about not showing sundance to your users, you can always submit a one-line MODULE_ALIAS() change which permits users to load ip100a (really sundance.c). Using MODULE_ALIAS() seems quite reasonable, given that IC Plus appears to be taking the lead in future Sundance-like chip development. So, please resubmit as changes to the existing sundance.c. This is better for the standard Linux kernel engineering process. Thanks, 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: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
On Fri, Jul 28, 2006 at 12:49:46PM +0200, Francois Romieu wrote: The in-kernel 'r8169' drivers in 2.6.17 and 2.6.18-rc2 appear to work initially, but they don't actually seem to transmit any packets on the wire, nor do they receive any. Boot logs from 2.6.17 and 2.6.18-rc2 attached. Apart from the MAC address for eth1 being incorrect (boot loader bug, being worked on) there don't seem to be any strange messages or errors. Can you send: - the output of 'lspci -vvx' :00:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR+ PERR+ Latency: 0 (1000ns min, 250ns max), Cache Line Size: 0x08 (32 bytes) Interrupt: pin A routed to IRQ 27 Region 0: I/O ports at fe00 [size=256] Region 1: Memory at 800a0200 (32-bit, non-prefetchable) [size=256] Expansion ROM at 8008 [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] Vital Product Data 00: ec 10 69 81 47 01 30 c2 10 00 00 02 08 00 00 00 10: 01 00 00 90 00 02 0a 40 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 69 81 30: 00 00 fc dd dc 00 00 00 00 00 00 00 1b 01 04 01 :00:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 (1000ns min, 250ns max), Cache Line Size: 0x08 (32 bytes) Interrupt: pin A routed to IRQ 28 Region 0: I/O ports at fe000400 [size=256] Region 1: Memory at 800a0300 (32-bit, non-prefetchable) [size=256] Expansion ROM at 8009 [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] Vital Product Data 00: ec 10 69 81 47 01 38 02 10 00 00 02 08 00 00 00 10: 01 04 00 90 00 03 0a 40 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 69 81 30: 00 00 98 56 dc 00 00 00 00 00 00 00 1c 01 04 01 :00:03.0 Unknown mass storage controller: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3512 [SATALink/SATARaid] Serial ATA Controller (rev 01) Subsystem: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3512 [SATALink/SATARaid] Serial ATA Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0, Cache Line Size: 0x08 (32 bytes) Interrupt: pin A routed to IRQ 29 Region 0: I/O ports at fe000850 [size=8] Region 1: I/O ports at fe000860 [size=4] Region 2: I/O ports at fe000858 [size=8] Region 3: I/O ports at fe000864 [size=4] Region 4: I/O ports at fe000840 [size=16] Region 5: Memory at 800a (32-bit, non-prefetchable) [size=512] Expansion ROM at 8000 [disabled] [size=512K] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=2 PME- 00: 95 10 12 35 47 01 b0 02 01 00 80 01 08 00 00 00 10: 51 08 00 90 61 08 00 90 59 08 00 90 65 08 00 90 20: 41 08 00 90 00 00 0a 40 00 00 00 00 95 10 12 35 30: 00 00 00 00 60 00 00 00 00 00 00 00 1d 01 00 00 :00:04.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 61) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 22, Cache Line Size: 0x08 (32 bytes) Interrupt: pin A routed to IRQ 28 Region 4: I/O ports at fe000800 [size=32] Capabilities: [80] Power Management version 2 Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 06 11 38 30 47 01 10 02 61 00 03 0c 08 16 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Re: [PATCH] SNMPv2 tcpAttemptFails counter error
I have changed my patch with your advice and it looks more effective.
On Monday 24 July 2006 17:22, David Miller wrote:
From: Wei Yongjun [EMAIL PROTECTED]
Date: Wed, 05 Jul 2006 05:19:54 -0400
In my test, those direct state transition can not be counted to
tcpAttemptFails. Following is my patch:
Signed-off-by: Wei Yongjun [EMAIL PROTECTED]
This change can be implemented more simply, I believe.
Except for the tcp_minisocks.c change, all the paths
changed go to tcp_done() which is what actually transfers
the state to TCP_CLOSE. Therefore, tcp_done() can
simply be modified to check if the current state is
TCP_SYN_RECV, and is so bump the counter.
Once you implement it this way, please audit all call paths
to make sure we don't now bump this counter twice.
Signed-off-by: Wei Yongjun [EMAIL PROTECTED]
--- a/include/net/tcp.h 2006-07-28 16:19:14.492052104 -0400
+++ b/include/net/tcp.h 2006-07-28 16:22:03.414372008 -0400
@@ -904,6 +904,9 @@ static inline void tcp_set_state(struct
static inline void tcp_done(struct sock *sk)
{
+ if(sk-sk_state == TCP_SYN_SENT || sk-sk_state == TCP_SYN_RECV)
+ TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS);
+
tcp_set_state(sk, TCP_CLOSE);
tcp_clear_xmit_timers(sk);
--- a/net/ipv4/tcp_ipv4.c 2006-07-28 16:23:21.677474208 -0400
+++ b/net/ipv4/tcp_ipv4.c 2006-07-28 16:23:48.854342696 -0400
@@ -437,7 +437,6 @@ void tcp_v4_err(struct sk_buff *skb, u32
It can f.e. if SYNs crossed.
*/
if (!sock_owned_by_user(sk)) {
- TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS);
sk-sk_err = err;
sk-sk_error_report(sk);
@@ -855,7 +854,6 @@ int tcp_v4_conn_request(struct sock *sk,
drop_and_free:
reqsk_free(req);
drop:
- TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS);
return 0;
}
--- a/net/ipv4/tcp_minisocks.c 2006-07-28 16:23:55.862277328 -0400
+++ b/net/ipv4/tcp_minisocks.c 2006-07-28 16:25:18.263750400 -0400
@@ -592,8 +592,10 @@ struct sock *tcp_check_req(struct sock *
/* RFC793: second check the RST bit and
* fourth, check the SYN bit
*/
- if (flg (TCP_FLAG_RST|TCP_FLAG_SYN))
+ if (flg (TCP_FLAG_RST|TCP_FLAG_SYN)) {
+ TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS);
goto embryonic_reset;
+ }
/* ACK sequence verified above, just make sure ACK is
* set. If ACK not set, just silently drop the packet.
--- a/net/ipv6/tcp_ipv6.c 2006-07-28 16:25:36.651954968 -0400
+++ b/net/ipv6/tcp_ipv6.c 2006-07-28 16:26:00.808282648 -0400
@@ -429,7 +429,6 @@ static void tcp_v6_err(struct sk_buff *s
case TCP_SYN_RECV: /* Cannot happen.
It can, it SYNs are crossed. --ANK */
if (!sock_owned_by_user(sk)) {
- TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS);
sk-sk_err = err;
sk-sk_error_report(sk);/* Wake people
up to see the error (see connect in sock.c) */
@@ -815,7 +814,6 @@ drop:
if (req)
reqsk_free(req);
- TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS);
return 0; /* don't send reset */
}
-
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] NetLabel: core network changes
* [EMAIL PROTECTED] [EMAIL PROTECTED] 2006-07-17 11:52 + * NetLabel makes use of the Generic NETLINK mechanism as a transport layer to + * send messages between kernel and user space. The general format of a + * NetLabel message is shown below: + * + * +-+---+- --- -- - + * | struct nlmsghdr | struct genlmsghdr | payload + * +-+---+- --- -- - + * + * The 'nlmsghdr' and 'genlmsghdr' structs should be dealt with like normal. + * The payload is dependent on the subsystem specified in the + * 'nlmsghdr-nlmsg_type' and should be defined below, supporting functions + * should be defined in the corresponding net/netlabel/netlabel_subsys.h|c + * file. All of the fields in the NetLabel payload should be aligned using + * the alignment functions provided. + * + */ + +/* + * NetLabel NETLINK protocol + */ + Is there a reason for not using any of the existing netlink and genetlink interfaces in any of your patches? It's all duplicated code. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
* Lennert Buytenhek [EMAIL PROTECTED] [2006-07-28 13:15]: - an ethtool dump of the registers. I don't know if Realtek's driver support but it can help even the in-kernel driver I'll ask someone else with the same board to do the test and will post the results. Here's the output using the r8169 driver: RealTek RTL-8110 registers: -- 0x00: MAC Address 00:14:fd:10:27:74 0x08: Multicast Address Filter 0x 0x 0x10: Dump Tally Counter Command 0xd7bbfec0 0xfb74b6fb 0x20: Tx Normal Priority Ring Addr 0x 0x 0x28: Tx High Priority Ring Addr 0xfffc3f00 0xfef7f6ad 0x30: Flash memory read/write 0x 0x34: Early Rx Byte Count 0 0x36: Early Rx Status 0x00 0x37: Command 0x00 Rx off, Tx off 0x3C: Interrupt Mask 0x 0x3E: Interrupt Status0x 0x40: Tx Configuration0x1000 0x44: Rx Configuration0x0002 0x48: Timer count 0x95887845 0x4C: Missed packet counter 0x00 0x50: EEPROM Command0x00 0x51: Config 0 0x04 0x52: Config 1 0x1f 0x53: Config 2 0x10 0x54: Config 3 0x20 0x55: Config 4 0x80 0x56: Config 5 0x01 0x58: Timer interrupt 0x 0x5C: Multiple Interrupt Select 0x 0x60: PHY access 0x80001000 0x64: TBI control and status 0x 0x68: TBI Autonegotiation advertisement (ANAR)0x 0x6A: TBI Link partner ability (LPAR) 0x 0x6C: PHY status0x6b 0x84: PM wakeup frame 00xbcfeef7f 0xde9f 0x8C: PM wakeup frame 10xabf7cf3f 0xfffbdbbf 0x94: PM wakeup frame 2 (low) 0xdfbbfedf 0xbfbd 0x9C: PM wakeup frame 2 (high) 0xaa75befc 0xcb5feaf9 0xA4: PM wakeup frame 3 (low) 0xbbdf6fdf 0xff7e75b7 0xAC: PM wakeup frame 3 (high) 0xbbdffbf9 0xfbfc 0xB4: PM wakeup frame 4 (low) 0x7f3bde9f 0x3bbffa7f 0xBC: PM wakeup frame 4 (high) 0xae9fbdcd 0x32c8bbff 0xC4: Wakeup frame 0 CRC 0x9aff 0xC6: Wakeup frame 1 CRC 0xfdbf 0xC8: Wakeup frame 2 CRC 0xaeff 0xCA: Wakeup frame 3 CRC 0x6bfe 0xCC: Wakeup frame 4 CRC 0xdc2f 0xDA: RX packet maximum size 0x3fff 0xE0: C+ Command 0x2028 RX checksumming PCI Multiple RW 0xE2: Interrupt Mitigation0x TxTimer: 0 TxPackets: 0 RxTimer: 0 RxPackets: 0 0xE4: Rx Ring Addr 0x07bd4000 0x 0xEC: Early Tx threshold0x3f -- Martin Michlmayr http://www.cyrius.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: [RFC 6/8] NetLabel: CIPSOv4 integration
On Thu, 2006-22-06 at 18:49 -0400, [EMAIL PROTECTED] wrote:
plain text document attachment (netlabel-cipsov4)
Add CIPSO/IPv4 support and management to the NetLabel subsystem. These
changes
integrate the CIPSO/IPv4 configuration into the existing NetLabel code and
enable the use of CIPSO/IPv4 within the overall NetLabel framework.
---
net/netlabel/netlabel_cipso_v4.c | 583
+++
1 files changed, 583 insertions(+)
+/**
+ * netlbl_cipsov4_rcv - Process incoming NetLabel packets
+ * @skb: the NETLINK buffer
+ * @msg: pointer to the start of the NetLabel data
+ *
+ * Description:
+ * This function is reponsibile for reading all of the incoming CIPSO V4
+ * NetLabel traffic and dispatching it to the correct CIPSO V4 functions.
+ *
+ */
+void netlbl_cipsov4_rcv(const struct sk_buff *skb, const unsigned char *msg)
+{
+ int ret_val;
+ struct netlbl_cipsov4_msghdr *nl_cv4_hdr;
+
+ if (nlmsg_len((struct nlmsghdr *)skb-data)
+ sizeof(struct netlbl_cipsov4_msghdr)) {
+ netlbl_cipsov4_send_ack(skb, EINVAL);
+ return;
+ }
+
+ nl_cv4_hdr = (struct netlbl_cipsov4_msghdr *)msg;
+ switch (nl_cv4_hdr-opcode) {
+ case NL_CV4_ADD:
Could you not have had all these NL_CV4_CMDs as just TLVs?
This is just the classical way of how we do things.
This would allow you to send multiple cmds in one message as well as
very easily add new ones in the future.
BTW, can you please repost your latest changes to netdev?
cheers,
jamal
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
On Fri, 2006-28-07 at 13:15 +0200, Lennert Buytenhek wrote: On Fri, Jul 28, 2006 at 12:49:46PM +0200, Francois Romieu wrote: The in-kernel 'r8169' drivers in 2.6.17 and 2.6.18-rc2 appear to work initially, but they don't actually seem to transmit any packets on the wire, nor do they receive any. Boot logs from 2.6.17 and 2.6.18-rc2 attached. Apart from the MAC address for eth1 being incorrect (boot loader bug, being worked on) there don't seem to be any strange messages or errors. Can you send: - the output of 'lspci -vvx' Since you mention an incorrect MAC address: The one thing that has bitten me in the past(twice) is misprograming of the eeprom (where typically the MAC address would sit as well). Vendor in a hurry to put out the NIC/board forgets to do something at manufacturing time. The most recent was about 9 months back where the same chip was used in the board but in one port copper was used and in another hooking up via serdes. The eeprom claimed both to be copper. It worked for sometime until you pulled a link and then plugged it back in. A little ethtool magic to change the device id to match 0x107B (E1000_DEV_ID_82546GB_SERDES) instead of 0x1079 (E1000_DEV_ID_82546GB_COPPER) fixed it. cheers, jamal PS:- That box looks interesting - priced correctly i may even buy one ;- - 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: Regarding offloading IPv6 addrconf and ndisc
On Fri, 2006-28-07 at 09:34 +0100, Hugo Santos wrote: 2. What if user process dies? or gets overwhelmed? One of the assumptions of the any well designed kernel is that the system should never hang because some user application died or waited for ever. Of course that this is a real problem. However, if the control daemon dies the kernel won't die. Depending on the implementation -- you might temporarily get out of addresses, if the addresses are flushed when the control daemon dies, etc. But, just like a routing daemon is critical to a router, this control application would also be critical to the host's connectivity. And if it dies, it needs to be restarted. The application might be itself complex, but in the end we moved this complexity away from the kernel. Hugo, The biggest challenge you will face is the view that people hate daemons - mostly from a usability perspective (is the gist of the arguements i have seen) but also because of concerns such as the one Stephen mentions above. I hold the same views as you do on the separation of control from the datapath and to respond to Stephens assertion on well designed kernel above: It is good kernel abstraction to separate policy management from mechanisms. The certificate issue only validates further this pov: that control tends to be feature-rich, swiss-army knife i.e more moving target than datapath. Such things typically belong to user-space. I have also seen talk of secure ARP; i wonder if there may be certificates involved there as well? If you look at the archives on netdev you may notice such discussions. Summary: I violently agree with you and i think if you address the daemon concerns, you will get other folks to agree as well. cheers, jamal - 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: [3/4] kevent: AIO, aio_sendfile() implementation.
On Thu, 2006-07-27 at 14:02 -0700, Badari Pulavarty wrote:
On Thu, 2006-07-27 at 11:44 -0700, Ulrich Drepper wrote:
Badari Pulavarty wrote:
Before we spend too much time cleaning up and merging into mainline -
I would like an agreement that what we add is good enough for glibc
POSIX AIO.
I haven't seen a description of the interface so far. Would be good if
it existed. But I briefly mentioned one quirk in the interface about
which Suparna wasn't sure whether it's implemented/implementable in the
current interface.
Sebastien, could you provide a description of interfaces you are
adding ? Since you did all the work, it would be appropriate for
you to do it :)
Here are the descriptions for the AIO completion notification and
listio patches. Hope I did not leave out too much.
Sébastien.
--
-
Sébastien DuguéBULL/FREC:B1-247
phone: (+33) 476 29 77 70 Bullcom: 229-7770
mailto:[EMAIL PROTECTED]
Linux POSIX AIO: http://www.bullopensource.org/posix
http://sourceforge.net/projects/paiol
-
aio completion notification
Summary:
---
The current 2.6 kernel does not support notification of user space via
an RT signal upon an asynchronous IO completion. The POSIX specification
states that when an AIO request completes, a signal can be delivered to
the application as notification.
The aioevent patch adds a struct sigevent *aio_sigeventp to the iocb.
The relevant fields (pid, signal number and value) are stored in the kiocb
for use when the request completes.
That sigevent structure is filled by the application as part of the AIO
request preparation. Upon request completion, the kernel notifies the
application using those sigevent parameters. If SIGEV_NONE has been specified,
then the old behaviour is retained and the application must rely on polling
the completion queue using io_getevents().
Details:
---
A struct sigevent *aio_sigeventp is added to struct iocb in
include/linux/aio_abi.h
An enum {IO_NOTIFY_SIGNAL = 0, IO_NOTIFY_THREAD_ID = 1} is added in
include/linux/aio.h:
- IO_NOTIFY_SIGNAL means that the signal is to be sent to the
requesting thread
- IO_NOTIFY_THREAD_ID means that the signal is to be sent to a
specifi thread.
The following fields are added to struct kiocb in include/linux/aio.h:
- pid_t ki_pid: target of the signal
- __u16 ki_signo: signal number
- __u16 ki_notify: kind of notification, IO_NOTIFY_SIGNAL or
IO_NOTIFY_THREAD_ID
- uid_t ki_uid, ki_euid: filled with the submitter credentials
- sigval_t ki_sigev_value: value stuffed in siginfo
these fields are only valid if ki_signo != 0.
In io_submit_one(), if the application provided a sigevent then
iocb_setup_sigevent() is called which does the following:
- save current-uid and current-euid in the kiocb fields ki_uid and
ki_euid for use in the completion path to check permissions
- check access to the user sigevent
- extract the needed fields from the sigevent (pid, signo, and value).
If the signal number passed from userspace is 0 then no notification
is to occur and ki_signo is set to 0
- check whether the submitting thread wants to be notified directly
(sigevent-sigev_notify_thread_id is 0) or wants the signal to be sent
to another thread.
In the latter case a check is made to assert that the target thread
is in the same thread group
- fill in the kiocb fields (ki_pid, ki_signo, ki_notify and
ki_sigev_value)
for that request.
Upon request completion, in aio_complete(), if ki_signo is not 0, then
__aio_send_signal() is called which sends the signal as follows:
- fill in the siginfo struct to be sent to the application
- check whether we have permission to signal the given thread
- send the signal
listio support
Summary:
---
The lio patch adds POSIX listio completion notification support. It builds
on support provided by the aio event patch and adds an IOCB_CMD_GROUP
command to sys_io_submit().
The purpose of IOCB_CMD_GROUP is to group together the following requests in
the list up to the end of the list.
As part of listio submission, the user process prepends to a list of requests
an empty special aiocb with an aio_lio_opcode of IOCB_CMD_GROUP, filling only
the aio_sigevent fields.
Details:
---
An IOCB_CMD_GROUP is added to the IOCB_CMD enum in include/linux/aio_abi.h
A struct lio_event is added in include/linux/aio.h
A struct lio_event *ki_lio is added to struct iocb in include/linux/aio.h
In sys_io_submit(), upon detecting such an IOCB_CMD_GROUP marker iocb, an
Re: [PATCH] NET: fix kernel panic from no dev-hard_header_len space
Krzysztof Halasa [EMAIL PROTECTED] writes: Are you sure about that? It would mean almost devices, including ^^ Ethernet, are at risk: almost all devices, of course. -- Krzysztof Halasa - 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/9] d80211: pull request
On Tue, 18 Jul 2006 17:45:20 +0200 (CEST), Jiri Benc wrote: Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/jbenc/dscape.git master I renamed that branch to 'up'. Please pull from 'up' branch. to obtain following patches: Jiri Benc: d80211: do not receive through master interface when not scanning d80211: host_gen_beacon_template flag d80211: better deallocation of mdev d80211: fix receiving through virtual interfaces d80211: fix defragmentation d80211: optimize defragmentation d80211: SET_NETDEV_DEV for non-master devices Michael Wu: d80211: Replace rc4 code with crypto api arc4 d80211: Add sparse bitwise annotations -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SMSC LAN911x and LAN921x vendor driver
+/* Tasklet declarations */ +static unsigned long rx_tasklet_parameter; +static void smsc911x_rx_tasklet(unsigned long data); + +DECLARE_TASKLET(rx_tasklet, smsc911x_rx_tasklet, 0); You can make this local with static DECLARE_TASKLET(rx_tasklet, smsc911x_rx_tasklet, 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
Re: Debugging kernel lockups during network activity
On 27-07-2006 20:19, Art Haas wrote: Hi. I've got Fedora Rawhide running on a SMP PIII machine, and the latest kernels from Fedora have been locking up when I run 'yum update' to get the latest packages. I also experience lock-ups when I use Firefox to do some web browsing. Not all my network usage results in a lockup, however. I can usually do 'git pull' and update git itself or my copy of Linus' kernel tree without problems, as well as update my GCC repo with subversion and Mozilla with cvs. I realize that running Fedora Rawhide means when things break I can keep the pieces, so the lockups or other occasional issues are not unexpected. I don't know the numbers of this kernels, but did you try linux-2.6.18-rc2. It has some great patch to queue scheduler by Hubert Xu. I think it is some Gnu/miracle that it has been working (mostly) under heavy load without this patch. But there are also other possibilities... Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
This patch by itself does nothing useful, other than remove a method.
If we assume you did the patch backwards, and wanted to add the method
instead, then where is this method ever called?
Ben
Christophe Devriese wrote:
diff -rU3 linux-2.6.17.7/net/core/dev.c linux-2.6.17.7-wapper/net/core/dev.c
--- linux-2.6.17.7/net/core/dev.c 2006-07-25 05:36:01.0 +0200
+++ linux-2.6.17.7-wapper/net/core/dev.c2006-07-27 20:16:36.0
+0200
@@ -88,6 +88,7 @@
#include linux/sockios.h
#include linux/errno.h
#include linux/interrupt.h
+#include linux/if_bonding.h
#include linux/if_ether.h
#include linux/netdevice.h
#include linux/etherdevice.h
@@ -1518,37 +1519,6 @@
EXPORT_SYMBOL(netif_rx_ni);
-static inline struct net_device *skb_bond(struct sk_buff *skb)
-{
- struct net_device *dev = skb-dev;
-
- if (dev-master) {
- /*
-* On bonding slaves other than the currently active
-* slave, suppress duplicates except for 802.3ad
-* ETH_P_SLOW and alb non-mcast/bcast.
-*/
- if (dev-priv_flags IFF_SLAVE_INACTIVE) {
- if (dev-master-priv_flags IFF_MASTER_ALB) {
- if (skb-pkt_type != PACKET_BROADCAST
- skb-pkt_type != PACKET_MULTICAST)
- goto keep;
- }
-
- if (dev-master-priv_flags IFF_MASTER_8023AD
- skb-protocol == __constant_htons(ETH_P_SLOW))
- goto keep;
-
- kfree_skb(skb);
- return NULL;
- }
-keep:
- skb-dev = dev-master;
- }
-
- return dev;
-}
-
static void net_tx_action(struct softirq_action *h)
{
struct softnet_data *sd = __get_cpu_var(softnet_data);
--
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 2/7] NetLabel: core network changes
Thomas Graf wrote: * [EMAIL PROTECTED] [EMAIL PROTECTED] 2006-07-17 11:52 + * NetLabel makes use of the Generic NETLINK mechanism as a transport layer to + * send messages between kernel and user space. The general format of a + * NetLabel message is shown below: + * + * +-+---+- --- -- - + * | struct nlmsghdr | struct genlmsghdr | payload + * +-+---+- --- -- - + * + * The 'nlmsghdr' and 'genlmsghdr' structs should be dealt with like normal. + * The payload is dependent on the subsystem specified in the + * 'nlmsghdr-nlmsg_type' and should be defined below, supporting functions + * should be defined in the corresponding net/netlabel/netlabel_subsys.h|c + * file. All of the fields in the NetLabel payload should be aligned using + * the alignment functions provided. + * + */ + +/* + * NetLabel NETLINK protocol + */ + Is there a reason for not using any of the existing netlink and genetlink interfaces in any of your patches? It's all duplicated code. I'm a little confused by your comment, could you be a bit more specific? Are you basing your comment strictly on the text above? If so, the problem may be my poor excuse for documentation rather then my poor excuse for implementation :) I am using the generic netlink interface, in what I believe to be a correct fashion - please correct me if I'm wrong. -- paul moore linux security @ hp - 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] NetLabel: core network changes
* Paul Moore [EMAIL PROTECTED] 2006-07-28 13:58 I'm a little confused by your comment, could you be a bit more specific? Are you basing your comment strictly on the text above? If so, the problem may be my poor excuse for documentation rather then my poor excuse for implementation :) I am using the generic netlink interface, in what I believe to be a correct fashion - please correct me if I'm wrong. The netlink bits are spread around all patches so I just quoted on this comment. By adding functions like netlbl_align(), netlbl_put_u8(), netlbl_put_hdr() writing a netlink header etc. you are just duplicating the already existing interfaces found in net/netlink.h and net/genetlink.h. - 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 6/8] NetLabel: CIPSOv4 integration
Jamal Hadi Salim wrote:
On Thu, 2006-22-06 at 18:49 -0400, [EMAIL PROTECTED] wrote:
+/**
+ * netlbl_cipsov4_rcv - Process incoming NetLabel packets
+ * @skb: the NETLINK buffer
+ * @msg: pointer to the start of the NetLabel data
+ *
+ * Description:
+ * This function is reponsibile for reading all of the incoming CIPSO V4
+ * NetLabel traffic and dispatching it to the correct CIPSO V4 functions.
+ *
+ */
+void netlbl_cipsov4_rcv(const struct sk_buff *skb, const unsigned char *msg)
+{
+ int ret_val;
+ struct netlbl_cipsov4_msghdr *nl_cv4_hdr;
+
+ if (nlmsg_len((struct nlmsghdr *)skb-data)
+ sizeof(struct netlbl_cipsov4_msghdr)) {
+ netlbl_cipsov4_send_ack(skb, EINVAL);
+ return;
+ }
+
+ nl_cv4_hdr = (struct netlbl_cipsov4_msghdr *)msg;
+ switch (nl_cv4_hdr-opcode) {
+ case NL_CV4_ADD:
Could you not have had all these NL_CV4_CMDs as just TLVs?
This is just the classical way of how we do things.
This would allow you to send multiple cmds in one message as well as
very easily add new ones in the future.
I think you are looking at an older patchset, which is most likely my
fault for not clearly marking each patch set with a datestamp or version
number. I will fix that in next release.
Anyway, back to your comment - this function no longer exists in the
current patchset. All of the different commands specified by NL_CV4_*
are now operations registered with the genetlink interface. It's not
the TLV solution you mention but it seems to be inline with how the
generic netlink interface works.
BTW, can you please repost your latest changes to netdev?
Yes I will, but not much has changed from my last patchset posted to
netdev (although quite a bit has changed since the patchset you are
looking at). I'm in the middle of moving/unpacking right now so it may
not get posted until sometime this weekend, although I try for today.
--
paul moore
linux security @ hp
-
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] NetLabel: core network changes
Thomas Graf wrote: * Paul Moore [EMAIL PROTECTED] 2006-07-28 13:58 I'm a little confused by your comment, could you be a bit more specific? Are you basing your comment strictly on the text above? If so, the problem may be my poor excuse for documentation rather then my poor excuse for implementation :) I am using the generic netlink interface, in what I believe to be a correct fashion - please correct me if I'm wrong. The netlink bits are spread around all patches so I just quoted on this comment. By adding functions like netlbl_align(), netlbl_put_u8(), netlbl_put_hdr() writing a netlink header etc. you are just duplicating the already existing interfaces found in net/netlink.h and net/genetlink.h. Thanks for the clarification, I think I understand your point a bit better now. It sounds like you main concern is that I'm not using the netlink attribute interfaces, yes? I looked at using those originally but decided not to use them for the following reasons: 1. They are listed as optional in the documents I read 2. They add at least an extra 32 bits to each attribute 3. There seems to be plenty of users in net/ipv4 who do not make use of attributes (a *quick* look again reveals none) 4. Since I'm reading messages from userspace I can't trust the message contents regardless of it's use of attributes 5. Harder to work with in userspace without using a netlink library, which would create an extra dependency for tools which talk to the NetLabel subsystem Basically, I saw no requirement to use the netlink attributes and no advantage so I didn't. Is this reasonable, or do you feel the use of attributes is a requirement? -- paul moore linux security @ hp - 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] NetLabel: core network changes
David Miller wrote: From: [EMAIL PROTECTED] Date: Mon, 17 Jul 2006 11:52:26 -0400 @@ -617,6 +618,8 @@ int inet_accept(struct socket *sock, str sock_graft(sk2, newsock); + netlbl_socket_inet_accept(sock, newsock); + newsock-state = SS_CONNECTED; err = 0; release_sock(sk2); This is only true wart I see in the patch set from my perspective. You have security_post_accept_hook(), which gets the parent and the child socket which is all the information you need, and it seems to be invoked at the correct location. So can you please hook into this location using the security level hook we already have? Just check sock-sk-sk_family is PF_INET at the top of that hook if you only want to handle ipv4 sockets, or something like that. Could this work? When preparing and argument stating why this won't work, please suggest a nicer name for this af_inet.c hook or some way to make it more generic and palatable to us. The only reason for having this new hook in inet_accept() is to catch all the in-kernel daemons who do not go through the LSM hooked accept() code path. I debated putting this hook into the patchset and in the end figured it was at least worth a shot. I'm happy to drop this hook as it *looks* like the MLSXFRM patchset is going to make it which has some of the accept hooks I was hoping to get, but figured I stood a snowballs chance in hell trying to get it in solely for use with CIPSO :) I'll drop this on the next release of the NetLabel patchset and assuming both the NetLabel and the MLSXFRM patchset make it into the 2.6.19 release I'll issue another small patchset then to integrate into the new LSM hooks for accept. I'd do it now but I think it would cause too much of a mess with patch dependencies/collisions/etc. - case 0x86: /* Another Commercial Security crap. */ + case IPOPT_CIPSO: I am sad to see this comment disappear :-) ... and I was surprised you didn't comment about that change sooner ;) -- paul moore linux security @ hp - 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] NetLabel: core network changes
* Paul Moore [EMAIL PROTECTED] 2006-07-28 14:39 It sounds like you main concern is that I'm not using the netlink attribute interfaces, yes? I looked at using those originally but decided not to use them for the following reasons: 1. They are listed as optional in the documents I read 2. They add at least an extra 32 bits to each attribute 3. There seems to be plenty of users in net/ipv4 who do not make use of attributes (a *quick* look again reveals none) 4. Since I'm reading messages from userspace I can't trust the message contents regardless of it's use of attributes 5. Harder to work with in userspace without using a netlink library, which would create an extra dependency for tools which talk to the NetLabel subsystem Basically, I saw no requirement to use the netlink attributes and no advantage so I didn't. Is this reasonable, or do you feel the use of attributes is a requirement? Not a requirement but I would encourage it. Almost all netlink families are using attributes with a few exceptions. We just used to call them rtattr defined in rtnetlink.h before the new api was added. There is one huge advantage in using attributes which is that your protocol is extendable without breaking binary interfaces. What I'm refering to primarly are the existing functions to write netlink and genetlink headers etc. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] NetLabel: core network changes
Thomas Graf wrote: * Paul Moore [EMAIL PROTECTED] 2006-07-28 14:39 It sounds like you main concern is that I'm not using the netlink attribute interfaces, yes? I looked at using those originally but decided not to use them for the following reasons: 1. They are listed as optional in the documents I read 2. They add at least an extra 32 bits to each attribute 3. There seems to be plenty of users in net/ipv4 who do not make use of attributes (a *quick* look again reveals none) 4. Since I'm reading messages from userspace I can't trust the message contents regardless of it's use of attributes 5. Harder to work with in userspace without using a netlink library, which would create an extra dependency for tools which talk to the NetLabel subsystem Basically, I saw no requirement to use the netlink attributes and no advantage so I didn't. Is this reasonable, or do you feel the use of attributes is a requirement? Not a requirement but I would encourage it. Almost all netlink families are using attributes with a few exceptions. We just used to call them rtattr defined in rtnetlink.h before the new api was added. There is one huge advantage in using attributes which is that your protocol is extendable without breaking binary interfaces. What I'm refering to primarly are the existing functions to write netlink and genetlink headers etc. Okay. Thanks for your feedback but unless I hear from others that this is a requirement I think I'm going to leave the code as written for the reasons I listed above. I won't argue the fact that attributes may make life easier when extending existing messages/interfaces but I think the existing NetLabel message format as well as the generic netlinks versioning of each message should allow plenty of room for growth in the future (if needed). -- paul moore linux security @ hp - 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] NetLabel: core network changes
On Fri, Jul 28, 2006 at 03:08:44PM -0400, Paul Moore ([EMAIL PROTECTED]) wrote: Not a requirement but I would encourage it. Almost all netlink families are using attributes with a few exceptions. We just used to call them rtattr defined in rtnetlink.h before the new api was added. There is one huge advantage in using attributes which is that your protocol is extendable without breaking binary interfaces. What I'm refering to primarly are the existing functions to write netlink and genetlink headers etc. Okay. Thanks for your feedback but unless I hear from others that this is a requirement I think I'm going to leave the code as written for the reasons I listed above. I won't argue the fact that attributes may make life easier when extending existing messages/interfaces but I think the existing NetLabel message format as well as the generic netlinks versioning of each message should allow plenty of room for growth in the future (if needed). Attributes are usual for rtnetlink users way. It complicates code and reading, but allows to have a lot of commands inside your message (if one has not created special field himself), thus do not breaking existing interfaces. IT can be easily avoided by introducing new commands in your protocol, which is essentially the same as new attributes. It is just another way of representing the data. For example connector (idealogical parent of gennetlink) does not have such attributes, but has similar to your structures approach, so it is only the way you like to represent your data. -- paul moore linux security @ hp -- 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: [RFC 1/4] kevent: core files.
I completely agree that existing kevent interface is not the best, so I'm opened for any suggestions. Should kevent creation/removing/modification be separated too? Yeah, I think so. Hmm, it looks like I'm lost here... Yeah, it seems my description might not have sunk in :). We're giving userspace a way to collect events without performing a system call. And why do we want this? So that event collection can be very efficient. How glibc is supposed to determine, that some events already fired and such requests will return immediately, or for example how timer events will be managed? ... That was what my previous mail was all about! - z - 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 1/4] kevent: core files.
On Fri, Jul 28, 2006 at 11:33:16AM -0700, Zach Brown ([EMAIL PROTECTED]) wrote: I completely agree that existing kevent interface is not the best, so I'm opened for any suggestions. Should kevent creation/removing/modification be separated too? Yeah, I think so. So, I'm going to create kevent_create/destroy/control and kevent_get_events() Or any better names? Hmm, it looks like I'm lost here... Yeah, it seems my description might not have sunk in :). We're giving userspace a way to collect events without performing a system call. And why do we want this? So that event collection can be very efficient. How glibc is supposed to determine, that some events already fired and such requests will return immediately, or for example how timer events will be managed? ... That was what my previous mail was all about! Some events are impossible to create in userspace (like timer notification, which requires timer start and check when timer completed). Actually all events are part of the kernel, since glibc does not have any knowledge about in-kernel state machines which are bound to appropriate kevents, so each kevent takes at least two syscall (create and get ready), and I do not see how, for exmple, glibc can avoid them when user requested POLLIN or similar event for network dataflow? According to syscall speed on Linux, last time I checked empty syscall took about 100ns on AMD Athlon 3500+. - z -- 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: [RFC 1/4] kevent: core files.
Things were like that at one point in time, but file descriptors turn out to introduce a huge gaping security hole with SUID programs. The problem is that any event context is closely tied to the address space of the thread issuing the syscalls, and file descriptors do not have this close binding. Can you go into that hole in more detail? Except that you're not usually pulling a full ring worth of events at a time, more often just one. OK, but then to wait for it you were already sleeping in the kernel, right? Clearly we should port httpd to kevents and take some measurements :) - z - 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 1/4] kevent: core files.
So, I'm going to create kevent_create/destroy/control and kevent_get_events() Or any better names? Yeah, that sounds good. Some events are impossible to create in userspace (like timer notification, which requires timer start and check when timer completed). We're not talking about *creating* events in userspace, we're talking about checking for their completion events in the ring. and get ready), and I do not see how, for exmple, glibc can avoid them when user requested POLLIN or similar event for network dataflow? There are events that can be generated by kernel code paths as the event completes. Network sockets have the hooks to do this with SIGIO, it's very natural for the storage completion paths, etc. So that kernel code would update the ring which userspace could check. AIO does this today. Userspace would still have to use the syscall to sleep waiting for new events when the ring is empty. According to syscall speed on Linux, last time I checked empty syscall took about 100ns on AMD Athlon 3500+. Oh, sure, but still nice to avoid. I'm mostly pursuing this because Ulrich seemed so insistent on it in his paper and talk. I will be very sad if we don't have aggressive glibc support for this generic event collection interface and so I want very much to keep him engaged. Ulrich, would you be satisfied if we didn't have the userspace mapped ring on the first pass and only had a collection syscall? - z - 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 1/4] kevent: core files.
On Fri, Jul 28, 2006 at 12:01:28PM -0700, Zach Brown ([EMAIL PROTECTED]) wrote: Clearly we should port httpd to kevents and take some measurements :) One of my main kevent benchmarks (socket notifications for accept/receive) is handmade http server. I compared it with FreeBSD kqueue, epoll and kevent_poll (this is generic poll/select notifications ported to kevent) based (it is the same server but with different event functions. Client was httperf, I ran it with 30k connections in bursts of 3k connection with 1 second timeout between bursts. Here are results: kevent: more than 2600 requests/second epoll and kevent_poll: about 1600-1800 requests/second kqueue: enormous number of connection reset errors (only 62% of successfull connections) (likely misconfiguration, default FreeBSD 6-something does not allow such rates at all). More info can be found on kevent homepage: http://tservice.net.ru/~s0mbre/old/?section=projectsitem=kevent - z -- 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: [RFC 1/4] kevent: core files.
Evgeniy Polyakov wrote: On Fri, Jul 28, 2006 at 12:01:28PM -0700, Zach Brown ([EMAIL PROTECTED]) wrote: Clearly we should port httpd to kevents and take some measurements :) One of my main kevent benchmarks (socket notifications for accept/receive) is handmade http server. Yeah, so I noticed. That's a good starting point but I'm more interested in seeing the work integrated with servers that have to survive outside of benchmarking runs. - z - 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 1/4] kevent: core files.
Clearly we should port httpd to kevents and take some measurements :) oh, I see, I forgot the 't' in 'thttpd'. My mistake. - z - 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
lockdep tcp_v6_rcv message
Triggered on Fedora rawhide kernel-2.6.17-1.2462.fc6 x86_64 which is
based on 2.6.18rc2-git6. IPv6 was in use at the time.
=
[ INFO: inconsistent lock state ]
-
inconsistent {softirq-on-W} - {in-softirq-R} usage.
swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
(sk-sk_dst_lock){---?}, at: [80418ef3]
sk_dst_check+0x26/0x12b
{softirq-on-W} state was registered at:
[802a874d] lock_acquire+0x4a/0x69
[802672a1] _write_lock+0x24/0x31
[8044a26b] ip4_datagram_connect+0x2e1/0x350
[80451214] inet_dgram_connect+0x57/0x65
[8041652a] sys_connect+0x7d/0xa4
[8025ff0d] system_call+0x7d/0x83
irq event stamp: 3507830
hardirqs last enabled at (3507830): [8020aaa8]
kmem_cache_alloc+0xd3/0xf7
hardirqs last disabled at (3507829): [8020aa20]
kmem_cache_alloc+0x4b/0xf7
softirqs last enabled at (3507808): [80212a9d]
__do_softirq+0xec/0xf5
softirqs last disabled at (3507811): [802611ba]
call_softirq+0x1e/0x28
other info that might help us debug this:
1 lock held by swapper/0:
#0: (slock-AF_INET6){-+..}, at: [883dc3d6]
tcp_v6_rcv+0x30e/0x770 [ipv6]
stack backtrace:
Call Trace:
[8026e269] show_trace+0xaa/0x23d
[8026e411] dump_stack+0x15/0x17
[802a67bd] print_usage_bug+0x259/0x26a
[802a6fc2] mark_lock+0x1d5/0x3e3
[802a7b80] __lock_acquire+0x427/0xa54
[802a874e] lock_acquire+0x4b/0x69
[802673b8] _read_lock+0x28/0x34
[80418ef3] sk_dst_check+0x26/0x12b
[883bd9be] :ipv6:ip6_dst_lookup+0x3a/0x1a2
[883d9dcf] :ipv6:tcp_v6_send_synack+0x185/0x2ec
[883dac02] :ipv6:tcp_v6_conn_request+0x291/0x2f3
[80243ce6] tcp_rcv_state_process+0x5f/0xe7b
[883da1bd] :ipv6:tcp_v6_do_rcv+0x268/0x372
[883dc7e7] :ipv6:tcp_v6_rcv+0x71f/0x770
[883bf4ef] :ipv6:ip6_input+0x223/0x315
[883bfb9d] :ipv6:ipv6_rcv+0x254/0x2af
[8022154d] netif_receive_skb+0x260/0x2dd
[881163ef] :e1000:e1000_clean_rx_irq+0x423/0x4c2
[881148c9] :e1000:e1000_clean+0x88/0x15b
[8020cc82] net_rx_action+0xac/0x1c7
[80212a19] __do_softirq+0x68/0xf5
[802611ba] call_softirq+0x1e/0x28
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.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: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
Martin Michlmayr [EMAIL PROTECTED] :
[...]
Here's the output using the r8169 driver:
RealTek RTL-8110 registers:
--
The (untested) patch below should apply to the source code that Realtek
included in linux-r1000(103).zip, wherence supporting the extraction
of the same info.
--- r1000/src/r1000_ioctl.c 2006-07-28 21:35:25.0 +0200
+++ r1000/src/r1000_ioctl.c 2006-07-28 21:38:17.0 +0200
@@ -4,6 +4,27 @@ extern int R1000_READ_GMII_REG(unsigned
extern int R1000_WRITE_GMII_REG(unsigned long ioaddr, int RegAddr, int value);
extern int r1000_set_speed_duplex(unsigned long ioaddr, unsigned long anar,
unsigned long gbcr, unsigned long bmcr);
+#define R1000_REGS_SIZE 256
+
+static int r1000_get_regs_len(struct net_device *dev)
+{
+ return R1000_REGS_SIZE;
+}
+
+static void r1000_get_regs(struct net_device *dev, struct ethtool_regs *regs,
+ void *p)
+{
+ struct r1000_private *priv = netdev_priv(dev);
+ unsigned long flags;
+
+ if (regs-len R1000_REGS_SIZE)
+ regs-len = R1000_REGS_SIZE;
+
+ spin_lock_irqsave(priv-lock, flags);
+ memcpy_fromio(p, (void __iomem *)priv-ioaddr, regs-len);
+ spin_unlock_irqrestore(priv-lock, flags);
+}
+
static int ethtool_get_settings(struct net_device *netdev,struct ethtool_cmd
*ecmd){
struct r1000_private *priv = (struct r1000_private *)(netdev-priv);
unsigned long ioaddr = priv-ioaddr;
@@ -136,6 +157,8 @@ int ethtool_ioctl(struct ifreq *ifr){
#if LINUX_VERSION_CODE KERNEL_VERSION(2,5,0)
struct ethtool_ops r1000_ethtool_ops = {
+ .get_regs_len = r1000_get_regs_len,
+ .get_regs = r1000_get_regs,
.get_settings = ethtool_get_settings,
.set_settings = ethtool_set_settings,
};
-
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] NetLabel: core network changes
From: Paul Moore [EMAIL PROTECTED] Date: Fri, 28 Jul 2006 14:45:53 -0400 I'm happy to drop this hook as it *looks* like the MLSXFRM patchset is going to make it which has some of the accept hooks I was hoping to get, but figured I stood a snowballs chance in hell trying to get it in solely for use with CIPSO :) I'll drop this on the next release of the NetLabel patchset and assuming both the NetLabel and the MLSXFRM patchset make it into the 2.6.19 release I'll issue another small patchset then to integrate into the new LSM hooks for accept. I'd do it now but I think it would cause too much of a mess with patch dependencies/collisions/etc. The MLSXFRM stuff is already queued up in my 2.6.19 tree at: master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.19.git so you can make your work relative to that if you wish. - 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: tg3 module problem with suspend2
I have this problem since I first tried to use suspend. The first kernel I tried was 2.6.13 I guess. Since that time I reload the driver, then I do not know if it works with kernel 2.6.14, 2.6.15 or 2.6.16 without reloading. - Lamarque V. Souza http://www.geographicguide.com/brazil.htm Linux User #57137 - http://counter.li.org/ From: Michael Chan [EMAIL PROTECTED] To: Lamarque Souza [EMAIL PROTECTED],netdev@vger.kernel.org CC: [EMAIL PROTECTED] Subject: Re: tg3 module problem with suspend2 Date: Thu, 27 Jul 2006 20:37:32 -0700 Lamarque Souza wrote: Do you have any idea why that happens? Not yet. Did it use to work with an older tg3 driver or kernel? - 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] NetLabel: core network changes
From: Paul Moore [EMAIL PROTECTED] Date: Fri, 28 Jul 2006 15:08:44 -0400 Thanks for your feedback but unless I hear from others that this is a requirement I think I'm going to leave the code as written for the reasons I listed above. Please switch over to the scheme which Thomas has suggested. There are real solid reasons for doing this, even if you think your API is complete today and won't run into some of the issues he mentioned. - 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] NetLabel: core network changes
David Miller wrote: From: Paul Moore [EMAIL PROTECTED] Date: Fri, 28 Jul 2006 15:08:44 -0400 Thanks for your feedback but unless I hear from others that this is a requirement I think I'm going to leave the code as written for the reasons I listed above. Please switch over to the scheme which Thomas has suggested. Okay. I stated earlier today that I would push a new patchset out to the list this weekend or perhaps today, but in light of this I think I'll wait until I have had a chance to make this change which should be sometime next week. -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
* Francois Romieu [EMAIL PROTECTED] [2006-07-28 21:49]:
The (untested) patch below should apply to the source code that Realtek
included in linux-r1000(103).zip, wherence supporting the extraction
of the same info.
Note quite. I also had to add the patch below but now it's working:
Offset Value
-
00 0x00
01 0x14
02 0xfd
03 0x10
04 0x27
05 0x74
06 0x00
07 0x00
08 0x00
09 0x00
10 0x00
11 0x80
12 0x00
13 0x00
14 0x00
15 0x00
16 0xc0
17 0xfe
18 0xbb
19 0xdf
20 0x7b
21 0xb6
22 0x74
23 0xff
24 0x00
25 0x00
26 0x00
27 0x00
28 0x00
29 0x00
30 0x00
31 0x00
32 0x00
33 0x80
34 0x20
35 0x07
36 0x00
37 0x00
38 0x00
39 0x00
40 0x00
41 0x3f
42 0xfc
43 0xff
44 0xac
45 0xf7
46 0xf7
47 0xfe
48 0x00
49 0x00
50 0x00
51 0x00
52 0x00
53 0x00
54 0x08
55 0x0c
56 0x00
57 0x00
58 0x00
59 0x00
60 0x7f
61 0x00
62 0x00
63 0x00
64 0x00
65 0x07
66 0x00
67 0x13
68 0x0e
69 0xe7
70 0x00
71 0x00
72 0x24
73 0x57
74 0xaf
75 0x31
76 0x00
77 0x00
78 0x00
79 0x00
80 0x00
81 0x04
82 0x1f
83 0x10
84 0x20
85 0x80
86 0x03
87 0x00
88 0x00
89 0x00
90 0x00
91 0x00
92 0x00
93 0x00
94 0x10
95 0x00
96 0x6d
97 0x79
98 0x01
99 0x80
100 0x00
101 0x00
102 0x00
103 0x00
104 0x00
105 0x00
106 0x00
107 0x00
108 0x6b
109 0x00
110 0x00
111 0x00
112 0xff
113 0xfd
114 0xfb
115 0xff
116 0xfc
117 0x03
118 0x00
119 0x00
120 0x00
121 0xff
122 0xff
123 0xff
124 0x00
125 0x00
126 0x00
127 0x00
128 0x00
129 0x00
130 0x00
131 0x00
132 0x7f
133 0xef
134 0xfe
135 0xfc
136 0x9f
137 0xfe
138 0xff
139 0xdf
140 0x3f
141 0xcf
142 0xf7
143 0xab
144 0xbf
145 0xdb
146 0xfb
147 0xff
148 0xdf
149 0xff
150 0xfa
151 0xdf
152 0xfd
153 0xbf
154 0xbf
155 0xbf
156 0xfc
157 0xbe
158 0x75
159 0xaa
160 0xf9
161 0xea
162 0x5f
163 0xcb
164 0xdf
165 0x6f
166 0xdf
167 0xfb
168 0xb7
169 0x75
170 0x7e
171 0xff
172 0xfd
173 0xfb
174 0xdf
175 0xbb
176 0xff
177 0xff
178 0x7c
179 0xff
180 0x9f
181 0xde
182 0x3b
183 0x7f
184 0x7f
185 0xfa
186 0xbf
187 0xbb
188 0xcd
189 0xfd
190 0x9f
191 0xae
192 0xff
193 0xbb
194 0xc8
195 0x36
196 0xef
197 0xda
198 0xff
199 0xff
200 0xff
201 0xae
202 0xfe
203 0x6a
204 0x2f
205 0xdc
206 0x00
207 0x00
208 0x00
209 0x00
210 0x00
211 0x00
212 0x00
213 0x00
214 0x00
215 0x00
216 0x00
217 0x00
218 0xf2
219 0x05
220 0x00
221 0x00
222 0x00
223 0x00
224 0x08
225 0x20
226 0x00
227 0x00
228 0x00
229 0x00
230 0x79
231 0x07
232 0x00
233 0x00
234 0x00
235 0x00
236 0x3f
237 0x00
238 0x00
239 0x00
240 0x00
241 0x80
242 0x00
243 0x00
244 0x00
245 0x00
246 0x00
247 0x00
248 0x02
249 0x00
250 0x00
251 0x00
252 0x00
253 0x00
254 0x00
255 0x00
--- r1000_ioctl.c~ 2006-07-28 20:32:58.027267250 +
+++ r1000_ioctl.c 2006-07-28 20:33:18.600553000 +
@@ -6,6 +6,16 @@
#define R1000_REGS_SIZE 256
+static void r1000_get_drvinfo(struct net_device *dev,
+ struct ethtool_drvinfo *info)
+{
+ struct r1000_private *priv = netdev_priv(dev);
+
+ strcpy(info-driver, MODULENAME);
+ strcpy(info-version, R1000_VERSION);
+ strcpy(info-bus_info, pci_name(priv-pci_dev));
+}
+
static int r1000_get_regs_len(struct net_device *dev)
{
return R1000_REGS_SIZE;
@@ -157,6 +167,7 @@
#if LINUX_VERSION_CODE KERNEL_VERSION(2,5,0)
struct ethtool_ops r1000_ethtool_ops = {
+ .get_drvinfo= r1000_get_drvinfo,
.get_regs_len = r1000_get_regs_len,
.get_regs = r1000_get_regs,
.get_settings = ethtool_get_settings,
--
Martin Michlmayr
http://www.cyrius.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 2/7] NetLabel: core network changes
From: Paul Moore [EMAIL PROTECTED] Date: Fri, 28 Jul 2006 16:09:15 -0400 Okay. I stated earlier today that I would push a new patchset out to the list this weekend or perhaps today, but in light of this I think I'll wait until I have had a chance to make this change which should be sometime next week. Thanks a lot Paul. I think once we flesh all of this out we can queue your code into my net-2.6.19 tree. Thanks again. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] NetLabel: core network changes
David Miller wrote: From: Paul Moore [EMAIL PROTECTED] Date: Fri, 28 Jul 2006 16:09:15 -0400 Okay. I stated earlier today that I would push a new patchset out to the list this weekend or perhaps today, but in light of this I think I'll wait until I have had a chance to make this change which should be sometime next week. Thanks a lot Paul. I think once we flesh all of this out we can queue your code into my net-2.6.19 tree. Thanks again. No problem, thanks for being open to some more of that Commercial Security crap :) -- paul moore linux security @ hp - 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][SECURITY] secmark: nul-terminate secdata
The patch below fixes a problem in the iptables SECMARK target, where the
user-supplied 'selctx' string may not be nul-terminated.
From initial analysis, it seems that the strlen() called from
selinux_string_to_sid() could run until it arbitrarily finds a zero, and
possibly cause a kernel oops before then.
The impact of this appears limited because the operation requires
CAP_NET_ADMIN, which is essentially always root. Also, the module is not
yet in wide use.
Please apply.
Note: some other iptables modules which handle strings supplied from
userspace may require a similar fix (e.g. xt_string looks suspect at first
glance).
cc'd Chris Wright, as this patch seems like a candidate for the stable
tree.
Signed-off-by: James Morris [EMAIL PROTECTED]
Signed-off-by: Stephen Smalley [EMAIL PROTECTED]
---
diff -purN -X dontdiff linux-2.6.18-rc2-mm1.o/net/netfilter/xt_SECMARK.c
linux-2.6.18-rc2-mm1.w/net/netfilter/xt_SECMARK.c
--- linux-2.6.18-rc2-mm1.o/net/netfilter/xt_SECMARK.c 2006-07-28
11:01:46.0 -0400
+++ linux-2.6.18-rc2-mm1.w/net/netfilter/xt_SECMARK.c 2006-07-28
11:15:44.0 -0400
@@ -57,6 +57,8 @@ static int checkentry_selinux(struct xt_
{
int err;
struct xt_secmark_target_selinux_info *sel = info-u.sel;
+
+ sel-selctx[SECMARK_SELCTX_MAX - 1] = '\0';
err = selinux_string_to_sid(sel-selctx, sel-selsid);
if (err) {
-
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: SMSC LAN911x and LAN921x vendor driver
[...]
diff --git a/drivers/net/smsc911x.c b/drivers/net/smsc911x.c
new file mode 100644
index 000..12bbe67
--- /dev/null
+++ b/drivers/net/smsc911x.c
[...]
+/* Tasklet declarations */
+static unsigned long rx_tasklet_parameter;
+static void smsc911x_rx_tasklet(unsigned long data);
+
+DECLARE_TASKLET(rx_tasklet, smsc911x_rx_tasklet, 0);
+MODULE_LICENSE(GPL);
+
+/* MAC */
[lots of forward declarations]
Despite Jeff claiming otherwise, I see no added value in forward
declarations. It adds bloat, it pollutes ctags and it is inferior
to real kernel docbook documentation.
[...]
+/* Linux network device interface */
+static int smsc911x_open(struct net_device *dev);
+static int smsc911x_stop(struct net_device *dev);
+static int smsc911x_hard_start_xmit(struct sk_buff *skb,
+ struct net_device *dev);
+
+static struct net_device_stats *smsc911x_get_stats(struct net_device *dev);
+static void smsc911x_set_multicast_list(struct net_device *dev);
+static irqreturn_t smsc911x_irqhandler(int irq, void *dev_id,
+struct pt_regs *regs);
+
+/* Module interface */
+static int smsc911x_init_module(void);
+static void smsc911x_cleanup_module(void);
+
+/* Driver interface */
+static int smsc911x_drv_probe(struct platform_device *pdev);
+static int smsc911x_drv_remove(struct platform_device *pdev);
These one are completely useless.
+/* Entry point for starting/opening the interface */
+static int smsc911x_open(struct net_device *dev)
+{
+ struct smsc911x_data *pdata;
+ unsigned int mac_high16;
+ unsigned int mac_low32;
+ unsigned int timeout;
+ unsigned int intcfg;
+ int result;
+
+ /* Set interrupt deassertion to 220uS */
+ intcfg = 22 24;
+ timeout = 1000;
+ result = -ENODEV;
+
+ pdata = netdev_priv(dev);
It is quite common to set pdata on flight, i.e.:
struct smsc911x_data *pdata = netdev_priv(dev);
Same thing for 'result'.
+
+ /* Initialise smsc911x */
+
+ /*
+ * dwIntCfg|=INT_CFG_IRQ_POL_; use this to set IRQ_POL bit
+ * dwIntCfg|=INT_CFG_IRQ_TYPE_; use this to set IRQ_TYPE bit
+ */
+ if (!smsc911x_lan_initialise(pdata, intcfg))
+ goto done;
+
+ SMSC_TRACE(Testing irq handler using IRQ %d, dev-irq);
+ pdata-request_irq_disable = 0;
+ pdata-software_irq_signal = 0;
+ smsc911x_reg_write((smsc911x_reg_read(pdata, INT_EN) |
+ INT_EN_SW_INT_EN_), pdata, INT_EN);
+ do {
+ udelay(10);
+ timeout--;
+ } while (timeout (!pdata-software_irq_signal));
+
+ if (!pdata-software_irq_signal) {
+ printk(1ISR failed signaling test.);
Should be printk(KERN_XYZ, ...
It would be nice to display the device name too.
+ result = -ENODEV;
+ goto done;
+ }
+ SMSC_TRACE(IRQ handler passed test using IRQ %d, dev-irq);
+
+ printk(%s: SMSC911x/921x identified at %#08x, IRQ: %d\n, dev-name,
+pdata-base, dev-irq);
printk(KERN_XYZ, ...
[...]
+static int smsc911x_stop(struct net_device *dev)
+{
+ unsigned long flags;
+ unsigned long base;
+ unsigned long idrev;
+ struct smsc911x_data *pdata;
+ struct net_device *pnetdev;
+
+ pdata = netdev_priv(dev);
+
+ pdata-stop_link_poll = 1;
+ del_timer_sync(pdata-link_poll_timer);
+
+ spin_lock_irqsave(dev-_xmit_lock, flags);
If this is supposed to protect against hard_start_xmit, it is not needed.
+ smsc911x_reg_write((smsc911x_reg_read(pdata, INT_CFG)
+ (~INT_CFG_IRQ_EN_)), pdata, INT_CFG);
+ netif_stop_queue(pdata-dev);
Any reason why 'pdata-dev' would be different from 'dev' ?
pnetdev seems redundant with dev.
+ spin_unlock_irqrestore(dev-_xmit_lock, flags);
+
+ /* At this point all Rx and Tx activity is stopped */
+ pdata-stats.rx_dropped += smsc911x_reg_read(pdata, RX_DROP);
+ smsc911x_tx_update_txcounters(pdata);
+
+ /* Preserve important fields */
+ base = pdata-base;
+ idrev = pdata-idrev;
+ pnetdev = pdata-dev;
+
+ /* Clear all structure */
+ memset((void *)pdata, 0, sizeof(struct smsc911x_data));
Useless conversion to void *
+static int smsc911x_hard_start_xmit(struct sk_buff *skb, struct net_device
*dev)
+{
[...]
+ return 0;
s/0/NETDEV_TX_OK/
[...]
+/* Entry point for setting addressing modes */
+static void smsc911x_set_multicast_list(struct net_device *dev)
+{
+ struct smsc911x_data *pdata;
+ unsigned long flags;
+
+ pdata = netdev_priv(dev);
+
+ spin_lock_irqsave(pdata-phy_lock, flags);
+
+ if (dev-flags IFF_PROMISC) {
+ /* Enabling promiscuous mode */
+ pdata-set_bits_mask = MAC_CR_PRMS_;
+ pdata-clear_bits_mask = (MAC_CR_MCPAS_ | MAC_CR_HPFILT_);
+ pdata-hashhi = 0;
+
Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
I basically move the skb_bond method into if_bonding.h, include that file
in if_vlan ( and call it from the vlan forwarding path, and the netif_rx
routine ).
Somehow this patch is very incomplete. Let me try again.
sorry for the trouble. (I'm new at this)
Regards,
Christophe
Christophe Devriese wrote:
diff -rU3 linux-2.6.17.7/net/core/dev.c
linux-2.6.17.7-wapper/net/core/dev.c
--- linux-2.6.17.7/net/core/dev.c 2006-07-25 05:36:01.0 +0200
+++ linux-2.6.17.7-wapper/net/core/dev.c2006-07-27
20:16:36.0 +0200
@@ -88,6 +88,7 @@
#include linux/sockios.h
#include linux/errno.h
#include linux/interrupt.h
+#include linux/if_bonding.h
#include linux/if_ether.h
#include linux/netdevice.h
#include linux/etherdevice.h
@@ -1518,37 +1519,6 @@
EXPORT_SYMBOL(netif_rx_ni);
-static inline struct net_device *skb_bond(struct sk_buff *skb)
-{
- struct net_device *dev = skb-dev;
-
- if (dev-master) {
- /*
-* On bonding slaves other than the currently active
-* slave, suppress duplicates except for 802.3ad
-* ETH_P_SLOW and alb non-mcast/bcast.
-*/
- if (dev-priv_flags IFF_SLAVE_INACTIVE) {
- if (dev-master-priv_flags IFF_MASTER_ALB) {
- if (skb-pkt_type != PACKET_BROADCAST
- skb-pkt_type != PACKET_MULTICAST)
- goto keep;
- }
-
- if (dev-master-priv_flags IFF_MASTER_8023AD
- skb-protocol == __constant_htons(ETH_P_SLOW))
- goto keep;
-
- kfree_skb(skb);
- return NULL;
- }
-keep:
- skb-dev = dev-master;
- }
-
- return dev;
-}
-
static void net_tx_action(struct softirq_action *h)
{
struct softnet_data *sd = __get_cpu_var(softnet_data);
--
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
--
---
Christophe Devriese EURiD
Network Adminstrator / Developer
[EMAIL PROTECTED]
http://www.eth1.org --
diff -rU3 linux-2.6.17.7/include/linux/if_bonding.h
linux-2.6.17.7-wapper/include/linux/if_bonding.h
--- linux-2.6.17.7/include/linux/if_bonding.h 2006-07-25 05:36:01.0
+0200
+++ linux-2.6.17.7-wapper/include/linux/if_bonding.h2006-07-27
21:17:25.0 +0200
@@ -46,6 +46,7 @@
#include linux/if.h
#include linux/types.h
#include linux/if_ether.h
+#include linux/netdevice.h
/* userland - kernel ABI version (2003/05/08) */
#define BOND_ABI_VERSION 2
@@ -110,6 +111,37 @@
__u8 partner_system[ETH_ALEN];
};
+static inline struct net_device *skb_bond(struct sk_buff *skb)
+{
+ struct net_device *dev = skb-dev;
+
+ if (dev-master) {
+ /*
+* On bonding slaves other than the currently active
+* slave, suppress duplicates except for 802.3ad
+* ETH_P_SLOW and alb non-mcast/bcast.
+*/
+ if (dev-priv_flags IFF_SLAVE_INACTIVE) {
+ if (dev-master-priv_flags IFF_MASTER_ALB) {
+ if (skb-pkt_type != PACKET_BROADCAST
+ skb-pkt_type != PACKET_MULTICAST)
+ goto keep;
+ }
+
+ if (dev-master-priv_flags IFF_MASTER_8023AD
+ skb-protocol == __constant_htons(ETH_P_SLOW))
+ goto keep;
+
+ kfree_skb(skb);
+ return NULL;
+ }
+keep:
+ skb-dev = dev-master;
+ }
+
+ return dev;
+}
+
#endif /* _LINUX_IF_BONDING_H */
/*
diff -rU3 linux-2.6.17.7/include/linux/if_vlan.h
linux-2.6.17.7-wapper/include/linux/if_vlan.h
--- linux-2.6.17.7/include/linux/if_vlan.h 2006-07-25 05:36:01.0
+0200
+++ linux-2.6.17.7-wapper/include/linux/if_vlan.h 2006-07-27
20:16:36.0 +0200
@@ -24,6 +24,7 @@
struct hlist_node;
#include linux/proc_fs.h /* for proc_dir_entry */
+#include linux/if_bonding.h /* for skb_bond */
#include linux/netdevice.h
#define VLAN_HLEN 4 /* The additional bytes (on top of the
Ethernet header)
@@ -154,6 +155,12 @@
unsigned short vlan_tag, int polling)
{
struct net_device_stats *stats;
+ struct net_device
Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
Christophe Devriese wrote: I basically move the skb_bond method into if_bonding.h, include that file in if_vlan ( and call it from the vlan forwarding path, and the netif_rx routine ). Somehow this patch is very incomplete. Let me try again. The patch looks sane this time. The skb_bond method assigns skb-dev when it does the 'keep', but the VLAN code immediately over-writes the skb-dev when searching for the vlan device. What is the purpose of assinging skb-dev to the master device? 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
[PATCH] e1000: add forgotten PCI ID for supported device
The Intel(R) PRO/1000 82572EI card is fully supported by 7.0.33-k2 and onward. Add the device ID so this card works with 2.6.17.y onward. This device ID was accidentally omitted. Signed-off-by: Auke Kok [EMAIL PROTECTED] diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c index 523c2c9..c5e7023 100644 --- a/drivers/net/e1000/e1000_hw.c +++ b/drivers/net/e1000/e1000_hw.c @@ -353,6 +353,7 @@ e1000_set_mac_type(struct e1000_hw *hw) case E1000_DEV_ID_82572EI_COPPER: case E1000_DEV_ID_82572EI_FIBER: case E1000_DEV_ID_82572EI_SERDES: +case E1000_DEV_ID_82572EI: hw-mac_type = e1000_82572; break; case E1000_DEV_ID_82573E: diff --git a/drivers/net/e1000/e1000_hw.h b/drivers/net/e1000/e1000_hw.h index 150e45e..c01e5d2 100644 --- a/drivers/net/e1000/e1000_hw.h +++ b/drivers/net/e1000/e1000_hw.h @@ -462,6 +462,7 @@ #define E1000_DEV_ID_82571EB_SERDES #define E1000_DEV_ID_82572EI_COPPER 0x107D #define E1000_DEV_ID_82572EI_FIBER 0x107E #define E1000_DEV_ID_82572EI_SERDES 0x107F +#define E1000_DEV_ID_82572EI 0x10B9 #define E1000_DEV_ID_82573E 0x108B #define E1000_DEV_ID_82573E_IAMT 0x108C #define E1000_DEV_ID_82573L 0x109A
Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
On Fri, Jul 28, 2006 at 02:55:17PM -0700, Ben Greear wrote: Christophe Devriese wrote: I basically move the skb_bond method into if_bonding.h, include that file in if_vlan ( and call it from the vlan forwarding path, and the netif_rx routine ). Somehow this patch is very incomplete. Let me try again. The patch looks sane this time. The skb_bond method assigns skb-dev when it does the 'keep', but the VLAN code immediately over-writes the skb-dev when searching for the vlan device. What is the purpose of assinging skb-dev to the master device? I don't know. The method was only moved by this patch, not changed. The contents of the method are exactly what they are in linux-2.6.17.7/net/core/dev.c I assume it has something to do with the other bonding methods. -- --- Christophe Devriese EURiD Network Adminstrator / Developer [EMAIL PROTECTED] http://www.eth1.org -- - 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 bonding active-backup behavior for VLAN interfaces
On Fri, Jul 28, 2006 at 03:08:49PM -0700, Ben Greear wrote: Christophe Devriese wrote: On Fri, Jul 28, 2006 at 02:55:17PM -0700, Ben Greear wrote: Christophe Devriese wrote: I basically move the skb_bond method into if_bonding.h, include that file in if_vlan ( and call it from the vlan forwarding path, and the netif_rx routine ). Somehow this patch is very incomplete. Let me try again. The patch looks sane this time. The skb_bond method assigns skb-dev when it does the 'keep', but the VLAN code immediately over-writes the skb-dev when searching for the vlan device. What is the purpose of assinging skb-dev to the master device? I don't know. The method was only moved by this patch, not changed. The contents of the method are exactly what they are in linux-2.6.17.7/net/core/dev.c I assume it has something to do with the other bonding methods. Ok, I don't know much about the bonding logic. Looks OK to me. Will you sign-off on it then ? Or how do I get this applied ? -- --- Christophe Devriese EURiD Network Adminstrator / Developer [EMAIL PROTECTED] http://www.eth1.org -- - 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 bonding active-backup behavior for VLAN interfaces
From: Christophe Devriese [EMAIL PROTECTED] Date: Sat, 29 Jul 2006 00:58:59 +0200 On Fri, Jul 28, 2006 at 03:08:49PM -0700, Ben Greear wrote: Christophe Devriese wrote: On Fri, Jul 28, 2006 at 02:55:17PM -0700, Ben Greear wrote: Christophe Devriese wrote: I basically move the skb_bond method into if_bonding.h, include that file in if_vlan ( and call it from the vlan forwarding path, and the netif_rx routine ). Somehow this patch is very incomplete. Let me try again. The patch looks sane this time. The skb_bond method assigns skb-dev when it does the 'keep', but the VLAN code immediately over-writes the skb-dev when searching for the vlan device. What is the purpose of assinging skb-dev to the master device? I don't know. The method was only moved by this patch, not changed. The contents of the method are exactly what they are in linux-2.6.17.7/net/core/dev.c I assume it has something to do with the other bonding methods. Ok, I don't know much about the bonding logic. Looks OK to me. Will you sign-off on it then ? Or how do I get this applied ? I'll apply this over the weekend unless I spot some problem with it, thanks. A sign off from Ben would be nice 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 Fix bonding active-backup behavior for VLAN interfaces
David Miller wrote: From: Christophe Devriese [EMAIL PROTECTED] Date: Sat, 29 Jul 2006 00:58:59 +0200 On Fri, Jul 28, 2006 at 03:08:49PM -0700, Ben Greear wrote: Christophe Devriese wrote: On Fri, Jul 28, 2006 at 02:55:17PM -0700, Ben Greear wrote: Christophe Devriese wrote: I basically move the skb_bond method into if_bonding.h, include that file in if_vlan ( and call it from the vlan forwarding path, and the netif_rx routine ). Somehow this patch is very incomplete. Let me try again. The patch looks sane this time. The skb_bond method assigns skb-dev when it does the 'keep', but the VLAN code immediately over-writes the skb-dev when searching for the vlan device. What is the purpose of assinging skb-dev to the master device? I don't know. The method was only moved by this patch, not changed. The contents of the method are exactly what they are in linux-2.6.17.7/net/core/dev.c I assume it has something to do with the other bonding methods. Ok, I don't know much about the bonding logic. Looks OK to me. Will you sign-off on it then ? Or how do I get this applied ? I'll apply this over the weekend unless I spot some problem with it, thanks. A sign off from Ben would be nice too :) I don't see any problems with the patch. The skb-dev assignment is redundant for the VLAN path, but may be useful elsewhere. At any rate, it doesn't seem like it would hurt anything. Signed-off-by Ben Greear [EMAIL PROTECTED] -- 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
[PATCH Round 5 0/3] Network Event Notifier Mechanism
Dave/Roland, is this patchset about ready to go? Round 5 Changes: - removed user-mode support - removed route add/del events. -- This patch implements a mechanism that allows interested clients to register for notification of certain network events. The intended use is to allow RDMA devices (linux/drivers/infiniband) to be notified of neighbour updates, ICMP redirects, and path MTU changes. RDMA devices need these network events because they typically cache this information in hardware and need to be notified when it changes. To learn about RDMA internet protocols, see: http://www.ietf.org/html.charters/rddp-charter.html. The key events of interest are: - neighbour mac address change - routing redirect (the next hop neighbour changes for a dst_entry) - path mtu change (the path mtu for a dst_entry changes). This patchset consists of 3 patches: 1) New files implementing the Network Event Notifier 2) Core network changes to generate netevents 3) Cleanup ib_addr modules to use the netevent patch Signed-off-by: Tom Tucker [EMAIL PROTECTED] Signed-off-by: Steve Wise [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 Round 5 1/3] Network Event Notifier Mechanism.
This patch uses notifier blocks to implement a network event
notifier mechanism.
Clients register their callback function by calling
register_netevent_notifier() like this:
static struct notifier_block nb = {
.notifier_call = my_callback_func
};
...
register_netevent_notifier(nb);
---
include/net/netevent.h | 33 +++
net/core/netevent.c| 69
2 files changed, 102 insertions(+), 0 deletions(-)
diff --git a/include/net/netevent.h b/include/net/netevent.h
new file mode 100644
index 000..e5d2162
--- /dev/null
+++ b/include/net/netevent.h
@@ -0,0 +1,33 @@
+#ifndef _NET_EVENT_H
+#define _NET_EVENT_H
+
+/*
+ * Generic netevent notifiers
+ *
+ * Authors:
+ * Tom Tucker [EMAIL PROTECTED]
+ * Steve Wise [EMAIL PROTECTED]
+ *
+ * Changes:
+ */
+#ifdef __KERNEL__
+
+#include net/dst.h
+
+struct netevent_redirect {
+ struct dst_entry *old;
+ struct dst_entry *new;
+};
+
+enum netevent_notif_type {
+ NETEVENT_NEIGH_UPDATE = 1, /* arg is struct neighbour ptr */
+ NETEVENT_PMTU_UPDATE, /* arg is struct dst_entry ptr */
+ NETEVENT_REDIRECT, /* arg is struct netevent_redirect ptr */
+};
+
+extern int register_netevent_notifier(struct notifier_block *nb);
+extern int unregister_netevent_notifier(struct notifier_block *nb);
+extern int call_netevent_notifiers(unsigned long val, void *v);
+
+#endif
+#endif
diff --git a/net/core/netevent.c b/net/core/netevent.c
new file mode 100644
index 000..35d02c3
--- /dev/null
+++ b/net/core/netevent.c
@@ -0,0 +1,69 @@
+/*
+ * Network event notifiers
+ *
+ * Authors:
+ * Tom Tucker [EMAIL PROTECTED]
+ * Steve Wise [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Fixes:
+ */
+
+#include linux/rtnetlink.h
+#include linux/notifier.h
+
+static ATOMIC_NOTIFIER_HEAD(netevent_notif_chain);
+
+/**
+ * register_netevent_notifier - register a netevent notifier block
+ * @nb: notifier
+ *
+ * Register a notifier to be called when a netevent occurs.
+ * The notifier passed is linked into the kernel structures and must
+ * not be reused until it has been unregistered. A negative errno code
+ * is returned on a failure.
+ */
+int register_netevent_notifier(struct notifier_block *nb)
+{
+ int err;
+
+ err = atomic_notifier_chain_register(netevent_notif_chain, nb);
+ return err;
+}
+
+/**
+ * netevent_unregister_notifier - unregister a netevent notifier block
+ * @nb: notifier
+ *
+ * Unregister a notifier previously registered by
+ * register_neigh_notifier(). The notifier is unlinked into the
+ * kernel structures and may then be reused. A negative errno code
+ * is returned on a failure.
+ */
+
+int unregister_netevent_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_unregister(netevent_notif_chain, nb);
+}
+
+/**
+ * call_netevent_notifiers - call all netevent notifier blocks
+ * @val: value passed unmodified to notifier function
+ * @v: pointer passed unmodified to notifier function
+ *
+ * Call all neighbour notifier blocks. Parameters and return value
+ * are as for notifier_call_chain().
+ */
+
+int call_netevent_notifiers(unsigned long val, void *v)
+{
+ return atomic_notifier_call_chain(netevent_notif_chain, val, v);
+}
+
+EXPORT_SYMBOL_GPL(register_netevent_notifier);
+EXPORT_SYMBOL_GPL(unregister_netevent_notifier);
+EXPORT_SYMBOL_GPL(call_netevent_notifiers);
-
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 Round 5 2/3] Core net changes to generate netevents
Generate netevents for:
- neighbour changes
- routing redirects
- pmtu changes
---
net/core/Makefile|2 +-
net/core/neighbour.c | 14 --
net/ipv4/route.c |8
net/ipv6/route.c |7 +++
4 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/net/core/Makefile b/net/core/Makefile
index e9bd246..2645ba4 100644
--- a/net/core/Makefile
+++ b/net/core/Makefile
@@ -7,7 +7,7 @@ obj-y := sock.o request_sock.o skbuff.o
obj-$(CONFIG_SYSCTL) += sysctl_net_core.o
-obj-y += dev.o ethtool.o dev_mcast.o dst.o \
+obj-y += dev.o ethtool.o dev_mcast.o dst.o netevent.o \
neighbour.o rtnetlink.o utils.o link_watch.o filter.o
obj-$(CONFIG_XFRM) += flow.o
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 7ad681f..5130d2e 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -29,6 +29,7 @@ #include linux/times.h
#include net/neighbour.h
#include net/dst.h
#include net/sock.h
+#include net/netevent.h
#include linux/rtnetlink.h
#include linux/random.h
#include linux/string.h
@@ -754,6 +755,7 @@ #endif
neigh-nud_state = NUD_STALE;
neigh-updated = jiffies;
neigh_suspect(neigh);
+ notify = 1;
}
} else if (state NUD_DELAY) {
if (time_before_eq(now,
@@ -762,6 +764,7 @@ #endif
neigh-nud_state = NUD_REACHABLE;
neigh-updated = jiffies;
neigh_connect(neigh);
+ notify = 1;
next = neigh-confirmed + neigh-parms-reachable_time;
} else {
NEIGH_PRINTK2(neigh %p is probed.\n, neigh);
@@ -819,6 +822,8 @@ #endif
out:
write_unlock(neigh-lock);
}
+ if (notify)
+ call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, neigh);
#ifdef CONFIG_ARPD
if (notify neigh-parms-app_probes)
@@ -926,9 +931,7 @@ int neigh_update(struct neighbour *neigh
{
u8 old;
int err;
-#ifdef CONFIG_ARPD
int notify = 0;
-#endif
struct net_device *dev;
int update_isrouter = 0;
@@ -948,9 +951,7 @@ #endif
neigh_suspect(neigh);
neigh-nud_state = new;
err = 0;
-#ifdef CONFIG_ARPD
notify = old NUD_VALID;
-#endif
goto out;
}
@@ -1022,9 +1023,7 @@ #endif
if (!(new NUD_CONNECTED))
neigh-confirmed = jiffies -
(neigh-parms-base_reachable_time 1);
-#ifdef CONFIG_ARPD
notify = 1;
-#endif
}
if (new == old)
goto out;
@@ -1056,6 +1055,9 @@ out:
(neigh-flags ~NTF_ROUTER);
}
write_unlock_bh(neigh-lock);
+
+ if (notify)
+ call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, neigh);
#ifdef CONFIG_ARPD
if (notify neigh-parms-app_probes)
neigh_app_notify(neigh);
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 2dc6dbb..19bd49d 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -104,6 +104,7 @@ #include net/tcp.h
#include net/icmp.h
#include net/xfrm.h
#include net/ip_mp_alg.h
+#include net/netevent.h
#ifdef CONFIG_SYSCTL
#include linux/sysctl.h
#endif
@@ -1125,6 +1126,7 @@ void ip_rt_redirect(u32 old_gw, u32 dadd
struct rtable *rth, **rthp;
u32 skeys[2] = { saddr, 0 };
int ikeys[2] = { dev-ifindex, 0 };
+ struct netevent_redirect netevent;
if (!in_dev)
return;
@@ -1216,6 +1218,11 @@ void ip_rt_redirect(u32 old_gw, u32 dadd
rt_drop(rt);
goto do_next;
}
+
+ netevent.old = rth-u.dst;
+ netevent.new = rt-u.dst;
+ call_netevent_notifiers(NETEVENT_REDIRECT,
+ netevent);
rt_del(hash, rth);
if (!rt_intern_hash(hash, rt, rt))
@@ -1452,6 +1459,7 @@ static void ip_rt_update_pmtu(struct dst
}
dst-metrics[RTAX_MTU-1] = mtu;
dst_set_expires(dst, ip_rt_mtu_expires);
+ call_netevent_notifiers(NETEVENT_PMTU_UPDATE, dst);
}
}
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 87c39c9..4b16371 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -53,6 +53,7 @@ #include net/tcp.h
#include linux/rtnetlink.h
#include net/dst.h
#include net/xfrm.h
+#include net/netevent.h
#include asm/uaccess.h
@@ -742,6 +743,7 @@ static void ip6_rt_update_pmtu(struct ds
Re: [stable] [PATCH] e1000: add forgotten PCI ID for supported device
On Fri, Jul 28, 2006 at 03:06:17PM -0700, Auke Kok wrote: The Intel(R) PRO/1000 82572EI card is fully supported by 7.0.33-k2 and onward. Add the device ID so this card works with 2.6.17.y onward. This device ID was accidentally omitted. Sorry, but we don't add new device support in the -stable kernel tree, it's bugfixes only. thanks, greg k-h - 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: [stable] [PATCH] e1000: add forgotten PCI ID for supported device
On Fri, 28 Jul 2006, Greg KH wrote: On Fri, Jul 28, 2006 at 03:06:17PM -0700, Auke Kok wrote: The Intel(R) PRO/1000 82572EI card is fully supported by 7.0.33-k2 and onward. Add the device ID so this card works with 2.6.17.y onward. This device ID was accidentally omitted. Sorry, but we don't add new device support in the -stable kernel tree, it's bugfixes only. In this case I believe it to be a bug in our code, instead of adding new support. The driver code supports other device IDs for this same chip. The kernel driver advertises through our probe table and in our readme that we support this device (code is in e1000_main.c) but we don't load on it correctly due to an error when we submitted the patches (e1000_hw.c/h). Patch is very simple and low risk, but it is your call. Thanks, Jesse - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [stable] [PATCH] e1000: add forgotten PCI ID for supported device
On Fri, Jul 28, 2006 at 05:04:49PM -0700, Brandeburg, Jesse wrote: On Fri, 28 Jul 2006, Greg KH wrote: On Fri, Jul 28, 2006 at 03:06:17PM -0700, Auke Kok wrote: The Intel(R) PRO/1000 82572EI card is fully supported by 7.0.33-k2 and onward. Add the device ID so this card works with 2.6.17.y onward. This device ID was accidentally omitted. Sorry, but we don't add new device support in the -stable kernel tree, it's bugfixes only. In this case I believe it to be a bug in our code, instead of adding new support. The driver code supports other device IDs for this same chip. Heh, that would be a slipery slope, as everyone who adds device ids feels that it is a bug that the driver does not support their device. If we were to allow this, there would be a _lot_ more -stable patches, which I don't think is a good thing to have. The kernel driver advertises through our probe table and in our readme that we support this device (code is in e1000_main.c) but we don't load on it correctly due to an error when we submitted the patches (e1000_hw.c/h). Patch is very simple and low risk, but it is your call. Sorry, but for now, no. Users should be able to use the sysfs bind and new_id interface to add new device support for your driver, if it's written properly :) thanks, greg k-h - 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: SMSC LAN911x and LAN921x vendor driver
Could the tasklet be replaced by using NAPI (dev-poll) 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
Re: [PATCH][SECURITY] secmark: nul-terminate secdata
James Morris wrote: The patch below fixes a problem in the iptables SECMARK target, where the user-supplied 'selctx' string may not be nul-terminated. From initial analysis, it seems that the strlen() called from selinux_string_to_sid() could run until it arbitrarily finds a zero, and possibly cause a kernel oops before then. The impact of this appears limited because the operation requires CAP_NET_ADMIN, which is essentially always root. Also, the module is not yet in wide use. Please apply. Note: some other iptables modules which handle strings supplied from userspace may require a similar fix (e.g. xt_string looks suspect at first glance). I'll look into these, but it won't be the last of these problems. At the last netfilter workshop Rusty spent some time figuring out how many iptables crashes (triggered by root) can I find in a few minutes, and it was quite a lot. So far we've hoped for pkttables to make everything better, but it looks like things like OpenVZ will beat us. - 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 3/5] [NET]: Protocol Independant Policy Routing Rules Framework
Martin Josefsson wrote: As a somewhat related note, I've just digged a bit through RCU land, talked to dipankar and mckenney, and discovered that rcu_read_lock() / rcu_read_unlock() aren't strictly needed in softirqs since preempt is already disabled in softirqs. This means that you can use the result of the rcu read-side critical outside of the rcu_read_lock() / Thats true, but in this case the code is executed both in softirq- and user-context. Using rcu_read_lock and still relying on softirq properties outside the locked section is also very confusing in my opinion. - 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: [stable] [PATCH] e1000: add forgotten PCI ID for supported device
On Fri, Jul 28, 2006 at 05:24:40PM -0700, Greg KH wrote: On Fri, Jul 28, 2006 at 05:04:49PM -0700, Brandeburg, Jesse wrote: The kernel driver advertises through our probe table and in our readme that we support this device (code is in e1000_main.c) but we don't load on it correctly due to an error when we submitted the patches (e1000_hw.c/h). Patch is very simple and low risk, but it is your call. Sorry, but for now, no. Users should be able to use the sysfs bind and new_id interface to add new device support for your driver, if it's written properly :) In this case it isn't an addition to the PCI ID table, but an actual added check in the code. You could make the argument that it is a bug since the PCI ID table says the device is supported, but it won't work w/o this additional check. Of course, the if it's written properly comment is still valid... :-) John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/4] kevent: core files.
Zach Brown wrote: Ulrich, would you be satisfied if we didn't have the userspace mapped ring on the first pass and only had a collection syscall? I'm not the one to make a call but why rush things? Let's do it right from the start. Later changes can only lead to problems with users of the earlier interface. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ signature.asc Description: OpenPGP digital signature
Re: [PATCH 4/3] forcedeth: fix NAPI hang in IRQ.
On Thu, 27 Jul 2006 19:01:14 -0700
Stephen Hemminger [EMAIL PROTECTED] wrote:
Fix for NAPI hanging in interrupt. With NAPI, we only need one
iteration over the IRQ.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- linux-2.6.orig/drivers/net/forcedeth.c2006-07-27
18:58:21.0 -0700 +++ linux-2.6/drivers/net/forcedeth.c
2006-07-27 18:57:31.0 -0700 @@ -2422,10 +2422,11 @@
dev-name, events);
}
#ifdef CONFIG_FORCEDETH_NAPI
- if (netif_rx_schedule_prep(dev)) {
- __netif_rx_schedule(dev);
+ if (events NVREG_IRQ_RX_ALL) {
+ netif_rx_schedule(dev);
nv_disable_hw_interrupts(dev,
NVREG_IRQ_RX_ALL); }
+ return IRQ_HANDLED;
#else
nv_rx_process(dev, dev-weight);
if (nv_alloc_rx(dev)) {
@@ -2434,7 +2435,6 @@
mod_timer(np-oom_kick, jiffies +
OOM_REFILL); spin_unlock(np-lock);
}
-#endif
if (i max_interrupt_work) {
spin_lock(np-lock);
/* disable interrupts on the nic */
@@ -2452,7 +2452,7 @@
spin_unlock(np-lock);
break;
}
-
+#endif
}
dprintk(KERN_DEBUG %s: nv_nic_irq completed\n, dev-name);
What on earth happened to that?
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] [IPV6]: Multiple Routing Tables
Hello. In article [EMAIL PROTECTED] (at Thu, 27 Jul 2006 00:00:02 +0200), Thomas Graf [EMAIL PROTECTED] says: Adds the framework to support multiple IPv6 routing tables. Well, one design consideration that I have had for several months is performance impact. Previously, we directly use address, ifindex etc., not flowi, in IPv6 routing code except for ip6_route_output(). This patch changes them to use flowi. I know this should work and it is a good way for abstraction. However, initializing flowi for IPv6 is more expensive than one for IPv4, and it would result in poor performance (especially without CONFIG_IPV6_MULTIPLE_TABLES). Am I too cautious? Should we eat this? --yoshfuji - 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/5] [IPV6]: Multiple Routing Tables
From: YOSHIFUJI Hideaki [EMAIL PROTECTED] Date: Sat, 29 Jul 2006 13:13:06 +0900 (JST) Previously, we directly use address, ifindex etc., not flowi, in IPv6 routing code except for ip6_route_output(). This patch changes them to use flowi. I know this should work and it is a good way for abstraction. However, initializing flowi for IPv6 is more expensive than one for IPv4, and it would result in poor performance (especially without CONFIG_IPV6_MULTIPLE_TABLES). Am I too cautious? Should we eat this? I think it is a legitimate consideration. For now I would suggest we use Thomas's approach, and we can make performance measurements to determine if it makes to optimize this or consider other methods. - 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] Multiple IPV6 Routing Tables Policy Routing
In article [EMAIL PROTECTED] (at Fri, 28 Jul 2006 12:32:29 +0200), Thomas Graf [EMAIL PROTECTED] says: * YOSHIFUJI Hideaki / ?$B5HF#1QL@ [EMAIL PROTECTED] 2006-07-28 15:10 Well, as you stated, the code is based on the work of MIPL, which is being jointly developed by Helsinki University of Technology (HUT) and USAGI/WIDE Project. Please describe this on your commit logs. Please retain copyright information as well. Please tell me which copyright I missed? Please put these lines in net/ipv6/fib6_rules.c (and maybe, its derived files): Copyright (C)2003-2006 Helsinki University of Technology Copyright (C)2003-2006 USAGI/WIDE Project You can add your own copyright notice if you want, of course. Thank you. --yoshfuji - 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/5] [IPV6]: Multiple Routing Tables
In article [EMAIL PROTECTED] (at Fri, 28 Jul 2006 21:14:28 -0700 (PDT)), David Miller [EMAIL PROTECTED] says: For now I would suggest we use Thomas's approach, and we can make performance measurements to determine if it makes to optimize this or consider other methods. Okay. --yoshfuji - 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: Please pull 'upstream-fixes' branch of wireless-2.6
pulled - 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: Please pull 'upstream' branch of wireless-2.6
pulled - 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 1/4] kevent: core files.
On Fri, 2006-07-28 at 20:38 -0700, Ulrich Drepper wrote: Zach Brown wrote: Ulrich, would you be satisfied if we didn't have the userspace mapped ring on the first pass and only had a collection syscall? I'm not the one to make a call but why rush things? Let's do it right from the start. Later changes can only lead to problems with users of the earlier interface. Speaking of API design choices, I saw your OLS paper and was wondering if you were familiar with the Solaris port APIs* and, if so, you could please comment on how your proposed event channels are different/better. * http://docs.sun.com/app/docs/doc/816-5168/6mbb3hrir?a=view -- Nicholas Miell [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
[IPV6]: Audit all ip6_dst_lookup/ip6_dst_store calls
On Fri, Jul 28, 2006 at 07:45:31PM +, Matt Domsch wrote:
Triggered on Fedora rawhide kernel-2.6.17-1.2462.fc6 x86_64 which is
based on 2.6.18rc2-git6. IPv6 was in use at the time.
=
[ INFO: inconsistent lock state ]
-
inconsistent {softirq-on-W} - {in-softirq-R} usage.
swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
(sk-sk_dst_lock){---?}, at: [80418ef3]
sk_dst_check+0x26/0x12b
{softirq-on-W} state was registered at:
[802a874d] lock_acquire+0x4a/0x69
[802672a1] _write_lock+0x24/0x31
[8044a26b] ip4_datagram_connect+0x2e1/0x350
[80451214] inet_dgram_connect+0x57/0x65
[8041652a] sys_connect+0x7d/0xa4
[8025ff0d] system_call+0x7d/0x83
Thanks for the report. This is actually a false positive because
by these two paths can't intersect since one is a UDP while the other
is TCP.
However, here is a patch which should shut up the validator as well
as removing unnecessary locking from most callers of ip6_dst_lookup.
[IPV6]: Audit all ip6_dst_lookup/ip6_dst_store calls
The current users of ip6_dst_lookup can be divided into two classes:
1) The caller holds no locks and is in user-context (UDP).
2) The caller does not want to lookup the dst cache at all.
The second class covers everyone except UDP because most people do
the cache lookup directly before calling ip6_dst_lookup. This patch
adds ip6_sk_dst_lookup for the first class.
Similarly ip6_dst_store users can be divded into those that need to
take the socket dst lock and those that don't. This patch adds
__ip6_dst_store for those (everyone except UDP/datagram) that don't
need an extra lock.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index ab29daf..96b0e66 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -139,16 +139,22 @@ extern rwlock_t rt6_lock;
/*
* Store a destination cache entry in a socket
*/
-static inline void ip6_dst_store(struct sock *sk, struct dst_entry *dst,
-struct in6_addr *daddr)
+static inline void __ip6_dst_store(struct sock *sk, struct dst_entry *dst,
+ struct in6_addr *daddr)
{
struct ipv6_pinfo *np = inet6_sk(sk);
struct rt6_info *rt = (struct rt6_info *) dst;
- write_lock(sk-sk_dst_lock);
sk_setup_caps(sk, dst);
np-daddr_cache = daddr;
np-dst_cookie = rt-rt6i_node ? rt-rt6i_node-fn_sernum : 0;
+}
+
+static inline void ip6_dst_store(struct sock *sk, struct dst_entry *dst,
+struct in6_addr *daddr)
+{
+ write_lock(sk-sk_dst_lock);
+ __ip6_dst_store(sk, dst, daddr);
write_unlock(sk-sk_dst_lock);
}
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index a8fdf79..ece7e8a 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -468,6 +468,9 @@ extern void ip6_flush_pending_frames(s
extern int ip6_dst_lookup(struct sock *sk,
struct dst_entry **dst,
struct flowi *fl);
+extern int ip6_sk_dst_lookup(struct sock *sk,
+ struct dst_entry **dst,
+ struct flowi *fl);
/*
* skb processing functions
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 9f3d4d7..610c722 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -230,7 +230,7 @@ static int dccp_v6_connect(struct sock *
ipv6_addr_copy(np-saddr, saddr);
inet-rcv_saddr = LOOPBACK4_IPV6;
- ip6_dst_store(sk, dst, NULL);
+ __ip6_dst_store(sk, dst, NULL);
icsk-icsk_ext_hdr_len = 0;
if (np-opt != NULL)
@@ -863,7 +863,7 @@ static struct sock *dccp_v6_request_recv
* comment in that function for the gory details. -acme
*/
- ip6_dst_store(newsk, dst, NULL);
+ __ip6_dst_store(newsk, dst, NULL);
newsk-sk_route_caps = dst-dev-features ~(NETIF_F_IP_CSUM |
NETIF_F_TSO);
newdp6 = (struct dccp6_sock *)newsk;
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 5a0ba58..ac85e9c 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -658,7 +658,7 @@ int inet6_sk_rebuild_header(struct sock
return err;
}
- ip6_dst_store(sk, dst, NULL);
+ __ip6_dst_store(sk, dst, NULL);
}
return 0;
diff --git a/net/ipv6/inet6_connection_sock.c b/net/ipv6/inet6_connection_sock.c
index 5c950cc..bf49107 100644
---
Re: [PATCH] via-velocity: fix reported speed and link detected status
Francois Romieu wrote: Jay Cliburn [EMAIL PROTECTED] : The via-velocity driver reports incorrect speed and link detected status as viewed by ethtool (and probably other tools). This patch fixes those incorrect reports and prettifies a long line. Looks fine. Fixed the whitespace/tabs damage, the 190 cols comment and taged as 'upstream-20060720-00' in branch 'upstream' at git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git pulled - 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/3] forcedeth: coding style cleanups
applied patches 1-2 - 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] forcdeth: NAPI support (rev3)
Previous patches in this series were applied to netdev-2.6.git#upstream. Can you resend this one + patch #4 as a single patch? 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
