* [PATCH 1/2] ipv4: Invalidate nexthop cache nh_saddr more correctly.
From: David Miller @ 2011-03-25 1:14 UTC (permalink / raw)
To: netdev; +Cc: ja
Any operation that:
1) Brings up an interface
2) Adds an IP address to an interface
3) Deletes an IP address from an interface
can potentially invalidate the nh_saddr value, requiring
it to be recomputed.
Perform the recomputation lazily using a generation ID.
Reported-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/ip_fib.h | 12 ++++++++++--
include/net/netns/ipv4.h | 1 +
net/ipv4/fib_frontend.c | 11 +++++++----
net/ipv4/fib_semantics.c | 32 +++++++++++---------------------
net/ipv4/route.c | 6 ++++--
5 files changed, 33 insertions(+), 29 deletions(-)
diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
index a1a8580..cd92b92 100644
--- a/include/net/ip_fib.h
+++ b/include/net/ip_fib.h
@@ -62,6 +62,7 @@ struct fib_nh {
int nh_oif;
__be32 nh_gw;
__be32 nh_saddr;
+ int nh_saddr_genid;
};
/*
@@ -141,12 +142,19 @@ struct fib_result_nl {
#endif /* CONFIG_IP_ROUTE_MULTIPATH */
-#define FIB_RES_SADDR(res) (FIB_RES_NH(res).nh_saddr)
+extern __be32 fib_info_update_nh_saddr(struct net *net, struct fib_nh *nh);
+
+#define FIB_RES_SADDR(net, res) \
+ ((FIB_RES_NH(res).nh_saddr_genid == \
+ atomic_read(&(net)->ipv4.dev_addr_genid)) ? \
+ FIB_RES_NH(res).nh_saddr : \
+ fib_info_update_nh_saddr((net), &FIB_RES_NH(res)))
#define FIB_RES_GW(res) (FIB_RES_NH(res).nh_gw)
#define FIB_RES_DEV(res) (FIB_RES_NH(res).nh_dev)
#define FIB_RES_OIF(res) (FIB_RES_NH(res).nh_oif)
-#define FIB_RES_PREFSRC(res) ((res).fi->fib_prefsrc ? : FIB_RES_SADDR(res))
+#define FIB_RES_PREFSRC(net, res) ((res).fi->fib_prefsrc ? : \
+ FIB_RES_SADDR(net, res))
struct fib_table {
struct hlist_node tb_hlist;
diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index e2e2ef5..542195d 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -55,6 +55,7 @@ struct netns_ipv4 {
int current_rt_cache_rebuild_count;
atomic_t rt_genid;
+ atomic_t dev_addr_genid;
#ifdef CONFIG_IP_MROUTE
#ifndef CONFIG_IP_MROUTE_MULTIPLE_TABLES
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 02c3ba6..f116ce8 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -228,7 +228,7 @@ int fib_validate_source(__be32 src, __be32 dst, u8 tos, int oif,
if (res.type != RTN_LOCAL || !accept_local)
goto e_inval;
}
- *spec_dst = FIB_RES_PREFSRC(res);
+ *spec_dst = FIB_RES_PREFSRC(net, res);
fib_combine_itag(itag, &res);
dev_match = false;
@@ -258,7 +258,7 @@ int fib_validate_source(__be32 src, __be32 dst, u8 tos, int oif,
ret = 0;
if (fib_lookup(net, &fl4, &res) == 0) {
if (res.type == RTN_UNICAST) {
- *spec_dst = FIB_RES_PREFSRC(res);
+ *spec_dst = FIB_RES_PREFSRC(net, res);
ret = FIB_RES_NH(res).nh_scope >= RT_SCOPE_HOST;
}
}
@@ -960,6 +960,7 @@ static int fib_inetaddr_event(struct notifier_block *this, unsigned long event,
{
struct in_ifaddr *ifa = (struct in_ifaddr *)ptr;
struct net_device *dev = ifa->ifa_dev->dev;
+ struct net *net = dev_net(dev);
switch (event) {
case NETDEV_UP:
@@ -967,12 +968,12 @@ static int fib_inetaddr_event(struct notifier_block *this, unsigned long event,
#ifdef CONFIG_IP_ROUTE_MULTIPATH
fib_sync_up(dev);
#endif
- fib_update_nh_saddrs(dev);
+ atomic_inc(&net->ipv4.dev_addr_genid);
rt_cache_flush(dev_net(dev), -1);
break;
case NETDEV_DOWN:
fib_del_ifaddr(ifa, NULL);
- fib_update_nh_saddrs(dev);
+ atomic_inc(&net->ipv4.dev_addr_genid);
if (ifa->ifa_dev->ifa_list == NULL) {
/* Last address was deleted from this interface.
* Disable IP.
@@ -990,6 +991,7 @@ static int fib_netdev_event(struct notifier_block *this, unsigned long event, vo
{
struct net_device *dev = ptr;
struct in_device *in_dev = __in_dev_get_rtnl(dev);
+ struct net *net = dev_net(dev);
if (event == NETDEV_UNREGISTER) {
fib_disable_ip(dev, 2, -1);
@@ -1007,6 +1009,7 @@ static int fib_netdev_event(struct notifier_block *this, unsigned long event, vo
#ifdef CONFIG_IP_ROUTE_MULTIPATH
fib_sync_up(dev);
#endif
+ atomic_inc(&net->ipv4.dev_addr_genid);
rt_cache_flush(dev_net(dev), -1);
break;
case NETDEV_DOWN:
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 75b9fb5..2d4bebc 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -695,6 +695,16 @@ static void fib_info_hash_move(struct hlist_head *new_info_hash,
fib_info_hash_free(old_laddrhash, bytes);
}
+__be32 fib_info_update_nh_saddr(struct net *net, struct fib_nh *nh)
+{
+ nh->nh_saddr = inet_select_addr(nh->nh_dev,
+ nh->nh_gw,
+ nh->nh_cfg_scope);
+ nh->nh_saddr_genid = atomic_read(&net->ipv4.dev_addr_genid);
+
+ return nh->nh_saddr;
+}
+
struct fib_info *fib_create_info(struct fib_config *cfg)
{
int err;
@@ -855,9 +865,7 @@ struct fib_info *fib_create_info(struct fib_config *cfg)
change_nexthops(fi) {
nexthop_nh->nh_cfg_scope = cfg->fc_scope;
- nexthop_nh->nh_saddr = inet_select_addr(nexthop_nh->nh_dev,
- nexthop_nh->nh_gw,
- nexthop_nh->nh_cfg_scope);
+ fib_info_update_nh_saddr(net, nexthop_nh);
} endfor_nexthops(fi)
link_it:
@@ -1128,24 +1136,6 @@ out:
return;
}
-void fib_update_nh_saddrs(struct net_device *dev)
-{
- struct hlist_head *head;
- struct hlist_node *node;
- struct fib_nh *nh;
- unsigned int hash;
-
- hash = fib_devindex_hashfn(dev->ifindex);
- head = &fib_info_devhash[hash];
- hlist_for_each_entry(nh, node, head, nh_hash) {
- if (nh->nh_dev != dev)
- continue;
- nh->nh_saddr = inet_select_addr(nh->nh_dev,
- nh->nh_gw,
- nh->nh_cfg_scope);
- }
-}
-
#ifdef CONFIG_IP_ROUTE_MULTIPATH
/*
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 34921b0..4b0c811 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1718,7 +1718,7 @@ void ip_rt_get_source(u8 *addr, struct rtable *rt)
rcu_read_lock();
if (fib_lookup(dev_net(rt->dst.dev), &fl4, &res) == 0)
- src = FIB_RES_PREFSRC(res);
+ src = FIB_RES_PREFSRC(dev_net(rt->dst.dev), res);
else
src = inet_select_addr(rt->dst.dev, rt->rt_gateway,
RT_SCOPE_UNIVERSE);
@@ -2615,7 +2615,7 @@ static struct rtable *ip_route_output_slow(struct net *net,
fib_select_default(&res);
if (!fl4.saddr)
- fl4.saddr = FIB_RES_PREFSRC(res);
+ fl4.saddr = FIB_RES_PREFSRC(net, res);
dev_out = FIB_RES_DEV(res);
fl4.flowi4_oif = dev_out->ifindex;
@@ -3219,6 +3219,8 @@ static __net_init int rt_genid_init(struct net *net)
{
get_random_bytes(&net->ipv4.rt_genid,
sizeof(net->ipv4.rt_genid));
+ get_random_bytes(&net->ipv4.dev_addr_genid,
+ sizeof(net->ipv4.dev_addr_genid));
return 0;
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/2] Fix nh_saddr caching.
From: David Miller @ 2011-03-25 1:14 UTC (permalink / raw)
To: netdev; +Cc: ja
Julian, the following two patches should take all of the
issues we discovered the other week wrt. nh_saddr caching.
First, we use a generation ID to invalidate cache nh_saddr
settings any time a device goes up or an IP address is
added/removed.
Second, we move fa_scope up to fib_info->fib_scope, so that
we always use the correct scope when computing the cached
nh_saddr.
Please review this carefully as this is delicate code.
Thanks!
^ permalink raw reply
* Re: [PATCH] ipv4: fix fib metrics
From: Alessandro Suardi @ 2011-03-25 1:04 UTC (permalink / raw)
To: Kyle Moffett; +Cc: Eric Dumazet, David Miller, linux-kernel, netdev
In-Reply-To: <AANLkTinh9Li7DGgSqcZ+p9peS5XrHWomerSvKTYwHZ9-@mail.gmail.com>
On Fri, Mar 25, 2011 at 1:53 AM, Kyle Moffett <kyle@moffetthome.net> wrote:
> On Thu, Mar 24, 2011 at 20:12, Alessandro Suardi
> <alessandro.suardi@gmail.com> wrote:
>> On Thu, Mar 24, 2011 at 11:44 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>> Le jeudi 24 mars 2011 à 15:36 -0700, David Miller a écrit :
>>>> From: Eric Dumazet <eric.dumazet@gmail.com>
>>>> Date: Thu, 24 Mar 2011 23:32:26 +0100
>>>>
>>>> > Then it doesnt work anymore because it parses an ipip field from
>>>> > ip route get ...
>>>> >
>>>> > $ ip ro get 192.168.1.1
>>>> > 192.168.1.1 dev wlan0 src 192.168.1.21
>>>> > cache ipid 0x784c mtu 1500 advmss 1460 hoplimit 64
>>>> >
>>>> >
>>>> > Maybe you upgraded iproute2
>>>>
>>>> I'm leaning towards app bug too.
>>>>
>>>> These default metrics wouldn't get printed before, but now because of
>>>> how metrics are handled, they will.
>>>>
>>>> Userland needs to cope properly with this.
>>>
>>>
>>> BTW, ipip is not always printed (even on old kernels) : One needs to
>>> actually need ipip generation .
>>>
>>> edumazet@edumazet-laptop:~$ ping 4.4.4.4
>>> PING 4.4.4.4 (4.4.4.4) 56(84) bytes of data.
>>> ^C
>>>
>>> edumazet@edumazet-laptop:~$ ip ro get 4.4.4.4
>>> 4.4.4.4 dev ppp0 src 10.150.51.210
>>> cache mtu 1500 advmss 1460 hoplimit 64
>>>
>>> edumazet@edumazet-laptop:~$ ping -s 2000 4.4.4.4
>>> PING 4.4.4.4 (4.4.4.4) 2000(2028) bytes of data.
>>> ^C
>>>
>>> edumazet@edumazet-laptop:~$ ip ro get 4.4.4.4
>>> 4.4.4.4 dev ppp0 src 10.150.51.210
>>> cache ipid 0xf99a mtu 1500 advmss 1460 hoplimit 64
>>>
>>>
>>> This on a 2.6.35 kernel
>>>
>>> I suspect Alessandro tool had a bug anyway.
>>
>> I still contend this is a kernel regression :)
>>
>>
>> vpnc is a custom build from trunk as of June 2010, with openssl support
>> to talk to my corporate VPN concentrator:
>>
> [...snip...]
>>
>> My iproute package, on this up-to-date Fedora 14 x86_64, has last been
>> updated on 20 Nov 2010, and back then I was running 2.6.37-rc2-git4
>> (I keep around my historical .config files, so I know for sure).
>>
>> [root@duff ~]# ip -V
>> ip utility, iproute2-ss100804
>> [root@duff ~]# rpm -qf /sbin/ip
>> iproute-2.6.35-6.fc14.x86_64
>>
>> The behavior of this version of 'ip' as invoked by this version of 'vpnc'
>> is something that has worked for the last 4 months, and isn't working
>> right now. Furthermore, previous versions of 'ip' in Fedora 14 were
>> also working with the same 'vpnc', which means it's actually 9 months
>> minimum of working behavior.
>>
>> If some change in the kernel broke my userspace, this usually qualifies
>> as a regression.
>>
>> That said, if you can point me to a working version of iproute with the
>> current kernel, I have no problem in upgrading it :)
>
> Historically you could usually take the text output of "ip route get"
> and feed it right back to "ip route add", and it would work, but this
> was never guaranteed.
>
> Recently, the "ip route get" command started printing extra statistics
> (like "ipid") after the other information, but obviously those
> statistics are not valid for an "ip route add" command.
>
> The kernel bug was that the "ip" command was not always getting those
> statistics from the kernel, so obviously they would not be printed.
>
> Unfortunately vpnc still tries to pass the entire output of "ip route
> get" as arguments to "ip route add"; the latter command reports an
> error when it gets the statistics from the former command as input.
>
> So this is certainly not a kernel bug. At *best* it's an iproute bug,
> depending on whether or not this is considered valid:
> RT="$(ip route get [...])"
> ip route flush
> ip route add ${RT}
Fair enough, I get it.
Looks like the fix_ip_get_output() function in /etc/vpnc/vpnc-script
needs to be augmented from the current
sed 's/cache//;s/metric \?[0-9]\+ [0-9]\+//g;s/hoplimit [0-9]\+//g'
to something slightly more comprehensive.
Thanks for the explanation - will keep around -git2 for my vpnc
needs until I get this one sorted out :)
--alessandro
"There's always a siren singing you to shipwreck"
(Radiohead, "There There")
^ permalink raw reply
* Re: [PATCH] ipv4: fix fib metrics
From: Kyle Moffett @ 2011-03-25 0:53 UTC (permalink / raw)
To: Alessandro Suardi; +Cc: Eric Dumazet, David Miller, linux-kernel, netdev
In-Reply-To: <AANLkTi=Xb3KCBKoVCcaVD5iyCtMCAnYaGF_DTeFQ0ays@mail.gmail.com>
On Thu, Mar 24, 2011 at 20:12, Alessandro Suardi
<alessandro.suardi@gmail.com> wrote:
> On Thu, Mar 24, 2011 at 11:44 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> Le jeudi 24 mars 2011 à 15:36 -0700, David Miller a écrit :
>>> From: Eric Dumazet <eric.dumazet@gmail.com>
>>> Date: Thu, 24 Mar 2011 23:32:26 +0100
>>>
>>> > Then it doesnt work anymore because it parses an ipip field from
>>> > ip route get ...
>>> >
>>> > $ ip ro get 192.168.1.1
>>> > 192.168.1.1 dev wlan0 src 192.168.1.21
>>> > cache ipid 0x784c mtu 1500 advmss 1460 hoplimit 64
>>> >
>>> >
>>> > Maybe you upgraded iproute2
>>>
>>> I'm leaning towards app bug too.
>>>
>>> These default metrics wouldn't get printed before, but now because of
>>> how metrics are handled, they will.
>>>
>>> Userland needs to cope properly with this.
>>
>>
>> BTW, ipip is not always printed (even on old kernels) : One needs to
>> actually need ipip generation .
>>
>> edumazet@edumazet-laptop:~$ ping 4.4.4.4
>> PING 4.4.4.4 (4.4.4.4) 56(84) bytes of data.
>> ^C
>>
>> edumazet@edumazet-laptop:~$ ip ro get 4.4.4.4
>> 4.4.4.4 dev ppp0 src 10.150.51.210
>> cache mtu 1500 advmss 1460 hoplimit 64
>>
>> edumazet@edumazet-laptop:~$ ping -s 2000 4.4.4.4
>> PING 4.4.4.4 (4.4.4.4) 2000(2028) bytes of data.
>> ^C
>>
>> edumazet@edumazet-laptop:~$ ip ro get 4.4.4.4
>> 4.4.4.4 dev ppp0 src 10.150.51.210
>> cache ipid 0xf99a mtu 1500 advmss 1460 hoplimit 64
>>
>>
>> This on a 2.6.35 kernel
>>
>> I suspect Alessandro tool had a bug anyway.
>
> I still contend this is a kernel regression :)
>
>
> vpnc is a custom build from trunk as of June 2010, with openssl support
> to talk to my corporate VPN concentrator:
>
[...snip...]
>
> My iproute package, on this up-to-date Fedora 14 x86_64, has last been
> updated on 20 Nov 2010, and back then I was running 2.6.37-rc2-git4
> (I keep around my historical .config files, so I know for sure).
>
> [root@duff ~]# ip -V
> ip utility, iproute2-ss100804
> [root@duff ~]# rpm -qf /sbin/ip
> iproute-2.6.35-6.fc14.x86_64
>
> The behavior of this version of 'ip' as invoked by this version of 'vpnc'
> is something that has worked for the last 4 months, and isn't working
> right now. Furthermore, previous versions of 'ip' in Fedora 14 were
> also working with the same 'vpnc', which means it's actually 9 months
> minimum of working behavior.
>
> If some change in the kernel broke my userspace, this usually qualifies
> as a regression.
>
> That said, if you can point me to a working version of iproute with the
> current kernel, I have no problem in upgrading it :)
Historically you could usually take the text output of "ip route get"
and feed it right back to "ip route add", and it would work, but this
was never guaranteed.
Recently, the "ip route get" command started printing extra statistics
(like "ipid") after the other information, but obviously those
statistics are not valid for an "ip route add" command.
The kernel bug was that the "ip" command was not always getting those
statistics from the kernel, so obviously they would not be printed.
Unfortunately vpnc still tries to pass the entire output of "ip route
get" as arguments to "ip route add"; the latter command reports an
error when it gets the statistics from the former command as input.
So this is certainly not a kernel bug. At *best* it's an iproute bug,
depending on whether or not this is considered valid:
RT="$(ip route get [...])"
ip route flush
ip route add ${RT}
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: bnx2 vlan issue
From: Seblu @ 2011-03-25 0:26 UTC (permalink / raw)
To: Jesse Gross; +Cc: netdev
In-Reply-To: <AANLkTi=zfhwHTB7kitgwk3AzSa0aFFyxgM_ZY-3wObR5@mail.gmail.com>
On Thu, Mar 24, 2011 at 8:55 PM, Jesse Gross <jesse@nicira.com> wrote:
> On Thu, Mar 24, 2011 at 5:58 AM, Seblu <seblu@seblu.net> wrote:
>>> I don't necessarily disagree that there should be a better way to do
>>> this, though as of the moment the above is probably your best bet.
>>>
>>> To me, the most important thing is to have consistent behavior across
>>> different cards.
>>
>> Speaking of that, i've tryed 2.6.38 on my station (dell opitplex 980)
>> to use the new bridging schema and it doesn't work.
>> Exactly the case previously described: ip on br0 (eth0+eth1) and ip on
>> br0.42. eth0 driver is e1000e and eth1 is tg3. br0.42 don't receive
>> traffic.
>> I have to open a bug report?
>
> The change was deliberate, not an accidental mistake, so don't expect
> 2.6.38 to suddenly switch back to the previous behavior. There's no
> need to file a bug report - the new behavior is known (I was the one
> who changed it in the first place). I will look into nicer semantics
> in the future.
>
Maybe i was not enough clear. It seems to me that new behaviour, with
vlan on top of bridge rather than above interface in bridge is not
functional.
In other words, i cannot use vlan and bridge together in 2.6.38 (with e1000e).
I understand hard works are in progress and old behaviour will maybe
disapear forever. Here i just don't use vlan and bridge like you
suggest me in your previous post.
--
Sébastien Luttringer
www.seblu.net
^ permalink raw reply
* Re: [PATCH] ipv4: fix fib metrics
From: David Miller @ 2011-03-25 0:22 UTC (permalink / raw)
To: alessandro.suardi; +Cc: eric.dumazet, linux-kernel, netdev
In-Reply-To: <AANLkTi=Xb3KCBKoVCcaVD5iyCtMCAnYaGF_DTeFQ0ays@mail.gmail.com>
From: Alessandro Suardi <alessandro.suardi@gmail.com>
Date: Fri, 25 Mar 2011 01:12:11 +0100
> If some change in the kernel broke my userspace, this usually
> qualifies as a regression.
Not if userspace was working on an assumption it was not allowed to
make, which we believe it is in this case.
^ permalink raw reply
* Re: [PATCH] ipv4: fix fib metrics
From: Alessandro Suardi @ 2011-03-25 0:12 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, linux-kernel, netdev
In-Reply-To: <1301006652.2714.145.camel@edumazet-laptop>
On Thu, Mar 24, 2011 at 11:44 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 24 mars 2011 à 15:36 -0700, David Miller a écrit :
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Thu, 24 Mar 2011 23:32:26 +0100
>>
>> > Then it doesnt work anymore because it parses an ipip field from
>> > ip route get ...
>> >
>> > $ ip ro get 192.168.1.1
>> > 192.168.1.1 dev wlan0 src 192.168.1.21
>> > cache ipid 0x784c mtu 1500 advmss 1460 hoplimit 64
>> >
>> >
>> > Maybe you upgraded iproute2
>>
>> I'm leaning towards app bug too.
>>
>> These default metrics wouldn't get printed before, but now because of
>> how metrics are handled, they will.
>>
>> Userland needs to cope properly with this.
>
>
> BTW, ipip is not always printed (even on old kernels) : One needs to
> actually need ipip generation .
>
> edumazet@edumazet-laptop:~$ ping 4.4.4.4
> PING 4.4.4.4 (4.4.4.4) 56(84) bytes of data.
> ^C
>
> edumazet@edumazet-laptop:~$ ip ro get 4.4.4.4
> 4.4.4.4 dev ppp0 src 10.150.51.210
> cache mtu 1500 advmss 1460 hoplimit 64
>
> edumazet@edumazet-laptop:~$ ping -s 2000 4.4.4.4
> PING 4.4.4.4 (4.4.4.4) 2000(2028) bytes of data.
> ^C
>
> edumazet@edumazet-laptop:~$ ip ro get 4.4.4.4
> 4.4.4.4 dev ppp0 src 10.150.51.210
> cache ipid 0xf99a mtu 1500 advmss 1460 hoplimit 64
>
>
> This on a 2.6.35 kernel
>
> I suspect Alessandro tool had a bug anyway.
I still contend this is a kernel regression :)
vpnc is a custom build from trunk as of June 2010, with openssl support
to talk to my corporate VPN concentrator:
[root@duff oldconfigs]# vpnc --version
vpnc version 0.5.3-449M
Copyright (C) 2002-2006 Geoffrey Keating, Maurice Massar, others
vpnc comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of vpnc under the terms of the GNU General
Public License. For more information about these matters, see the files
named COPYING.
Built with openssl certificate support. Be aware of the
license implications.
Supported DH-Groups: nopfs dh1 dh2 dh5
Supported Hash-Methods: md5 sha1
Supported Encryptions: null des 3des aes128 aes192 aes256
Supported Auth-Methods: psk psk+xauth hybrid(rsa)
My iproute package, on this up-to-date Fedora 14 x86_64, has last been
updated on 20 Nov 2010, and back then I was running 2.6.37-rc2-git4
(I keep around my historical .config files, so I know for sure).
[root@duff ~]# ip -V
ip utility, iproute2-ss100804
[root@duff ~]# rpm -qf /sbin/ip
iproute-2.6.35-6.fc14.x86_64
The behavior of this version of 'ip' as invoked by this version of 'vpnc'
is something that has worked for the last 4 months, and isn't working
right now. Furthermore, previous versions of 'ip' in Fedora 14 were
also working with the same 'vpnc', which means it's actually 9 months
minimum of working behavior.
If some change in the kernel broke my userspace, this usually qualifies
as a regression.
That said, if you can point me to a working version of iproute with the
current kernel, I have no problem in upgrading it :)
Thanks,
--alessandro
"There's always a siren singing you to shipwreck"
(Radiohead, "There There")
^ permalink raw reply
* [PATCH] bridge: notify applications if address of bridge device changes
From: Stephen Hemminger @ 2011-03-24 23:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, bridge
The mac address of the bridge device may be changed when a new interface
is added to the bridge. If this happens, then the bridge needs to call
the network notifiers to tickle any other systems that care. Since bridge
can be a module, this also means exporting the notifier function.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
net/bridge/br_if.c | 6 +++++-
net/bridge/br_private.h | 2 +-
net/bridge/br_stp_if.c | 9 ++++++---
net/core/dev.c | 1 +
4 files changed, 13 insertions(+), 5 deletions(-)
--- a/net/bridge/br_stp_if.c 2011-03-22 10:13:27.917855706 -0700
+++ b/net/bridge/br_stp_if.c 2011-03-22 10:24:50.416524699 -0700
@@ -204,7 +204,7 @@ void br_stp_change_bridge_id(struct net_
static const unsigned short br_mac_zero_aligned[ETH_ALEN >> 1];
/* called under bridge lock */
-void br_stp_recalculate_bridge_id(struct net_bridge *br)
+bool br_stp_recalculate_bridge_id(struct net_bridge *br)
{
const unsigned char *br_mac_zero =
(const unsigned char *)br_mac_zero_aligned;
@@ -222,8 +222,11 @@ void br_stp_recalculate_bridge_id(struct
}
- if (compare_ether_addr(br->bridge_id.addr, addr))
- br_stp_change_bridge_id(br, addr);
+ if (compare_ether_addr(br->bridge_id.addr, addr) == 0)
+ return false; /* no change */
+
+ br_stp_change_bridge_id(br, addr);
+ return true;
}
/* called under bridge lock */
--- a/net/core/dev.c 2011-03-22 10:14:12.681547462 -0700
+++ b/net/core/dev.c 2011-03-22 10:24:50.416524699 -0700
@@ -1474,6 +1474,7 @@ int call_netdevice_notifiers(unsigned lo
ASSERT_RTNL();
return raw_notifier_call_chain(&netdev_chain, val, dev);
}
+EXPORT_SYMBOL(call_netdevice_notifiers);
/* When > 0 there are consumers of rx skb time stamps */
static atomic_t netstamp_needed = ATOMIC_INIT(0);
--- a/net/bridge/br_if.c 2011-03-22 10:14:12.669553975 -0700
+++ b/net/bridge/br_if.c 2011-03-22 10:24:50.420524900 -0700
@@ -389,6 +389,7 @@ int br_add_if(struct net_bridge *br, str
{
struct net_bridge_port *p;
int err = 0;
+ bool changed_addr;
/* Don't allow bridging non-ethernet like devices */
if ((dev->flags & IFF_LOOPBACK) ||
@@ -446,7 +447,7 @@ int br_add_if(struct net_bridge *br, str
list_add_rcu(&p->list, &br->port_list);
spin_lock_bh(&br->lock);
- br_stp_recalculate_bridge_id(br);
+ changed_addr = br_stp_recalculate_bridge_id(br);
br_features_recompute(br);
if ((dev->flags & IFF_UP) && netif_carrier_ok(dev) &&
@@ -456,6 +457,9 @@ int br_add_if(struct net_bridge *br, str
br_ifinfo_notify(RTM_NEWLINK, p);
+ if (changed_addr)
+ call_netdevice_notifiers(NETDEV_CHANGEADDR, dev);
+
dev_set_mtu(br->dev, br_min_mtu(br));
kobject_uevent(&p->kobj, KOBJ_ADD);
--- a/net/bridge/br_private.h 2011-03-22 10:14:12.673551804 -0700
+++ b/net/bridge/br_private.h 2011-03-22 10:24:50.420524900 -0700
@@ -497,7 +497,7 @@ extern void br_stp_disable_bridge(struct
extern void br_stp_set_enabled(struct net_bridge *br, unsigned long val);
extern void br_stp_enable_port(struct net_bridge_port *p);
extern void br_stp_disable_port(struct net_bridge_port *p);
-extern void br_stp_recalculate_bridge_id(struct net_bridge *br);
+extern bool br_stp_recalculate_bridge_id(struct net_bridge *br);
extern void br_stp_change_bridge_id(struct net_bridge *br, const unsigned char *a);
extern void br_stp_set_bridge_priority(struct net_bridge *br,
u16 newprio);
^ permalink raw reply
* Re: [PATCH] Fix IP timestamp option (IPOPT_TS_PRESPEC) handling in ip_options_echo()
From: David Miller @ 2011-03-24 23:20 UTC (permalink / raw)
To: jluebbe; +Cc: netdev
In-Reply-To: <1300988662-13204-1-git-send-email-jluebbe@debian.org>
From: Jan Luebbe <jluebbe@debian.org>
Date: Thu, 24 Mar 2011 18:44:22 +0100
> - if (soffset + 8 <= optlen) {
> + if (soffset + 7 <= optlen) {
I don't see how you can legally reduce this check from 8 to 7 bytes.
> + if (inet_addr_type(dev_net(skb_dst(skb)->dev), addr) != RTN_UNICAST) {
> dopt->ts_needtime = 1;
> soffset += 8;
> }
Yet keep this code which advances soffset by 8.
^ permalink raw reply
* Re: [PATCH] net: fix pch_gbe section mismatch warning
From: David Miller @ 2011-03-24 23:16 UTC (permalink / raw)
To: randy.dunlap; +Cc: netdev, toshiharu-linux
In-Reply-To: <20110324132812.5bd28f51.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Thu, 24 Mar 2011 13:28:12 -0700
> Fix section mismatch warning by renaming the pci_driver variable to a
> recognized (whitelisted) name.
>
> WARNING: drivers/net/pch_gbe/pch_gbe.o(.data+0x1f8): Section mismatch in reference from the variable pch_gbe_pcidev to the variable .devinit.rodata:pch_gbe_pcidev_id
> The variable pch_gbe_pcidev references
> the variable __devinitconst pch_gbe_pcidev_id
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied, thanks Randy.
^ permalink raw reply
* Re: [PATCH] ipv4: fix fib metrics
From: Eric Dumazet @ 2011-03-24 22:44 UTC (permalink / raw)
To: David Miller; +Cc: alessandro.suardi, linux-kernel, netdev
In-Reply-To: <20110324.153623.45921344.davem@davemloft.net>
Le jeudi 24 mars 2011 à 15:36 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 24 Mar 2011 23:32:26 +0100
>
> > Then it doesnt work anymore because it parses an ipip field from
> > ip route get ...
> >
> > $ ip ro get 192.168.1.1
> > 192.168.1.1 dev wlan0 src 192.168.1.21
> > cache ipid 0x784c mtu 1500 advmss 1460 hoplimit 64
> >
> >
> > Maybe you upgraded iproute2
>
> I'm leaning towards app bug too.
>
> These default metrics wouldn't get printed before, but now because of
> how metrics are handled, they will.
>
> Userland needs to cope properly with this.
BTW, ipip is not always printed (even on old kernels) : One needs to
actually need ipip generation .
edumazet@edumazet-laptop:~$ ping 4.4.4.4
PING 4.4.4.4 (4.4.4.4) 56(84) bytes of data.
^C
edumazet@edumazet-laptop:~$ ip ro get 4.4.4.4
4.4.4.4 dev ppp0 src 10.150.51.210
cache mtu 1500 advmss 1460 hoplimit 64
edumazet@edumazet-laptop:~$ ping -s 2000 4.4.4.4
PING 4.4.4.4 (4.4.4.4) 2000(2028) bytes of data.
^C
edumazet@edumazet-laptop:~$ ip ro get 4.4.4.4
4.4.4.4 dev ppp0 src 10.150.51.210
cache ipid 0xf99a mtu 1500 advmss 1460 hoplimit 64
This on a 2.6.35 kernel
I suspect Alessandro tool had a bug anyway.
^ permalink raw reply
* Re: [PATCH] ipv4: fix fib metrics
From: David Miller @ 2011-03-24 22:36 UTC (permalink / raw)
To: eric.dumazet; +Cc: alessandro.suardi, linux-kernel, netdev
In-Reply-To: <1301005946.2714.130.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 24 Mar 2011 23:32:26 +0100
> Then it doesnt work anymore because it parses an ipip field from
> ip route get ...
>
> $ ip ro get 192.168.1.1
> 192.168.1.1 dev wlan0 src 192.168.1.21
> cache ipid 0x784c mtu 1500 advmss 1460 hoplimit 64
>
>
> Maybe you upgraded iproute2
I'm leaning towards app bug too.
These default metrics wouldn't get printed before, but now because of
how metrics are handled, they will.
Userland needs to cope properly with this.
^ permalink raw reply
* Re: [PATCH] ipv4: fix fib metrics
From: Eric Dumazet @ 2011-03-24 22:32 UTC (permalink / raw)
To: Alessandro Suardi; +Cc: David Miller, linux-kernel, netdev
In-Reply-To: <AANLkTinv+XGBjbFoK6vpyiDW6gBEBKFjUef+mCAMJU9i@mail.gmail.com>
Le jeudi 24 mars 2011 à 23:27 +0100, Alessandro Suardi a écrit :
> Don't think so. This tool has been working since I built it (29 June 2010)
> and still works in -git2 :)
>
Then it doesnt work anymore because it parses an ipip field from
ip route get ...
$ ip ro get 192.168.1.1
192.168.1.1 dev wlan0 src 192.168.1.21
cache ipid 0x784c mtu 1500 advmss 1460 hoplimit 64
Maybe you upgraded iproute2
^ permalink raw reply
* Re: [PATCH] ipv4: fix fib metrics
From: Alessandro Suardi @ 2011-03-24 22:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, linux-kernel, netdev
In-Reply-To: <1301005107.2714.113.camel@edumazet-laptop>
On Thu, Mar 24, 2011 at 11:18 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 24 mars 2011 à 23:11 +0100, Alessandro Suardi a écrit :
>
>> On a -git14 kernel + both the fib metrics and the above git diff, I
>> strace'd vpnc
>> and found out this (first triplet of public IP masked intentionally)
>>
>> [root@duff tmp]# egrep 'execve|garbage' strace.log |egrep '/ip|garbage'
>> [pid 4228] execve("/sbin/ip", ["/sbin/ip", "route", "get",
>> "xxx.9.13.212"], [/* 32 vars */]) = 0
>> [pid 4231] execve("/sbin/ip", ["/sbin/ip", "route", "replace",
>> "10.175.0.0/19", "dev", "tun0"], [/* 32 vars */]) = 0
>> [pid 4232] execve("/sbin/ip", ["/sbin/ip", "route", "flush",
>> "cache"], [/* 32 vars */]) = 0
>> [pid 4234] execve("/sbin/ip", ["/sbin/ip", "route", "get",
>> "xxx.9.13.212"], [/* 32 vars */]) = 0
>> [pid 4237] execve("/sbin/ip", ["/sbin/ip", "route", "add",
>> "xxx.9.13.212", "via", "192.168.1.1", "dev", "eth1", "src",
>> "192.168.1.8", "ipid", "0x043f", "advmss", "1400"], [/* 32 vars */]) =
>> 0
>> [pid 4237] write(2, "Error: either \"to\" is duplicate,"..., 57Error:
>> either "to" is duplicate, or "ipid" is a garbage.
>>
>> 192.168.1.1 is my DSL router and 192.168.1.8 is my computer's wireless IP.
>>
>> Does this ring any bell ?
>>
>>
>
> Not a kernel error, but a tool error ?
>
>
> (ipid is only displayed by "ip ro show")
>
> grep ipid */*.c
> ip/iproute.c: fprintf(fp, " ipid 0x%04x", ci->rta_id);
Don't think so. This tool has been working since I built it (29 June 2010)
and still works in -git2 :)
--alessandro
"There's always a siren singing you to shipwreck"
(Radiohead, "There There")
^ permalink raw reply
* Re: [PATCH] ipv4: fix fib metrics
From: Eric Dumazet @ 2011-03-24 22:18 UTC (permalink / raw)
To: Alessandro Suardi; +Cc: David Miller, linux-kernel, netdev
In-Reply-To: <AANLkTin_gxMF1hyK_yhN+G9UGfcBKAhPE24r7tLe5j3D@mail.gmail.com>
Le jeudi 24 mars 2011 à 23:11 +0100, Alessandro Suardi a écrit :
> On a -git14 kernel + both the fib metrics and the above git diff, I
> strace'd vpnc
> and found out this (first triplet of public IP masked intentionally)
>
> [root@duff tmp]# egrep 'execve|garbage' strace.log |egrep '/ip|garbage'
> [pid 4228] execve("/sbin/ip", ["/sbin/ip", "route", "get",
> "xxx.9.13.212"], [/* 32 vars */]) = 0
> [pid 4231] execve("/sbin/ip", ["/sbin/ip", "route", "replace",
> "10.175.0.0/19", "dev", "tun0"], [/* 32 vars */]) = 0
> [pid 4232] execve("/sbin/ip", ["/sbin/ip", "route", "flush",
> "cache"], [/* 32 vars */]) = 0
> [pid 4234] execve("/sbin/ip", ["/sbin/ip", "route", "get",
> "xxx.9.13.212"], [/* 32 vars */]) = 0
> [pid 4237] execve("/sbin/ip", ["/sbin/ip", "route", "add",
> "xxx.9.13.212", "via", "192.168.1.1", "dev", "eth1", "src",
> "192.168.1.8", "ipid", "0x043f", "advmss", "1400"], [/* 32 vars */]) =
> 0
> [pid 4237] write(2, "Error: either \"to\" is duplicate,"..., 57Error:
> either "to" is duplicate, or "ipid" is a garbage.
>
> 192.168.1.1 is my DSL router and 192.168.1.8 is my computer's wireless IP.
>
> Does this ring any bell ?
>
>
Not a kernel error, but a tool error ?
(ipid is only displayed by "ip ro show")
grep ipid */*.c
ip/iproute.c: fprintf(fp, " ipid 0x%04x", ci->rta_id);
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Eric Paris @ 2011-03-24 22:15 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: David Miller, shemminger, bhutchings, eparis, segoon,
linux-kernel, mjt, arnd, mirqus, netdev, kuznet, pekkas, jmorris,
yoshfuji, kaber, eric.dumazet, therbert, xiaosuo, jesse,
kees.cook, eugene, dan.j.rosenberg, akpm, greg, sds,
linux-security-module, dwalsh, dhowells
In-Reply-To: <20110324215747.GA12585@peq.hallyn.com>
On Thu, 2011-03-24 at 16:57 -0500, Serge E. Hallyn wrote:
> Quoting David Miller (davem@davemloft.net):
> > From: Stephen Hemminger <shemminger@vyatta.com>
> > Date: Thu, 24 Mar 2011 14:39:44 -0700
> >
> > > This breaks for many of the tunneling protocols, that rely on
> > > autoload for names like "sit0"
> >
> > Frankly I'm very disappointed in the fallout this has been causing.
> >
> > Everyone supporting this change, get real, and admit it doing in fact
> > cause a serious regression.
>
> Sorry, I thought this was causing some extra audit messages but no
> actual breakage?
I've got one report of someone claiming their system broke, but I'm not
convinced I believe it since his dmesg didn't show the magic pr_err()
when it should have. It's certainly possible this can break someone in
a system which uses fine grained capabilities controls, but I agree it's
pretty unlikely. My biggest personal concern is that I have a whole
darn bunch of new scary messages which are popping out of people's
computers since they don't have CAP_SYS_MODULE. While I can silence
them, it's going to hide use of init_module() directly as well, which I
really don't want to hide from the scary logs....
> > If you can't get past that simple fact, you cannot discuss this issue
> > intelligently.
> >
> > You can't say "userland will fix things up"
> >
> > Because we're never supposed to break userland in the first place.
> >
> > There is simply no excuse for this and I want this change reverted
> > both in Linus's tree and in -stable.
>
> Eric, in this particular case, since we've already done a
> 'capable(CAP_NET_ADMIN)', I woudl argue that doing the check
> for CAP_SYS_ADMIN without auditing failure (even if it requires
> a new helper in capability.c) isn't horrible. Thoughts?
s/CAP_SYS_ADMIN/CAP_SYS_MODULE/
I can do that. It was actually my #2 suggestion. But, I'm certainly
willing to put some of the burden on userspace. SELinux policy is a
userspace construct and we often force other userspace applications to
fix things they do poorly (even if it gets us a rep for being
'difficult') Non-SELinux systems aren't going to see this problem,
because basically noone else I know of tries to enforce any kind of
capabilities sets other than all or none, so you'll never see
CAP_NET_ADMIN without CAP_SYS_MODULE.
I guess what it comes down to is that I'm happy to break Fedora user's
with SELinux if in the end it gets us a better system. I'd be happy to
just rip the whole CAP_SYS_MODULE portion out and blame it on SELinux,
but I know that's not what upstream does. So given what we have today I
personally would push for a no_audit() interface rather than a complete
revert. (or maybe a compile option so I can turn off the fallback
altogether and force people to come into compliance)
-Eric
^ permalink raw reply
* Re: [PATCH] ipv4: fix fib metrics
From: Alessandro Suardi @ 2011-03-24 22:11 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, linux-kernel, netdev
In-Reply-To: <1300992308.3747.205.camel@edumazet-laptop>
On Thu, Mar 24, 2011 at 7:45 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 24 mars 2011 à 19:14 +0100, Alessandro Suardi a écrit :
>
>>
>> I will however make one more bug report, as vpnc is broken before
>> and after this patch - have to dig out what vpnc-script tries to do,
>> which results in
>>
>> Error: either "to" is duplicate, or "ipid" is a garbage.
>>
>> after establishing the VPN tunnel.
>>
>
> try following patch
>
> http://git2.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=406b6f974dae76a5b795d5c251d11c979a4e509b
That one doesn't work.
On a -git14 kernel + both the fib metrics and the above git diff, I
strace'd vpnc
and found out this (first triplet of public IP masked intentionally)
[root@duff tmp]# egrep 'execve|garbage' strace.log |egrep '/ip|garbage'
[pid 4228] execve("/sbin/ip", ["/sbin/ip", "route", "get",
"xxx.9.13.212"], [/* 32 vars */]) = 0
[pid 4231] execve("/sbin/ip", ["/sbin/ip", "route", "replace",
"10.175.0.0/19", "dev", "tun0"], [/* 32 vars */]) = 0
[pid 4232] execve("/sbin/ip", ["/sbin/ip", "route", "flush",
"cache"], [/* 32 vars */]) = 0
[pid 4234] execve("/sbin/ip", ["/sbin/ip", "route", "get",
"xxx.9.13.212"], [/* 32 vars */]) = 0
[pid 4237] execve("/sbin/ip", ["/sbin/ip", "route", "add",
"xxx.9.13.212", "via", "192.168.1.1", "dev", "eth1", "src",
"192.168.1.8", "ipid", "0x043f", "advmss", "1400"], [/* 32 vars */]) =
0
[pid 4237] write(2, "Error: either \"to\" is duplicate,"..., 57Error:
either "to" is duplicate, or "ipid" is a garbage.
192.168.1.1 is my DSL router and 192.168.1.8 is my computer's wireless IP.
Does this ring any bell ?
Thanks,
--alessandro
"There's always a siren singing you to shipwreck"
(Radiohead, "There There")
^ permalink raw reply
* Re: [PATCH iproute2] tc : SFB flow scheduler
From: Stephen Hemminger @ 2011-03-24 21:59 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Juliusz.Chroboczek, netdev, Jonathan Morton
In-Reply-To: <1300988649.3747.160.camel@edumazet-laptop>
On Thu, 24 Mar 2011 18:44:09 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr>
>
> Supports SFB qdisc (included in linux-2.6.39)
>
> 1) Setup phase : accept non default parameters
>
> 2) dump information
>
> qdisc sfb 11: parent 1:11 limit 1 max 25 target 20
> increment 0.00050 decrement 0.00005 penalty rate 10 burst 20 (600000ms 60000ms)
> Sent 47991616 bytes 521648 pkt (dropped 549245, overlimits 549245 requeues 0)
> rate 7193Kbit 9774pps backlog 0b 0p requeues 0
> earlydrop 0 penaltydrop 0 bucketdrop 0 queuedrop 549245 childdrop 0 marked 0
> maxqlen 0 maxprob 0.00000 avgprob 0.00000
>
> Signed-off-by: Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied (to net-next branch)
--
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Greg KH @ 2011-03-24 21:57 UTC (permalink / raw)
To: David Miller
Cc: shemminger, serge.hallyn, bhutchings, eparis, eparis, segoon,
linux-kernel, mjt, arnd, mirqus, netdev, kuznet, pekkas, jmorris,
yoshfuji, kaber, eric.dumazet, therbert, xiaosuo, jesse,
kees.cook, eugene, dan.j.rosenberg, akpm, sds,
linux-security-module, dwalsh, dhowells
In-Reply-To: <20110324.144628.58411809.davem@davemloft.net>
On Thu, Mar 24, 2011 at 02:46:28PM -0700, David Miller wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 24 Mar 2011 14:39:44 -0700
>
> > This breaks for many of the tunneling protocols, that rely on
> > autoload for names like "sit0"
>
> Frankly I'm very disappointed in the fallout this has been causing.
>
> Everyone supporting this change, get real, and admit it doing in fact
> cause a serious regression.
>
> If you can't get past that simple fact, you cannot discuss this issue
> intelligently.
>
> You can't say "userland will fix things up"
>
> Because we're never supposed to break userland in the first place.
>
> There is simply no excuse for this and I want this change reverted
> both in Linus's tree and in -stable.
Ok, as I totally got lost in the thread here, what is the git commit id
of the patch to revert?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Serge E. Hallyn @ 2011-03-24 21:57 UTC (permalink / raw)
To: David Miller
Cc: shemminger, serge.hallyn, bhutchings, eparis, eparis, segoon,
linux-kernel, mjt, arnd, mirqus, netdev, kuznet, pekkas, jmorris,
yoshfuji, kaber, eric.dumazet, therbert, xiaosuo, jesse,
kees.cook, eugene, dan.j.rosenberg, akpm, greg, sds,
linux-security-module, dwalsh, dhowells
In-Reply-To: <20110324.144628.58411809.davem@davemloft.net>
Quoting David Miller (davem@davemloft.net):
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 24 Mar 2011 14:39:44 -0700
>
> > This breaks for many of the tunneling protocols, that rely on
> > autoload for names like "sit0"
>
> Frankly I'm very disappointed in the fallout this has been causing.
>
> Everyone supporting this change, get real, and admit it doing in fact
> cause a serious regression.
Sorry, I thought this was causing some extra audit messages but no
actual breakage?
> If you can't get past that simple fact, you cannot discuss this issue
> intelligently.
>
> You can't say "userland will fix things up"
>
> Because we're never supposed to break userland in the first place.
>
> There is simply no excuse for this and I want this change reverted
> both in Linus's tree and in -stable.
Eric, in this particular case, since we've already done a
'capable(CAP_NET_ADMIN)', I woudl argue that doing the check
for CAP_SYS_ADMIN without auditing failure (even if it requires
a new helper in capability.c) isn't horrible. Thoughts?
-serge
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: David Miller @ 2011-03-24 21:46 UTC (permalink / raw)
To: shemminger
Cc: serge.hallyn, bhutchings, eparis, eparis, segoon, linux-kernel,
mjt, arnd, mirqus, netdev, kuznet, pekkas, jmorris, yoshfuji,
kaber, eric.dumazet, therbert, xiaosuo, jesse, kees.cook, eugene,
dan.j.rosenberg, akpm, greg, sds, linux-security-module, dwalsh,
dhowells
In-Reply-To: <20110324143944.29f4c362@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 24 Mar 2011 14:39:44 -0700
> This breaks for many of the tunneling protocols, that rely on
> autoload for names like "sit0"
Frankly I'm very disappointed in the fallout this has been causing.
Everyone supporting this change, get real, and admit it doing in fact
cause a serious regression.
If you can't get past that simple fact, you cannot discuss this issue
intelligently.
You can't say "userland will fix things up"
Because we're never supposed to break userland in the first place.
There is simply no excuse for this and I want this change reverted
both in Linus's tree and in -stable.
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Stephen Hemminger @ 2011-03-24 21:39 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Ben Hutchings, Eric Paris, Eric Paris, Vasiliy Kulikov,
linux-kernel, mjt, arnd, mirqus, netdev, David Miller, kuznet,
pekkas, jmorris, yoshfuji, kaber, eric.dumazet, therbert, xiaosuo,
jesse, kees.cook, eugene, dan.j.rosenberg, akpm, Greg KH,
Stephen Smalley, LSM List, Daniel J Walsh, David Howells
In-Reply-To: <20110324202634.GB9191@peq.hallyn.com>
On Thu, 24 Mar 2011 15:26:34 -0500
"Serge E. Hallyn" <serge.hallyn@ubuntu.com> wrote:
> Quoting Ben Hutchings (bhutchings@solarflare.com):
> > On Thu, 2011-03-24 at 14:03 -0400, Eric Paris wrote:
> > > Not quite. SELinux logs every time an operation is denied. This patch
> > > means that every time a module is requested which does not exist as
>
> Ah. I see.
>
> ...
>
> > > I think there are 3 possibilities:
>
> ...(3)
>
> > > Figure out a way to stop the calls to "reg" "wifi0" and "virbr0" if they
> > > don't exist.
> > >
> > > I feel like the last one is the best way, but I don't know what a
> > > solution could look like....
> >
> > This really has to be done in userland, where these names are being
> > invented. Though I suspect the usual way to check whether an interface
> > exists would be SIOCGIFINDEX, which calls dev_load()! An alternate
> > would be to check whether /sys/class/net/<name> exists, but I seem to
> > recall that /sys/class is somewhat deprecated.
>
> Of course this will mean pain for users until distributions have
> updated to userspace which is doing this, but yeah, this clearly seems
> like the best way. (And the only sane one.)
>
This breaks for many of the tunneling protocols, that rely on
autoload for names like "sit0"
^ permalink raw reply
* [PATCH] net: fix pch_gbe section mismatch warning
From: Randy Dunlap @ 2011-03-24 20:28 UTC (permalink / raw)
To: netdev; +Cc: davem, Toshiharu Okada
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix section mismatch warning by renaming the pci_driver variable to a
recognized (whitelisted) name.
WARNING: drivers/net/pch_gbe/pch_gbe.o(.data+0x1f8): Section mismatch in reference from the variable pch_gbe_pcidev to the variable .devinit.rodata:pch_gbe_pcidev_id
The variable pch_gbe_pcidev references
the variable __devinitconst pch_gbe_pcidev_id
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
---
drivers/net/pch_gbe/pch_gbe_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.38-git13.orig/drivers/net/pch_gbe/pch_gbe_main.c
+++ linux-2.6.38-git13/drivers/net/pch_gbe/pch_gbe_main.c
@@ -2441,7 +2441,7 @@ static struct pci_error_handlers pch_gbe
.resume = pch_gbe_io_resume
};
-static struct pci_driver pch_gbe_pcidev = {
+static struct pci_driver pch_gbe_driver = {
.name = KBUILD_MODNAME,
.id_table = pch_gbe_pcidev_id,
.probe = pch_gbe_probe,
@@ -2458,7 +2458,7 @@ static int __init pch_gbe_init_module(vo
{
int ret;
- ret = pci_register_driver(&pch_gbe_pcidev);
+ ret = pci_register_driver(&pch_gbe_driver);
if (copybreak != PCH_GBE_COPYBREAK_DEFAULT) {
if (copybreak == 0) {
pr_info("copybreak disabled\n");
@@ -2472,7 +2472,7 @@ static int __init pch_gbe_init_module(vo
static void __exit pch_gbe_exit_module(void)
{
- pci_unregister_driver(&pch_gbe_pcidev);
+ pci_unregister_driver(&pch_gbe_driver);
}
module_init(pch_gbe_init_module);
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Serge E. Hallyn @ 2011-03-24 20:26 UTC (permalink / raw)
To: Ben Hutchings
Cc: Eric Paris, Serge E. Hallyn, Eric Paris, Vasiliy Kulikov,
linux-kernel, mjt, arnd, mirqus, netdev, David Miller, kuznet,
pekkas, jmorris, yoshfuji, kaber, eric.dumazet, therbert, xiaosuo,
jesse, kees.cook, eugene, dan.j.rosenberg, akpm, Greg KH,
Stephen Smalley, LSM List, Daniel J Walsh, David Howells
In-Reply-To: <1300991584.2689.35.camel@bwh-desktop>
[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]
Quoting Ben Hutchings (bhutchings@solarflare.com):
> On Thu, 2011-03-24 at 14:03 -0400, Eric Paris wrote:
> > Not quite. SELinux logs every time an operation is denied. This patch
> > means that every time a module is requested which does not exist as
Ah. I see.
...
> > I think there are 3 possibilities:
...(3)
> > Figure out a way to stop the calls to "reg" "wifi0" and "virbr0" if they
> > don't exist.
> >
> > I feel like the last one is the best way, but I don't know what a
> > solution could look like....
>
> This really has to be done in userland, where these names are being
> invented. Though I suspect the usual way to check whether an interface
> exists would be SIOCGIFINDEX, which calls dev_load()! An alternate
> would be to check whether /sys/class/net/<name> exists, but I seem to
> recall that /sys/class is somewhat deprecated.
Of course this will mean pain for users until distributions have
updated to userspace which is doing this, but yeah, this clearly seems
like the best way. (And the only sane one.)
thanks,
-serge
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: bnx2 vlan issue
From: Jesse Gross @ 2011-03-24 19:55 UTC (permalink / raw)
To: Seblu; +Cc: netdev
In-Reply-To: <AANLkTimnKRDY8QLiJMMLqNzCA_-6UJmUDHKf-i1Yt3V5@mail.gmail.com>
On Thu, Mar 24, 2011 at 5:58 AM, Seblu <seblu@seblu.net> wrote:
>> I don't necessarily disagree that there should be a better way to do
>> this, though as of the moment the above is probably your best bet.
>>
>> To me, the most important thing is to have consistent behavior across
>> different cards.
>
> Speaking of that, i've tryed 2.6.38 on my station (dell opitplex 980)
> to use the new bridging schema and it doesn't work.
> Exactly the case previously described: ip on br0 (eth0+eth1) and ip on
> br0.42. eth0 driver is e1000e and eth1 is tg3. br0.42 don't receive
> traffic.
> I have to open a bug report?
The change was deliberate, not an accidental mistake, so don't expect
2.6.38 to suddenly switch back to the previous behavior. There's no
need to file a bug report - the new behavior is known (I was the one
who changed it in the first place). I will look into nicer semantics
in the future.
^ 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