* Re: (Lack of) specification for RX n-tuple filtering
From: Dimitris Michailidis @ 2010-07-22 21:50 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Peter Waskiewicz, netdev, David Miller
In-Reply-To: <1279832544.2104.63.camel@achroite.uk.solarflarecom.com>
Ben Hutchings wrote:
> The n-tuple filtering facility is half-baked at present. There is an
> interface to add filters but none to remove them! And ETHTOOL_GRXNTUPLE
> is not at all symmetric with ETHTOOL_SRXNTUPLE (which I complained about
> at the time it was added, to no avail).
It's a bit worse than that. Currently one can only append filters, not
insert at a given position, as ethtool_rx_ntuple doesn't have an index
field. For devices that use TCAMs, where position matters, it's quite an
obstacle. It also means one cannot modify an existing filter by specifying
a new filter for the same index.
>
> An ETHTOOL_RESET command with flag ETH_RESET_FILTER set could be defined
> to clear all the filters, but that's a big hammer to use, and I think
> that in general drivers should push the same configuration back to the
> hardware after resetting it for whatever reason.
>
> So far as I can work out, ixgbe clears all the filters when the filter
> table fills up. Is that true? Is this really the intended behaviour of
> manually set filters?
>
> I also see this in the ixgbe implementation:
>
> /*
> * Program the relevant mask registers. If src/dst_port or src/dst_addr
> * are zero, then assume a full mask for that field. Also assume that
> * a VLAN of 0 is unspecified, so mask that out as well. L4type
> * cannot be masked out in this implementation.
> *
> * This also assumes IPv4 only. IPv6 masking isn't supported at this
> * point in time.
> */
>
> An IPv4 address of 0 is certainly valid, so this isn't a good rule. And
> in any case, such a rule should be specified *with the interface*, in
> <linux/ethtool.h>, not the implementation.
>
> This also implies that 'mask' specifies bits to be ignored, not bits to
> be matched. That also was not specified.
>
> Ben.`
>
^ permalink raw reply
* IPv6 Anycast?
From: Stuart Sheldon @ 2010-07-22 21:32 UTC (permalink / raw)
To: netdev; +Cc: Stuart Sheldon
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Is IPv6 Anycast supported? And if so, how do I setup the Anycast addresses?
Please reply to me directly, as I am not on this list...
Thanks In advance,
Stu Sheldon
ACT USA
- --
Every year is getting shorter, never seem to find the time
Plans that either come to naught or half a page of scribbled lines
Hanging on in quiet desperation is the english way
The time is gone, the song is over, thought Id something more to say
-- Pink Floyd - "Time Lyrics"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iQIcBAEBCAAGBQJMSLkLAAoJEFKVLITDJSGSpcwP/0Q9a1PSDE6Iv+ACBo4wfpIV
vI1jLBF+Fxk7yxte+NdSqXNc8LOzzYaoEy0F1DGW3AZ2+OBoLyb6mY8hoVtrEFHS
6qXk0DBkqQIZdxLjkuQDpXMKvaHPJplIk2IlaOHAvMP4vmQo1/57mlsDpdgkBetN
meAj+OXc/aybw4E12ui6Hf6fDHrXyrdhgtUztoSfk6R/w0MBksgbNDQsLW7LJl1l
1bYWNaiskktn+Y9HwBmrTvL038VA3zy3TuZTn8shNGkpLwzd9qDBUgsS/GqY1v2e
XXjCMr3kWm6ezsuHKe/ihviSZxFIoXtS50rynDhrA9ZQM930OgcPPB1yRhzUvI6d
b7jXR25oetW1XLQhjR+4+J301JQh9cPPGhwn3MUh26LdpkUMhpqX7OXfuvCDxxA9
ktdDK2To/FBUUvNgTFUa4hhH6DSeofjRYtQmafr4YszFbeyGs1ob7yv/CupekZlv
DYva0fcc7LIT4Lc/9/0D3vkgTnLlhT4u13BY9uTZ9UxbwN2YZ+9j7uk4x+2tMCiN
t03mot9lP9uQ/g4QYpLF0nsnmHBjzZczS0gYTLy7hkbQRIeu8MiF0jIUtuHvaxZn
6C9Opki6ZCgXLdkHqPhPNuA58T/7vH7a5ct+2eHHWW5UALngUAsZJnGHaMiBB2pX
diQHlPmeMTJ8YzqGu/Vz
=kxGX
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH] ipv6: remove sysctl jiffies conversion on gc_elasticity and min_adv_ms
From: Min Zhang @ 2010-07-22 21:39 UTC (permalink / raw)
To: netdev
sysctl output ipv6 gc_elasticity and min_adv_mss as values divided by
HZ. However, they are not in unit of jiffies, since ip6_rt_min_advmss
refers to packet size and ip6_rt_fc_elasticity is used as scaler as in
expire>>ip6_rt_gc_elasticity, so replace the jiffies conversion
handler will regular handler for them.
This has impact on scripts that are currently working assuming the
divide by HZ, will yield different results with this patch in place.
Signed-off-by: Min Zhang <mzhang@mvista.com>
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 252d761..3b3de49 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2583,7 +2583,7 @@ ctl_table ipv6_route_table_template[] = {
.data = &init_net.ipv6.sysctl.ip6_rt_gc_elasticity,
.maxlen = sizeof(int),
.mode = 0644,
- .proc_handler = proc_dointvec_jiffies,
+ .proc_handler = proc_dointvec,
},
{
.procname = "mtu_expires",
@@ -2597,7 +2597,7 @@ ctl_table ipv6_route_table_template[] = {
.data = &init_net.ipv6.sysctl.ip6_rt_min_advmss,
.maxlen = sizeof(int),
.mode = 0644,
- .proc_handler = proc_dointvec_jiffies,
+ .proc_handler = proc_dointvec,
},
{
.procname = "gc_min_interval_ms",
^ permalink raw reply related
* Re: RE: Re: Fwd: LVS on local node
From: Franchoze Eric @ 2010-07-22 21:37 UTC (permalink / raw)
To: Graeme Fowler; +Cc: Eric Dumazet, wensong, lvs-devel, netdev, netfilter-devel
In-Reply-To: <20100723010102.121uPPJ1@mxfront8.mail.yandex.net>
23.07.10, 01:01, "Graeme Fowler" <graeme@graemef.net>:
> Hi
>
> Technically keepalived is not LVS. It's a monitoring/mgmt app which can manage an LVS according to health-check logic. LVS by itself cannot "detect" any form of service failure - it's a fancy router with special rules.
>
> Graeme.
>
Ah, ok. Then with iptables I can write keepalived app to insert/remove rules.
Is there interface to iptables for dynamically turn on/off rules without inserting and removing them from the table?
^ permalink raw reply
* Re: [PATCH UPDATED 1/3] vhost: replace vhost_workqueue with per-vhost kthread
From: Tejun Heo @ 2010-07-22 21:21 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Oleg Nesterov, Sridhar Samudrala, netdev, lkml,
kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev, Jiri Kosina,
Thomas Gleixner, Ingo Molnar, Andi Kleen
In-Reply-To: <20100722155840.GA1743@redhat.com>
Hello,
On 07/22/2010 05:58 PM, Michael S. Tsirkin wrote:
> All the tricky barrier pairing made me uncomfortable. So I came up with
> this on top (untested): if we do all operations under the spinlock, we
> can get by without barriers and atomics. And since we need the lock for
> list operations anyway, this should have no paerformance impact.
>
> What do you think?
I've created kthread_worker in wq#for-next tree and already converted
ivtv to use it. Once this lands in mainline, I think converting vhost
to use it would be better choice. kthread worker code uses basically
the same logic used in the vhost_workqueue code but is better
organized and documented. So, I think it would be better to stick
with the original implementation, as otherwise we're likely to just
decrease test coverage without much gain.
http://git.kernel.org/?p=linux/kernel/git/tj/wq.git;a=commitdiff;h=b56c0d8937e665a27d90517ee7a746d0aa05af46;hp=53c5f5ba42c194cb13dd3083ed425f2c5b1ec439
> @@ -151,37 +161,37 @@ static void vhost_vq_reset(struct vhost_dev *dev,
> static int vhost_worker(void *data)
> {
> struct vhost_dev *dev = data;
> - struct vhost_work *work;
> + struct vhost_work *work = NULL;
>
> -repeat:
> - set_current_state(TASK_INTERRUPTIBLE); /* mb paired w/ kthread_stop */
> + for (;;) {
> + set_current_state(TASK_INTERRUPTIBLE); /* mb paired w/ kthread_stop */
>
> - if (kthread_should_stop()) {
> - __set_current_state(TASK_RUNNING);
> - return 0;
> - }
> + if (kthread_should_stop()) {
> + __set_current_state(TASK_RUNNING);
> + return 0;
> + }
>
> - work = NULL;
> - spin_lock_irq(&dev->work_lock);
> - if (!list_empty(&dev->work_list)) {
> - work = list_first_entry(&dev->work_list,
> - struct vhost_work, node);
> - list_del_init(&work->node);
> - }
> - spin_unlock_irq(&dev->work_lock);
> + spin_lock_irq(&dev->work_lock);
> + if (work) {
> + work->done_seq = work->queue_seq;
> + if (work->flushing)
> + wake_up_all(&work->done);
I don't think doing this before executing the function is correct, so
you'll have to release the lock, execute the function, regrab the lock
and then do the flush processing.
Thanks.
--
tejun
^ permalink raw reply
* Re: [patch -next] stmmac: handle allocation errors in setup functions
From: David Miller @ 2010-07-22 21:13 UTC (permalink / raw)
To: error27; +Cc: peppe.cavallaro, netdev, kernel-janitors
In-Reply-To: <20100722111648.GD17585@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Thu, 22 Jul 2010 13:16:48 +0200
> If the allocations fail in either dwmac1000_setup() or dwmac100_setup()
> then return NULL. These are called from stmmac_mac_device_setup(). The
> check for NULL returns in stmmac_mac_device_setup() needed to be moved
> forward a couple lines.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied.
^ permalink raw reply
* Re: [patch -next] caif: precedence bug
From: David Miller @ 2010-07-22 21:13 UTC (permalink / raw)
To: error27; +Cc: SjurBraendeland, sjur.brandeland, netdev, kernel-janitors
In-Reply-To: <20100722111131.GB17585@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Thu, 22 Jul 2010 13:11:31 +0200
> Negate has precedence over comparison so the original assert only
> checked that "rfml->fragment_size" was larger than 1 or 0.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/2] bonding: don't lock when copying/clearing VLAN list on slave
From: David Miller @ 2010-07-22 21:13 UTC (permalink / raw)
To: fubar; +Cc: netdev, mchan
In-Reply-To: <1279750488-32611-2-git-send-email-fubar@us.ibm.com>
From: Jay Vosburgh <fubar@us.ibm.com>
Date: Wed, 21 Jul 2010 15:14:48 -0700
> When copying VLAN information to or removing from a slave
> during slave addition or removal, the bonding code currently holds
> the bond->lock for write to prevent concurrent modification of the
> vlan_list / vlgrp.
>
> This is unnecessary, as all of these operations occur under
> RTNL. Holding the bond->lock also caused might_sleep issues for
> some drivers' ndo_vlan_* functions. This patch removes the extra
> locking.
>
> Problem reported by Michael Chan <mchan@broadcom.com>
>
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH] fec: use interrupt for MDIO completion indication
From: David Miller @ 2010-07-22 21:12 UTC (permalink / raw)
To: w.sang; +Cc: baruch, netdev, bryan.wu, kernel, gerg, linux-arm-kernel
In-Reply-To: <20100721125113.GA2651@pengutronix.de>
From: Wolfram Sang <w.sang@pengutronix.de>
Date: Wed, 21 Jul 2010 14:51:13 +0200
> From: Wolfram Sang <w.sang@pengutronix.de>
> Subject: [PATCH] net/fec: restore interrupt mask after software-reset in fec_stop()
>
> After the change from mdio polling to irq, it became necessary to
> restore the interrupt mask after resetting the chip in fec_stop().
> Otherwise, with all irqs disabled, no communication with the PHY will be
> possible after e.g. un-/replugging the cable and the device gets
> stalled.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] bonding: change test for presence of VLANs
From: David Miller @ 2010-07-22 21:12 UTC (permalink / raw)
To: fubar; +Cc: netdev, pedro.netdev, kaber
In-Reply-To: <1279750488-32611-1-git-send-email-fubar@us.ibm.com>
From: Jay Vosburgh <fubar@us.ibm.com>
Date: Wed, 21 Jul 2010 15:14:47 -0700
> After commit:
>
> commit ad1afb00393915a51c21b1ae8704562bf036855f
> Author: Pedro Garcia <pedro.netdev@dondevamos.com>
> Date: Sun Jul 18 15:38:44 2010 -0700
>
> vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)
>
> it is now regular practice for a VLAN "add vid" for VLAN 0 to
> arrive prior to any VLAN registration or creation of a vlan_group.
>
> This patch updates the bonding code that tests for the presence
> of VLANs configured above bonding. The new logic tests for bond->vlgrp
> to determine if a registration has occured, instead of testing that
> bonding's internal vlan_list is empty.
>
> The old code would panic when vlan_list was not empty, but
> vlgrp was still NULL (because only an "add vid" for VLAN 0 had occured).
>
> Bonding still adds VLAN 0 to its internal list so that 802.1p
> frames are handled correctly on transmit when non-VLAN accelerated
> slaves are members of the bond. The test against bond->vlan_list
> remains in bond_dev_queue_xmit for this reason.
>
> Modification to the bond->vlgrp now occurs under lock (in
> addition to RTNL), because not all inspections of it occur under RTNL.
>
> Additionally, because 8021q will never issue a "kill vid" for
> VLAN 0, there is now logic in bond_uninit to release any remaining
> entries from vlan_list.
>
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH] au1000_eth: get ethernet address from platform_data
From: David Miller @ 2010-07-22 21:12 UTC (permalink / raw)
To: manuel.lauss; +Cc: linux-mips, netdev
In-Reply-To: <1279715450-28762-1-git-send-email-manuel.lauss@googlemail.com>
From: Manuel Lauss <manuel.lauss@googlemail.com>
Date: Wed, 21 Jul 2010 14:30:50 +0200
> au1000_eth uses firmware calls to get a valid MAC address, and changes
> it depending on platform device id. This patch moves this logic out
> of the driver into the platform device registration part, where boards
> with supported chips can use whatever firmware interface they need;
> the default implementation maintains compatibility with existing,
> YAMON-based firmware.
>
> Tested-by: Wolfgang Grandegger <wg@denx.de>
> Acked-by: Florian Fainelli <florian@openwrt.org>
> Signed-off-by: Manuel Lauss <manuel.lauss@googlemail.com>
> ---
> This patch depends on another patch to the MIPS tree to
> apply cleanly, so I'd prefer if it went in through it as well.
Ok, feel free:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] 3c59x: handle pci_iomap() errors
From: David Miller @ 2010-07-22 21:11 UTC (permalink / raw)
To: segooon
Cc: kernel-janitors, klassert, eric.dumazet, ben, adobriyan, joe,
netdev
In-Reply-To: <1279713638-31567-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Wed, 21 Jul 2010 16:00:36 +0400
> pci_iomap() can fail, handle this case and return -ENOMEM from probe
> function.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied.
We seem to leak the iomaps if vortex_probe1() fails, feel free to fix
that too :-)
^ permalink raw reply
* (Lack of) specification for RX n-tuple filtering
From: Ben Hutchings @ 2010-07-22 21:02 UTC (permalink / raw)
To: Peter Waskiewicz; +Cc: netdev, David Miller
The n-tuple filtering facility is half-baked at present. There is an
interface to add filters but none to remove them! And ETHTOOL_GRXNTUPLE
is not at all symmetric with ETHTOOL_SRXNTUPLE (which I complained about
at the time it was added, to no avail).
An ETHTOOL_RESET command with flag ETH_RESET_FILTER set could be defined
to clear all the filters, but that's a big hammer to use, and I think
that in general drivers should push the same configuration back to the
hardware after resetting it for whatever reason.
So far as I can work out, ixgbe clears all the filters when the filter
table fills up. Is that true? Is this really the intended behaviour of
manually set filters?
I also see this in the ixgbe implementation:
/*
* Program the relevant mask registers. If src/dst_port or src/dst_addr
* are zero, then assume a full mask for that field. Also assume that
* a VLAN of 0 is unspecified, so mask that out as well. L4type
* cannot be masked out in this implementation.
*
* This also assumes IPv4 only. IPv6 masking isn't supported at this
* point in time.
*/
An IPv4 address of 0 is certainly valid, so this isn't a good rule. And
in any case, such a rule should be specified *with the interface*, in
<linux/ethtool.h>, not the implementation.
This also implies that 'mask' specifies bits to be ignored, not bits to
be matched. That also was not specified.
Ben.`
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: RTA_MARK addition
From: David Miller @ 2010-07-22 20:46 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1279699394.2452.6.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 21 Jul 2010 10:03:14 +0200
> Add a new rt attribute, RTA_MARK, and use it in
> rt_fill_info()/inet_rtm_getroute() to support following commands :
>
> ip route get 192.168.20.110 mark NUMBER
> ip route get 192.168.20.108 from 192.168.20.110 iif eth1 mark NUMBER
> ip route list cache [192.168.20.110] mark NUMBER
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: With disable_ipv6 set to 1 on an interface, ff00:/8 and fe80::/64 are still added on device UP
From: David Miller @ 2010-07-22 20:41 UTC (permalink / raw)
To: brian.haley; +Cc: maheshkelkar, netdev
In-Reply-To: <4C460856.5090701@hp.com>
From: Brian Haley <brian.haley@hp.com>
Date: Tue, 20 Jul 2010 16:34:30 -0400
> If the interface has IPv6 disabled, don't add a multicast or
> link-local route since we won't be adding a link-local address.
>
> Reported-by: Mahesh Kelkar <maheshkelkar@gmail.com>
> Signed-off-by: Brian Haley <brian.haley@hp.com>
Applied, thanks Brian.
^ permalink raw reply
* Re: [PATCH] Fix corruption of skb csum field in pskb_expand_head() of net/core/skbuff.c
From: David Miller @ 2010-07-22 20:28 UTC (permalink / raw)
To: andrea; +Cc: linux-kernel, netdev
In-Reply-To: <20100722191234.GA832@cronus.persephoneslair.org>
From: Andrea Shepard <andrea@persephoneslair.org>
Date: Thu, 22 Jul 2010 12:12:35 -0700
> Make pskb_expand_head() check ip_summed to make sure csum_start is really
> csum_start and not csum before adjusting it.
...
> Signed-off-by: Andrea Shepard <andrea@persephoneslair.org>
Applied, but your email client corrupted tab characters into spaces so
I had to apply your patch by hand.
There is a similar bug in skb_copy_expand() so I fixed that too.
Thanks again.
--------------------
net: Fix skb_copy_expand() handling of ->csum_start
It should only be adjusted if ip_summed == CHECKSUM_PARTIAL.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/core/skbuff.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index c699159..ce88293 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -932,7 +932,8 @@ struct sk_buff *skb_copy_expand(const struct sk_buff *skb,
copy_skb_header(n, skb);
off = newheadroom - oldheadroom;
- n->csum_start += off;
+ if (n->ip_summed == CHECKSUM_PARTIAL)
+ n->csum_start += off;
#ifdef NET_SKBUFF_DATA_USES_OFFSET
n->transport_header += off;
n->network_header += off;
--
1.7.1.1
^ permalink raw reply related
* Re: macvtap: Limit packet queue length
From: David Miller @ 2010-07-22 20:09 UTC (permalink / raw)
To: arnd; +Cc: herbert, netdev, mwagner, chrisw
In-Reply-To: <201007221130.53612.arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 22 Jul 2010 11:30:53 +0200
> On Thursday 22 July 2010, Herbert Xu wrote:
>> Reported-by: Mark Wagner <mwagner@redhat.com>
>> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> As long as we're missing a better solution,
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks everyone.
^ permalink raw reply
* [PATCH] minstrel: don't complain about feedback for unrequested rates
From: John W. Linville @ 2010-07-22 19:46 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Sven Geggus, netdev, John W. Linville
In-Reply-To: <4C4896D5.8010802@openwrt.org>
"It's not problematic if minstrel gets feedback for rates that it
doesn't have in its list, it should just ignore it. - Felix"
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Felix Fietkau <nbd@openwrt.org>
---
net/mac80211/rc80211_minstrel.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index f65ce6d..778c604 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -67,7 +67,6 @@ rix_to_ndx(struct minstrel_sta_info *mi, int rix)
for (i = rix; i >= 0; i--)
if (mi->r[i].rix == rix)
break;
- WARN_ON(i < 0);
return i;
}
--
1.7.1.1
^ permalink raw reply related
* Re: macvtap: Limit packet queue length
From: David Miller @ 2010-07-22 19:58 UTC (permalink / raw)
To: herbert; +Cc: mashirle, netdev, arnd, mwagner
In-Reply-To: <20100722160731.GA30723@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 23 Jul 2010 00:07:31 +0800
> On Thu, Jul 22, 2010 at 08:59:58AM -0700, Shirley Ma wrote:
>> On Thu, 2010-07-22 at 14:41 +0800, Herbert Xu wrote:
>> > {
>> > struct macvtap_queue *q = macvtap_get_queue(dev, skb);
>> > if (!q)
>> > - return -ENOLINK;
>> > + goto drop;
>> > +
>> > + if (skb_queue_len(&q->sk.sk_receive_queue) >=
>> > dev->tx_queue_len)
>> > + goto drop;
>> >
>>
>> Do we need to orphan skb here, just like tun?
>
> We could, but that is orthogonal to the problem at hand so feel
> free to do that in another patch.
These days, the stack pre-orphans all packets sent to ->ndo_start_xmit()
in dev_hard_start_xmit() as long as socket based TX timestamping is not
active for the packet.
^ permalink raw reply
* [net 2/2] veth: Remove redundant timestamp assignment.
From: Ben Greear @ 2010-07-22 19:54 UTC (permalink / raw)
To: netdev; +Cc: Ben Greear
In-Reply-To: <1279828488-17800-1-git-send-email-greearb@candelatech.com>
The timestamp is already cleared in the dev_forward_skb
logic.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 0cfbb3d... 161ee02... M drivers/net/veth.c
drivers/net/veth.c | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 0cfbb3d..161ee02 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -181,11 +181,6 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)
if (dev->features & NETIF_F_NO_CSUM)
skb->ip_summed = rcv_priv->ip_summed;
- /* Zero out the time-stamp so that receiving code is forced
- * to recalculate it.
- */
- skb->tstamp.tv64 = 0;
-
length = skb->len + ETH_HLEN;
if (dev_forward_skb(rcv, skb) != NET_RX_SUCCESS)
goto rx_drop;
--
1.6.2.5
^ permalink raw reply related
* [net 1/2] net: dev_forward_skb should call nf_reset
From: Ben Greear @ 2010-07-22 19:54 UTC (permalink / raw)
To: netdev; +Cc: Ben Greear
In-Reply-To: <1279828488-17800-1-git-send-email-greearb@candelatech.com>
With conn-track zones and probably with different network
namespaces, the netfilter logic needs to be re-calculated
on packet receive. If the netfilter logic is not reset,
it will not be recalculated properly. This patch adds
the nf_reset logic to dev_forward_skb.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 7ac33e5... 22eee4e... M net/core/dev.c
net/core/dev.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 7ac33e5..22eee4e 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1482,6 +1482,7 @@ static inline void net_timestamp(struct sk_buff *skb)
int dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
{
skb_orphan(skb);
+ nf_reset(skb);
if (!(dev->flags & IFF_UP) ||
(skb->len > (dev->mtu + dev->hard_header_len))) {
--
1.6.2.5
^ permalink raw reply related
* [net 0/2] Clean up netfilter cache on xmit-to-self.
From: Ben Greear @ 2010-07-22 19:54 UTC (permalink / raw)
To: netdev
These patches are against 2.6.34.1. The first one may be
worth submitting to stable. The second one is less critical
and should probably just go in the development tree.
^ permalink raw reply
* Re: [RFC 1/1] netfilter: xtables: inclusion of xt_condition
From: Luciano Coelho @ 2010-07-22 19:30 UTC (permalink / raw)
To: ext Alexey Dobriyan
Cc: Jan Engelhardt, Netfilter Developer Mailing List,
netdev@vger.kernel.org, Patrick McHardy, sameo@linux.intel.com
In-Reply-To: <20100722191940.GA10029@x200>
On Thu, 2010-07-22 at 21:19 +0200, ext Alexey Dobriyan wrote:
> On Thu, Jul 22, 2010 at 04:44:35PM +0200, Jan Engelhardt wrote:
> >
> > On Thursday 2010-07-22 16:09, Luciano Coelho wrote:
> > >+static int condition_mt_check(const struct xt_mtchk_param *par)
> > >+{
> > >+ struct xt_condition_mtinfo *info = par->matchinfo;
> > >+ struct condition_variable *var;
> > >+ struct condition_net *cond_net =
> > >+ condition_pernet(current->nsproxy->net_ns);
> >
> > Cc'ing Alexey who has done the netns support.
> >
> > Alexey, you added par->net, but given Luciano just did it with
> > current->nsproxy->net_ns, do we really need par->net?
>
> In ->check, maybe, we can get away with current->nsproxy->net_ns.
>
> But definitely not in ->destroy(), because destruction can happen
> when _no_ task is in netns, so current->nsproxy->net_ns is 100% bogus.
>
> Steps to reproduce:
> iptables -A ...
> exit
>
> ->destroy hook gets netns from par->net, ->checkentry does the same
> for symmetry and less confusion.
Very good point. I guess that when Patrick suggested using
current->nsproxy->net_ns, he meant only for the module_params part.
I'll be removing that anyway. And I'll change the code to use par->net
instead of current->nsproxy->net_ns to avoid the problem in _destroy.
Thanks for your comments!
I must admit that I was a bit insecure about this code. That's why I
sent a RFC early enough. ;)
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] CAN: Add Flexcan CAN controller driver
From: David Miller @ 2010-07-22 19:29 UTC (permalink / raw)
To: mkl; +Cc: wg, socketcan-core, netdev, s.hauer
In-Reply-To: <1279816844-12138-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Thu, 22 Jul 2010 18:40:44 +0200
> The following changes since commit 4cfa580e7eebb8694b875d2caff3b989ada2efac:
>
> r6040: Fix args to phy_mii_ioctl(). (2010-07-21 21:10:49 -0700)
>
> are available in the git repository at:
> git://git.pengutronix.de/git/mkl/linux-2.6.git for-net-next-2.6
>
> Marc Kleine-Budde (1):
> CAN: Add Flexcan CAN controller driver
Pulled, thanks.
^ permalink raw reply
* Re: [Uclinux-dist-devel] [PATCH 2/2] net: dsa: introduce MICREL KSZ8893MQL/BL ethernet switch chip support
From: Karl Beldan @ 2010-07-22 19:27 UTC (permalink / raw)
To: Mike Frysinger
Cc: Lennert Buytenhek, netdev, uclinux-dist-devel, David S. Miller
In-Reply-To: <AANLkTikoSb8WA40teXaYvaPf1XsC4r7ySWZOBTKug4ip@mail.gmail.com>
On Wed, Jul 21, 2010 at 11:00 PM, Mike Frysinger <vapier.adi@gmail.com> wrote:
> On Wed, Jul 21, 2010 at 16:31, Karl Beldan wrote:
>> On Wed, Jul 21, 2010 at 6:05 PM, Mike Frysinger wrote:
>>> On Wed, Jul 21, 2010 at 11:16, Lennert Buytenhek wrote:
>>>> On Wed, Jul 21, 2010 at 09:37:22AM -0400, Mike Frysinger wrote:
>>>>> +static int ksz8893m_setup(struct dsa_switch *ds)
>>>>> +{
>>>>> + int i;
>>>>> + int ret;
>>>>> +
>>>>> + ret = ksz8893m_switch_reset(ds);
>>>>> + if (ret < 0)
>>>>> + return ret;
>>>>
>>>> It's pretty ugly that the mdiobus is passed in via the normal means,
>>>> but a reference to the SPI bus to use is just stuffed into some global
>>>> variable.
>>>>
>>>> Can you not access all registers via MII?
>>>
>>> it depends on the host mdio bus. if it supports the semi-standard
>>> behavior of toggling the OP field of MDIO frames, then yes, you can do
>>> it via MII. but i dont think the current mdio framework in the kernel
>>> keeps track of that functionality, so there isnt a way in the driver
>>> to say "is this possible, else fall back to SPI".
>>
>> Are you referring to SMI ?
>
> that is the term the ksz datasheet uses (Serial Management Interface),
> but i'm not aware of it being a standardized term. even the ksz
> datasheet admits that its behavior is a bit non-standard. the
> Blackfin MAC doesnt support it so we have no way of testing the it as
> that is the MAC on the board with the ksz switch.
>
Can't either, we don't even have mdio, only spi.
Speaking of which, maybe you can replace this while you are at it :
--- net/dsa/slave.c 2010-05-22 09:58:34.000000000 +0200
void dsa_slave_mii_bus_init(struct dsa_switch *ds)
{
ds->slave_mii_bus->priv = (void *)ds;
- ds->slave_mii_bus->name = "dsa slave smi";
--
Karl
^ 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