* Re: [RFC PATCH] dont create cached routes from ARP requests
From: Ulrich Weber @ 2010-09-24 16:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ulrich Weber, David Miller, netdev
In-Reply-To: <1285344352.2503.321.camel@edumazet-laptop>
On 09/24/2010 06:05 PM, Eric Dumazet wrote:
> Le vendredi 24 septembre 2010 à 17:38 +0200, Ulrich Weber a écrit :
>> steps to reproduce:
>> server:
>> ip route add 1.0.0.0/8 dev dummy0
>>
>> client:
>> ip route add 1.0.0.0/8 dev eth0
>> nmap --min-rate 500 -sP 1.0.0.0/8
>>
>
> Great, you use nmap and fill 'client' neighbour cache.
Nope, I fills the 'server' neighbor cache too
due cached routes in arp_process():
if (arp->ar_op == htons(ARPOP_REQUEST) &&
ip_route_input_noref(skb, tip, sip, 0, dev) == 0)
> Now, back to the _real_ problem, please ?
>
> <quote>
>
> Background: At home I have two Internet connections, DSL and Cable.
> DSL is the primary uplink while Cable is the secondary.
> My Cable ISP is flooding me with ARP request from 10.0.0.0/8,
> which creates routes via the primary uplink.
> There are thousands of cached routes and after some time
> I get "Neighbour table overflow" messages.
>
> </quote>
>
> You receive an ARP request on device eth1,
> this creates a route on eth0 ?
>
> Could you send your routing/address setup ?
>
> ip addr
> ip ro
>
ARP request flood comes in via eth2.
Have to correct myself: With configuration below only route cache
increases but no "Neighbour table overflow".
By adding "ip route add 10.0.0.0/8 dev eth0" the Neighbor table overflow
will occur.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
inet 78.43.x.x/22 brd 78.43.35.255 scope global eth2
12: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc hfsc
state UNKNOWN qlen 3
inet 95.114.x.x peer 213.20.56.129/32 scope global ppp0
default via 213.20.56.129 dev ppp0
78.43.32.0/22 dev eth2 proto kernel scope link src 78.43.x.x
127.0.0.0/8 dev lo scope link
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
213.20.56.129 dev ppp0 proto kernel scope link src 95.114.x.x
--
Ulrich Weber | uweber@astaro.com | Software Engineer
Astaro GmbH & Co. KG | www.astaro.com | Phone +49-721-25516-0 | Fax –200
An der RaumFabrik 33a | 76227 Karlsruhe | Germany
^ permalink raw reply
* [PATCH] iwl3945: queue the right work if the scan needs to be aborted
From: Florian Mickler @ 2010-09-24 16:22 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Florian Mickler, Reinette Chatre, Wey-Yi Guy,
Intel Linux Wireless, John W. Linville, Johannes Berg, Zhu Yi,
Ben Cahill, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
iwl3945's scan_completed calls into the mac80211 stack which triggers a
warn on if there is no scan outstanding.
This can be avoided by not calling scan_completed but abort_scan in
iwl3945_request_scan in the done: branch of the function which is used
as an error out.
The done: branch seems to be an error-out branch, as, for example, if
iwl_is_ready(priv) returns false the done: branch is executed.
NOTE:
I'm not familiar with the driver at all.
I just quickly scanned as a reaction to
https://bugzilla.kernel.org/show_bug.cgi?id=17722
the users of scan_completed in the iwl3945 driver and noted the odd
discrepancy between the comment above this instance and the comment in
mac80211 scan_completed function.
Signed-off-by: Florian Mickler <florian-sVu6HhrpSfRAfugRpC6u6w@public.gmane.org>
---
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 2 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
index 9dd9e64..8fd00a6 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
@@ -1411,7 +1411,7 @@ void iwlagn_request_scan(struct iwl_priv *priv, struct ieee80211_vif *vif)
clear_bit(STATUS_SCAN_HW, &priv->status);
clear_bit(STATUS_SCANNING, &priv->status);
/* inform mac80211 scan aborted */
- queue_work(priv->workqueue, &priv->scan_completed);
+ queue_work(priv->workqueue, &priv->abort_scan);
}
int iwlagn_manage_ibss_station(struct iwl_priv *priv,
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 59a308b..d31661c 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -3018,7 +3018,7 @@ void iwl3945_request_scan(struct iwl_priv *priv, struct ieee80211_vif *vif)
clear_bit(STATUS_SCANNING, &priv->status);
/* inform mac80211 scan aborted */
- queue_work(priv->workqueue, &priv->scan_completed);
+ queue_work(priv->workqueue, &priv->abort_scan);
}
static void iwl3945_bg_restart(struct work_struct *data)
--
1.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net-next-2.6] net: update SOCK_MIN_RCVBUF
From: Eric Dumazet @ 2010-09-24 16:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev
SOCK_MIN_RCVBUF current value is 256 bytes
It doesnt permit to receive the smallest possible frame, considering
socket sk_rmem_alloc/sk_rcvbuf account skb truesizes. On 64bit arches,
sizeof(struct sk_buff) is 240 bytes. Add the typical 64 bytes of
headroom, and we go over the limit.
With old kernels and 32bit arches, we were under the limit, if netdriver
was doing copybreak.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/sock.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 8ae97c4..c33e62c 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1558,7 +1558,11 @@ static inline void sk_wake_async(struct sock *sk, int how, int band)
}
#define SOCK_MIN_SNDBUF 2048
-#define SOCK_MIN_RCVBUF 256
+/*
+ * Since sk_rmem_alloc sums skb->truesize, even a small frame might need
+ * sizeof(sk_buff) + MTU + padding, unless net driver perform copybreak
+ */
+#define SOCK_MIN_RCVBUF (2048 + sizeof(struct sk_buff))
static inline void sk_stream_moderate_sndbuf(struct sock *sk)
{
^ permalink raw reply related
* Re: [PATCH] net: reset skb queue mapping when rx'ing over tunnel
From: Tom Herbert @ 2010-09-24 16:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem, chavey
In-Reply-To: <1285293960.2380.23.camel@edumazet-laptop>
> Hmm...
>
> This would need to be reverted later when tunnels are updated to be
> multiqueue aware ? I made an attempt with GRE some days ago.
>
> I dont understand why this patch is needed, since get_rps_cpu() has a
> check anyway
>
I think the skb queue_mapping should correspond to a queue in the
skb's device as an invariant. In the case that an skb's device is
change from a multiqueue device to single queue device (like GRE), the
inconsistency in the queue_mapping is fairly innocuous, we get one
warning but will pretty much take the unlikely branch for GRE packets
then on. But imagine a case where skb's device was change from one
multiqueue device to another, but the queue mapping was not also
updated. This would cause poor weighting in get_rps_cpus. For
example, if the new device had fewer queues than the old one,
get_rps_cpu will bias toward using queue 0's rps mask.
> if (skb_rx_queue_recorded(skb)) {
> u16 index = skb_get_rx_queue(skb);
> if (unlikely(index >= dev->num_rx_queues)) {
> WARN_ONCE(dev->num_rx_queues > 1, "%s received packet "
> "on queue %u, but number of RX queues is %u\n",
> dev->name, index, dev->num_rx_queues);
> goto done;
> }
> rxqueue = dev->_rx + index;
> } else
> rxqueue = dev->_rx;
>
>
>
>
^ permalink raw reply
* Re: [RFC PATCH] dont create cached routes from ARP requests
From: Eric Dumazet @ 2010-09-24 16:05 UTC (permalink / raw)
To: Ulrich Weber; +Cc: Ulrich Weber, David Miller, netdev
In-Reply-To: <4C9CC608.7010401@astaro.com>
Le vendredi 24 septembre 2010 à 17:38 +0200, Ulrich Weber a écrit :
> Yes, as I wrote before my Cable ISP is flooding me with
> ARP requests from 10.0.0.0/8, which get a route
> via the primary PPP link.
>
> I know thats not a common setup but why do that
> kind of routes have to be cached ? :)
>
>
> steps to reproduce:
> server:
> ip route add 1.0.0.0/8 dev dummy0
>
> client:
> ip route add 1.0.0.0/8 dev eth0
> nmap --min-rate 500 -sP 1.0.0.0/8
>
Great, you use nmap and fill 'client' neighbour cache.
Now, back to the _real_ problem, please ?
<quote>
Background: At home I have two Internet connections, DSL and Cable.
DSL is the primary uplink while Cable is the secondary.
My Cable ISP is flooding me with ARP request from 10.0.0.0/8,
which creates routes via the primary uplink.
There are thousands of cached routes and after some time
I get "Neighbour table overflow" messages.
</quote>
You receive an ARP request on device eth1,
this creates a route on eth0 ?
Could you send your routing/address setup ?
ip addr
ip ro
^ permalink raw reply
* Re: [PATCH net-next-2.6] rps: allocate rx queues in register_netdevice only
From: Tom Herbert @ 2010-09-24 15:58 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ben Hutchings, David Miller, netdev, linux-net-drivers
In-Reply-To: <1285312049.2380.66.camel@edumazet-laptop>
On Fri, Sep 24, 2010 at 12:07 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 24 septembre 2010 à 05:26 +0200, Eric Dumazet a écrit :
>> > Also, I dont understand why we need to restrict
>> > netif_set_real_num_rx_queues() to lower the count.
>> > This wastes memory.
>> >
>> > Why dont we allocate dev->_rx once we know the real count, not in
>> > alloc_netdev_mq() but in register_netdevice() ?
>> >
>> >
>>
>> Here is a patch to make this possible
>>
>> I guess a similar thing could be done for tx queues.
>>
>> boot tested, but please double check.
>>
>> Thanks
>>
>> [PATCH net-next-2.6] rps: allocate rx queues in register_netdevice()
>>
>> Instead of having two places were we allocate dev->_rx, introduce
>> netif_alloc_rx_queues() helper and call it only from
>> register_netdevice(), not from alloc_netdev_mq()
>>
>> Goal is to let drivers change dev->num_rx_queues after allocating netdev
>> and before registering it.
>>
>> This also removes a lot of ifdefs in net/core/dev.c
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> ---
>> net/core/dev.c | 76 +++++++++++++++++++----------------------------
>> 1 file changed, 32 insertions(+), 44 deletions(-)
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 2c7934f..9110b8d 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -4964,6 +4964,34 @@ void netif_stacked_transfer_operstate(const struct net_device *rootdev,
>> }
>> EXPORT_SYMBOL(netif_stacked_transfer_operstate);
>>
>> +static int netif_alloc_rx_queues(struct net_device *dev)
>> +{
>> +#ifdef CONFIG_RPS
>> + unsigned int i, count = dev->num_rx_queues;
>> +
>
> Tom
>
> I tried to find a caller with dev->num_rx_queues = 0, but failed
>
> If it's valid, we might add a
>
> if (!dev->num_rx_queues)
> dev->num_rx_queues = 1;
>
Or maybe just enforce that in register_net_device and make it an error
to call alloc_netdev_mq with zero queue count. You've uncovered a bug
since get_rps_cpus assumes at least one queue, but alloc_netdev_mq
allows zeros queues to be allocated!
> I wonder if you remember why you added the section :
> /*
> * Allocate a single RX queue if driver never called
> * alloc_netdev_mq
> */
RPS is configured per queue, so every device will need at least one RX
queue for the structures.
^ permalink raw reply
* Re: [RFC PATCH] dont create cached routes from ARP requests
From: Ulrich Weber @ 2010-09-24 15:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ulrich Weber, David Miller, netdev
In-Reply-To: <1285342497.2503.260.camel@edumazet-laptop>
/proc/sys/net/ipv4/conf/all/arp_accept:0
/proc/sys/net/ipv4/conf/default/arp_accept:0
/proc/sys/net/ipv4/conf/lo/arp_accept:0
/proc/sys/net/ipv4/conf/eth0/arp_accept:0
/proc/sys/net/ipv4/conf/dummy0/arp_accept:0
On 09/24/2010 05:34 PM, Eric Dumazet wrote:
> Le vendredi 24 septembre 2010 à 17:28 +0200, Eric Dumazet a écrit :
>
>> What are the packets you receive ? A flood of ARP answers ?
>>
>> a "tcpdump -X" of a few packets would help to understand.
>>
>>
>
>
> Also please report
>
> grep . `find /proc/sys -name arp_accept`
>
>
>
--
Ulrich Weber | uweber@astaro.com | Software Engineer
Astaro GmbH & Co. KG | www.astaro.com | Phone +49-721-25516-0 | Fax –200
An der RaumFabrik 33a | 76227 Karlsruhe | Germany
^ permalink raw reply
* Re: [RFC PATCH] dont create cached routes from ARP requests
From: Ulrich Weber @ 2010-09-24 15:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ulrich Weber, David Miller, netdev
In-Reply-To: <1285342083.2503.252.camel@edumazet-laptop>
Yes, as I wrote before my Cable ISP is flooding me with
ARP requests from 10.0.0.0/8, which get a route
via the primary PPP link.
I know thats not a common setup but why do that
kind of routes have to be cached ? :)
steps to reproduce:
server:
ip route add 1.0.0.0/8 dev dummy0
client:
ip route add 1.0.0.0/8 dev eth0
nmap --min-rate 500 -sP 1.0.0.0/8
On 09/24/2010 05:28 PM, Eric Dumazet wrote:
> Le vendredi 24 septembre 2010 à 17:00 +0200, Ulrich Weber a écrit :
>> Hi Eric,
>>
>> please find the output in the attached text file.
>>
>> Neighbor garbage collection wont't work because all
>> neighbor records are bound to cached routes.
>>
>> Forced route garbaged collections returns without freeing
>> any routes, probably because the route threshold is quite high
>> with 65536 compared to the small neighbor threshold of 1024,
>> resulting in a fixed amount of 1024 cached routes...
>>
>> Instead of running the garbage collection we could flush the route
>> cache completely if the neighbor cache overflows.
>> But why do we have to cache that routes in first place ?
>> See the previous patch which skips caching for that kind of routes.
>
> What are the packets you receive ? A flood of ARP answers ?
>
> a "tcpdump -X" of a few packets would help to understand.
>
>
>
--
Ulrich Weber | uweber@astaro.com | Software Engineer
Astaro GmbH & Co. KG | www.astaro.com | Phone +49-721-25516-0 | Fax –200
An der RaumFabrik 33a | 76227 Karlsruhe | Germany
^ permalink raw reply
* Re: [RFC PATCH] dont create cached routes from ARP requests
From: Eric Dumazet @ 2010-09-24 15:34 UTC (permalink / raw)
To: Ulrich Weber; +Cc: Ulrich Weber, David Miller, netdev
In-Reply-To: <1285342083.2503.252.camel@edumazet-laptop>
Le vendredi 24 septembre 2010 à 17:28 +0200, Eric Dumazet a écrit :
> What are the packets you receive ? A flood of ARP answers ?
>
> a "tcpdump -X" of a few packets would help to understand.
>
>
Also please report
grep . `find /proc/sys -name arp_accept`
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] net: Allow changing number of RX queues after device allocation
From: Tom Herbert @ 2010-09-24 15:34 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Eric Dumazet, David Miller, netdev, linux-net-drivers
In-Reply-To: <1285331081.2257.3.camel@achroite.uk.solarflarecom.com>
Looks good to me.
>> All functions in this file use a single line.
>>
>> > -static int rx_queue_register_kobjects(struct net_device *net)
>> > +int
>> > +net_rx_queue_update_kobjects(struct net_device *net, int old_num, int new_num)
>>
>> ->
>>
>> int net_rx_queue_update_kobjects(struct net_device *net, int old, int new)
>
> Why should I rename variables to fit a function signature on one line?
>
Maybe split the line within the parameter list, this would be more
consistent with other function declarations.
^ permalink raw reply
* Re: [RFC PATCH] dont create cached routes from ARP requests
From: Eric Dumazet @ 2010-09-24 15:28 UTC (permalink / raw)
To: Ulrich Weber; +Cc: Ulrich Weber, David Miller, netdev
In-Reply-To: <4C9CBCFC.6080300@gmail.com>
Le vendredi 24 septembre 2010 à 17:00 +0200, Ulrich Weber a écrit :
> Hi Eric,
>
> please find the output in the attached text file.
>
> Neighbor garbage collection wont't work because all
> neighbor records are bound to cached routes.
>
> Forced route garbaged collections returns without freeing
> any routes, probably because the route threshold is quite high
> with 65536 compared to the small neighbor threshold of 1024,
> resulting in a fixed amount of 1024 cached routes...
>
> Instead of running the garbage collection we could flush the route
> cache completely if the neighbor cache overflows.
> But why do we have to cache that routes in first place ?
> See the previous patch which skips caching for that kind of routes.
What are the packets you receive ? A flood of ARP answers ?
a "tcpdump -X" of a few packets would help to understand.
^ permalink raw reply
* Re: [RFC PATCH] dont create cached routes from ARP requests
From: Ulrich Weber @ 2010-09-24 15:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ulrich Weber, David Miller, netdev
In-Reply-To: <1285254302.2509.47.camel@edumazet-laptop>
[-- Attachment #1: Type: text/plain, Size: 653 bytes --]
Hi Eric,
please find the output in the attached text file.
Neighbor garbage collection wont't work because all
neighbor records are bound to cached routes.
Forced route garbaged collections returns without freeing
any routes, probably because the route threshold is quite high
with 65536 compared to the small neighbor threshold of 1024,
resulting in a fixed amount of 1024 cached routes...
Instead of running the garbage collection we could flush the route
cache completely if the neighbor cache overflows.
But why do we have to cache that routes in first place ?
See the previous patch which skips caching for that kind of routes.
Cheers
Ulrich
[-- Attachment #2: cache_debug.txt --]
[-- Type: text/plain, Size: 8009 bytes --]
/proc/sys/net/ipv4/route/error_burst:1250
/proc/sys/net/ipv4/route/error_cost:250
/proc/sys/net/ipv4/route/gc_elasticity:8
/proc/sys/net/ipv4/route/gc_interval:60
/proc/sys/net/ipv4/route/gc_min_interval:0
/proc/sys/net/ipv4/route/gc_min_interval_ms:500
/proc/sys/net/ipv4/route/gc_thresh:65536
/proc/sys/net/ipv4/route/gc_timeout:300
/proc/sys/net/ipv4/route/max_size:1048576
/proc/sys/net/ipv4/route/min_adv_mss:256
/proc/sys/net/ipv4/route/min_pmtu:552
/proc/sys/net/ipv4/route/mtu_expires:600
/proc/sys/net/ipv4/route/redirect_load:5
/proc/sys/net/ipv4/route/redirect_number:9
/proc/sys/net/ipv4/route/redirect_silence:5120
/proc/sys/net/ipv4/neigh/default/gc_interval:30
/proc/sys/net/ipv4/neigh/default/gc_stale_time:60
/proc/sys/net/ipv4/neigh/default/gc_thresh1:128
/proc/sys/net/ipv4/neigh/default/gc_thresh2:512
/proc/sys/net/ipv4/neigh/default/gc_thresh3:1024
net-next:
rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|
entries| in_hit|in_slow_|in_slow_|in_no_ro| in_brd|in_marti|in_marti| out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis|
| | tot| mc| ute| | an_dst| an_src| | _tot| _mc| | ed| miss| verflow| _search|t_search|
10| 255| 2| 1| 0| 0| 0| 0| 128| 17| 2| 0| 0| 0| 0| 15| 3|
199| 1| 189| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|
433| 190| 234| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
433| 424| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 1| 0|
433| 235| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|
533| 119| 100| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 1| 0|
533| 219| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|
533| 219| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|
551| 406| 18| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
551| 424| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
551| 424| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
973| 1| 422| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 9| 0|
973| 423| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
973| 423| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
1030| 357| 68| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
1030| 413| 11| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
1030| 413| 11| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
1030| 124| 300| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
1030| 124| 300| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
1030| 125| 300| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0|
next-next with forced rt_garbage_collect
rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|
entries| in_hit|in_slow_|in_slow_|in_no_ro| in_brd|in_marti|in_marti| out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis|
| | tot| mc| ute| | an_dst| an_src| | _tot| _mc| | ed| miss| verflow| _search|t_search|
8| 43| 2| 0| 0| 0| 0| 0| 129| 20| 3| 0| 0| 0| 0| 1| 1|
138| 1| 130| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|
431| 131| 293| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0|
431| 424| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0|
431| 294| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0|
531| 120| 100| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|
531| 220| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|
531| 220| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|
550| 405| 19| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0|
550| 424| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0|
550| 424| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0|
972| 1| 422| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 1| 0|
972| 423| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 1| 0|
972| 423| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 1| 0|
1029| 358| 66| 0| 0| 0| 0| 0| 0| 0| 0| 9| 0| 0| 0| 1| 0|
1029| 415| 9| 0| 0| 0| 0| 0| 0| 0| 0| 9| 0| 0| 0| 1| 0|
1029| 415| 9| 0| 0| 0| 0| 0| 0| 0| 0| 9| 0| 0| 0| 1| 0|
1029| 122| 302| 0| 0| 0| 0| 0| 0| 0| 0| 302| 0| 0| 0| 2| 0|
1029| 122| 302| 0| 0| 0| 0| 0| 0| 0| 0| 302| 0| 0| 0| 2| 0|
1029| 122| 302| 0| 0| 0| 0| 0| 0| 0| 0| 302| 0| 0| 0| 2| 0|
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Alan Cox @ 2010-09-24 14:57 UTC (permalink / raw)
To: Richard Cochran
Cc: john stultz, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
netdev-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, Christoph Lameter,
David Miller, Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <20100924135001.GB3113-7KxsofuKt4IfAd9E5cN8NEzG7cXyKsk/@public.gmane.org>
> > Instead, I think having the id hanging off the class driver is much
> > better, as it allows mapping the actual hardware to the id more clearly.
> >
> > So I'd drop the "timesource" listing. And maybe change "id" to
> > "clock_id" so its a little more clear what the id is for.
>
> Okay, I will drop /sys/class/timesource (hope Alan Cox agrees :)
It makes sense to hang anything off the physical id
> I threw it out there mostly for the sake of discussion. I imagined
> that there could be other properties in that directory, like time
> scale (TAI, UTC, etc). But it seems like we don't really need anything
> in that direction.
They can still hang off the physical device. Thats really a detail
> > interrupts are awfully frequent, so systems concerned with power-saving
> > and deep idles probably would like something that could be done at a
> > more coarse interval.
>
> We could always make the pulse rate programmable, for power-saving
> applications.
I would expect the kernel drivers to be responsible for
- Turning off when they can
- Picking rates that are power optimal for the requirement
The latter is a bit interesting as I don't see anything in any of the
timer APIs to express accuracy (a problem we have in kernel too).
Historically it simply hasn't mattered.
^ permalink raw reply
* Re: [PATCH 1/2] Phonet: Implement Pipe Controller to support Nokia Slim Modems
From: Kumar SANGHVI @ 2010-09-24 14:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: remi.denis-courmont@nokia.com, davem@davemloft.net,
netdev@vger.kernel.org, STEricsson_nomadik_linux,
Sudeep DIVAKARAN, Gulshan KARMANI, Linus WALLEIJ
In-Reply-To: <1285336333.2503.153.camel@edumazet-laptop>
Hi Eric,
On Fri, Sep 24, 2010 at 15:52:13 +0200, Eric Dumazet wrote:
> Le vendredi 24 septembre 2010 à 17:53 +0530, Kumar A Sanghvi a écrit :
>
> > +static int pipe_get_flow_info(struct sock *sk, struct sk_buff *skb,
> > + u8 *pref_rx_fc, u8 *req_tx_fc)
> > +{
> > + struct pnpipehdr *hdr = pnp_hdr(skb);
> > + u8 n_sb;
> > +
> > + if (!pskb_may_pull(skb, sizeof(*hdr) + 4))
> > + return -EINVAL;
>
> This is wrong.
>
> pskb_may_pull() might change skb->data, so you should do
>
> {
> struct pnpipehdr *hdr;
> u8 n_sb;
>
> if (!pskb_may_pull(skb, sizeof(*hdr) + 4))
> return -EINVAL;
>
> hdr = pnp_hdr(skb);
>
Thanks for pointing this out.
I will correct this and post a v2 version of patch.
I will also post a fix for similar problem which now I noticed, based on
your above comment, in pipe_rcv_status function in net/phonet/pep.c
Best regards,
Kumar.
^ permalink raw reply
* Re: [PATCH 7/8] net: Allow setting the network namespace by fd
From: jamal @ 2010-09-24 14:16 UTC (permalink / raw)
To: David Lamparter
Cc: Eric W. Biederman, linux-kernel, Linux Containers, netdev,
netfilter-devel, linux-fsdevel
In-Reply-To: <20100924140943.GB1551619@jupiter.n2.diac24.net>
On Fri, 2010-09-24 at 16:09 +0200, David Lamparter wrote:
> I understood your point. What I'm saying is that that functional graph
> you're describing is too simplistic do be a workable model. Your graph
> allows for what you're trying to do, yes. But your graph is not modeling
> the reality.
How about we put this specific point to rest by agreeing to
disagree? ;->
> Err... I'm migrating netdevs to assign them to namespaces to allow them
> to use them? Setup, basically. Either way a device move only happens as
> result of some administrative action; be it creating a new namespace or
> changing the physical/logical network setup.
>
Ok, different need. You have a much more basic requirement than i do.
> wtf is a "remote" namespace?
>
A namespace that is remotely located on another machine/hardware ;->
> Can you please describe your application that requires moving possibly
> several network devices together with "their" routes to a different
> namespace?
scaling and availability are the driving requirements.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 7/8] net: Allow setting the network namespace by fd
From: David Lamparter @ 2010-09-24 14:09 UTC (permalink / raw)
To: jamal
Cc: David Lamparter, Eric W. Biederman, linux-kernel,
Linux Containers, netdev, netfilter-devel, linux-fsdevel
In-Reply-To: <1285335173.13976.693.camel@bigi>
On Fri, Sep 24, 2010 at 09:32:53AM -0400, jamal wrote:
> On Fri, 2010-09-24 at 14:57 +0200, David Lamparter wrote:
> > No. While you sure could associate routes with devices, they don't
> > *functionally* reside on top of network devices. They reside on top of
> > the entire IP configuration,
>
> I think i am not clearly making my point. There are data dependencies;
> If you were to move routes, youd need everything that routes depend on.
> IOW, if i was to draw a functional graph, routes would appear on top
> of netdevs (I dont care what other functional blocks you put in between
> or sideways to them).
I understood your point. What I'm saying is that that functional graph
you're describing is too simplistic do be a workable model. Your graph
allows for what you're trying to do, yes. But your graph is not modeling
the reality.
> > The routes depend on your BGP view, and
> > if your set of interfaces (and peers) changes, your routes will change.
> > Your bgpd will, either way, need to set up new peerings and redo best
> > path evaluations.
>
> Worst case scenario, yes. I am beginning to get a feeling we are trying
> to achieve different goals maybe? Why are you even migrating netdevs?
Err... I'm migrating netdevs to assign them to namespaces to allow them
to use them? Setup, basically. Either way a device move only happens as
result of some administrative action; be it creating a new namespace or
changing the physical/logical network setup.
> > (On an unrelated note, how often are you planning to move stuff between
> > namespaces? I don't expect to be moving stuff except on configuration
> > events...)
>
> Triggering on config events is useful and it is likely the only
> possibility if you assumed the other namespace is remote.
wtf is a "remote" namespace?
> But if could
> send a single command to migrate several things in the kernel (in my
> case to recover state to a different ns), then that is much simpler and
> uses the least resources (memory, cpu, bandwidth). I admit it is very
> hard to do in most cases where the underlying dependencies are evolving
> and synchronizing via user space is the best approach. The example
> of route table i pointed to is simple.
> Besides that: dynamic state created in the kernel that doesnt have to be
> recreated by the next arriving 100K packets helps to improve recovery.
Can you please describe your application that requires moving possibly
several network devices together with "their" routes to a different
namespace?
-David
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Alan Cox @ 2010-09-24 14:07 UTC (permalink / raw)
To: Alan Cox
Cc: John Stultz, Rodolfo Giometti, Arnd Bergmann, Peter Zijlstra,
linux-api, devicetree-discuss, linux-kernel, David Miller,
Thomas Gleixner, netdev, Christoph Lameter, linuxppc-dev,
Richard Cochran, linux-arm-kernel, Krzysztof Halasa
In-Reply-To: <20100924150246.0e6064b6@lxorguk.ukuu.org.uk>
> You can't do that avoiding as you might like because the behaviour of
> file handle numbering is defined by the standards. Hence the "f*"
> versions of the calls (and of lots of other stuff)
>
> Whether you add new syscalls or do the fd passing using flags and hide
> the ugly bits in glibc is another question.
To add an example of what I mean you might end up defining "CLOCK_FD" to
indicate to use the fd in the struct, but given syscalls are trivial
codewise and would end up as
fclock_foo(int fd, blah)
{
clock = fd_to_clock(fd);
if (error)
return error
clock_do_foo(clock, blah);
clock_put(clock);
}
and
clock_foo(int posixid, blah)
{
clock = posix_to_clock(posixid)
...
rest same
}
as wrappers it seems hardly worth adding ugly hacks
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Alan Cox @ 2010-09-24 14:02 UTC (permalink / raw)
To: Richard Cochran
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
netdev-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, Christoph Lameter,
David Miller, John Stultz, Krzysztof Halasa, Peter Zijlstra,
Rodolfo Giometti, Thomas Gleixner
In-Reply-To: <20100924131407.GA3113-7KxsofuKt4IfAd9E5cN8NEzG7cXyKsk/@public.gmane.org>
On Fri, 24 Sep 2010 15:14:07 +0200
Richard Cochran <richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Sep 23, 2010 at 09:36:54PM +0100, Alan Cox wrote:
> > Drop the clockid_t and swap it for a file handle like a proper Unix or
> > Linux interface. The rest is much the same
> >
> > fd = open /sys/class/timesource/[whatever]
> >
> > various queries you may want to do to check the name etc
> >
> > fclock_adjtime(fd, ...)
>
> Okay, but lets extend the story:
>
> clock_getttime(fd, ...);
>
> clock_settime(fd, ...);
>
> timer_create(fd, ...);
>
> Can you agree to that as well?
>
> (We would need to ensure that 'fd' avoids the range 0 to MAX_CLOCKS).
You can't do that avoiding as you might like because the behaviour of
file handle numbering is defined by the standards. Hence the "f*"
versions of the calls (and of lots of other stuff)
Whether you add new syscalls or do the fd passing using flags and hide
the ugly bits in glibc is another question.
^ permalink raw reply
* Re: [PATCH 1/2] Phonet: Implement Pipe Controller to support Nokia Slim Modems
From: Eric Dumazet @ 2010-09-24 13:52 UTC (permalink / raw)
To: Kumar A Sanghvi
Cc: remi.denis-courmont, davem, netdev, STEricsson_nomadik_linux,
sudeep.divakaran, gulshan.karmani, Linus Walleij
In-Reply-To: <1285330996-27076-2-git-send-email-kumar.sanghvi@stericsson.com>
Le vendredi 24 septembre 2010 à 17:53 +0530, Kumar A Sanghvi a écrit :
> +static int pipe_get_flow_info(struct sock *sk, struct sk_buff *skb,
> + u8 *pref_rx_fc, u8 *req_tx_fc)
> +{
> + struct pnpipehdr *hdr = pnp_hdr(skb);
> + u8 n_sb;
> +
> + if (!pskb_may_pull(skb, sizeof(*hdr) + 4))
> + return -EINVAL;
This is wrong.
pskb_may_pull() might change skb->data, so you should do
{
struct pnpipehdr *hdr;
u8 n_sb;
if (!pskb_may_pull(skb, sizeof(*hdr) + 4))
return -EINVAL;
hdr = pnp_hdr(skb);
...
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Richard Cochran @ 2010-09-24 13:50 UTC (permalink / raw)
To: john stultz
Cc: Rodolfo Giometti, Peter Zijlstra,
linux-api-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Thomas Gleixner,
netdev-u79uwXL29TY76Z2rM5mHXA, Christoph Lameter,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, David Miller,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Krzysztof Halasa
In-Reply-To: <1285270733.2587.46.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On Thu, Sep 23, 2010 at 12:38:53PM -0700, john stultz wrote:
> On Thu, 2010-09-23 at 19:30 +0200, Richard Cochran wrote:
> > /sys/class/timesource/<name>/id
> > /sys/class/ptp/ptp_clock_X/id
> >
> So yea, I'm not a fan of the "timesource" sysfs interface. One, I think
> the name is poor (posix_clocks or something a little more specific would
> be an improvement), and second, I don't like the dictionary interface,
> where one looks up the clock by name.
>
> Instead, I think having the id hanging off the class driver is much
> better, as it allows mapping the actual hardware to the id more clearly.
>
> So I'd drop the "timesource" listing. And maybe change "id" to
> "clock_id" so its a little more clear what the id is for.
Okay, I will drop /sys/class/timesource (hope Alan Cox agrees :)
I threw it out there mostly for the sake of discussion. I imagined
that there could be other properties in that directory, like time
scale (TAI, UTC, etc). But it seems like we don't really need anything
in that direction.
> > 3.3 Synchronizing the Linux System Time
> > ========================================
> >
> > One could offer a PHC as a combined clock source and clock event
> > device. The advantage of this approach would be that it obviates
> > the need for synchronization when the PHC is selected as the system
> > timer. However, some PHCs, namely the PHY based clocks, cannot be
> > used in this way.
>
> Again, I'd scratch this.
Okay, I only wanted to preempt the question which people are asking
all the time: why can't it work with the system clock transparently?
> > Instead, the patch set provides a way to offer a Pulse Per Second
> > (PPS) event from the PHC to the Linux PPS subsystem. A user space
> > application can read the PPS events and tune the system clock, just
> > like when using other external time sources like radio clocks or
> > GPS.
>
> Forgive me for a bit of a tangent here:
> So while I think this PPS method is a neat idea, I'm a little curious
> how much of a difference the PPS method for syncing the clock would be
> over just a simple reading of the two clocks and correcting the offset.
>
> It seems much of it depends on the read latency of the PTP hardware vs
> the interrupt latency. Also the PTP clock granularity would effect the
> read accuracy (like on the RTC, you don't really know how close to the
> second boundary you are).
>
> Have you done any such measurements between the two methods?
I have not yet tested how well the PPS method works, but I expect at
least as good results as when using a GPS.
> I just
> wonder if it would actually be something noticeable, and if its not, how
> much lighter this patch-set would be without the PPS connection.
As you say, the problem with just reading two clocks at nearly the
same time is that you have two uncertain operations. If you use a PPS,
then there is only one clock to read, and that clock is the system
clock, which hopefully is not too slow to read!
In addition, PHY reads can sleep, and that surely won't work. Even with
MAC PHCs, reading outside of interrupt context makes you vulnerable to
other interrupts.
> Again, this isn't super critical, just trying to make sure we don't end
> up adding a bunch of code that doesn't end up being used.
The PPS hooks are really only just a few lines of code.
The great advantage of a PPS approach over and ad-hoc "read two clocks
and compare", is that, with a steady, known sample rate, you can
analyze and predict your control loop behavior. There is lots of
literature available on how to do it. IMHO, that is the big weakness
of the timecompare.c stuff used in the current IGB driver.
> Also PPS
> interrupts are awfully frequent, so systems concerned with power-saving
> and deep idles probably would like something that could be done at a
> more coarse interval.
We could always make the pulse rate programmable, for power-saving
applications.
> > 4.1 Supported Hardware Clocks
> > ==============================
> >
> > + Standard Linux system timer
> > This driver exports the standard Linux timer as a PTP clock.
> > Although this duplicates CLOCK_REALTIME, the code serves as a
> > simple example for driver development and lets people who without
> > special hardware try the new API.
>
> Still not a fan of this one, figure the app should handle the special
> case where there are no PTP clocks and just use CLOCK_REALTIME rather
> then funneling CLOCK_REALTIME through the PTP interface.
It is really just as an example and for people who want to test driver
the API. It can surely be removed before the final version...
Thanks for your comments,
Richard
^ permalink raw reply
* Re: [ABI REVIEW][PATCH 0/8] Namespace file descriptors
From: Daniel Lezcano @ 2010-09-24 13:49 UTC (permalink / raw)
To: Andrew Lutomirski
Cc: Eric W. Biederman, Sukadev Bhattiprolu, Pavel Emelyanov,
Pavel Emelyanov, Ulrich Drepper, netdev, Jonathan Corbet,
linux-kernel, Jan Engelhardt, linux-fsdevel, netfilter-devel,
Michael Kerrisk, Linux Containers, Ben Greear, Linus Torvalds,
David Miller, Al Viro
In-Reply-To: <4C9CA16F.3000505@mit.edu>
On 09/24/2010 03:02 PM, Andrew Lutomirski wrote:
> Eric W. Biederman wrote:
>> Introduce file for manipulating namespaces and related syscalls.
>> files:
>> /proc/self/ns/<nstype>
>>
>> syscalls:
>> int setns(unsigned long nstype, int fd);
>> socketat(int nsfd, int family, int type, int protocol);
>>
>
> How does security work? Are there different kinds of fd that give (say) pin-the-namespace permission, socketat permission, and setns permission?
AFAICS, socketat, setns and "set netns by fd" only accept fd from
/proc/<pid>/ns/<ns>.
setns does :
file = proc_ns_fget(fd);
if (IS_ERR(file))
return PTR_ERR(file);
proc_ns_fget checks if (file->f_op != &ns_file_operations)
socketat and get_net_ns_by_fd:
net = get_net_ns_by_fd(fd);
this one calls proc_ns_fget.
We have the guarantee here, the fd is resulting from an open of the file
with the right permissions.
Another way to pin the namespace, would be to mount --bind
/proc/<pid>/ns/<ns> but we have to be root to do that ...
^ permalink raw reply
* Re: [PATCH 7/8] net: Allow setting the network namespace by fd
From: Daniel Lezcano @ 2010-09-24 13:46 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Pavel Emelyanov, Ulrich Drepper, netdev-u79uwXL29TY76Z2rM5mHXA,
Jonathan Corbet, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Jan Engelhardt, Linux Containers, Al Viro,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA, Michael Kerrisk,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, Ben Greear,
Sukadev Bhattiprolu, Linus Torvalds, David Miller,
Pavel Emelyanov
In-Reply-To: <m1hbhgq1v1.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
On 09/23/2010 10:51 AM, Eric W. Biederman wrote:
>
> Take advantage of the new abstraction and allow network devices
> to be placed in any network namespace that we have a fd to talk
> about.
>
> Signed-off-by: Eric W. Biederman<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
> ---
[ ... ]
> +struct net *get_net_ns_by_fd(int fd)
> +{
> + struct proc_inode *ei;
> + struct file *file;
> + struct net *net;
> +
> + file = NULL;
> + net = ERR_PTR(-EINVAL);
> + file = proc_ns_fget(fd);
> + if (!fd)
> + goto out;
> + return ERR_PTR(-EINVAL);
> +
> + ei = PROC_I(file->f_dentry->d_inode);
> + if (ei->ns_ops !=&netns_operations)
> + goto out;
Is this check necessary here ? proc_ns_fget checks "file->f_op !=
&ns_file_operations", no ?
^ permalink raw reply
* Re: [PATCH 7/8] net: Allow setting the network namespace by fd
From: jamal @ 2010-09-24 13:32 UTC (permalink / raw)
To: David Lamparter
Cc: Eric W. Biederman, linux-kernel, Linux Containers, netdev,
netfilter-devel, linux-fsdevel
In-Reply-To: <20100924125704.GA1551619@jupiter.n2.diac24.net>
On Fri, 2010-09-24 at 14:57 +0200, David Lamparter wrote:
> No. While you sure could associate routes with devices, they don't
> *functionally* reside on top of network devices. They reside on top of
> the entire IP configuration,
I think i am not clearly making my point. There are data dependencies;
If you were to move routes, youd need everything that routes depend on.
IOW, if i was to draw a functional graph, routes would appear on top
of netdevs (I dont care what other functional blocks you put in between
or sideways to them).
> and in case of BGP they even reside on top
> of your set of peerings and their data.
> Even if you could "move" routes together with a network device, the
> result would be utter nonsense.
You could argue that moving a netdevice where some of its fundamental
properties such as an ifindex change is utter nonsense. But you can
work around it.
> The routes depend on your BGP view, and
> if your set of interfaces (and peers) changes, your routes will change.
> Your bgpd will, either way, need to set up new peerings and redo best
> path evaluations.
Worst case scenario, yes. I am beginning to get a feeling we are trying
to achieve different goals maybe? Why are you even migrating netdevs?
> (On an unrelated note, how often are you planning to move stuff between
> namespaces? I don't expect to be moving stuff except on configuration
> events...)
Triggering on config events is useful and it is likely the only
possibility if you assumed the other namespace is remote. But if could
send a single command to migrate several things in the kernel (in my
case to recover state to a different ns), then that is much simpler and
uses the least resources (memory, cpu, bandwidth). I admit it is very
hard to do in most cases where the underlying dependencies are evolving
and synchronizing via user space is the best approach. The example
of route table i pointed to is simple.
Besides that: dynamic state created in the kernel that doesnt have to be
recreated by the next arriving 100K packets helps to improve recovery.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Richard Cochran @ 2010-09-24 13:14 UTC (permalink / raw)
To: Alan Cox
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
netdev-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, Christoph Lameter,
David Miller, John Stultz, Krzysztof Halasa, Peter Zijlstra,
Rodolfo Giometti, Thomas Gleixner
In-Reply-To: <20100923213654.0c64b047-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
On Thu, Sep 23, 2010 at 09:36:54PM +0100, Alan Cox wrote:
> Drop the clockid_t and swap it for a file handle like a proper Unix or
> Linux interface. The rest is much the same
>
> fd = open /sys/class/timesource/[whatever]
>
> various queries you may want to do to check the name etc
>
> fclock_adjtime(fd, ...)
Okay, but lets extend the story:
clock_getttime(fd, ...);
clock_settime(fd, ...);
timer_create(fd, ...);
Can you agree to that as well?
(We would need to ensure that 'fd' avoids the range 0 to MAX_CLOCKS).
Richard
^ permalink raw reply
* Re: [ABI REVIEW][PATCH 0/8] Namespace file descriptors
From: Andrew Lutomirski @ 2010-09-24 13:02 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-kernel, Linux Containers, netdev, netfilter-devel,
linux-fsdevel, jamal, Daniel Lezcano, Linus Torvalds,
Michael Kerrisk, Ulrich Drepper, Al Viro, David Miller,
Serge E. Hallyn, Pavel Emelyanov, Pavel Emelyanov, Ben Greear,
Matt Helsley, Jonathan Corbet, Sukadev Bhattiprolu,
Jan Engelhardt, Patrick McHardy
In-Reply-To: <m1ocborgq7.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> Introduce file for manipulating namespaces and related syscalls.
> files:
> /proc/self/ns/<nstype>
>
> syscalls:
> int setns(unsigned long nstype, int fd);
> socketat(int nsfd, int family, int type, int protocol);
>
How does security work? Are there different kinds of fd that give (say) pin-the-namespace permission, socketat permission, and setns permission?
--Andy
> Netlink attribute:
> IFLA_NS_FD int fd.
>
> Name space file descriptors address three specific problems that
> can make namespaces hard to work with.
> - Namespaces require a dedicated process to pin them in memory.
> - It is not possible to use a namespace unless you are the child of the
> original creator.
> - Namespaces don't have names that userspace can use to talk about them.
>
> Opening of the /proc/self/ns/<nstype> files return a file descriptor
> that can be used to talk about a specific namespace, and to keep the
> specified namespace alive.
>
> /proc/self/ns/<nstype> can be bind mounted as:
> mount --bind /proc/self/ns/net /some/filesystem/path
> to keep the namespace alive as long as the mount exists.
>
> setns() as a companion to unshare allows changing the namespace
> of the current process, being able to unshare the namespace is
> a requirement.
>
> There are two primary envisioned uses for this functionality.
> o ``Entering'' an existing container.
> o Allowing multiple network namespaces to be in use at once on
> the same machine, without requiring elaborate infrastructure.
>
> Overall this received positive reviews on the containers list but this
> needs a wider review of the ABI as this is pretty fundamental kernel
> functionality.
>
>
> I have left out the pid namespaces bits for the moment because the pid
> namespace still needs work before it is safe to unshare, and my concern
> at the moment is ensuring the system calls seem reasonable.
>
> Eric W. Biederman (8):
> ns: proc files for namespace naming policy.
> ns: Introduce the setns syscall
> ns proc: Add support for the network namespace.
> ns proc: Add support for the uts namespace
> ns proc: Add support for the ipc namespace
> ns proc: Add support for the mount namespace
> net: Allow setting the network namespace by fd
> net: Implement socketat.
>
> ---
> fs/namespace.c | 57 +++++++++++++
> fs/proc/Makefile | 1 +
> fs/proc/base.c | 22 +++---
> fs/proc/inode.c | 7 ++
> fs/proc/internal.h | 18 ++++
> fs/proc/namespaces.c | 193 +++++++++++++++++++++++++++++++++++++++++++
> include/linux/if_link.h | 1 +
> include/linux/proc_fs.h | 20 +++++
> include/net/net_namespace.h | 1 +
> ipc/namespace.c | 31 +++++++
> kernel/nsproxy.c | 39 +++++++++
> kernel/utsname.c | 32 +++++++
> net/core/net_namespace.c | 56 +++++++++++++
> net/core/rtnetlink.c | 4 +-
> net/socket.c | 26 ++++++-
> 15 files changed, 494 insertions(+), 14 deletions(-)
>
^ 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