This patch adds GPCS, SGMII and M88E1112 PHY support for the AMCC PPC460GT/EX processors. Signed-off-by: Victor Gallardo <vgallardo@amcc.com> --- drivers/net/ibm_newemac/core.c | 40 +++++++++++++++---- drivers/net/ibm_newemac/core.h | 3 + drivers/net/ibm_newemac/phy.c | 84 ++++++++++++++++++++++++++++++++++++++++ drivers/net/ibm_newemac/phy.h | 2 + 4 files changed, 120 insertions(+), 9 deletions(-) diff --git a/drivers/net/ibm_newemac/core.c ...

Smack needs to call netlbl_skbuff_err() to let NetLabel do the necessary protocol specific error handling. Signed-off-by: Paul Moore <paul.moore@hp.com> --- security/smack/smack_lsm.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c index 87d7541..6e2dc0b 100644 --- a/security/smack/smack_lsm.c +++ b/security/smack/smack_lsm.c @@ -2179,7 +2179,10 @@ static int smack_socket_sock_rcv_skb(struct sock *sk, ...

A new spin to fix problems pointed out by Andrew Mortion and Randy Dunlap as well as some minor things found by James Morris during review. Thanks to all three for the extra sets of eyes. This patchset also has a slight change in it which involves moving the SELinux packet parsing (to determine protocol, address, etc.) farther down in the SELinux per-packet processing routines. This should help reduce some wasted cycles, especially in the unconfigured case. I've updated both my ...

This patch accomplishes two minor tasks: add a new tag type for local labeling and rename the CIPSO_V4_MAP_STD define to CIPSO_V4_MAP_TRANS. The first change allows CIPSO to support full LSM labels/contexts, not just MLS attributes. The second change brings the mapping names inline with what userspace is using, compatibility is preserved since we don't actually change the value. Signed-off-by: Paul Moore <paul.moore@hp.com> --- include/net/cipso_ipv4.h | 13 +++-- ...

After some discussions with the Smack folks, well just Casey, I now have a better idea of what Smack wants out of NetLabel in the future so I think it is now safe to do some API "pruning". If another LSM comes along that needs this functionality we can always add it back in, but I don't see any LSMs on the horizon which might make use of these functions. Thanks to Rami Rosen who suggested removing netlbl_cfg_cipsov4_del() back in February 2008. Signed-off-by: Paul Moore ...

It turns out that checking to see if skb->sk is NULL is not a very good indicator of a forwarded packet as some locally generated packets also have skb->sk set to NULL. Fix this by not only checking the skb->sk field but also the IP[6]CB(skb)->flags field for the IP[6]SKB_FORWARDED flag. While we are at it, we are calling selinux_parse_skb() much earlier than we really should resulting in potentially wasted cycles parsing packets for information we might no use; so shuffle the code around a bit ...

NetLabel has always had a list of backpointers in the CIPSO DOI definition structure which pointed to the NetLabel LSM domain mapping structures which referenced the CIPSO DOI struct. The rationale for this was that when an administrator removed a CIPSO DOI from the system all of the associated NetLabel LSM domain mappings should be removed as well; a list of backpointers made this a simple operation. Unfortunately, while the backpointers did make the removal easier they were a bit of a mess ...

Create an ordered IP address linked list mechanism similar to the core kernel's linked list construct. The idea behind this list functionality is to create an extensibile linked list ordered by IP address mask to ease the matching of network addresses. The linked list is ordered with larger address masks at the front of the list and shorter address masks at the end to facilitate overriding network entries with individual host or subnet entries. Signed-off-by: Paul Moore ...

> drivers/net/mlx4/alloc.c:164: error: 'PAGE_KERNEL' undeclared (first use in this function) > +#include <linux/mm.h> Looks like a good fix to me. - R. --

From: Yinghai Lu <yhlu.kernel@gmail.com> after | commit f735a2a1a4f2a0f5cd823ce323e82675990469e2 | Author: Tobias Diedrich <ranma+kernel@tdiedrich.de> | Date: Sun May 18 15:02:37 2008 +0200 | | [netdrvr] forcedeth: setup wake-on-lan before shutting down | | When hibernating in 'shutdown' mode, after saving the image the suspend hook | is not called again. | However, if the device is in promiscous mode, wake-on-lan will not work. | This adds a shutdown hook to setup ...

From: Matthew Wilcox <matthew@wil.cx> Lockdep warns about the mdio_lock taken with interrupts enabled then later taken from interrupt context. Initially, I considered changing these to spin_lock_irq/spin_unlock_irq, but then I looked at atl1e_phy_init() and saw that it calls msleep(). Sleeping while holding a spinlock is not allowed either. In the probe path, we haven't registered the interrupt handler, so it can't poke at this card yet. It's before we call register_netdev(), so I don't ...

From: Christopher Li <chrisl@vmware.com> Andrey reports e1000 corruption, and that a patch in vmware's ESX fixed it. The EEPROM corruption is triggered by concurrent access of the EEPROM read/write. Putting a lock around it solve the problem. [akpm@linux-foundation.org: use DEFINE_SPINLOCK to avoid confusing lockdep] Signed-off-by: Christopher Li <chrisl@vmware.com> Reported-by: Andrey Borzenkov <arvidjaar@mail.ru> Cc: Zach Amsden <zach@vmware.com> Cc: Pratap Subrahmanyam ...

Hi, in -next tree, this patch fixes the compilation error instead of my patch. So, there is a conflict. commit 9b90dc7bc3079376567fc501e2e84751fa4040fd Author: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed Aug 27 14:45:37 2008 +1000 rr: build fix for remove CONFIG_KMOD from net Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> thanks, Hiroshi Shimamoto --

The documentation is kind of confusing. It took me some time to figure this whole thing out. Note that Linux TCP stack does not support IP checksum offload. Only TCP/UDP offload is supported - but to confuse all we have skb->ipsummed, which in reality holds the L4 partial checksum state. Also, note that the stack always does the L4 pseudo header calculation, even though the underlying device might be able to perform it. Only the L4 payload checksum is offloaded to the device. The driver ...

The Documentation/networking/bonding.txt file talks about VLAN offload support and the bonding driver, but not TCP segmentation, UDP/TCP checksum, etc, offloading. Is this supported by the bonding driver, and if so, how is it configured? If it matters, we are using bonding for HA/failover, not for bandwidth aggregation. Thanks! Cheers, Dan -- Dan Noé Software Engineer Lime Brokerage LLC 781-370-2518 --

This patch adds the capability flag to the capability list for dynamic LPAR memory remove to enable this feature. Signed-off-by: Hannes Hering <hering2@de.ibm.com> --- diff -Nurp -X dontdiff linux-2.6.27-rc5/drivers/net/ehea/ehea.h patched_kernel/drivers/net/ehea/ehea.h --- linux-2.6.27-rc5/drivers/net/ehea/ehea.h 2008-08-29 00:52:02.000000000 +0200 +++ patched_kernel/drivers/net/ehea/ehea.h 2008-09-05 15:33:12.000000000 +0200 @@ -40,13 +40,13 @@ #include <asm/io.h> #define ...

This is supported by userspace network stack, which was presented here, but I'm not sure that exactly unetstack was recommended to you. Depending on how NAT is implemented. Usually NAT software will only allow syn/ack packets before connection is established, and thus if one peer sends syn packet, and second one sends ack packet (without seeng ack first) it will work, but if second peer's NAT will send a reset packet before ack from the peer, first NAT can drop connection (as long It is ...

Hi! Recently someone mentioned on this (or maybe other...) list a seldom used technique of establishing a TCP connection without one host listening on a port, but but acting as "clients" and connecting to the peers port. My question: Can this be used to establish a TCP connection between two hosts that are both behind a (P)NAT router ? (the idea being: NAT router lets outgoing connections thru, and in this case both NAT router would see an "outgoing" connection) If yes, this would ...

Yes, but that requires either additional drivers or privileges, while TCP simultaneous open works without all that. Thanks for giving me the name of this thing ;-) I will do some experimenting at home (there goes the weekend...) Regards, David --

Thanks Alan, I didn't see that check. I'll shave a few lines off my code & send the patch again. -- best regards, D.J. Barrow --

Hi Alan, You are very close to understanding me. If my understanding of the n_tty.c code is correct it will only start throttling when there is TTY_THRESHOLD_THROTTLE i.e. 128 bytes left in the n_tty ring buffer this is a very low limit for my driver. This means that if I try to do a tty_flip_buffer_push of of a tty buffer larger than 128 bytes when the threshold is reached I will lose data. My urb buffers are 4k in size 2 buffers of this size up to the tty layer in a row quickly I believe ...

Hi Greg, Jeff Alan Tamas & others, please find a patch below, it isn't absolutely vital that it makes it into the driver but it would be nice if it did, if it is verified to be good. I've verified that it does unthrottle & appears to do the right thing I've yet to hear back from our firmware diagnostic team at option whether it really really works so I'm posting this patch a bit prematurely. The variable I'm most worried about in the patch is int curr_rx_urb_idx; I depend in all cases ...

OK but it seems that there is no way to control packet format. (beginning of packet and size of packet). Each packet must start with a specific header (on my app). This is a kind of streaming. Thanks, Johann -- Johann Baudy johaahn@gmail.com --

Hi Johann. This may be a bad sign. Or extremely needed step like in satellite links with its huge rtts. Likely in case of ethernet usage tcp/udp over IP is the way to go. -- Evgeniy Polyakov --

vmsplice() is short in comparison to splice() ~ 200us ! This was just to show you that even this vmpslice duration of 80us that is needed for each packet is too long to send only 1 packet. I really need a mechanism that allow sending of ~ 40 packets of 7200K in one system call to keep some cpu ressources to do other things. I've only observed a small performance between with and without gettimeofday().(< 1MB/s). I've used it to do a light FTRACE and to get Between kill_fasync() ...

Hi Johann. Hmmm... splice()/sendfile() shuold be able to send the whole file in This worries me a lot: sendfile should be a single syscall which very optimally creates network packets getting into account MTU and hardware capabilities. I do belive it is a problem with userspace code. -- Evgeniy Polyakov --

I've finally made the test: Packet is not going through device due to this test: if (inet->cork.length + size > 0xFFFF - fragheaderlen) { ip_local_error(sk, EMSGSIZE, rt->rt_dst, inet->dport, mtu); return -EMSGSIZE; } in ip_append_page() inet->cork.length reach 61448 then this failure occurs size = 4096 What do you mean with global offset ? Thanks, Johann -- Johann Baudy johaahn@gmail.com --

I'm leaving office right now. Ok, I see. I just need to check if UDP is fine for my application or if i need to do my own L3/L4. Many thanks again, Have a nice weekend, Johann -- Johann Baudy johaahn@gmail.com --

Hi. Great, thank you. But it should take into account UDP nature: data is Ethernet header is appended by the network core itself, likely core will just allocate skb with small data area, put there an ethernet and udp/ip headers and attach pages from the file. If hardware does not support I think matter of packet loss relevance here is just the same like with any other sending method. -- Evgeniy Polyakov --

Carsten Aulbert <carsten.aulbert@aei.mpg.de> wrote: Nope. If you're concerned about tolerance to failure, you may want to pick one port from each (one built-in port, one from the card) so if the expansion card dies you're not totally cut off. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com --

Hi Jeff & others, This patch is against the virgin linux-2.6.27-rc4 hso.c driver but should apply against 2.6.27-rc5 as well. I believe it is very well designed but owing to its complexity it might have bugs. Enjoy the patch. A new structure hso_mutex_table had to be declared statically & used as as hso_device mutex_lock(&serial->parent->mutex) etc is freed in hso_serial_open & hso_serial_close by kref_put while the mutex is still in use. This is a substantial change but should make the ...

Even with this patch, net/netlabel/netlabel_mgmt.c has build errors when CONFIG_IPV6=n: linux-next-20080904/net/netlabel/netlabel_domainhash.c:79: warning: unused variable 'tmp6' linux-next-20080904/net/netlabel/netlabel_domainhash.c:78: warning: unused variable 'iter6' linux-next-20080904/net/netlabel/netlabel_domainhash.c:340: warning: unused variable 'tmp6' linux-next-20080904/net/netlabel/netlabel_domainhash.c:301: warning: unused variable ...

Interesting, I tried to reproduce this quickly by changing my .config, running 'make oldconfig', verifying that CONFIG_IPV6 was still "n" (it was actually commented out), and then running 'make M=net/netlabel' ... the result was no error. You are correct, I obviously made a mistake in the code (which I am fixing now) but I don't understand why the steps I took above didn't -- paul moore linux @ hp --

[Empty message]

We have some reasons to kill netdev->priv: 1. netdev->priv is equal to netdev_priv(). 2. netdev_priv() wraps the calculation of netdev->priv's offset, obviously netdev_priv() is more flexible than netdev->priv. But we cann't kill netdev->priv, because so many drivers reference to it directly. OK, becasue Dave S. Miller said, "every direct netdev->priv usage is a bug", and I want to kill netdev->priv later, I decided to convert all the direct reference of netdev->priv first. Different to ...

v1->v2: - Jeff pointed out some patch's subject is not same as content. fixed. - Remove sfc driver fix, because it's already merged. - I split safe convertion to 18 parts in version-1, but I split to 4 parts here. --

For what it's worth Acked-by: Dave Dillow <dave@thedillows.org> Thanks for the diffstats on the broken up patches -- I missed this patch to typhoon last time around. It was easy to find this time. --

We have some reasons to kill netdev->priv: 1. netdev->priv is equal to netdev_priv(). 2. netdev_priv() wraps the calculation of netdev->priv's offset, obviously netdev_priv() is more flexible than netdev->priv. But we cann't kill netdev->priv, because so many drivers reference to it directly. OK, becasue Dave S. Miller said, "every direct netdev->priv usage is a bug", and I want to kill netdev->priv later, I decided to convert all the direct reference of netdev->priv first. Different to ...

Same comment as the other two; any reason we can't use netdev_priv() instead of ->ml_priv? That would be preferable. Thanks! --

We have some reasons to kill netdev->priv: 1. netdev->priv is equal to netdev_priv(). 2. netdev_priv() wraps the calculation of netdev->priv's offset, obviously netdev_priv() is more flexible than netdev->priv. But we cann't kill netdev->priv, because so many drivers reference to it directly. OK, becasue Dave S. Miller said, "every direct netdev->priv usage is a bug", and I want to kill netdev->priv later, I decided to convert all the direct reference of netdev->priv first. Different to ...

We have some reasons to kill netdev->priv: 1. netdev->priv is equal to netdev_priv(). 2. netdev_priv() wraps the calculation of netdev->priv's offset, obviously netdev_priv() is more flexible than netdev->priv. But we cann't kill netdev->priv, because so many drivers reference to it directly. OK, becasue Dave S. Miller said, "every direct netdev->priv usage is a bug", and I want to kill netdev->priv later, I decided to convert all the direct reference of netdev->priv first. Different to ...

We have some reasons to kill netdev->priv: 1. netdev->priv is equal to netdev_priv(). 2. netdev_priv() wraps the calculation of netdev->priv's offset, obviously netdev_priv() is more flexible than netdev->priv. But we cann't kill netdev->priv, because so many drivers reference to it directly. OK, becasue Dave S. Miller said, "every direct netdev->priv usage is a bug", and I want to kill netdev->priv later, I decided to convert all the direct reference of netdev->priv first. Different to ...

Signed-off-by: Wang Chen <wangchen@cn.fujitsu.com> --- drivers/net/declance.c | 2 +- drivers/net/depca.c | 40 +++++++++--------- drivers/net/dm9000.c | 32 +++++++------- drivers/net/e1000/e1000_main.c | 9 ++-- drivers/net/e1000e/netdev.c | 3 +- drivers/net/eepro.c | 4 +- drivers/net/epic100.c | 42 +++++++++--------- drivers/net/eth16i.c | 2 +- ...

We have some reasons to kill netdev->priv: 1. netdev->priv is equal to netdev_priv(). 2. netdev_priv() wraps the calculation of netdev->priv's offset, obviously netdev_priv() is more flexible than netdev->priv. But we cann't kill netdev->priv, because so many drivers reference to it directly. OK, becasue Dave S. Miller said, "every direct netdev->priv usage is a bug", and I want to kill netdev->priv later, I decided to convert all the direct reference of netdev->priv first. Different to ...

We have some reasons to kill netdev->priv: 1. netdev->priv is equal to netdev_priv(). 2. netdev_priv() wraps the calculation of netdev->priv's offset, obviously netdev_priv() is more flexible than netdev->priv. But we cann't kill netdev->priv now, because so many drivers reference to it directly. OK, becasue Dave S. Miller said, "every direct netdev->priv usage is a bug", and I want to kill netdev->priv later, I decided to convert all the direct reference of netdev->priv first. - Patch ...

We have some reasons to kill netdev->priv: 1. netdev->priv is equal to netdev_priv(). 2. netdev_priv() wraps the calculation of netdev->priv's offset, obviously netdev_priv() is more flexible than netdev->priv. But we cann't kill netdev->priv, because so many drivers reference to it directly. OK, becasue Dave S. Miller said, "every direct netdev->priv usage is a bug", and I want to kill netdev->priv later, I decided to convert all the direct reference of netdev->priv first. This patch is ...

Hm, shouldn't this be (af == AF_INET6 && ...) instead of "||"? The current expression just NF_ACCEPTs _any_ incoming IPv6 packets, even non-local ones. Julius -- Julius Volz - Corporate Operations - SysOps Google Switzerland GmbH - Identification No.: CH-020.4.028.116-1 --

The new packets that we handle are on the loopback device and no checksums appear to be generated there. I initially changed the condition to check for loopback device (which we could do), but checking udp code found that it already handled it by checking zero checksum, hence the same -- Siiralt Teie, Elektromehaaniline Põder --

From: Malcolm Turnbull <malcolm@loadbalancer.org> ipvs: load balance IPv4 connections from a local process This allows IPVS to load balance connections made by a local process. For example a proxy server running locally. External client --> pound:443 -> Local:443 --> IPVS:80 --> RealServer Signed-off-by: Siim Põder <siim@p6drad-teel.net> Signed-off-by: Malcolm Turnbull <malcolm@loadbalancer.org> Signed-off-by: Simon Horman <horms@verge.net.au> --- net/ipv4/ipvs/ip_vs_core.c | ...

No, they _do_ all get copied and the result seems correct. There must be another reason... Julius -- Julius Volz - Corporate Operations - SysOps Google Switzerland GmbH - Identification No.: CH-020.4.028.116-1 --

It was a once-off. --

On Thu, 4 Sep 2008 16:17:01 -0700 (PDT) btw if the oops was on lkml like it was here you can also just look it up on kerneloops.org via the search option which for this case finds you http://www.kerneloops.org/raw.php?rawid=59347&msgid=http://mid.gmane.org/200809041... and this has the decodecode already done and the search output at http://www.kerneloops.org/search.php?search=get_next_timer_interrupt shows that there's only been very few reports ...

Return statements shouldn't be enlosed in brackets according to The above like is >80 characters wide. It seems that that first three calls to irq_of_parse_and_map() could be moved outside of the if/else clause. mal->txeob_irq = irq_of_parse_and_map(ofdev->node, 0); mal->rxeob_irq = irq_of_parse_and_map(ofdev->node, 1); mal->serr_irq = irq_of_parse_and_map(ofdev->node, 2); if (mal_has_feature(mal, MAL_FTR_COMMON_ERR_INT)) { mal->txde_irq = mal->rxde_irq = mal->serr_irq; } else ...

You also add an actual feature (CLR_ICINSTAT). You should document that Nah. Just stick an | 0 in the enum to make it happy. Cheers, Ben. --

I guess it would be helpful to put vmlinux from this kernel build under some link (or send some gdb listing of this address). Jarek P. --

In my view... an sram node (it would be /buildin/sram on Pegasos) which defines the location of sram. In the mv643xx_eth driver you'd check if you're on Pegasos and set it up, which is what the extra code amounts to anyway. It just reduces the need to have this address hardcoded in the kernel. Or, perhaps an sram "driver" - like the sram driver on the MPC5200B which BestComm relies on. It's simply an rheap wrapper and a few extra bobbins to find the base address and suchlike from the ...

Tested, working fine, bug fixed. --

OK let's see if this is creative enough :) The next step after this patch is to kill x->all altogether and go back to the old walking method (plus the saved state). ipsec: Use RCU-like construct for saved state within a walk Now that we save states within a walk we need synchronisation so that the list the saved state is on doesn't disappear from under us. As it stands this is done by keeping the state on the list which is bad because it gets in the way of the management of the ...

Acked-by: James Morris <jmorris@namei.org> -- James Morris <jmorris@namei.org> --

Acked-by: James Morris <jmorris@namei.org> -- James Morris <jmorris@namei.org> --

Acked-by: James Morris <jmorris@namei.org> -- James Morris <jmorris@namei.org> --

Acked-by: James Morris <jmorris@namei.org> -- James Morris <jmorris@namei.org> --

Thanks Robert, The architecture of PF_RING seems to be really similar to packet mmap IO to optimize capture process. Is it planned to replace it? I'll try it to get performance. Best regards, Johann On Fri, Sep 5, 2008 at 12:28 PM, Robert Iakobashvili -- Johann Baudy johaahn@gmail.com --

Hi Johann. vmsplice() can be slow, try to inject header via usual send() call, or Amount of gettimofday() and friends is excessive, but it can be a trace tool itself. kill_fasync() also took too much time (top CPU user is at bottom I suppose?), do you use SIGIO? Also vma traveling and page checking is not what will be done in network code and your project, so it also adds an overhead. Please try without vmsplice() at all, usual splice()/sendfile() _has_ to saturate the link, otherwise we ...

Hi Julius, Hi Vince, I have applied all of these patches to the lvs-next-2.6 branch of the lvs-2.6 tree and I will ask Dave to pull these into net-next-2.6 shortly. git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-2.6.git --

Great, many thanks! Julius -- Julius Volz - Corporate Operations - SysOps Google Switzerland GmbH - Identification No.: CH-020.4.028.116-1 --

They are only used in this file, so they should be static Signed-off-by: Sven Wegener <sven.wegener@stealer.net> --- net/ipv4/ipvs/ip_vs_proto.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Simon, please apply onto lvs-next-2.6. diff --git a/net/ipv4/ipvs/ip_vs_proto.c b/net/ipv4/ipvs/ip_vs_proto.c index 50f6215..b06da1c 100644 --- a/net/ipv4/ipvs/ip_vs_proto.c +++ b/net/ipv4/ipvs/ip_vs_proto.c @@ -151,7 +151,7 @@ const char * ip_vs_state_name(__u16 proto, int state) ...

Thanks! There are probably still lots of these easy-to-miss (but bad) Yes! Julius -- Julius Volz - Corporate Operations - SysOps Google Switzerland GmbH - Identification No.: CH-020.4.028.116-1 --

Hi. By whom it was tainted? -- Evgeniy Polyakov --

Gah, not another yield in the network code we have to figure out wtf its meant to do. --

This one breaks wireless with 32bit userspace/64bit kernel. Bisected back to changeset 087d833e5a9f67ba933cb32eaf5a2279c1a5b47c: mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM -- Alex Williamson HP Open Source & Linux Org. --

No, they are skipped by the only event handler, ctnetlink. --

I hope so :) A different possiblity suggest by Pablo some time ago would be to mark untracked packets in skb->nfctinfo and not I don't think so, untracked conntracks are skipped early in the NAT It looks that way, but its not right. I think it should return false for every match except on (untracked) state. --

Ewww, can I? Regardless of netns, switching to struct nf_conntrack nf_conntrack_untracked; means we must be absolutely sure that every place which uses, say, ct->status won't get untracked conntrack. For example, does setting IPS_NAT_DONE_MASK and IPS_CONFIRMED_BIT on untracked conntracked really necessary? In conntrack_mt_v0() "ct->status" can be used even for untracked connection, --

ct == NULL would indicate either untracked or invalid. For the cases where it makes a difference, ctinfo has to be checked additionally. --

Would that work? Right now, a ct==NULL indicates the 'INVALID' state, and overloading it with 'UNTRACKED' does not seem nice. --