* [PATCH] ip_gre: fix possible use after free
From: Eric Dumazet @ 2012-12-21 2:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Isaku Yamahata
From: Eric Dumazet <edumazet@google.com>
Once skb_realloc_headroom() is called, tiph might point to freed memory.
Cache tiph->ttl value before the reallocation, to avoid unexpected
behavior.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Isaku Yamahata <yamahata@valinux.co.jp>
---
net/ipv4/ip_gre.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index a85ae2f..4c22e70 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -750,6 +750,7 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
int gre_hlen;
__be32 dst;
int mtu;
+ u8 ttl;
if (skb->ip_summed == CHECKSUM_PARTIAL &&
skb_checksum_help(skb))
@@ -812,6 +813,7 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
goto tx_error;
}
+ ttl = tiph->ttl;
tos = tiph->tos;
if (tos == 1) {
tos = 0;
@@ -904,6 +906,7 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
dev_kfree_skb(skb);
skb = new_skb;
old_iph = ip_hdr(skb);
+ /* Warning : tiph value might point to freed memory */
}
skb_reset_transport_header(skb);
@@ -927,8 +930,9 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
iph->tos = ipgre_ecn_encapsulate(tos, old_iph, skb);
iph->daddr = fl4.daddr;
iph->saddr = fl4.saddr;
+ iph->ttl = ttl;
- if ((iph->ttl = tiph->ttl) == 0) {
+ if (ttl == 0) {
if (skb->protocol == htons(ETH_P_IP))
iph->ttl = old_iph->ttl;
#if IS_ENABLED(CONFIG_IPV6)
^ permalink raw reply related
* sock_ioctl sleeping while atomic warning during boot.
From: Dave Jones @ 2012-12-21 2:24 UTC (permalink / raw)
To: netdev
Seen on Linus tree as of 810a4855513b9cb1a191301eb5e4e28b276cc318
BUG: sleeping function called from invalid context at mm/slub.c:925
in_atomic(): 1, irqs_disabled(): 0, pid: 364, name: systemd-udevd
2 locks on stack by systemd-udevd/364:
#0: held: (rtnl_mutex){+.+.+.}, instance: ffffffff81d1c038, at: [<ffffffff815d82d7>] rtnl_lock+0x17/0x20
#1: held: (devnet_rename_seq){+.+.+.}, instance: ffffffff81d1ba60, at: [<ffffffff815c9737>] dev_change_name+0x67/0x2a0
Pid: 364, comm: systemd-udevd Not tainted 3.7.0+ #32
Call Trace:
[<ffffffff810a892b>] __might_sleep+0x14b/0x210
[<ffffffff811ce833>] __kmalloc_track_caller+0x63/0x2d0
[<ffffffff8146810f>] ? device_rename+0x5f/0x130
[<ffffffff8119190a>] kstrdup+0x3a/0x70
[<ffffffff8146810f>] device_rename+0x5f/0x130
[<ffffffff815c97d3>] dev_change_name+0x103/0x2a0
[<ffffffff815cb851>] dev_ifsioc+0x251/0x3b0
[<ffffffff815cbb5b>] dev_ioctl+0x1ab/0x840
[<ffffffff81367588>] ? __const_udelay+0x28/0x30
[<ffffffff812f7a49>] ? avc_has_perm_flags+0x29/0x2b0
[<ffffffff815aa86d>] sock_do_ioctl+0x5d/0x70
[<ffffffff815aa8fd>] sock_ioctl+0x7d/0x2c0
[<ffffffff812f9d05>] ? inode_has_perm.isra.47.constprop.60+0x65/0xa0
[<ffffffff811f1079>] do_vfs_ioctl+0x99/0x5a0
[<ffffffff812f9dd7>] ? file_has_perm+0x97/0xb0
[<ffffffff811f1611>] sys_ioctl+0x91/0xb0
[<ffffffff81711480>] tracesys+0xdd/0xe2
systemd-udevd[364]: renamed network interface eth0 to p6p1
^ permalink raw reply
* Re: [PATCH 4/5] net: sfc: fix return value check in efx_ptp_probe_channel().
From: Ben Hutchings @ 2012-12-21 3:09 UTC (permalink / raw)
To: David Miller, tipecaml
Cc: linux-kernel, kernel-janitors, linux-net-drivers, netdev
In-Reply-To: <20121212.001550.741463250196231082.davem@davemloft.net>
On Wed, 2012-12-12 at 00:15 -0500, David Miller wrote:
> From: Cyril Roelandt <tipecaml@gmail.com>
> Date: Wed, 12 Dec 2012 01:24:53 +0100
>
> > The ptp_clock_register() returns ERR_PTR() and never returns NULL. Replace the
> > NULL check by a call to IS_ERR().
> >
> > Signed-off-by: Cyril Roelandt <tipecaml@gmail.com>
>
> I'll let Ben queue this up.
>
> Probably he'll want to avoid potentially leaving an ERR_PTR
> in ptp->phc_clock even if, with this fix, that would be
> harmless.
Sorry for the delay in looking at this. This change is fine, as the
entire structure *ptp will be freed on the failure path.
I'm now on vacation until the new year. Cyril, please re-send your
patch with the addition of:
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
so it will show up on 'patchwork' again and David can apply it from
there.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
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: sock_ioctl sleeping while atomic warning during boot.
From: Eric Dumazet @ 2012-12-21 3:25 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev, Brian Haley
In-Reply-To: <20121221022409.GA1927@redhat.com>
From: Eric Dumazet <edumazet@google.com>
On Thu, 2012-12-20 at 21:24 -0500, Dave Jones wrote:
> Seen on Linus tree as of 810a4855513b9cb1a191301eb5e4e28b276cc318
>
>
> BUG: sleeping function called from invalid context at mm/slub.c:925
> in_atomic(): 1, irqs_disabled(): 0, pid: 364, name: systemd-udevd
> 2 locks on stack by systemd-udevd/364:
> #0: held: (rtnl_mutex){+.+.+.}, instance: ffffffff81d1c038, at: [<ffffffff815d82d7>] rtnl_lock+0x17/0x20
> #1: held: (devnet_rename_seq){+.+.+.}, instance: ffffffff81d1ba60, at: [<ffffffff815c9737>] dev_change_name+0x67/0x2a0
> Pid: 364, comm: systemd-udevd Not tainted 3.7.0+ #32
> Call Trace:
> [<ffffffff810a892b>] __might_sleep+0x14b/0x210
> [<ffffffff811ce833>] __kmalloc_track_caller+0x63/0x2d0
> [<ffffffff8146810f>] ? device_rename+0x5f/0x130
> [<ffffffff8119190a>] kstrdup+0x3a/0x70
> [<ffffffff8146810f>] device_rename+0x5f/0x130
> [<ffffffff815c97d3>] dev_change_name+0x103/0x2a0
> [<ffffffff815cb851>] dev_ifsioc+0x251/0x3b0
> [<ffffffff815cbb5b>] dev_ioctl+0x1ab/0x840
> [<ffffffff81367588>] ? __const_udelay+0x28/0x30
> [<ffffffff812f7a49>] ? avc_has_perm_flags+0x29/0x2b0
> [<ffffffff815aa86d>] sock_do_ioctl+0x5d/0x70
> [<ffffffff815aa8fd>] sock_ioctl+0x7d/0x2c0
> [<ffffffff812f9d05>] ? inode_has_perm.isra.47.constprop.60+0x65/0xa0
> [<ffffffff811f1079>] do_vfs_ioctl+0x99/0x5a0
> [<ffffffff812f9dd7>] ? file_has_perm+0x97/0xb0
> [<ffffffff811f1611>] sys_ioctl+0x91/0xb0
> [<ffffffff81711480>] tracesys+0xdd/0xe2
> systemd-udevd[364]: renamed network interface eth0 to p6p1
>
> --
OK, thanks for the report.
We need a seqcount, not a seqlock, as RTNL already protects multiple
writers.
Please try following fix :
[PATCH] net: devnet_rename_seq should be a seqcount
Using a seqlock for devnet_rename_seq is not a good idea,
as device_rename() can sleep.
As we hold RTNL, we dont need a protection for writers,
and only need a seqcount so that readers can catch a change done
by a writer.
Bug added in commit c91f6df2db4972d3 (sockopt: Change getsockopt() of
SO_BINDTODEVICE to return an interface name)
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Brian Haley <brian.haley@hp.com>
---
include/linux/netdevice.h | 2 +-
net/core/dev.c | 18 +++++++++---------
net/core/sock.c | 4 ++--
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 02e0f6b..c599e47 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1576,7 +1576,7 @@ extern int call_netdevice_notifiers(unsigned long val, struct net_device *dev);
extern rwlock_t dev_base_lock; /* Device list lock */
-extern seqlock_t devnet_rename_seq; /* Device rename lock */
+extern seqcount_t devnet_rename_seq; /* Device rename seq */
#define for_each_netdev(net, d) \
diff --git a/net/core/dev.c b/net/core/dev.c
index d0cbc93..26d73e2 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -203,7 +203,7 @@ static struct list_head offload_base __read_mostly;
DEFINE_RWLOCK(dev_base_lock);
EXPORT_SYMBOL(dev_base_lock);
-DEFINE_SEQLOCK(devnet_rename_seq);
+seqcount_t devnet_rename_seq;
static inline void dev_base_seq_inc(struct net *net)
{
@@ -1093,10 +1093,10 @@ int dev_change_name(struct net_device *dev, const char *newname)
if (dev->flags & IFF_UP)
return -EBUSY;
- write_seqlock(&devnet_rename_seq);
+ write_seqcount_begin(&devnet_rename_seq);
if (strncmp(newname, dev->name, IFNAMSIZ) == 0) {
- write_sequnlock(&devnet_rename_seq);
+ write_seqcount_end(&devnet_rename_seq);
return 0;
}
@@ -1104,7 +1104,7 @@ int dev_change_name(struct net_device *dev, const char *newname)
err = dev_get_valid_name(net, dev, newname);
if (err < 0) {
- write_sequnlock(&devnet_rename_seq);
+ write_seqcount_end(&devnet_rename_seq);
return err;
}
@@ -1112,11 +1112,11 @@ rollback:
ret = device_rename(&dev->dev, dev->name);
if (ret) {
memcpy(dev->name, oldname, IFNAMSIZ);
- write_sequnlock(&devnet_rename_seq);
+ write_seqcount_end(&devnet_rename_seq);
return ret;
}
- write_sequnlock(&devnet_rename_seq);
+ write_seqcount_end(&devnet_rename_seq);
write_lock_bh(&dev_base_lock);
hlist_del_rcu(&dev->name_hlist);
@@ -1135,7 +1135,7 @@ rollback:
/* err >= 0 after dev_alloc_name() or stores the first errno */
if (err >= 0) {
err = ret;
- write_seqlock(&devnet_rename_seq);
+ write_seqcount_begin(&devnet_rename_seq);
memcpy(dev->name, oldname, IFNAMSIZ);
goto rollback;
} else {
@@ -4180,7 +4180,7 @@ static int dev_ifname(struct net *net, struct ifreq __user *arg)
return -EFAULT;
retry:
- seq = read_seqbegin(&devnet_rename_seq);
+ seq = read_seqcount_begin(&devnet_rename_seq);
rcu_read_lock();
dev = dev_get_by_index_rcu(net, ifr.ifr_ifindex);
if (!dev) {
@@ -4190,7 +4190,7 @@ retry:
strcpy(ifr.ifr_name, dev->name);
rcu_read_unlock();
- if (read_seqretry(&devnet_rename_seq, seq))
+ if (read_seqcount_retry(&devnet_rename_seq, seq))
goto retry;
if (copy_to_user(arg, &ifr, sizeof(struct ifreq)))
diff --git a/net/core/sock.c b/net/core/sock.c
index a692ef4..bc131d4 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -583,7 +583,7 @@ static int sock_getbindtodevice(struct sock *sk, char __user *optval,
goto out;
retry:
- seq = read_seqbegin(&devnet_rename_seq);
+ seq = read_seqcount_begin(&devnet_rename_seq);
rcu_read_lock();
dev = dev_get_by_index_rcu(net, sk->sk_bound_dev_if);
ret = -ENODEV;
@@ -594,7 +594,7 @@ retry:
strcpy(devname, dev->name);
rcu_read_unlock();
- if (read_seqretry(&devnet_rename_seq, seq))
+ if (read_seqcount_retry(&devnet_rename_seq, seq))
goto retry;
len = strlen(devname) + 1;
^ permalink raw reply related
* Re: sock_ioctl sleeping while atomic warning during boot.
From: Brian Haley @ 2012-12-21 3:31 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Dave Jones, netdev
In-Reply-To: <1356060308.21834.4455.camel@edumazet-glaptop>
On 12/20/2012 10:25 PM, Eric Dumazet wrote:
> OK, thanks for the report.
>
> We need a seqcount, not a seqlock, as RTNL already protects multiple
> writers.
>
> Please try following fix :
>
>
> [PATCH] net: devnet_rename_seq should be a seqcount
>
> Using a seqlock for devnet_rename_seq is not a good idea,
> as device_rename() can sleep.
>
> As we hold RTNL, we dont need a protection for writers,
> and only need a seqcount so that readers can catch a change done
> by a writer.
>
> Bug added in commit c91f6df2db4972d3 (sockopt: Change getsockopt() of
> SO_BINDTODEVICE to return an interface name)
>
> Reported-by: Dave Jones <davej@redhat.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Brian Haley <brian.haley@hp.com>
Sorry about that, thanks for the quick fix Eric.
-Brian
^ permalink raw reply
* Re: TUN problems (regression?)
From: Jason Wang @ 2012-12-21 3:32 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Eric Dumazet, Paul Moore, netdev
In-Reply-To: <20121220155001.538bbdb0@nehalam.linuxnetplumber.net>
On 12/21/2012 07:50 AM, Stephen Hemminger wrote:
> On Thu, 20 Dec 2012 15:38:17 -0800
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> On Thu, 2012-12-20 at 18:16 -0500, Paul Moore wrote:
>>> [CC'ing netdev in case this is a known problem I just missed ...]
>>>
>>> Hi Jason,
>>>
>>> I started doing some more testing with the multiqueue TUN changes and I ran
>>> into a problem when running tunctl: running it once w/o arguments works as
>>> expected, but running it a second time results in failure and a
>>> kmem_cache_sanity_check() failure. The problem appears to be very repeatable
>>> on my test VM and happens independent of the LSM/SELinux fixup patches.
>>>
>>> Have you seen this before?
>>>
>> Obviously code in tun_flow_init() is wrong...
>>
>> static int tun_flow_init(struct tun_struct *tun)
>> {
>> int i;
>>
>> tun->flow_cache = kmem_cache_create("tun_flow_cache",
>> sizeof(struct tun_flow_entry), 0, 0,
>> NULL);
>> if (!tun->flow_cache)
>> return -ENOMEM;
>> ...
>> }
>>
>>
>> I have no idea why we would need a kmem_cache per tun_struct,
>> and why we even need a kmem_cache.
> Normally flow malloc/free should be good enough.
> It might make sense to use private kmem_cache if doing hlist_nulls.
>
>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Should be at least a global cache, I thought I can get some speed-up by
using kmem_cache.
Acked-by: Jason Wang <jasowang@redhat.com>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: TUN problems (regression?)
From: Eric Dumazet @ 2012-12-21 3:39 UTC (permalink / raw)
To: Jason Wang; +Cc: Stephen Hemminger, Paul Moore, netdev
In-Reply-To: <50D3D85B.1070605@redhat.com>
On Fri, 2012-12-21 at 11:32 +0800, Jason Wang wrote:
> On 12/21/2012 07:50 AM, Stephen Hemminger wrote:
> > On Thu, 20 Dec 2012 15:38:17 -0800
> > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> >> On Thu, 2012-12-20 at 18:16 -0500, Paul Moore wrote:
> >>> [CC'ing netdev in case this is a known problem I just missed ...]
> >>>
> >>> Hi Jason,
> >>>
> >>> I started doing some more testing with the multiqueue TUN changes and I ran
> >>> into a problem when running tunctl: running it once w/o arguments works as
> >>> expected, but running it a second time results in failure and a
> >>> kmem_cache_sanity_check() failure. The problem appears to be very repeatable
> >>> on my test VM and happens independent of the LSM/SELinux fixup patches.
> >>>
> >>> Have you seen this before?
> >>>
> >> Obviously code in tun_flow_init() is wrong...
> >>
> >> static int tun_flow_init(struct tun_struct *tun)
> >> {
> >> int i;
> >>
> >> tun->flow_cache = kmem_cache_create("tun_flow_cache",
> >> sizeof(struct tun_flow_entry), 0, 0,
> >> NULL);
> >> if (!tun->flow_cache)
> >> return -ENOMEM;
> >> ...
> >> }
> >>
> >>
> >> I have no idea why we would need a kmem_cache per tun_struct,
> >> and why we even need a kmem_cache.
> > Normally flow malloc/free should be good enough.
> > It might make sense to use private kmem_cache if doing hlist_nulls.
> >
> >
> > Acked-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Should be at least a global cache, I thought I can get some speed-up by
> using kmem_cache.
>
> Acked-by: Jason Wang <jasowang@redhat.com>
Was it with SLUB or SLAB ?
Using generic kmalloc-64 is better than a dedicated kmem_cache of 48
bytes per object, as we guarantee each object is on a single cache line.
^ permalink raw reply
* Re: [PATCH] net: ipv4: route: fixed a coding style issues net: ipv4: tcp: fixed a coding style issues
From: David Miller @ 2012-12-21 3:53 UTC (permalink / raw)
To: hasko.stevo; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1355990910-3688-1-git-send-email-hasko.stevo@gmail.com>
I'm definitely not applying this, sorry.
^ permalink raw reply
* Re: [PATCH] net: ipv4: route: fix coding style issues net: ipv4: tcp: fix coding style issues
From: David Miller @ 2012-12-21 3:58 UTC (permalink / raw)
To: hasko.stevo; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1356013685-31649-1-git-send-email-hasko.stevo@gmail.com>
From: Stefan Hasko <hasko.stevo@gmail.com>
Date: Thu, 20 Dec 2012 15:28:05 +0100
> Fix a coding style issues.
>
> Signed-off-by: Stefan Hasko <hasko.stevo@gmail.com>
Again, I am absolutely not applying a whole-sale coding
style patch to this file.
Do not submit this patch again, regardless of what other
feedback you might have gotten.
^ permalink raw reply
* Re: [PATCH] net: ipv4: route: fixed a coding style issues net: ipv4: tcp: fixed a coding style issues
From: David Miller @ 2012-12-21 3:59 UTC (permalink / raw)
To: erdnetdev
Cc: nicolas.dichtel, hasko.stevo, kuznet, jmorris, yoshfuji, kaber,
netdev, linux-kernel
In-Reply-To: <1356017039.21834.2819.camel@edumazet-glaptop>
From: Eric Dumazet <erdnetdev@gmail.com>
Date: Thu, 20 Dec 2012 07:23:59 -0800
> Such "coding style" patches are a real pain when trying to fix bugs,
> especially dealing with stable/old kernels.
Totally agreed, and I refuse to apply such patches.
^ permalink raw reply
* Re: TUN problems (regression?)
From: Jason Wang @ 2012-12-21 4:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, Paul Moore, netdev
In-Reply-To: <1356061179.21834.4515.camel@edumazet-glaptop>
On 12/21/2012 11:39 AM, Eric Dumazet wrote:
> On Fri, 2012-12-21 at 11:32 +0800, Jason Wang wrote:
>> On 12/21/2012 07:50 AM, Stephen Hemminger wrote:
>>> On Thu, 20 Dec 2012 15:38:17 -0800
>>> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>>
>>>> On Thu, 2012-12-20 at 18:16 -0500, Paul Moore wrote:
>>>>> [CC'ing netdev in case this is a known problem I just missed ...]
>>>>>
>>>>> Hi Jason,
>>>>>
>>>>> I started doing some more testing with the multiqueue TUN changes and I ran
>>>>> into a problem when running tunctl: running it once w/o arguments works as
>>>>> expected, but running it a second time results in failure and a
>>>>> kmem_cache_sanity_check() failure. The problem appears to be very repeatable
>>>>> on my test VM and happens independent of the LSM/SELinux fixup patches.
>>>>>
>>>>> Have you seen this before?
>>>>>
>>>> Obviously code in tun_flow_init() is wrong...
>>>>
>>>> static int tun_flow_init(struct tun_struct *tun)
>>>> {
>>>> int i;
>>>>
>>>> tun->flow_cache = kmem_cache_create("tun_flow_cache",
>>>> sizeof(struct tun_flow_entry), 0, 0,
>>>> NULL);
>>>> if (!tun->flow_cache)
>>>> return -ENOMEM;
>>>> ...
>>>> }
>>>>
>>>>
>>>> I have no idea why we would need a kmem_cache per tun_struct,
>>>> and why we even need a kmem_cache.
>>> Normally flow malloc/free should be good enough.
>>> It might make sense to use private kmem_cache if doing hlist_nulls.
>>>
>>>
>>> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
>> Should be at least a global cache, I thought I can get some speed-up by
>> using kmem_cache.
>>
>> Acked-by: Jason Wang <jasowang@redhat.com>
> Was it with SLUB or SLAB ?
>
> Using generic kmalloc-64 is better than a dedicated kmem_cache of 48
> bytes per object, as we guarantee each object is on a single cache line.
>
>
Right, thanks for the explanation.
^ permalink raw reply
* Re: [PATCH net-next V4 03/13] bridge: Validate that vlan is permitted on ingress
From: Shmulik Ladkani @ 2012-12-21 4:48 UTC (permalink / raw)
To: vyasevic; +Cc: netdev, shemminger, davem, or.gerlitz, jhs, mst, erdnetdev, jiri
In-Reply-To: <50D331A8.3080206@redhat.com>
On Thu, 20 Dec 2012 10:41:28 -0500 Vlad Yasevich <vyasevic@redhat.com> wrote:
> >> +static bool br_allowed_ingress(struct net_bridge_port *p, struct sk_buff *skb)
> >> +{
> >> + struct net_port_vlan *pve;
> >> + u16 vid;
> >> +
> >> + /* If there are no vlan in the permitted list, all packets are
> >> + * permitted.
> >> + */
> >> + if (list_empty(&p->vlan_list))
> >> + return true;
> >> + if (!br_allowed_ingress(p, skb))
> >> + goto drop;
> >> +
> >
> > This condition should be also encorporated upon "ingress" at the "bridge
> > master port" (that is, early at br_dev_xmit).
> > Think of the "bridge master port" as yet another port:
> > upon "ingress" (meaning, tx packets from the ip stack), we should
> > also enforce any ingress permission rules.
> >
>
> I've tried that before and now can't think of a reason why I rejected
> it. I'll try to remember...
(Current code does not allow you to put the test into 'br_dev_xmit',
since br_allow_ingress expects an 'nbp' as its 1st argument, and the
"master port" is not represented as an 'nbp')
But this is a must. The "master port" shouldn't be treated differently
with respect to vlan ingress/egress membership verifications.
Take for example why egress membership verification is important:
m
|
+----+----+
| |
p1 p2
p1 expects "normal" (untagged) traffic, and should be connected with the
IP stack (master port 'm'), but not leak to p2.
Traffic of some specific service, marked with VLAN 2, arrives at p2 and
should be forwardable with p1 (keeping the tag), but should not go to
the IP stack.
p1 pvid: 1
m pvid: 1
vlan 1 membership map: p1 m
vlan 1 egress policy map: U U
vlan 2 membership map: p1 p2
vlan 2 egress policy map: T T
If you don't verify membership upon egress towards IP stack (at the
"master port"), VLAN 2 packets from p2 will leak into the stack.
Regards,
Shmulik
^ permalink raw reply
* [RFC] IP_MAX_MTU value
From: Eric Dumazet @ 2012-12-21 6:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Rick Jones
Hi David
We have the following definition in net/ipv4/route.c
#define IP_MAX_MTU 0xFFF0
This means that "netperf -t UDP_STREAM", using UDP messages of 65507
bytes, are fragmented on loopback interface (while its MTU is now 65536
and should allow those UDP messages being sent without fragments)
I guess Rick chose 65507 bytes in netperf because it was related to the
max IPv4 datagram length :
65507 + 28 = 65535
Changing IP_MAX_MTU from 0xFFF0 to 0x10000 seems safe [1], but I might
miss something really obvious ?
It might be because in old days we reserved 16 bytes for the ethernet
header, and we wanted to avoid kmalloc() round-up to kmalloc-131072
slab ?
If so, we certainly can limit skb->head to 32 or 64 KB and complete with
page fragments the remaining space.
Thanks
[1] performance increase is ~50%
^ permalink raw reply
* Re: [RFC] IP_MAX_MTU value
From: Eric Dumazet @ 2012-12-21 7:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Rick Jones
In-Reply-To: <1356072468.21834.4805.camel@edumazet-glaptop>
On Thu, 2012-12-20 at 22:47 -0800, Eric Dumazet wrote:
> It might be because in old days we reserved 16 bytes for the ethernet
> header, and we wanted to avoid kmalloc() round-up to kmalloc-131072
> slab ?
Well, we add the struct skb_shared_info anyway, so we hit kmalloc-131072
with current IP_MAX_MTU value...
^ permalink raw reply
* INVESTMENT ASSISTANCE
From: Thabopeter @ 2012-12-21 8:24 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 67 bytes --]
Good Day Kindly Open The Attachment File
[-- Attachment #2: INVESTMENT ASSISTANCE.doc --]
[-- Type: application/msword, Size: 48640 bytes --]
^ permalink raw reply
* INVESTMENT ASSISTANCE
From: Thabopeter @ 2012-12-21 8:25 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 67 bytes --]
Good Day Kindly Open The Attachment File
[-- Attachment #2: INVESTMENT ASSISTANCE.doc --]
[-- Type: application/msword, Size: 48640 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] net/smsc911x: Provide common clock functionality
From: Lee Jones @ 2012-12-21 9:13 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Steve Glendinning, Robert Marklund, linus.walleij, arnd, netdev,
Linus Walleij, linux-kernel, linux-arm-kernel
In-Reply-To: <20121220205113.GD14363@n2100.arm.linux.org.uk>
On Thu, 20 Dec 2012, Russell King - ARM Linux wrote:
> On Thu, Dec 20, 2012 at 08:35:14PM +0000, Lee Jones wrote:
> > On Thu, 20 Dec 2012, Russell King - ARM Linux wrote:
> >
> > > On Thu, Dec 20, 2012 at 08:12:08PM +0100, Linus Walleij wrote:
> > > > On Wed, Dec 19, 2012 at 6:19 PM, Lee Jones <lee.jones@linaro.org> wrote:
> > > >
> > > > > Some platforms provide clocks which require enabling before the
> > > > > SMSC911x chip will power on. This patch uses the new common clk
> > > > > framework to do just that. If no clock is provided, it will just
> > > > > be ignored and the driver will continue to assume that no clock
> > > > > is required for the chip to run successfully.
> > > > >
> > > > > Cc: Steve Glendinning <steve.glendinning@shawell.net>
> > > > > Cc: netdev@vger.kernel.org
> > > > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > >
> > > > Seems to me like it'll do the trick.
> > > > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > >
> > > This looks fairly dangerous. What about those platforms which use this
> > > driver, but don't provide a clock for it?
> > >
> > > It looks like this will result in those platforms losing their ethernet
> > > support. There's at least a bunch of the ARM evaluation boards which
> > > make use of this driver...
> >
> > Right, but nothing should regress. If no clock is provided the driver
> > moves on during the request and will refuse to prepare, enable and
> > disable there after.
> >
> > Unless I've made a mistake somewhere? If so, I'd be happy to fixup.
>
> No, but... don't use NULL for that. Use IS_ERR(pdata->clk) instead.
I'm a bit confused. I do use IS_ERR, then if there was a problem
pdata->clk is set to NULL, then we test for NULL thereafter:
> /* Request clock */
> pdata->clk = clk_get(&pdev->dev, NULL);
> if (IS_ERR(pdata->clk)) {
> netdev_warn(ndev, "couldn't get clock %d\n", PTR_ERR(pdata->clk));
> pdata->clk = NULL;
> }
Are you saying remove "pdata->clk = NULL;" and test for IS_ERR
every time?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/4] net/smsc911x: Provide common clock functionality
From: Russell King - ARM Linux @ 2012-12-21 9:24 UTC (permalink / raw)
To: Lee Jones
Cc: Linus Walleij, Steve Glendinning, Robert Marklund, linus.walleij,
arnd, netdev, linux-kernel, linux-arm-kernel
In-Reply-To: <20121221091306.GO2691@gmail.com>
On Fri, Dec 21, 2012 at 09:13:06AM +0000, Lee Jones wrote:
> Are you saying remove "pdata->clk = NULL;" and test for IS_ERR
> every time?
Exactly.
^ permalink raw reply
* Re: PMTU discovery is broken on kernel 3.7.1 for UDP sockets
From: Steffen Klassert @ 2012-12-21 10:22 UTC (permalink / raw)
To: Yurij M. Plotnikov; +Cc: Ben Hutchings, netdev, Alexandra N. Kossovsky
In-Reply-To: <20121220123535.GN18940@secunet.com>
On Thu, Dec 20, 2012 at 01:35:35PM +0100, Steffen Klassert wrote:
> On Thu, Dec 20, 2012 at 03:22:13PM +0400, Yurij M. Plotnikov wrote:
> > On 12/20/12 11:34, Steffen Klassert wrote:
> > >
> > >diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> > >index 3c9d208..1049ce0 100644
> > >--- a/net/ipv4/ip_sockglue.c
> > >+++ b/net/ipv4/ip_sockglue.c
> > >@@ -1198,7 +1198,7 @@ static int do_ip_getsockopt(struct sock *sk, int level, int optname,
> > > {
> > > struct dst_entry *dst;
> > > val = 0;
> > >- dst = sk_dst_get(sk);
> > >+ dst = sk_dst_check(sk, 0);
> > > if (dst) {
> > > val = dst_mtu(dst);
> > > dst_release(dst);
> > With this patch kernel 3.7.1 works perfect. All described problems
> > are fixed.
>
> Thanks for testing!
>
> I'm not sure if we can't use this as a fix. I think with this patch it
> could happen that we return -ENOTCONN instead of a pmtu value on a
> connected socket. Perhaps it is better to update the cached dst_entry in
> ipv4_sk_update_pmtu() when we receive the -EMSGSIZE. I'll do some
> investigation.
>
It turned out that updating the cached dst_entry in ipv4_sk_update_pmtu()
is not trivial. We need to implement proper socket locking and we need
socket release calback functions for all protocols that use
ipv4_sk_update_pmtu(), similar to tcp.
Today is my last office day for this year, so we probably have to defer
a solution to the next year.
Thanks.
^ permalink raw reply
* Re: [PATCH] xen/netfront: improve truesize tracking
From: Sander Eikelenboom @ 2012-12-21 11:21 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ian Campbell, netdev@vger.kernel.org, Konrad Rzeszutek Wilk,
annie li, xen-devel@lists.xensource.com
In-Reply-To: <1356017968.21834.2859.camel@edumazet-glaptop>
Thursday, December 20, 2012, 4:39:28 PM, you wrote:
> On Thu, 2012-12-20 at 13:51 +0100, Sander Eikelenboom wrote:
>> Eric:
>> From the warn_on_once, delta should be smaller than len, but probably they should be as close together as possible.
>> When you say "accurate estimation", what would be a acceptable difference between DELTA and LEN ?
> I would use the most exact value, which is :
> skb->truesize += nr_frags * PAGE_SIZE;
> Then, if we can spot later a regression in some stacks, adapt the
> limiting parameters. I did a lot of work in GRO and TCP stack to reduce
> the memory, and further changes are possible.
> We really want to account memory, because we want to control how memory
> is used on our machines and don't let some users use more than the
> amount that was allowed to them.
Hi Eric and Ian,
I have ran some perfnet tests (although i'm not an expert, so i'm not sure i have done the right tests).
I you have better tests, please do say so ..
"current" is with netfront as is (skb->truesize += skb->data_len - RX_COPY_THRESHOLD;)
"patched" is with IanC's latest patch (skb->truesize += PAGE_SIZE * skb_shinfo(skb)->nr_frags;)
Tested between domU and dom0 (bridged) on a system with only one guest. The results don't seem to differ very much.
+ netperf -H 192.168.1.1 -t TCP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. KBytes/sec
current 87380 16384 16384 60.00 954438.38
patched 87380 16384 16384 60.00 975236.19
+ netperf -H 192.168.1.1 -t TCP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2 -- -s 50
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. KBytes/sec
current 87380 2048 2048 60.00 17614.79
patched 87380 2048 2048 60.00 17207.46
+ netperf -H 192.168.1.1 -t TCP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2 -- -s 50 -M 1432 -m 1432
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. KBytes/sec
current 87380 2048 1432 60.00 35.28
patched 87380 2048 1432 60.00 35.28
+ netperf -H 192.168.1.1 -t TCP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2 -- -s 9000
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. KBytes/sec
current 87380 18000 18000 60.00 157762.45
patched 87380 18000 18000 60.00 158606.02
+ netperf -H 192.168.1.1 -t TCP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2 -- -s 9000 -M 1432 -m 1432
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. KBytes/sec
current 87380 18000 1432 60.00 78567.39
patched 87380 18000 1432 60.00 78329.98
+ netperf -H 192.168.1.1 -t UDP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # KBytes/sec
current 212992 65507 60.00 248771 0 265238.24
current 212992 60.00 214267 228450.01
patched 212992 65507 60.00 251188 0 267814.90
patched 212992 60.00 235101 250662.67
+ netperf -H 192.168.1.1 -t UDP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2 -- -s 50
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # KBytes/sec
current 2048 2048 60.00 1329653 0 44321.73
current 212992 60.00 1329650 44321.62
patched 2048 2048 60.00 1363257 0 45441.68
patched 212992 60.00 1363253 45441.57
+ netperf -H 192.168.1.1 -t UDP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2 -- -s 50 -M 1432 -m 1432
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # KBytes/sec
current 2048 1432 60.00 1516249 0 35339.61
current 212992 60.00 1516247 35339.56
patched 2048 1432 60.00 1483705 0 34581.11
patched 212992 60.00 1483701 34581.01
+ netperf -H 192.168.1.1 -t UDP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2 -- -s 9000
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # KBytes/sec
current 18000 18000 60.00 540410 26 158322.98
current 212992 60.00 540349 158305.24
patched 18000 18000 60.00 555449 32 162728.98
patched 212992 60.00 555392 162712.28
+ netperf -H 192.168.1.1 -t UDP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2 -- -s 9000 -M 1432 -m 1432
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # KBytes/sec
current 18000 1432 60.00 5144189 0 119896.95
current 212992 60.00 5138354 119760.96
patched 18000 1432 60.00 5104540 0 118972.85
patched 212992 60.00 5099802 118862.44
^ permalink raw reply
* Re: bonding driver - how to recognize the active slave
From: Jiri Pirko @ 2012-12-21 11:34 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Eric Dumazet, Erez Shitrit, netdev@vger.kernel.org
In-Reply-To: <CAJZOPZLOj2QCWN75hAsQnmB=YiSGRhdhzf4ODhAD-QoU+Y0ZGg@mail.gmail.com>
Thu, Dec 20, 2012 at 11:21:00PM CET, or.gerlitz@gmail.com wrote:
>On Thu, Dec 20, 2012 at 11:19 PM, Eric Dumazet <erdnetdev@gmail.com> wrote:
>> cat /sys/class/net/bond0/bonding/active_slave
>
>sure, I think Erez would like to know that from within a network
>device kernel code, e.g maybe register to netdev kernel events and on
>the event of bonding fail-over identify the active slave for
>active-backup mode, etc.
I wonder why device should care of such thing? Would it behave
differently?
>
>Or.
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 4/4 v2] net/smsc911x: Provide common clock functionality
From: Lee Jones @ 2012-12-21 11:41 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Linus Walleij, Steve Glendinning, Robert Marklund, linus.walleij,
arnd, netdev, linux-kernel, linux-arm-kernel
In-Reply-To: <20121221092421.GG14363@n2100.arm.linux.org.uk>
Some platforms provide clocks which require enabling before the
SMSC911x chip will power on. This patch uses the new common clk
framework to do just that. If no clock is provided, it will just
be ignored and the driver will continue to assume that no clock
is required for the chip to run successfully.
Cc: Steve Glendinning <steve.glendinning@shawell.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/net/ethernet/smsc/smsc911x.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index e112877..afa4d62 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -33,6 +33,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/crc32.h>
+#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/errno.h>
#include <linux/etherdevice.h>
@@ -144,6 +145,9 @@ struct smsc911x_data {
/* regulators */
struct regulator_bulk_data supplies[SMSC911X_NUM_SUPPLIES];
+
+ /* clock */
+ struct clk *clk;
};
/* Easy access to information */
@@ -369,7 +373,7 @@ out:
}
/*
- * enable resources, currently just regulators.
+ * enable regulator and clock resources.
*/
static int smsc911x_enable_resources(struct platform_device *pdev)
{
@@ -382,6 +386,13 @@ static int smsc911x_enable_resources(struct platform_device *pdev)
if (ret)
netdev_err(ndev, "failed to enable regulators %d\n",
ret);
+
+ if (IS_ERR(pdata->clk)) {
+ ret = clk_prepare_enable(pdata->clk);
+ if (ret < 0)
+ netdev_err(ndev, "failed to enable clock %d\n", ret);
+ }
+
return ret;
}
@@ -396,6 +407,10 @@ static int smsc911x_disable_resources(struct platform_device *pdev)
ret = regulator_bulk_disable(ARRAY_SIZE(pdata->supplies),
pdata->supplies);
+
+ if (IS_ERR(pdata->clk))
+ clk_disable_unprepare(pdata->clk);
+
return ret;
}
@@ -421,6 +436,12 @@ static int smsc911x_request_resources(struct platform_device *pdev)
if (ret)
netdev_err(ndev, "couldn't get regulators %d\n",
ret);
+
+ /* Request clock */
+ pdata->clk = clk_get(&pdev->dev, NULL);
+ if (IS_ERR(pdata->clk))
+ netdev_warn(ndev, "couldn't get clock %li\n", PTR_ERR(pdata->clk));
+
return ret;
}
@@ -436,6 +457,12 @@ static void smsc911x_free_resources(struct platform_device *pdev)
/* Free regulators */
regulator_bulk_free(ARRAY_SIZE(pdata->supplies),
pdata->supplies);
+
+ /* Free clock */
+ if (IS_ERR(pdata->clk)) {
+ clk_put(pdata->clk);
+ pdata->clk = NULL;
+ }
}
/* waits for MAC not busy, with timeout. Only called by smsc911x_mac_read
--
1.7.9.5
^ permalink raw reply related
* [RFC] Route lost when src address is removed.
From: Hemmo Nieminen @ 2012-12-21 12:09 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 881 bytes --]
Hi,
A route is lost to a subnet, even if it still has addresses
in that subnet.
In normal situations, it seems, a route's source address is the
same as the subnet's primary address and if it gets removed, the
route's source address is updated to be the new primary address.
If, however, the route's source address has been changed to some
other IP address than the primary address, the route is lost
when the source address is removed. This leaves us with IP
addresses in a subnet but no route to that subnet.
I encountered this and was not able to figure out whether this
behaviour is intentional or not? I would sort of expect the
route the be updated to have e.g. the primary address as the new
source address but perhaps not in all cases... What do you
think?
Attached below an example run that should also include all the
information needed to reproduce this.
--
Hemmo
[-- Attachment #2: route.log --]
[-- Type: text/plain, Size: 2209 bytes --]
[root@fcku ~]# ip a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:23:54:20:73:3e brd ff:ff:ff:ff:ff:ff
inet 192.168.1.105/24 brd 192.168.1.255 scope global eth0
inet6 fe80::223:54ff:fe20:733e/64 scope link
valid_lft forever preferred_lft forever
[root@fcku ~]# ip a a 1.1.1.1/24 dev eth0
[root@fcku ~]# ip a a 1.1.1.2/24 dev eth0
[root@fcku ~]# ip a a 1.1.1.3/24 dev eth0
[root@fcku ~]# ip a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:23:54:20:73:3e brd ff:ff:ff:ff:ff:ff
inet 192.168.1.105/24 brd 192.168.1.255 scope global eth0
inet 1.1.1.1/24 scope global eth0
inet 1.1.1.2/24 scope global secondary eth0
inet 1.1.1.3/24 scope global secondary eth0
inet6 fe80::223:54ff:fe20:733e/64 scope link
valid_lft forever preferred_lft forever
[root@fcku ~]# ip r s
default via 192.168.1.1 dev eth0 metric 202
1.1.1.0/24 dev eth0 proto kernel scope link src 1.1.1.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.105 metric 202
[root@fcku ~]# ip r replace 1.1.1.0/24 dev eth0 proto kernel scope link src 1.1.1.2
[root@fcku ~]# ip r s
default via 192.168.1.1 dev eth0 metric 202
1.1.1.0/24 dev eth0 proto kernel scope link src 1.1.1.2
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.105 metric 202
[root@fcku ~]# ip a d 1.1.1.2/24 dev eth0
[root@fcku ~]# ip a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:23:54:20:73:3e brd ff:ff:ff:ff:ff:ff
inet 192.168.1.105/24 brd 192.168.1.255 scope global eth0
inet 1.1.1.1/24 scope global eth0
inet 1.1.1.3/24 scope global secondary eth0
inet6 fe80::223:54ff:fe20:733e/64 scope link
valid_lft forever preferred_lft forever
[root@fcku ~]# ip r s
default via 192.168.1.1 dev eth0 metric 202
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.105 metric 202
[root@fcku ~]# uname -a
Linux fcku 3.6.10-1-ARCH #1 SMP PREEMPT Tue Dec 11 09:40:17 CET 2012 x86_64 GNU/Linux
[root@fcku ~]# ip -V
ip utility, iproute2-ss121001
[root@fcku ~]#
^ permalink raw reply
* perm_addr get
From: Jiri Pirko @ 2012-12-21 13:01 UTC (permalink / raw)
To: netdev; +Cc: bhutchings
Hi all.
>From what I understand dev->perm_addr is set only in case the hw has
permanent hw address somewhere written (for example EPROM).
So when I query device which does not have perm_addr set I get:
testt1:~$ ethtool -P team0
Permanent address: 00:00:00:00:00:00
Is this the correct behaviour? Wouldn't it be more correct if
ethtool_get_perm_addr() fails with -ENOENT for something like that?
Thanks.
Jiri
^ permalink raw reply
* Re: [PATCH] pkt_sched: act_xt support new Xtables interface
From: Jamal Hadi Salim @ 2012-12-21 13:03 UTC (permalink / raw)
To: Yury Stankevich
Cc: Hasan Chowdhury, Stephen Hemminger, Jan Engelhardt,
netdev@vger.kernel.org, pablo, netfilter-devel
In-Reply-To: <50D327CD.3050904@gmail.com>
On 12-12-20 09:59 AM, Yury Stankevich wrote:
> interesting,
>
> #tc -s filter show dev usb0 parent ffff:
Given you are adding this on ingress - the settings you have will
happen before pre-routing hook.
If you did things at egress - the setting will take effect after
post-routing. So take a closer look at those details they look
like your source of issues..
cheers,
jamal
^ 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