* Re: [PATCH] ep93xx-eth: convert to phylib
From: David Miller @ 2011-06-05 21:06 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, hvr, kernel, mika.westerberg, hsweeten, ryan,
linux-arm-kernel
In-Reply-To: <201106052029.24742.f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Sun, 5 Jun 2011 20:29:24 +0200
> On Sunday 05 June 2011 19:57:36 Florian Fainelli wrote:
>> ep93xx-eth lacked support for monitoring link status changes, with this
>> patch, link changes are now watched and reported correctly.
>>
>> Signed-off-by: Florian Fainelli <florian@openwrt.org>
>> ---
>
> I just stumbled upon: http://www.mail-
> archive.com/netdev@vger.kernel.org/msg62549.html
> which does not seem to have been merged.
>
> I will respin my patch with Herbert's changes
If people wonder why things don't get merged in situations like
this it's because there is no clear person standing up to act as
a maintainer.
Instead there are several different people submitting changes to
this one driver and I haven't got a clue who is authoritative and
who is not.
So 9 times out of ten I'm not going to merge anything submitted
in this way unless I start to see lots of ACKs from other developers.
When it gets to the point where multiple people are touching the
driver in all sorts of ways, there needs to be someone to do all of
the merging and making sure the patches get applied in the right order
and handling merge conflicts handled properly. Then they submit them
formally here as a sane single set of patches to the list.
So who is going to step up and be the ep93xx-eth maintainer? Lennert
is listed in MAINTAINERS, but I see little to no activity from him.
The last ACK Lennert gave for a patch to this driver was in May 2010,
more than a year ago.
^ permalink raw reply
* Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth
From: David Miller @ 2011-06-05 21:08 UTC (permalink / raw)
To: mika.westerberg; +Cc: ynezz, netdev, hsweeten, ryan, kernel, linux-arm-kernel
In-Reply-To: <20110605085948.GB16018@acer>
From: Mika Westerberg <mika.westerberg@iki.fi>
Date: Sun, 5 Jun 2011 11:59:48 +0300
> It looks like David Miller (CC'd) has been taking care of ep93xx_eth.c maybe
> he knows this better.
Someone needs to step up and take over as the real maintainer of this
driver. The way the driver is currently being hacked on is
unsustainable.
^ permalink raw reply
* Re: [PATCH] fix return values of l2tp_dfs_seq_open()
From: David Miller @ 2011-06-05 21:11 UTC (permalink / raw)
To: viro; +Cc: netdev, jchapman
In-Reply-To: <20110605105403.GC11521@ZenIV.linux.org.uk>
From: Al Viro <viro@ZenIV.linux.org.uk>
Date: Sun, 5 Jun 2011 11:54:03 +0100
> More fallout from struct net lifetime rules review: PTR_ERR() is *already*
> negative and failing ->open() should return negatives on failure.
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Al, I applied this and your get_net_ns_by_fd() fix to my net-2.6
tree.
Thanks!
^ permalink raw reply
* Re: [PATCH] vlan: Fix the ingress VLAN_FLAG_REORDER_HDR check v2
From: David Miller @ 2011-06-05 21:14 UTC (permalink / raw)
To: xiaosuo
Cc: pratnakarlx, ebiederm, shemminger, greearb, nicolas.2p.debian,
jpirko, netdev, kaber, fubar, eric.dumazet, andy, jesse
In-Reply-To: <BANLkTikM1TuO_S9LuJv30uV9oGgLjE09Xw@mail.gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Fri, 3 Jun 2011 11:59:26 +0800
> On Fri, Jun 3, 2011 at 11:34 AM, padmanabh ratnakar
> <pratnakarlx@gmail.com> wrote:
>> Doesnt __vlan_put_tag()/vlan_insert_tag() depend on skb->data pointing
>> to ethernet header.
>> Is'nt the skb->data pointing past ethernet header in netif_receive_skb().
>> Am I missing anything?
>
> Yes, you are right. skb->data should be adjusted before feeding to
> vlan_insert_tag(), or we make vlan_insert_tag() rely on
> skb->mac_header instead.
I told you guys this is not simple stuff :-)
Even here we have 3 or 4 people who study this code all the time, and
are still having trouble sorting out all of these details.
^ permalink raw reply
* Re: [PATCH 1/2] af-packet: Hold reference to bound network devices.
From: David Miller @ 2011-06-05 21:16 UTC (permalink / raw)
To: greearb; +Cc: netdev
In-Reply-To: <1306948733-22441-1-git-send-email-greearb@candelatech.com>
From: greearb@candelatech.com
Date: Wed, 1 Jun 2011 10:18:52 -0700
> From: Ben Greear <greearb@candelatech.com>
>
> Old code was probably safe, but with this change we
> can actually use the netdev object, not just compare
> the pointer values.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 2/2 v3] af-packet: Use existing netdev reference for bound sockets.
From: David Miller @ 2011-06-05 21:16 UTC (permalink / raw)
To: greearb; +Cc: netdev
In-Reply-To: <1306948733-22441-2-git-send-email-greearb@candelatech.com>
From: greearb@candelatech.com
Date: Wed, 1 Jun 2011 10:18:53 -0700
> From: Ben Greear <greearb@candelatech.com>
>
> This saves a network device lookup on each packet transmitted,
> for sockets that are bound to a network device.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] qlcnic: Fix bug in FW queue dump
From: David Miller @ 2011-06-05 21:18 UTC (permalink / raw)
To: anirban.chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1307054541-11178-1-git-send-email-anirban.chakraborty@qlogic.com>
From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Date: Thu, 2 Jun 2011 15:42:21 -0700
> Due to a change in FW template, a bug was introduced in dump queue entries. This is
> fixed by reinitializing queue address before looping for each que dump operation.
>
> Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH] qlcnic: Avoid double free of skb in tx path
From: David Miller @ 2011-06-05 21:18 UTC (permalink / raw)
To: anirban.chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver, sucheta.chakraborty
In-Reply-To: <1307116338-1686-1-git-send-email-anirban.chakraborty@qlogic.com>
From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Date: Fri, 3 Jun 2011 08:52:18 -0700
> From: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
>
> buffer->skb should be marked NULL to avoid double free of the skb.
>
> Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
> Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] vlan: only create special VLAN 0 once
From: David Miller @ 2011-06-05 21:28 UTC (permalink / raw)
To: jbohac; +Cc: kaber, netdev, pedro.netdev
In-Reply-To: <20110603200738.GA24804@midget.suse.cz>
From: Jiri Bohac <jbohac@suse.cz>
Date: Fri, 3 Jun 2011 22:07:38 +0200
> Commit ad1afb00 registers a VLAN with vid == 0 for every device to handle
> 802.1p frames. This is currently done on every NETDEV_UP event and the special
> vlan is never unregistered. This may have strange effects on drivers
> implementning ndo_vlan_rx_add_vid(). E.g. bonding will allocate a linked-list
> element each time, causing a memory leak.
>
> Only register the special VLAN once on NETDEV_REGISTER.
>
> Signed-off-by: Jiri Bohac <jbohac@suse.cz>
I recognize the problem, but this solution isn't all that good.
I am pretty sure that the hardware device driver methods that
implement ndo_vlan_rx_add_vid() assume that the device is up.
Because most drivers completely reset the chip when the
interface is brought up and this will likely clear out the
VLAN ID tables in the chip.
Second, now even devices which don't ever get brought up will
have the VLAN ID 0 thing allocated.
Probably the thing to do is to remove the VLAN ID 0 entry on
NETDEV_DOWN.
Something like:
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index c7a581a..135019d 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -379,6 +379,14 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
dev->netdev_ops->ndo_vlan_rx_add_vid(dev, 0);
}
+ if ((event == NETDEV_DOWN) &&
+ (dev->features & NETIF_F_HW_VLAN_FILTER) &&
+ dev->netdev_ops->ndo_vlan_rx_kill_vid) {
+ pr_info("8021q: removing VLAN 0 from HW filter on device %s\n",
+ dev->name);
+ dev->netdev_ops->ndo_vlan_rx_kill_vid(dev, 0);
+ }
+
grp = rtnl_dereference(dev->vlgrp);
if (!grp)
goto out;
^ permalink raw reply related
* Re: [PATCH] bonding: reset queue mapping prior to transmission to physical device (v5)
From: David Miller @ 2011-06-05 21:32 UTC (permalink / raw)
To: fubar; +Cc: nhorman, netdev, andy
In-Reply-To: <26637.1307143866@death>
From: Jay Vosburgh <fubar@us.ibm.com>
Date: Fri, 03 Jun 2011 16:31:06 -0700
> Neil Horman <nhorman@tuxdriver.com> wrote:
>
>>The bonding driver is multiqueue enabled, in which each queue represents a slave
>>to enable optional steering of output frames to given slaves against the default
>>output policy. However, it needs to reset the skb->queue_mapping prior to
>>queuing to the physical device or the physical slave (if it is multiqueue) could
>>wind up transmitting on an unintended tx queue
>>
>>Change Notes:
>>v2) Based on first pass review, updated the patch to restore the origional queue
>>mapping that was found in bond_select_queue, rather than simply resetting to
>>zero. This preserves the value of queue_mapping when it was set on receive in
>>the forwarding case which is desireable.
>>
>>v3) Fixed spelling an casting error in skb->cb
>>
>>v4) fixed to store raw queue_mapping to avoid double decrement
>>
>>v5) Eric D requested that ->cb access be wrapped in a macro.
>
> Shouldn't the change log go below the "---" so it doesn't end up
> in the git commit log?
Yes, usually, however in this case Neil's change notes give some
important information about why the patch is implemented the way it
is, especially the notes about "v2" so I left them in the commit
message.
> In any event, I looked for ways into bond_dev_queue_xmit without
> first passing through bond_select_queue (lest stale cb[] data intrude),
> and I don't see any, so I think this is ok.
>
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: drivers/net: include/net: Remove unnecessary semicolons
From: David Miller @ 2011-06-05 21:34 UTC (permalink / raw)
To: joe; +Cc: netdev
In-Reply-To: <cover.1307137351.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Fri, 3 Jun 2011 14:51:18 -0700
> Done via perl script:
...
> Joe Perches (3):
> net: Remove unnecessary semicolons
> drivers/net: Remove unnecessary semicolons
> include/net: Remove unnecessary semicolons
All applied, thanks Joe.
I remember earlier in my programming that I was robotically
putting that trailing semicolon at the end of switch statements
:-)
^ permalink raw reply
* Re: [PATCH kernel 3.0-rc1] smc91c92_cs: set smc->base to NULL before iounmap
From: David Miller @ 2011-06-05 21:38 UTC (permalink / raw)
To: ken_kawasaki; +Cc: netdev
In-Reply-To: <20110605082016.5a26f61a.ken_kawasaki@spring.nifty.jp>
From: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Date: Sun, 5 Jun 2011 08:20:16 +0900
>
> smc91c92_cs:
> set smc->base to NULL before iounmap
> to avoid writing to smc->base in smc_interrupt.
>
> Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
The device should be completely made quiet and all interrupts
synchronized before unmapping chip registers. Using NULL checks
is merely a workaround for the real problem, even though you take
great pains to assign NULL before the iounmap() call.
Perhaps putting the pcmcia_disable_device() call before the iounmap()
will be sufficient to fix this bug. Or perhaps that, plus a call to
synchronize_irq() or similar.
^ permalink raw reply
* Re: [PATCH] net: fix smc91x.c device tree support
From: David Miller @ 2011-06-06 0:03 UTC (permalink / raw)
To: grant.likely; +Cc: netdev, linux-kernel, thomas
In-Reply-To: <20110604073127.27163.47519.stgit@ponder>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Sat, 04 Jun 2011 01:31:27 -0600
> Fix missing semicolon at end of smc91x.c match tabledevice driver.
> Also remove unnecessary #ifdef around of_match_table pointer.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Applied, thanks Grant.
^ permalink raw reply
* [PATCH] iwlwifi: remove unecessary if statement
From: Greg Dietsche @ 2011-06-06 0:30 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: wey-yi.w.guy-ral2JQCrhuEAvxtiuMwx3w, ilw-VuQAYsv1563Yd54FQh9/CA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Greg Dietsche
the code always returns ret regardless, so if(ret) check is unecessary.
Signed-off-by: Greg Dietsche <Gregory.Dietsche-5+R7UueiBCQ@public.gmane.org>
---
drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c b/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
index a95ad84..e40ad23 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
@@ -163,9 +163,6 @@ static int iwlagn_send_rxon_assoc(struct iwl_priv *priv,
ret = iwl_send_cmd_pdu_async(priv, ctx->rxon_assoc_cmd,
sizeof(rxon_assoc), &rxon_assoc, NULL);
- if (ret)
- return ret;
^ permalink raw reply related
* [PATCH] qlge: remove unecessary if statement
From: Greg Dietsche @ 2011-06-06 0:44 UTC (permalink / raw)
To: ron.mercer; +Cc: linux-driver, netdev, linux-kernel, Greg Dietsche
the code always returns 'status' regardless, so if(status) check is unecessary.
Signed-off-by: Greg Dietsche <Gregory.Dietsche@cuw.edu>
---
drivers/net/qlge/qlge_ethtool.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/qlge/qlge_ethtool.c b/drivers/net/qlge/qlge_ethtool.c
index 19b00fa..9b67bfe 100644
--- a/drivers/net/qlge/qlge_ethtool.c
+++ b/drivers/net/qlge/qlge_ethtool.c
@@ -650,8 +650,6 @@ static int ql_set_pauseparam(struct net_device *netdev,
return -EINVAL;
status = ql_mb_set_port_cfg(qdev);
- if (status)
- return status;
return status;
}
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCHv2 RFC 0/4] virtio and vhost-net capacity handling
From: Rusty Russell @ 2011-06-06 3:39 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Krishna Kumar, Carsten Otte, lguest-uLR06cmDAlY/bJ5BZ2RsiQ,
Shirley Ma, kvm-u79uwXL29TY76Z2rM5mHXA,
linux-s390-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
habanero-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8, Heiko Carstens,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
steved-r/Jw6+rmf7HQT0dZR+AlfA, Christian Borntraeger,
Tom Lendacky, Martin Schwidefsky, linux390-tA70FqPdS9bQT0dZR+AlfA
In-Reply-To: <20110602171721.GA13215-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Thu, 2 Jun 2011 20:17:21 +0300, "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, Jun 02, 2011 at 06:42:35PM +0300, Michael S. Tsirkin wrote:
> > OK, here's a new attempt to use the new capacity api. I also added more
> > comments to clarify the logic. Hope this is more readable. Let me know
> > pls.
> >
> > This is on top of the patches applied by Rusty.
> >
> > Warning: untested. Posting now to give people chance to
> > comment on the API.
> >
> > Changes from v1:
> > - fix comment in patch 2 to correct confusion noted by Rusty
> > - rewrite patch 3 along the lines suggested by Rusty
> > note: it's not exactly the same but I hope it's close
> > enough, the main difference is that mine does limited
> > polling even in the unlikely xmit failure case.
> > - added a patch to not return capacity from add_buf
> > it always looked like a weird hack
> >
> > Michael S. Tsirkin (4):
> > virtio_ring: add capacity check API
> > virtio_net: fix tx capacity checks using new API
> > virtio_net: limit xmit polling
> > Revert "virtio: make add_buf return capacity remaining:
> >
> > drivers/net/virtio_net.c | 111 ++++++++++++++++++++++++++----------------
> > drivers/virtio/virtio_ring.c | 10 +++-
> > include/linux/virtio.h | 7 ++-
> > 3 files changed, 84 insertions(+), 44 deletions(-)
> >
> > --
> > 1.7.5.53.gc233e
>
>
> And just FYI, here's a patch (on top) that I considered but
> decided against. This does a single get_buf before
> xmit. I thought it's not really needed as the capacity
> check in add_buf is relatively cheap, and we removed
> the kick in xmit_skb. But the point is that the loop
> will now be easy to move around if someone manages
> to show this benefits speed (which I doubt).
Agreed. The other is clearer.
I like the approach these patches take. Testing is required, but I
think the final result is a neater driver than the current one, as well
as having nicer latency.
Thanks,
Rusty.
^ permalink raw reply
* Re: [PATCHv3] net: Define enum for the bits used in features.
From: Michael S. Tsirkin @ 2011-06-06 3:58 UTC (permalink / raw)
To: David Miller; +Cc: maheshb, netdev, therbert, mirqus, shemminger
In-Reply-To: <20110604.133438.1450652272927306428.davem@davemloft.net>
On Sat, Jun 04, 2011 at 01:34:38PM -0700, David Miller wrote:
> From: Mahesh Bandewar <maheshb@google.com>
> Date: Wed, 25 May 2011 15:42:16 -0700
>
> > Little bit cleanup by defining enum for all bits used. Also use those enum
> > values to redefine flags.
> >
> > Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> > ---
> > Changes since v2:
> > (1) Removed the include which was part of the other patch (split mishap).
> > (2) Changed the enums to add NETIF_F_ prefix.
>
> I hate to be a pain after you've put so much work into these patches,
> but I simply don't like this approach.
>
> I think the abstracted interfaces should come first. You don't need to
> change any of the NETIF_F_* defines in order to do that. You should only
> need to add the netdev_{set,clear,test}_*() macros.
>
> If you want you can make the "bit" argument be the flag name after the
> NETIF_F_ prefix, so "netdev_test_active_feature(dev, SG)"
>
> Then you convert every single access.
>
> Then you make the flags type opaque, which should at that point be a
> 6 line change at best.
>
> And then you can implement the flags however you want.
I've been thinking about this as well. It turns out most
things above can be done with the spatch (aka coccinelle) tool.
But I think the largest problem is what to do with multiple-feature
macros such as NETIF_F_GSO_SOFTWARE.
If we keep them an 'or' of bits, we more or less commit to
an implementation that can represent them all in a single
constant.
I played with variadic macros but could not come up with something
that does not generate a lot of code.
Ideas?
--
MST
^ permalink raw reply
* Re: 3.0.0-rc1: dmesg shows 'wlan%d' instead of 'wlan0'
From: Mohammed Shafi @ 2011-06-06 4:43 UTC (permalink / raw)
To: Sergei Trofimovich; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20110605201042.21c86763@sf>
On Sun, Jun 5, 2011 at 10:40 PM, Sergei Trofimovich <slyich@gmail.com> wrote:
> Recently I've noticed small discrepancy in dmesg:
>
> $ { zcat messages.2.gz messages.1.gz; cat messages; } | egrep "(deauthen|Linux version)"
> ...
> May 21 22:01:31 sf kernel: [ 0.000000] Linux version 2.6.39-00004-g29c77fa (slyfox@sf) (gcc version 4.4.5 (Gentoo 4.4.5 p1.2, pie-0.4.5) ) #116 SMP PREEMPT Thu May 19 22:46:16 EEST 2011
> May 24 05:37:54 sf kernel: [81845.885094] wlan0: deauthenticated from ...
>
> Jun 1 22:38:38 sf kernel: [ 0.000000] Linux version 3.0.0-rc1-00035-g79f3f61 (slyfox@sf) (gcc version 4.4.5 (Gentoo 4.4.5 p1.2, pie-0.4.5) ) #118 SMP PREEMPT Wed Jun 1 22:14:46 EEST 2011
> Jun 1 23:41:23 sf kernel: [ 3877.773727] wlan%d: deauthenticating from ...
>
> Jun 1 23:42:16 sf kernel: [ 0.000000] Linux version 3.0.0-rc1-00035-g79f3f61-dirty (slyfox@sf) (gcc version 4.4.5 (Gentoo 4.4.5 p1.2, pie-0.4.5) ) #119 SMP PREEMPT Wed Jun 1 23:35:43 EEST 2011
> Jun 2 07:35:10 sf kernel: [ 5972.879970] wlan%d: deauthenticated from ...
>
> Here we see 'wlan0' -> 'wlan%d' switch. I presume those lines go from firmware
> (and not from userspace).
>
> The card is an iwl4965
>
> 10:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61)
this seems to be fixed by the following commit which was recently
merged in wireless-testing
commit 59e7e7078d6c2c6294caf454c6e3695f9d3e46a2
Author: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Date: Thu Jun 2 17:28:37 2011 -0300
mac80211: call dev_alloc_name before copying name to sdata
This partially reverts 1c5cae815d19ffe02bdfda1260949ef2b1806171, because
the netdev name is copied into sdata->name, which is used for debugging
messages, for example. Otherwise, we get messages like this:
wlan%d: authenticated
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Cc: Jiri Pirko <jpirko@redhat.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: "John W. Linville" <linville@tuxdriver.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
are we still getting it?
>
> --
>
> Sergei
>
--
shafi
^ permalink raw reply
* Re: [PATCHv3] net: Define enum for the bits used in features.
From: David Miller @ 2011-06-06 5:15 UTC (permalink / raw)
To: mst; +Cc: maheshb, netdev, therbert, mirqus, shemminger
In-Reply-To: <20110606035808.GA28858@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 6 Jun 2011 06:58:08 +0300
> I've been thinking about this as well. It turns out most
> things above can be done with the spatch (aka coccinelle) tool.
> But I think the largest problem is what to do with multiple-feature
> macros such as NETIF_F_GSO_SOFTWARE.
>
> If we keep them an 'or' of bits, we more or less commit to
> an implementation that can represent them all in a single
> constant.
>
> I played with variadic macros but could not come up with something
> that does not generate a lot of code.
Since the GSO accessors deal with mutliple bits, you can create
special GSO specific interfaces to manipulate them.
^ permalink raw reply
* Re: [PATCH] ep93xx-eth: convert to phylib
From: Florian Fainelli @ 2011-06-06 5:15 UTC (permalink / raw)
To: David Miller
Cc: netdev, hvr, kernel, mika.westerberg, hsweeten, ryan,
linux-arm-kernel
In-Reply-To: <20110605.140657.1039864716002412071.davem@davemloft.net>
On Sunday 05 June 2011 23:06:57 David Miller wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Sun, 5 Jun 2011 20:29:24 +0200
>
> > On Sunday 05 June 2011 19:57:36 Florian Fainelli wrote:
> >> ep93xx-eth lacked support for monitoring link status changes, with this
> >> patch, link changes are now watched and reported correctly.
> >>
> >> Signed-off-by: Florian Fainelli <florian@openwrt.org>
> >> ---
> >
> > I just stumbled upon: http://www.mail-
> > archive.com/netdev@vger.kernel.org/msg62549.html
> > which does not seem to have been merged.
> >
> > I will respin my patch with Herbert's changes
>
> If people wonder why things don't get merged in situations like
> this it's because there is no clear person standing up to act as
> a maintainer.
No problem here so far.
>
> Instead there are several different people submitting changes to
> this one driver and I haven't got a clue who is authoritative and
> who is not.
>
> So 9 times out of ten I'm not going to merge anything submitted
> in this way unless I start to see lots of ACKs from other developers.
>
> When it gets to the point where multiple people are touching the
> driver in all sorts of ways, there needs to be someone to do all of
> the merging and making sure the patches get applied in the right order
> and handling merge conflicts handled properly. Then they submit them
> formally here as a sane single set of patches to the list.
>
> So who is going to step up and be the ep93xx-eth maintainer? Lennert
> is listed in MAINTAINERS, but I see little to no activity from him.
Lennert, do you still have time, hardware and will to maintain that driver?
>
> The last ACK Lennert gave for a patch to this driver was in May 2010,
> more than a year ago.
--
Florian
^ permalink raw reply
* Re: Skipping past TCP lost packet in userspace
From: Josh Lehan @ 2011-06-06 6:30 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: Josh Lehan, netdev
In-Reply-To: <alpine.DEB.2.00.1106031428280.17529@wel-95.cs.helsinki.fi>
On 06/03/2011 04:51 AM, Ilpo Järvinen wrote:
> And you'd send a cumulative ACK without the actual data segment...?
> ...That's gonna break many middleboxes which would want to see that
> data segment too ...And there goes your "viability" (though with luck it
> will _sometimes_ work as rexmit of the data segment is already in flight).
No, there would be no wire-visible change. This idea was explored at
first, and then rejected. As you mentioned, this would break many
middleboxes. It would rightfully be considered an "optimistic ACK attack".
The late data segment would have to eventually arrive. It would either
be dropped, if the userspace application had already skipped beyond that
point, or better yet, it could be re-inserted into the data stream (if
too late for live playback, then it could at least be saved into the
rewind buffer, or saved to disk if the user is doing that).
> In addition, such a non-legimite cumulative ACK probably violates number
> of TCP RFCs or at least assumptions made in them... e.g., for starters,
> please explain which timestamp you would be putting there into that
> particular cumulative ACK?
It wouldn't change anything on the wire. As you mentioned, timestamps
remain a good defense for guarding against optimistic ACK attacks.
Josh Lehan
^ permalink raw reply
* [PATCH 1/3] xfrm: Fix off by one in the replay advance functions
From: Steffen Klassert @ 2011-06-06 6:46 UTC (permalink / raw)
To: David Miller, Herbert Xu; +Cc: netdev
We may write 4 byte too much when we reinitialize the anti replay
window in the replay advance functions. This patch fixes this by
adjusting the last index of the initialization loop.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_replay.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/xfrm/xfrm_replay.c b/net/xfrm/xfrm_replay.c
index 47f1b86..b11ea69 100644
--- a/net/xfrm/xfrm_replay.c
+++ b/net/xfrm/xfrm_replay.c
@@ -265,7 +265,7 @@ static void xfrm_replay_advance_bmp(struct xfrm_state *x, __be32 net_seq)
bitnr = bitnr & 0x1F;
replay_esn->bmp[nr] |= (1U << bitnr);
} else {
- nr = replay_esn->replay_window >> 5;
+ nr = (replay_esn->replay_window - 1) >> 5;
for (i = 0; i <= nr; i++)
replay_esn->bmp[i] = 0;
@@ -471,7 +471,7 @@ static void xfrm_replay_advance_esn(struct xfrm_state *x, __be32 net_seq)
bitnr = bitnr & 0x1F;
replay_esn->bmp[nr] |= (1U << bitnr);
} else {
- nr = replay_esn->replay_window >> 5;
+ nr = (replay_esn->replay_window - 1) >> 5;
for (i = 0; i <= nr; i++)
replay_esn->bmp[i] = 0;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] ipv4: Fix packet size calculation for IPsec packets in __ip_append_data
From: Steffen Klassert @ 2011-06-06 6:48 UTC (permalink / raw)
To: David Miller, Herbert Xu; +Cc: netdev, Eric Dumazet
In-Reply-To: <20110606064603.GB31505@secunet.com>
Git commit 59104f06 (ip: take care of last fragment in ip_append_data)
added a check to see if we exceed the mtu when we add trailer_len.
However, the mtu is already subtracted by trailer_len when the
xfrm transfomation bundles are set up. So IPsec packets with mtu
size get fragmented, or if the DF bit is set the packets will not
be send even though they match the mtu perfectly fine. This patch
actually reverts commit 59104f06.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/ip_output.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 98af369..a16859b 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -888,12 +888,9 @@ alloc_new_skb:
* because we have no idea what fragment will be
* the last.
*/
- if (datalen == length + fraggap) {
+ if (datalen == length + fraggap)
alloclen += rt->dst.trailer_len;
- /* make sure mtu is not reached */
- if (datalen > mtu - fragheaderlen - rt->dst.trailer_len)
- datalen -= ALIGN(rt->dst.trailer_len, 8);
- }
+
if (transhdrlen) {
skb = sock_alloc_send_skb(sk,
alloclen + hh_len + 15,
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/3] ipv4: Fix packet size calculation for raw IPsec packets in __ip_append_data
From: Steffen Klassert @ 2011-06-06 6:48 UTC (permalink / raw)
To: David Miller, Herbert Xu; +Cc: netdev
In-Reply-To: <20110606064603.GB31505@secunet.com>
We assume that transhdrlen is positive on the first fragment
which is wrong for raw packets. So we don't add exthdrlen to the
packet size for raw packets. This leads to a reallocation on IPsec
because we have not enough headroom on the skb to place the IPsec
headers. This patch fixes this by adding exthdrlen to the packet
size whenever the send queue of the socket is empty. This issue was
introduced with git commit 1470ddf7 (inet: Remove explicit write
references to sk/inet in ip_append_data)
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/ip_output.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index a16859b..6b894d4 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -799,7 +799,9 @@ static int __ip_append_data(struct sock *sk,
int csummode = CHECKSUM_NONE;
struct rtable *rt = (struct rtable *)cork->dst;
- exthdrlen = transhdrlen ? rt->dst.header_len : 0;
+ skb = skb_peek_tail(queue);
+
+ exthdrlen = !skb ? rt->dst.header_len : 0;
length += exthdrlen;
transhdrlen += exthdrlen;
mtu = cork->fragsize;
@@ -825,8 +827,6 @@ static int __ip_append_data(struct sock *sk,
!exthdrlen)
csummode = CHECKSUM_PARTIAL;
- skb = skb_peek_tail(queue);
-
cork->length += length;
if (((length > mtu) || (skb && skb_is_gso(skb))) &&
(sk->sk_protocol == IPPROTO_UDP) &&
--
1.7.0.4
^ permalink raw reply related
* Re: bridge/netfilter: regression in 2.6.39.1
From: Alexander Holler @ 2011-06-06 6:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, David Miller, Herbert Xu, netdev
In-Reply-To: <4DEA1F5F.4070707@ahsoftware.de>
Hello,
Am 04.06.2011 14:04, schrieb Alexander Holler:
> Anyway, I've used the broken way of not using git send-email because I'm
> unsure if the solution I've offered is the best one. I'm lacking the
> knowledge about what cow_metrics() does, what it is used for, and what,
> if any, pre- or post-requisites are needed to use
> dst_cow_metrics_generic().
>
> I can only say that my solution seems to work here, the machine comes up
> without an oops and I didn't have seen any other problems while using
> the bridge (which surely doesn't say anything, e.g. I'm not sure if my
> use of dst_cow_metrics_generic() may introduce a mem leak or similiar,
> it doesn't look so, but who knows).
After having a second look at dst_cow_metrics_generic(), it seems my
patch does introduce a small mem leak which occurs when the bridge will
be build as a module and the module gets unloaded. Then the static
struct dst_ops fake_dst_ops disappears and with that the memory
allocated by dst_cow_metrics_generic() is lost. I'm not sure which of
the dst*-functions should be called before the module gets unloaded.
Maybe someone with a deeper knowledge of the that stuff could have a
look at that.
Or maybe just changing the true in the call to dst_cow_metrics_generic()
in br_netfilter_rtable_init() to false instead of adding
dst_cow_metrics_generic() to fake_dst_ops() is an alternative. As I
said, I don't know what that metric-stuff does and what it is used for.
Regards,
Alexander
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox