From: Alexander Duyck <alexander.h.duyck@intel.com> The current driver is re-registering the DCA requester after every reset. Instead of doing this we should only be updating the on board DCA registers and not unregistering/re-registering our requester. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> --- drivers/net/igb/igb_main.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git ...

Acked-by: "Eric W. Biederman" <ebiederm@xmission.com> --

--

Use genl_register_family_with_ops() instead of a copy. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Cc: Samuel Ortiz <samuel@sortiz.org> diff -urN linux-orig-mqbr/net/irda/irnetlink.c linux-mqbr/net/irda/irnetlink.c --- linux-orig-mqbr/net/irda/irnetlink.c 2009-03-24 00:12:14.000000000 +0100 +++ linux-mqbr/net/irda/irnetlink.c 2009-05-21 17:47:31.000000000 +0200 @@ -148,21 +148,8 @@ int irda_nl_register(void) { - int err, i; - - err = ...

Use genl_register_family_with_ops() instead of a copy. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> diff -urN linux-orig-mqbr/net/wireless/nl80211.c linux-mqbr/net/wireless/nl80211.c --- linux-orig-mqbr/net/wireless/nl80211.c 2009-03-24 00:12:14.000000000 +0100 +++ linux-mqbr/net/wireless/nl80211.c 2009-05-21 17:51:34.000000000 +0200 @@ -3395,18 +3395,13 @@ int nl80211_init(void) { - int err, i; + int err; - err = genl_register_family(&nl80211_fam); + err = ...

From: Michał Mirosław <mirq-linux@rere.qmqm.pl> Nice cleanup, all patches applied to net-next-2.6, dzien dobry!

Use genl_register_family_with_ops() instead of a copy. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> diff -urN linux-orig-mqbr/net/netfilter/ipvs/ip_vs_ctl.c linux-mqbr/net/netfilter/ipvs/ip_vs_ctl.c --- linux-orig-mqbr/net/netfilter/ipvs/ip_vs_ctl.c 2009-03-24 00:12:14.000000000 +0100 +++ linux-mqbr/net/netfilter/ipvs/ip_vs_ctl.c 2009-05-21 17:54:36.000000000 +0200 @@ -3345,22 +3345,8 @@ static int __init ip_vs_genl_register(void) { - int ret, i; - - ret = ...

Do not go beyond ARRAY_SIZE of iwb->data Signed-off-by: Roel Kluin <roel.kluin@gmail.com> --- Sorry for the dup, the header was incorrect. This is against linux-next. diff --git a/drivers/isdn/gigaset/isocdata.c b/drivers/isdn/gigaset/isocdata.c index fbce522..5569a6e 100644 --- a/drivers/isdn/gigaset/isocdata.c +++ b/drivers/isdn/gigaset/isocdata.c @@ -177,7 +177,7 @@ int gigaset_isowbuf_getbytes(struct isowbuf_t *iwb, int size) return -EINVAL; } src = iwb->read; - if ...

From: Roel Kluin <roel.kluin@gmail.com> You don't need to keep CC:'ing Jeff, he hasn't handled networking device driver patches for some time now. --

Do not go beyond ARRAY_SIZE of ib->btx_ring Signed-off-by: Roel Kluin <roel.kluin@gmail.com> --- diff --git a/drivers/net/sunlance.c b/drivers/net/sunlance.c index 704301a..aa2a4ef 100644 --- a/drivers/net/sunlance.c +++ b/drivers/net/sunlance.c @@ -343,7 +343,7 @@ static void lance_init_ring_dvma(struct net_device *dev) ib->phys_addr [5] = dev->dev_addr [4]; /* Setup the Tx ring entries */ - for (i = 0; i <= TX_RING_SIZE; i++) { + for (i = 0; i < TX_RING_SIZE; i++) { leptr = ...

I'm still seeing this with 2.6.30-rc6. Should I just ignore it or is it an indication of a problem/regression? Cheers, FJP --

--

From: Jiri Pirko <jpirko@redhat.com> Agreed, please use proper formatting. --

You have won £1,000,000.00 GBP. send the following: name,Age,Sex,Country Mr. Paul Adams. --

From: Arnaldo Carvalho de Melo <acme@redhat.com> Nice work, applied, thanks! --

Reducing the number of direct users of sock_{recv,send}msg. Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> diff --git a/drivers/isdn/mISDN/l1oip_core.c b/drivers/isdn/mISDN/l1oip_core.c index abe5749..8caf40e 100644 --- a/drivers/isdn/mISDN/l1oip_core.c +++ b/drivers/isdn/mISDN/l1oip_core.c @@ -279,7 +279,6 @@ l1oip_socket_send(struct l1oip *hc, u8 localcodec, u8 channel, u32 chanmask, int multi = 0; u8 frame[len+32]; struct socket *socket = NULL; - mm_segment_t oldfs; ...

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCg0KIEkg aGF2ZSBhIHJ0MjUwMHBjaSBjYXJkDQoNCiBJIG5vdGljZWQgdGhhdCBteSB3aWZpIGNvbm5lY3Rp b24gaGFzIHNsb3dlZCB3aGVuIHN0aXRjaGluZw0KZnJvbSAyLjYuMjkuMSB0byAyLjYuMjkuNCAo aXQgaXMgYWxzbyBzbG93IG9uIDMwLXJjNikNCkFsc28gMi42LjI3ICh1YnVudHUpIGRvZXMgbm90 IHN1ZmZlciBpdC4NCg0KIEkgYmlzZWN0ZWQgYW5kIGNhbWUgdG8gdGhlIGZvbGxvd2luZyBjb21t aXQgYXMgdGhlIGN1bHByaXQNCg0KIEkgY2FuIHRlc3QgcGF0Y2hlcyBhbmQgaWYgeW91IG5lZWQg bW9yZSBpbmZvIGp1c3QgYXNrLg0KDQokIGdpdCBi ...

We loan at 3% Any interested person, Contact us now Via Email:jmcloandept@ymail.com for more details, regards. --

Change the initial name of IP-over-1394 networking interfaces from "eth[0-9]+" to "firewire[0-9]+". This should have been done years ago for the reason mentioned in the inline comment. The naming issue basically prevented acceptance of IP networking over 1394 on Linux. The future IP-over1394 driver in the newer alternative firewire driver stack will use the "firewire%d" format from the start while "eth%d" will no longer be used in the new driver. Necessary changes in userland: People ...

I don't think so, stuff at the tools level usually works flawlessly with "eth0_rename_ren" devices, when things went wrong with renaming the devices. :) Kay --

From: Stefan Richter <stefanr@s5r6.in-berlin.de> I think the basis for this patch is completely bogus. Device names are just that, names. If you want to know "what it is" or "where it is" you use tools to determine that information. If you make ethtool's get info command return something useful, then the user can see that it's a firewire interface and act accordingly, as can sophisticated confiruation applications. I am completely against this patch. --

Usually I prefer brevity too. Alas, it may not be clear to many people what "fw" is supposed to mean. People might associate it with, let's say, "firewall" before "firewire" when they deal with networking. However, more opinions on this are welcome. As for practical length restrictions: The kernel's networking core requires that these names fit into 15 characters plus trailing \0. I don't have an idea whether there are userland components which have even tighter ...

From: David Howells <dhowells@redhat.com> Applied to net-2.6, thanks! --

Dear Sir/Madam, This is to notify you that your Email Address have been awarded the sum of 1,000,000 GBP in the recent Tobacco Online Promo, for claims get back to us with your full details. Names:............ Address:.............. Country:................. Age:.......... Sex:.............. Phone/cellphone........ --

Hi, Andrei Popa: > clear ip bgp * soft" > when I have three full BGP sessions the kernel it oopses. > with CONFIG_PREEMPT=y It seems we can fix this by disabling preemption while we re-balance the trie. This is with the CONFIG_CLASSIC_RCU. It's been stress-tested at high loads continuesly taking a full BGP table up/down via iproute -batch. A patch is below. Note. fib_trie is not updated for CONFIG_PREEMPT_RCU Cheers --ro Signed-off-by: Robert Olsson ...

I thought a bit more about merging FEC drivers and I see one problem more. Driver fs_enet works with FEC's with own DMA engine and fec_mpc52xx.c uses BestComm. Integration of these two drivers will need a DMA abstraction layer to keep everything clean. Unfortuanetly BestComm driver does not provide any abstraction - it only exports set of functions to deal with specific hardware: FEC and PATA. More #ifdef's will be needed to remove linking with BestComm driver if kernel will be compiled ...

From: Divy Le Ray <divy@chelsio.com> Applied. --

From: Divy Le Ray <divy@chelsio.com> Applied. --

Hi Unfortunately this is only panic report. I used cgroup net_cls subsystem, then kernel panic occured. I attach panic message and kernel config in this mail's last paragraph. If my operation is wrong, could you tell me how to use net_cls and where the documentation is. # But I think panic is very bad even if my operation is wrong. System Environment: kernel: * 2.6.29.1 on x86_64 * 2.6.29.3 on x86_64 * 2.6.30-rc6 on x86_64 (panic occurred same sequence but I ...

Agreed that we must do this earlier to avoind vlen calls to security_socket_recvmsg, but there are many callers of sock_recvmsg... Also shouldn't recvmmsg have a different LSM hook? It doesn't look right at first sight to reuse security_socket_recvmsg, as we now are passing many msghdrs and sockaddrs, etc. If security_socket_recvmsg receives the msg and inspects it, I think fully inspecting the mmsg and vlen can be something LSM policies can be interested in inspecting too, no? - ...

Hi Arnaldo. What's the difference from the single msg with multiple iovecs? Can we implement receiving from multiple sockets using this or similar interface? -- Evgeniy Polyakov --

Yep, and since they are a rather ornery bunch I'm sure they will speak up. However, I would say to go ahead and trim the unused args and if we need them in the future we can always add them back in; none of this is really visible outside the kernel so changes are relatively easy. I'd hate to see us miss an opportunity to make things better over concerns about what might happen at some unknown point in the future. -- paul moore linux @ hp --

I assume that silently ignoring flags we don't understand is a specified part of the sockets api? I was looking at the posix definition of recvmsg and I don't see where its required that we ignore unknown flags (although I can see The new system call is definately cleaner, as it lets you specify the array semantics in a way that is much more efficient and less cumbersome for both user and kernel space. I just thought I'd propose an alternate method that avoids the need for a new syscall. It ...

Hi, Its not just UDP/SOCK_DGRAM either. SOCK_SEQPACKET has to return after each message because it is not allowed to (nor can it, given the api) return more than one message in a single call. So with small messages that can add up to a lot of calls. This way the MSG_EOR flags can be preserved in the correct places, Steve. --

Yeah, like I said there is a downside to this approach, the question is how much do we care about performance and what are we willing to give up for it? Well, right now the only LSM of the three in the mainline kernel that makes use of the recvmsg hook is SELinux and in SELinux the recvmsg hook really only checks to see if the process can read from the socket - there is no access check against the message itself. In general, all of the per-packet/message access controls happen below ...

From: Neil Horman <nhorman@tuxdriver.com> Unfortunately you can't use msg flags for this. We accept any message flag we don't understand without signalling any errors. So there is no way to determine if the kernel supports the flag or not. Whereas with a socket option, we'll always get an error on older kernels for unsupported options. I think the system call is the cleanest, because it's not only a semantic change but also a data type change. I also think the socket option scheme is ...

Well, if we only check if the process can read from the socket, I also see no reasons for a new security_socket_recvmmsg nor for checking it multiple times in recvmmsg, since what changes (the msg) is of no Perhaps, but up to LSM folks to tell if this was really a case where passing the msg was something that ended up being overkill. - Arnaldo --

From: Arnaldo Carvalho de Melo <acme@redhat.com> As I discussed with Arnaldo on IRC I am OK with this kind of interface. And, also, I think we need to seriously consider the patches posted by others a few weeks ago that allowed sending to multiple receivers in one system call. The old adage about syscalls being cheap no longer holds when we're talking about traversing all the way into the protocol stack socket code every call, taking the socket lock every time, etc. So we really do need ...

[..] This should fix it: From bca277bb59b865a4e9516953dfc9818af1a7deea Mon Sep 17 00:00:00 2001 From: Florian Westphal <fw@strlen.de> Date: Thu, 21 May 2009 23:52:17 +0200 Subject: [PATCH] pktgen: do not access flows[] beyond its length typo -- pkt_dev->nflows is for stats only, the number of concurrent flows is stored in cflows. Reported-By: Vladimir Ivashchenko <hazard@francoudi.com> Signed-off-by: Florian Westphal <fw@strlen.de> --- net/core/pktgen.c | 2 +- 1 files changed, 1 ...

From: Ben Hutchings <bhutchings@solarflare.com> Indeed, it's odd, but like others I don't think we can change it at this point. --

From: ebiederm@xmission.com (Eric W. Biederman) Looks good, applied to net-next-2.6 --

--

From: Divy Le Ray <divy@chelsio.com> Applied. --

That proposal sounds fine to me from a userspace perspective. Sane implementations don't assume the interface is IFF_UP when they configure the device anyway (since it's not necessarily up at boot time or after hibernate for example), and since you need a reconfigure after rfkill, this seems reasonable. You wouldn't have to give up on txpower either, you could simply map 'txpower off' to SW-rfkill, and 'txpower on' to un-SW-rfkill, where of course the interface would be !IFF_UP after ...

I don't think recovering IFF_UP needs to be done by the kernel. rfkill already hoses the card state anyway, requiring a full setup by userspace, which usually includes ensuring the device is up (which, for example, both NM and wpa_supplicant have done since the beginning of time). Dan --

From: Jean-Mickael Guerin <jean-mickael.guerin@6wind.com> Applied, thanks! --

From: Neil Horman <nhorman@tuxdriver.com> Also applied and queued up for -stable, thanks! --

It shouldn't be a problem : the system code always disable irq before using watchdog to reboot/halt (unless I miss other watchdog usage). Matthieu --

Are you using 2.6.29 with any conntrack helper loaded? In that case this fix is not in -stable yet. device_cmp() by nf_ct_iterate_cleanup() when NETDEV_DOWN event is received. Weird, is your device going down quite often? Another possibility is that there's some entry stuck in the conntrack table that we cannot delete, perhaps we're leaking refcounts somewhere. -- "Los honestos son inadaptados sociales" -- Les Luthiers --

The cxgb3 driver has had skb_orphan in its transmit routine forever (also due to lack of Tx interrupts) and I am not aware of adverse effects caused by doing so. It does skip skb_orphan when skb_shared but probably nobody sends sharead skbs with destructors. The only application I know of that has trouble with lazy skb freeing is pktgen because it treats freeing as an indication that the packet has been transmitted so it's thrown off if packets sit there for a while. (Also freeing ...

OK. Will submit a patch for this. Regards, Chaithrika --

Could we detect this at runtime and emit a warning (once) ? Or should we assume guys using this stuff should be smart enough ? I confess I made this error once and this was not so easy to spot... --

Can I balance only by destination IP using this approach? Normal IP flow-based balancing is not good for me, I need Yes indeed :( I'm trying to migrate from 2.6.21 eth/htb/esfq to 2.6.29 bond/htb/sfq, and that introduces a lot of changes. Apparently during some point I changed sfq divisor from 1024 to 2048 and forgot about it. Now I realize that the problems I reported were as follows: 1) HTB exceeds target when I use HTB + sfq + divisor 1024 2) HFSC exceeds target when I use ...

I still have no clue about the reason, but it would be really nice to do some short test with more current kernel (>= 2.6.27) and iproute2 (to exclude the possibility of some incomaptibility in configs e.g. rate tables passed to htb). Thanks, Jarek P. --

From: Neil Horman <nhorman@tuxdriver.com> If skbuff.h gets you the declaration for "struct napi_struct" it's via some indirect accident rather than it actually being in linux/skbuff.h Please include the correct headers, thanks. --

Thank you Dave, copy n' paste bit me. Patch v6 Change notes: 1) updated header file in trace/napi.h to include netdevice.h so that I correctly pull in struct napi_struct definition Neil Patch to add the ability to detect drops in hardware interfaces via dropwatch. Adds a tracepoint to net_rx_action to signal everytime a napi instance is polled. The dropmon code then periodically checks to see if the rx_frames counter has changed, and if so, adds a drop notification to the ...

From: "Hong H. Pham" <hong.pham@windriver.com> Thanks for doing this testing, I'll think about how to attack this bug. --

This change gave me about 15% increase in bandwidth in a multiflow tcp benchmark. But this optimization worked because tasks could be wakeup and send their answer in the same jiffies, and 'rearming' the xmit timer with the same value... (135.000 messages received/sent per second in my benchmark, with 60 flows) mod_timer() has special heuristic to avoid calling __mod_timer() int mod_timer(struct timer_list *timer, unsigned long expires) { /* * This is a common ...