* Re: [net-next-2.6 PATCH 2/4] e1000e: suppress compile warnings on certain archs
From: David Miller @ 2010-06-30 6:14 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100630041228.8652.61761.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:12:30 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Commit 84f4ee902ad3ee964b7b3a13d5b7cf9c086e9916 causes compile warnings on
> architectures that have unsigned long long's that are not 64-bit, e.g.
> ia64.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 3/4] e1000e: remove EEE module parameter
From: David Miller @ 2010-06-30 6:14 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100630041249.8652.67388.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:12:52 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> As requested by Dave Miller. A follow-on set of patches will allow for
> ethtool to enable/disable the feature instead.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 4/4] e1000e: disable EEE support by default
From: David Miller @ 2010-06-30 6:15 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bhutchings, bruce.w.allan
In-Reply-To: <20100630041311.8652.42432.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:13:13 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Based on community feedback, EEE should be disabled by default until the
> IEEE802.3az specification has been finalized.
>
> Cc: bhutchings@solarflare.com
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/3] ixgbe: fix panic when shutting down system with WoL enabled
From: David Miller @ 2010-06-30 6:15 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, andy, jesse.brandeburg
In-Reply-To: <20100630042739.8925.24962.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:28:12 -0700
> From: Andy Gospodarek <andy@greyhouse.net>
>
> This patch added to 2.6.34:
>
> commit 5f6c01819979afbfec7e0b15fe52371b8eed87e8
> Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Date: Wed Apr 14 16:04:23 2010 -0700
>
> ixgbe: fix bug with vlan strip in promsic mode
>
> among other things added a function called ixgbe_vlan_filter_enable.
> This new function wants to access and set some rx_ring parameters, but
> adapter->rx_ring has already been freed. This simply moves the free
> until after the access and makes __ixgbe_shutdown look more like
> ixgbe_remove.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/3] ixgbe: disable tx engine before disabling tx laser
From: David Miller @ 2010-06-30 6:15 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, bphilips, john.r.fastabend, peter.p.waskiewicz.jr
In-Reply-To: <20100630042836.8925.82492.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:28:36 -0700
> From: John Fastabend <john.r.fastabend@intel.com>
>
> Disabling the tx laser while receiving DMA requests
> can hang the device. After this occurs the device
> is in a bad state. The GPIO bit never clears when
> PCI master access is disabled and a reboot is required
> to get the device in a good state again.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 3/3] ixgbe: skip non IPv4 packets in ATR filter
From: David Miller @ 2010-06-30 6:15 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, bphilips, guillaume.gaudonville,
peter.p.waskiewicz.jr, donald.c.skidmore
In-Reply-To: <20100630042859.8925.23844.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:29:00 -0700
> From: Guillaume Gaudonville <guillaume.gaudonville@6wind.com>
>
> In driver ixgbe, ixgbe_atr may cause crashes for non-ipv4 packets. Just
> add a test to check skb->protocol. It may crash on short packets due
> to ip_hdr() access.
>
> Signed-off-by: Guillaume Gaudonville <guillaume.gaudonville@6wind.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCHv2 net-next-2.6] 3c59x: Use fine-grained locks for MII and windowed register access
From: David Miller @ 2010-06-30 6:15 UTC (permalink / raw)
To: ben; +Cc: steffen.klassert, netdev, chase.douglas, nordmark
In-Reply-To: <1277861216.28819.36.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Wed, 30 Jun 2010 02:26:56 +0100
> This avoids scheduling in atomic context and also means that IRQs
> will only be deferred for relatively short periods of time.
>
> Previously discussed in:
> http://article.gmane.org/gmane.linux.network/155024
>
> Reported-by: Arne Nordmark <nordmark@mech.kth.se>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied.
^ permalink raw reply
* Re: RFC: Allow 'ip' to run in daemon mode?
From: Stephen Hemminger @ 2010-06-30 7:00 UTC (permalink / raw)
To: Ben Greear, NetDev; +Cc: Stephen Hemminger
write a new service rather than bloating the existing code or just use netlink or libnl
Ben Greear <greearb@candelatech.com> wrote:
>I'm considering modifying 'ip' to be able to run in daemon
>mode so that I can do lots of IP commands without having to
>pay the startup cost of iproute.
>
>The -batch option almost works, but it's hard to programatically
>figure out failure codes.
>
>I'm thinking about making these changes:
>
>1) Move all of the error printing code into common methods (basically,
> wrap printf). In daemon mode this text can be sent back to the
> calling process, and in normal mode, it will be printed to stdout/stderr
> as it is currently.
>
>2) Remove all or most calls to 'exit' and instead return error codes
> to the calling logic.
>
>3) Add ability to listen on a unix socket for commands, basically treat
> them just like batch commands, one command per packet.
>
>4) Return well formatted error code and text response to calling process
> over the unix socket, maybe something like:
>
>RV: [errno or equiv, zero for success]\n
>CMD: [ command string this relates to ]\n
>[ Optional free form text ]
>
>
>Does something like this have any chance of upstream inclusion?
>
>Thanks,
>Ben
>
>--
>Ben Greear <greearb@candelatech.com>
>Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: static inline int xfrm_mark_get() broken
From: Simon Horman @ 2010-06-30 7:01 UTC (permalink / raw)
To: Andreas Steffen
Cc: Steffen Andreas (asteffen@hsr.ch), netdev@vger.kernel.org, jamal
In-Reply-To: <4C2AD009.40306@hsr.ch>
On Wed, Jun 30, 2010 at 07:03:05AM +0200, Andreas Steffen wrote:
> Hello Simon,
>
> actually I don't care how this bug is going to be fixed, but with
> sizeof(struct xfrm_mark) I'm dead certain that both the mark
> value and mask are being copied. Actually in the next inline
> function right below sizeof(struct xfrm_mark) is used, too:
>
> static inline int xfrm_mark_put(struct sk_buff *skb, struct xfrm_mark *m)
> {
> if (m->m | m->v)
> NLA_PUT(skb, XFRMA_MARK, sizeof(struct xfrm_mark), m);
> return 0;
In that case I withdraw my suggestion.
^ permalink raw reply
* ip6 route output() and ip_route_output_key() by drivers
From: Parav Pandit @ 2010-06-30 7:24 UTC (permalink / raw)
To: netdev
Hi,
Our device driver uses ip6 route output() and typecast the return value of dst_entry to rt6_info (similar to (net/ip6/icmp.c)
Driver uses (a) rt6i_dst.addr, (b) rt6i_dst.plen and (c) rt6i_gateway to get the route entry (ip/mask, gw, netdev).
Can anyone please confirm that drivers and/or netfilter kernel modules are allowed to use them? netdev drivers like : cnic.c, cxgb3, nes are using the ipv4 API (but not IPv6 API).
Also ip_route_output_key() rtable and dst_entry doesn't seem to provide route entry's subnet mask/prefix value. how drivers/netfilter kernel module can get a ip/mask gateway value while given a destination IP address as input?
I really appreciate your inputs. I hope I am asking it on the relevant mailing list.
Regards,
Parav Pandit
^ permalink raw reply
* Re: [Bridge] Bridge blocking network traffic
From: ratheesh k @ 2010-06-30 7:50 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Netfilter mailing list, netdev, bridge
In-Reply-To: <20100422130919.70206765@nehalam>
>>On Fri, Apr 23, 2010 at 1:39 AM, Stephen Hemminger <shemminger@linux-foundation.org> wrote:
>>You are supposed to assign IP address to bridge not the member of the bridge
Why is it so ?
I have a linux machine with interfaces eth0 (192.168.1.100 ) and
eth1 ( 192.168.2.100 ) . . I can connect both eth0 an eth1 to a
hardware HUB . How could i do this in linux machine itself using
brctl ?
Thanks,
Ratheesh
> On Thu, 22 Apr 2010 10:48:09 +1000
> benno joy <bennojoy@gmail.com> wrote:
>
>> Dear Team,
>>
>> I have a strange problem...... This is my problem i have a linux box running
>> Xen kernel (2.2). and i have the a bonding interface called bond0.497(eth0
>> and eth1 and also des Vlan tagging).
>> the bond0.497 is part of the bridge "xenbrv497", the issue is as soon as i
>> make the bond a part of the bridge my network traffic stops to work.
>> I did some prelimanary tests and found the following:
>> 1) if i assighn an ip to the bond and do a ping to the gateway it works
>> (provided it is not part of bridge xenbrv497)
>> 2) if i add the bondig interface to the brodge xenbrv497 (brclt addif
>> xenbrv497 bond0.497) the ping tests fails.
>> 3) i did a tcpdump and found that arp requests are going out of the
>> interface and we are getting response also. but soemhow
>> the arp entries are not gettign registered. i did some googling and found it
>> may be because of filtering so i disabled it by
>> echo 0 > in /proc/sys/net/bridge/bridge-nf-*.
>> But even this did not help still the arp entries are not getting registered
>> due to which my network traffic is gettign dropped.
>> This problem can be resolved by a reboot. but i would like to troubleshoot
>> it.
>> Could you please let me know how i can get more debugging message from the
>> bridge calls so i can figure out what exactly is happening.
>>
>> # uname -a
>> Linux vmclkxstgh04.espdev.aurdev.national.com.au 2.6.18-128.2.1.4.13.el5xen
>> #1 SMP Mon Dec 7 14:34:40 EST 2009 i686 i686 i386 GNU/Linux
>>
>> [root@vmclkxstgh04 ~]# brctl show
>> bridge name bridge id STP enabled interfaces
>> vlan441 8000.0017a4770470 no bond0.441
>> xenbrv205 8000.0017a477046c no bond1.205
>> xenbrv208 8000.0017a477046c no bond1.208
>> xenbrv220 8000.000000000000 no
>> xenbrv221 8000.000000000000 no
>> xenbrv226 8000.0017a477046c no vif40.1
>> vif39.1
>> vif37.1
>> vif26.1
>> vif25.1
>> vif24.1
>> vif13.1
>> bond1.226
>> xenbrv227 8000.0017a4770470 no vif40.0
>> vif39.0
>> vif37.0
>> vif26.0
>> vif25.0
>> vif24.0
>> vif13.0
>> bond0.227
>> xenbrv420 8000.0017a4770470 no bond0.420
>> xenbrv422 8000.0017a4770470 no vif35.0
>> vif7.0
>> vif6.0
>> vif4.0
>> vif3.0
>> vif2.0
>> tap2.0
>> bond0.422
>> xenbrv425 8000.0017a4770470 no bond0.425
>> xenbrv450 8000.0017a4770470 no bond0.450
>> xenbrv492 8000.0017a4770470 no bond0.492
>> xenbrv493 8000.0017a4770470 no bond0.493
>> xenbrv494 8000.0017a4770470 no bond0.494
>> xenbrv495 8000.0017a4770470 no bond0.495
>> xenbrv496 8000.0017a4770470 no bond0.496
>> xenbrv497 8000.0017a4770470 no bond0.497
>> xenbrv701 8000.0017a477046c no vif44.1
>> bond1.701
>>
>> bond0.497 Link encap:Ethernet HWaddr 00:17:A4:77:04:70
>> inet addr:10.12.166.231 Bcast:10.12.166.255 Mask:255.255.255.224
>> UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
>> RX packets:3807595 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:3304 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:188847200 (180.0 MiB) TX bytes:138768 (135.5 KiB)
>
> You are supposed to assign IP address to bridge not the member of the bridge.
>
>
> --
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
>
^ permalink raw reply
* [PATCH] igbvf: avoid name clash between PF and VF
From: Stefan Assmann @ 2010-06-30 8:53 UTC (permalink / raw)
To: netdev; +Cc: e1000-devel, Andy Gospodarek, jeffrey.t.kirsher, gregory.v.rose
From: Stefan Assmann <sassmann@redhat.com>
It looks like the VFs get initialized before all the PFs are. Therefore
the udev mapping MAC <-> ethX (for PFs) gets screwed because the VFs
may grab the ethX interface names (reserved by udev) for the PFs.
Example:
igb max_vfs=0
eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
eth1 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
eth2 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
eth3 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
igb max_vfs=1
eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
eth1 Link encap:Ethernet HWaddr 0A:CF:41:69:F7:A9
eth2 Link encap:Ethernet HWaddr 3A:FE:20:4C:2A:3B
eth3 Link encap:Ethernet HWaddr C6:C3:B1:56:C9:A4
eth3_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
eth4 Link encap:Ethernet HWaddr 6E:8A:8A:A3:5F:69
eth4_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
eth5_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
In the example above VF 0A:CF:41:69:F7:A9 grabs eth1 but udev
has a rule that says eth1 should be assigned PF 00:13:20:F7:A5:9F
(eth3_rename) and waits for the VF to disappear to rename eth3_rename
to eth1. Unfortunately eth1 is not going to disappear.
This is not a udev bug since udev doesn't create persistent rules for
VFs as their MAC address changes every reboot.
To avoid this problem we could change the kernel name for the VFs and
thus avoid confusion between VFs and PFs.
I've already discussed this with Alexander Duyck and Greg Rose, so far
they have no objection. However this problem appears for all drivers that
support PFs and VFs and thus the changes should be applied consistently
to all of these drivers.
Signed-off-by: Stefan Assmann <sassmann@redhat.com>
---
drivers/net/igbvf/netdev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/igbvf/netdev.c b/drivers/net/igbvf/netdev.c
index 5e2b2a8..2fb665b 100644
--- a/drivers/net/igbvf/netdev.c
+++ b/drivers/net/igbvf/netdev.c
@@ -2787,7 +2787,7 @@ static int __devinit igbvf_probe(struct pci_dev *pdev,
netif_carrier_off(netdev);
netif_stop_queue(netdev);
- strcpy(netdev->name, "eth%d");
+ strcpy(netdev->name, "veth%d");
err = register_netdev(netdev);
if (err)
goto err_hw_init;
--
1.6.5.2
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* [PATCH] act_mirred: combine duplicate code
From: Changli Gao @ 2010-06-30 8:54 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: David S. Miller, netdev, linux-kernel, Changli Gao
act_mirred: combine duplicate code
tcf_bstats is updated in any way, so we can do it earlier to reduce the size of
the code.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/sched/act_mirred.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 2e9a7b9..a16b017 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -160,6 +160,8 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
spin_lock(&m->tcf_lock);
m->tcf_tm.lastuse = jiffies;
+ m->tcf_bstats.bytes += qdisc_pkt_len(skb);
+ m->tcf_bstats.packets++;
dev = m->tcfm_dev;
if (!(dev->flags & IFF_UP)) {
@@ -174,8 +176,6 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
if (skb2 == NULL)
goto out;
- m->tcf_bstats.bytes += qdisc_pkt_len(skb2);
- m->tcf_bstats.packets++;
if (!(at & AT_EGRESS)) {
if (m->tcfm_ok_push)
skb_push(skb2, skb2->dev->hard_header_len);
@@ -193,8 +193,6 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
out:
if (err) {
m->tcf_qstats.overlimits++;
- m->tcf_bstats.bytes += qdisc_pkt_len(skb);
- m->tcf_bstats.packets++;
/* should we be asking for packet to be dropped?
* may make sense for redirect case only
*/
^ permalink raw reply related
* [PATCH v2] net/core: use ntohs for skb->protocol
From: Sebastian Andrzej Siewior @ 2010-06-30 9:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100629.151740.135534374.davem@davemloft.net>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
This is only noticed by people that are not doing everything correct in
the first place.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
net/core/dev.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index eb4be99..8e61dc5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1537,7 +1537,8 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
if (net_ratelimit())
printk(KERN_CRIT "protocol %04x is "
"buggy, dev %s\n",
- skb2->protocol, dev->name);
+ ntohs(skb2->protocol),
+ dev->name);
skb_reset_network_header(skb2);
}
--
1.6.6.1
^ permalink raw reply related
* [PATCH] act_nat: use stack variable
From: Changli Gao @ 2010-06-30 9:07 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: Herbert Xu, David S. Miller, netdev, Changli Gao
act_nat: use stack variable
structure tc_nat isn't too big for stack, so we can put it in stack.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/sched/act_nat.c | 31 ++++++++++---------------------
1 file changed, 10 insertions(+), 21 deletions(-)
diff --git a/net/sched/act_nat.c b/net/sched/act_nat.c
index 5709494..0be49a4 100644
--- a/net/sched/act_nat.c
+++ b/net/sched/act_nat.c
@@ -265,40 +265,29 @@ static int tcf_nat_dump(struct sk_buff *skb, struct tc_action *a,
{
unsigned char *b = skb_tail_pointer(skb);
struct tcf_nat *p = a->priv;
- struct tc_nat *opt;
+ struct tc_nat opt;
struct tcf_t t;
- int s;
- s = sizeof(*opt);
+ opt.old_addr = p->old_addr;
+ opt.new_addr = p->new_addr;
+ opt.mask = p->mask;
+ opt.flags = p->flags;
- /* netlink spinlocks held above us - must use ATOMIC */
- opt = kzalloc(s, GFP_ATOMIC);
- if (unlikely(!opt))
- return -ENOBUFS;
+ opt.index = p->tcf_index;
+ opt.action = p->tcf_action;
+ opt.refcnt = p->tcf_refcnt - ref;
+ opt.bindcnt = p->tcf_bindcnt - bind;
- opt->old_addr = p->old_addr;
- opt->new_addr = p->new_addr;
- opt->mask = p->mask;
- opt->flags = p->flags;
-
- opt->index = p->tcf_index;
- opt->action = p->tcf_action;
- opt->refcnt = p->tcf_refcnt - ref;
- opt->bindcnt = p->tcf_bindcnt - bind;
-
- NLA_PUT(skb, TCA_NAT_PARMS, s, opt);
+ NLA_PUT(skb, TCA_NAT_PARMS, sizeof(opt), &opt);
t.install = jiffies_to_clock_t(jiffies - p->tcf_tm.install);
t.lastuse = jiffies_to_clock_t(jiffies - p->tcf_tm.lastuse);
t.expires = jiffies_to_clock_t(p->tcf_tm.expires);
NLA_PUT(skb, TCA_NAT_TM, sizeof(t), &t);
- kfree(opt);
-
return skb->len;
nla_put_failure:
nlmsg_trim(skb, b);
- kfree(opt);
return -1;
}
^ permalink raw reply related
* [PATCH] xfrm: fix XFRMA_MARK extraction in xfrm_mark_get
From: Andreas Steffen @ 2010-06-30 7:57 UTC (permalink / raw)
To: netdev; +Cc: jamal, David Miller
Determine the size of the xfrm_mark struct, not of its pointer.
Signed-off-by: Andreas Steffen <andreas.steffen@strongswan.org>
---
include/net/xfrm.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 1913af6..fc8f36d 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1586,7 +1586,7 @@ static inline struct xfrm_state *xfrm_input_state(struct sk_buff *skb)
static inline int xfrm_mark_get(struct nlattr **attrs, struct xfrm_mark *m)
{
if (attrs[XFRMA_MARK])
- memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(m));
+ memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(struct xfrm_mark));
else
m->v = m->m = 0;
--
1.7.0.4
^ permalink raw reply related
* Re: nat bypass
From: ratheesh k @ 2010-06-30 9:24 UTC (permalink / raw)
To: Simon Horman; +Cc: Netfilter mailing list, netdev
In-Reply-To: <20100630023718.GU2138@verge.net.au>
> Let me try and understand this.
>
> R is routing between 192.168.1.0/24 and 10.232.18.0/24.
> As A is on the 192.168.1.0/24 side of R.
> But to give A an 10.232.18.0/24 address (dynamically)?
>
> Why?
>
For some clients , R should act as a mere bridge , Not a router .
On Wed, Jun 30, 2010 at 8:07 AM, Simon Horman <horms@verge.net.au> wrote:
> On Mon, Jun 28, 2010 at 03:43:46PM +0530, ratheesh k wrote:
>> Hi,
>>
>> A -------> R ------->S
>>
>> I have a linux machine A is connected to Linux machine R . Machine R
>> is having two network interfaces and acting as a router .
>> It has a dhcp server running . It will assign ip in 192.168.1.0/24
>> subnet to all machine connected on lan side ( A is connected also in
>> lan side ) . Wan side of R is connected to HTTP server S . There is
>> also a DHCP server running on S to assign ip in 10.232.18.0/24 subnet
>> . Is there any way , in which NAT should be bypassed to get ip from
>> DHCP server running on S . My question is : How can A will get an ip
>> from 10.232.18.0/24 pool ip .?
>> ebtables is an option ? How can we make it ?
>> Is there any other optimal way ?
>
> Let me try and understand this.
>
> R is routing between 192.168.1.0/24 and 10.232.18.0/24.
> As A is on the 192.168.1.0/24 side of R.
> But to give A an 10.232.18.0/24 address (dynamically)?
>
> Why?
>
>
^ permalink raw reply
* [ANNOUNCE] 7th Netfilter Workshop in Seville, Spain
From: Pablo Neira Ayuso @ 2010-06-30 10:06 UTC (permalink / raw)
To: netfilter-announce
Cc: Netfilter Development Mailinglist, Mail List - Netfilter, lwn,
Linux Netdev List
Hi!
We're happy to announce the next Netfilter Workshop in the series. This
year it will take place in Seville, Spain. We will provide you up to
date information through our website:
http://workshop.netfilter.org/2010/
On behalf of the Netfilter coreteam,
Pablo!
^ permalink raw reply
* Re: [PATCH] xfrm: fix XFRMA_MARK extraction in xfrm_mark_get
From: jamal @ 2010-06-30 10:07 UTC (permalink / raw)
To: Andreas Steffen; +Cc: netdev, David Miller, Simon Horman
In-Reply-To: <4C2AF8EE.8030508@strongswan.org>
On Wed, 2010-06-30 at 09:57 +0200, Andreas Steffen wrote:
> Determine the size of the xfrm_mark struct, not of its pointer.
>
> Signed-off-by: Andreas Steffen <andreas.steffen@strongswan.org>
Good catch (you are right this was tested on 64 bit ;->).
The preferred style would be what Simon mentioned. No biggie if
you keep it this way - but if you resubmit, add:
Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] act_mirred: combine duplicate code
From: jamal @ 2010-06-30 10:24 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <1277888098-27632-1-git-send-email-xiaosuo@gmail.com>
removed lkml
On Wed, 2010-06-30 at 16:54 +0800, Changli Gao wrote:
> act_mirred: combine duplicate code
>
> tcf_bstats is updated in any way, so we can do it earlier to reduce the size of
> the code.
There is one condition when !(dev->flags & IFF_UP) where we dont update
the stats in current code. This changes with your patch.
It would make sense to actually update at that point (as you do) and
additionally increment some other counter to track that like
m->tcf_qstats.drops. I suggest resubmit with that change and add my
signed-off.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] act_nat: use stack variable
From: jamal @ 2010-06-30 10:25 UTC (permalink / raw)
To: Changli Gao; +Cc: Herbert Xu, David S. Miller, netdev
In-Reply-To: <1277888829-30230-1-git-send-email-xiaosuo@gmail.com>
On Wed, 2010-06-30 at 17:07 +0800, Changli Gao wrote:
> act_nat: use stack variable
>
> structure tc_nat isn't too big for stack, so we can put it in stack.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Doesnt look unreasonable - will let Herbert make the call..
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] act_nat: use stack variable
From: Herbert Xu @ 2010-06-30 10:30 UTC (permalink / raw)
To: jamal; +Cc: Changli Gao, David S. Miller, netdev
In-Reply-To: <1277893521.3509.17.camel@bigi>
On Wed, Jun 30, 2010 at 06:25:21AM -0400, jamal wrote:
> On Wed, 2010-06-30 at 17:07 +0800, Changli Gao wrote:
> > act_nat: use stack variable
> >
> > structure tc_nat isn't too big for stack, so we can put it in stack.
> >
> > Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>
> Doesnt look unreasonable - will let Herbert make the call..
Looks good to me too.
Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] igbvf: avoid name clash between PF and VF
From: Ben Hutchings @ 2010-06-30 10:44 UTC (permalink / raw)
To: Stefan Assmann
Cc: netdev, e1000-devel, Duyck, Alexander H, gregory.v.rose,
jeffrey.t.kirsher, Andy Gospodarek
In-Reply-To: <4C2B0614.9040004@redhat.com>
On Wed, 2010-06-30 at 10:53 +0200, Stefan Assmann wrote:
> From: Stefan Assmann <sassmann@redhat.com>
>
> It looks like the VFs get initialized before all the PFs are. Therefore
> the udev mapping MAC <-> ethX (for PFs) gets screwed because the VFs
> may grab the ethX interface names (reserved by udev) for the PFs.
>
> Example:
> igb max_vfs=0
> eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
> eth1 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
> eth2 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
> eth3 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
> igb max_vfs=1
> eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
> eth1 Link encap:Ethernet HWaddr 0A:CF:41:69:F7:A9
> eth2 Link encap:Ethernet HWaddr 3A:FE:20:4C:2A:3B
> eth3 Link encap:Ethernet HWaddr C6:C3:B1:56:C9:A4
> eth3_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
> eth4 Link encap:Ethernet HWaddr 6E:8A:8A:A3:5F:69
> eth4_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
> eth5_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
>
> In the example above VF 0A:CF:41:69:F7:A9 grabs eth1 but udev
> has a rule that says eth1 should be assigned PF 00:13:20:F7:A5:9F
> (eth3_rename) and waits for the VF to disappear to rename eth3_rename
> to eth1. Unfortunately eth1 is not going to disappear.
> This is not a udev bug since udev doesn't create persistent rules for
> VFs as their MAC address changes every reboot.
[...]
I think it is a bug in the udev rules: udev should rename the VFs even
though their names won't be persistent.
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] act_mirred: combine duplicate code
From: jamal @ 2010-06-30 10:49 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <1277893442.3509.16.camel@bigi>
On Wed, 2010-06-30 at 06:24 -0400, jamal wrote:
> m->tcf_qstats.drops.
Sorry - this nagged me - we are already incrementing overlimits - we
should increment drops. Scratch that too. I am going to say your patch
as is:
signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] igbvf: avoid name clash between PF and VF
From: Stefan Assmann @ 2010-06-30 10:57 UTC (permalink / raw)
To: Ben Hutchings
Cc: e1000-devel, netdev, kay.sievers, gregory.v.rose,
jeffrey.t.kirsher, Andy Gospodarek, harald
In-Reply-To: <1277894679.28819.60.camel@localhost>
On 30.06.2010 12:44, Ben Hutchings wrote:
> On Wed, 2010-06-30 at 10:53 +0200, Stefan Assmann wrote:
>> From: Stefan Assmann <sassmann@redhat.com>
>>
>> It looks like the VFs get initialized before all the PFs are. Therefore
>> the udev mapping MAC <-> ethX (for PFs) gets screwed because the VFs
>> may grab the ethX interface names (reserved by udev) for the PFs.
>>
>> Example:
>> igb max_vfs=0
>> eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
>> eth1 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
>> eth2 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
>> eth3 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
>> igb max_vfs=1
>> eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
>> eth1 Link encap:Ethernet HWaddr 0A:CF:41:69:F7:A9
>> eth2 Link encap:Ethernet HWaddr 3A:FE:20:4C:2A:3B
>> eth3 Link encap:Ethernet HWaddr C6:C3:B1:56:C9:A4
>> eth3_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
>> eth4 Link encap:Ethernet HWaddr 6E:8A:8A:A3:5F:69
>> eth4_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
>> eth5_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
>>
>> In the example above VF 0A:CF:41:69:F7:A9 grabs eth1 but udev
>> has a rule that says eth1 should be assigned PF 00:13:20:F7:A5:9F
>> (eth3_rename) and waits for the VF to disappear to rename eth3_rename
>> to eth1. Unfortunately eth1 is not going to disappear.
>> This is not a udev bug since udev doesn't create persistent rules for
>> VFs as their MAC address changes every reboot.
> [...]
>
> I think it is a bug in the udev rules: udev should rename the VFs even
> though their names won't be persistent.
In that case let's Cc udev people.
Stefan
--
Stefan Assmann | Red Hat GmbH
Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach
| HR: Amtsgericht Muenchen HRB 153243
| GF: Brendan Lane, Charlie Peters,
sassmann at redhat.com | Michael Cunningham, Charles Cachera
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ 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