* Re: Using gretap to tunnel layer 2 traffic
From: David Lamparter @ 2011-09-12 12:52 UTC (permalink / raw)
To: John H; +Cc: netdev@vger.kernel.org
In-Reply-To: <1315589104.22676.YahooMailNeo@web45104.mail.sp1.yahoo.com>
On Fri, Sep 09, 2011 at 10:25:04AM -0700, John H wrote:
> [...] All VLANs and physical devices have MTUs of
> 1500. The gretap device has a resultant MTU of 1462, thereby causing the
> bridge device to have an MTU of 1462.
> [...]
> The real question is, however, why is any client able to send a single ICMP
> packet with size 1478 bytes when one of the hops along the way only
> supports 1462 bytes per its MTU? Shouldn't this have been negotiated
> beforehand?
No.
An Ethernet segment needs a single, unbroken, identical MTU at all of
its (packet-sending) participants. Your configuration is invalid; there
is no Ethernet-builtin mechanism to negotiate MTU.
You need to set all devices, hosts and possibly switches to the same MTU
value. (A switch with its default of 1500 isn't a problem as long as it
does not generate packets that large.) A way to do that is by DHCP,
which has a MTU option; that option is however not honoured by all
clients.
Alternatively, you need to change your gretap/bridge MTU to 1500, but
you'll somehow need to make gretap aware of the underlying
fragmentation support, from whereever it may come.
Alter-alternatively, you can use a layer 3 (IP/IPv6) router. IP, unlike
Ethernet, is designed to cope with varying MTUs...
-David
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Roopa Prabhu @ 2011-09-12 13:38 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, dragos.tatulea, arnd, dwang2, benve, kaber, sri, davem,
eric.dumazet, mchan, kvm
In-Reply-To: <20110911185238.GB4740@redhat.com>
On 9/11/11 11:52 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Sun, Sep 11, 2011 at 06:18:02AM -0700, Roopa Prabhu wrote:
>>
>>
>>
>> On 9/11/11 2:38 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>
>>> On Fri, Sep 09, 2011 at 09:33:33AM -0700, Roopa Prabhu wrote:
>>>
>>> It's probably more interesting for a card without SRIOV support.
>>>
>> If its an SRIOV card I am assuming people likely using PASSTHRU mode.
>> Non-SRIOV cards will use any of the non-PASSTHRU mode.
>>
>>
>>>> we will have to add filter lookup in macvlan
>>>> to filter pkts for each guest.
>>>
>>> Any chance to enable hardware filters for that?
>>>
>> NAFAIK. Am not sure how you would do it too. Its still a single device from
>> where the host receives traffic from.
>>
>> Thanks,
>> Roopa
>
> VMDQ cards might let you program mac addresses for individula rings.
>
I tried to lookup more information on this. I dint find any concrete
information. I am not sure if individual rings show up as separate netdev.
Any more info on how a VMDQ nic is used with macvlan ?.
I came across this
http://www.linux-kvm.org/wiki/images/6/6a/KvmForum2008$kdf2008_7.pdf
Thanks,
Roopa
^ permalink raw reply
* Re: [RFC/PATCH] net: add deferred flow cache flush function to be used in xfrm
From: Eric Dumazet @ 2011-09-12 13:58 UTC (permalink / raw)
To: madalin.bucur; +Cc: netdev, davem, timo.teras
In-Reply-To: <1315829846-15016-1-git-send-email-madalin.bucur@freescale.com>
Le lundi 12 septembre 2011 à 15:17 +0300, Madalin Bucur a écrit :
> The xfrm garbage collector calls flow_cache_flush() that might sleep.
> The xfrm garbage collector can be called from softirq context, such as from
> net_rx_action() through ip_forward(). Added flow_cache_flush_deferred()
> function that uses the kernel-global work queue to leave the actual
> cache flush processing outside the softirq context.
>
> Signed-off-by: Madalin Bucur <madalin.bucur@freescale.com>
> ---
> include/net/flow.h | 1 +
> net/core/flow.c | 12 ++++++++++++
> net/xfrm/xfrm_policy.c | 2 +-
> 3 files changed, 14 insertions(+), 1 deletions(-)
>
> diff --git a/include/net/flow.h b/include/net/flow.h
> index c6d5fe5..7b4bc88 100644
> --- a/include/net/flow.h
> +++ b/include/net/flow.h
> @@ -188,6 +188,7 @@ extern struct flow_cache_object *flow_cache_lookup(
> u8 dir, flow_resolve_t resolver, void *ctx);
>
> extern void flow_cache_flush(void);
> +extern void flow_cache_flush_deferred(void);
> extern atomic_t flow_cache_genid;
>
> #endif
> diff --git a/net/core/flow.c b/net/core/flow.c
> index 990703b..4edef63 100644
> --- a/net/core/flow.c
> +++ b/net/core/flow.c
> @@ -352,6 +352,18 @@ void flow_cache_flush(void)
> put_online_cpus();
> }
>
> +static void flow_cache_flush_wq(struct work_struct *work)
> +{
> + flow_cache_flush();
> +}
> +
> +static DECLARE_WORK(flow_cache_flush_work, flow_cache_flush_wq);
> +
> +void flow_cache_flush_deferred(void)
> +{
> + schedule_work(&flow_cache_flush_work);
> +}
> +
> static int __cpuinit flow_cache_cpu_prepare(struct flow_cache *fc, int cpu)
> {
> struct flow_cache_percpu *fcp = per_cpu_ptr(fc->percpu, cpu);
> diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
> index 5ce74a3..62b1af8 100644
> --- a/net/xfrm/xfrm_policy.c
> +++ b/net/xfrm/xfrm_policy.c
> @@ -2274,7 +2274,7 @@ static void __xfrm_garbage_collect(struct net *net)
> {
> struct dst_entry *head, *next;
>
> - flow_cache_flush();
> + flow_cache_flush_deferred();
>
> spin_lock_bh(&xfrm_policy_sk_bundle_lock);
> head = xfrm_policy_sk_bundles;
Problem is sometime we dont want to defer and are in process context.
xfrm_dev_event( event == NETDEV_DOWN) is probably a place we dont want
to defer the garbage collection.
^ permalink raw reply
* [PATCH 0/2] SUNRPC: pipefs virtualization
From: Stanislav Kinsbursky @ 2011-09-12 14:19 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem
This patch set is a part of further RPC layer virtualization and it's aim is to
make RPC pipefs mount creation and destruction per network namespace context.
It moves RPC pipefs internal data to sunrpc_net instance of network namespace
context.
With this patch set all calls to pipefs infrastructure are performed with
"&init_net" except rpc_new_client() and rpc_setup_pipedir() functions (but they
still passes pointer to "init_net" by current design).
This "init_net" pointer will be replaced later with NFS virtualization.
The following series consists of:
---
Stanislav Kinsbursky (2):
SUNRPC: make rpc pipefs mount per network namespace
SUNRPC: RPC pipefs virtualization
fs/nfs/blocklayout/blocklayout.c | 2 +-
fs/nfs/cache_lib.c | 7 ++++---
include/linux/sunrpc/rpc_pipe_fs.h | 4 ++--
net/sunrpc/clnt.c | 8 ++++----
net/sunrpc/netns.h | 3 +++
net/sunrpc/rpc_pipe.c | 23 +++++++++++++++--------
6 files changed, 29 insertions(+), 18 deletions(-)
--
Signature
^ permalink raw reply
* [PATCH 1/2] SUNRPC: make rpc pipefs mount per network namespace
From: Stanislav Kinsbursky @ 2011-09-12 14:19 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem
In-Reply-To: <20110912141633.6261.72180.stgit@localhost6.localdomain6>
This is another part of RPC layer virtualization.
RPC pipefs inner data was attached to per-net sunrpc_net instance.
Network namespace counter is increased and decreased with every RPC mount
reference. This is not hardly requred from my pow, but it looks safer since we
relay on network namespace presence.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
include/linux/sunrpc/rpc_pipe_fs.h | 4 ++--
net/sunrpc/netns.h | 3 +++
net/sunrpc/rpc_pipe.c | 23 +++++++++++++++--------
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/include/linux/sunrpc/rpc_pipe_fs.h b/include/linux/sunrpc/rpc_pipe_fs.h
index cf14db9..0bdf178 100644
--- a/include/linux/sunrpc/rpc_pipe_fs.h
+++ b/include/linux/sunrpc/rpc_pipe_fs.h
@@ -60,8 +60,8 @@ extern void rpc_remove_cache_dir(struct dentry *);
extern struct dentry *rpc_mkpipe(struct dentry *, const char *, void *,
const struct rpc_pipe_ops *, int flags);
extern int rpc_unlink(struct dentry *);
-extern struct vfsmount *rpc_get_mount(void);
-extern void rpc_put_mount(void);
+extern struct vfsmount *rpc_get_mount(struct net *net);
+extern void rpc_put_mount(struct net *net);
extern int register_rpc_pipefs(void);
extern void unregister_rpc_pipefs(void);
diff --git a/net/sunrpc/netns.h b/net/sunrpc/netns.h
index d013bf2..e45fdf0 100644
--- a/net/sunrpc/netns.h
+++ b/net/sunrpc/netns.h
@@ -9,6 +9,9 @@ struct cache_detail;
struct sunrpc_net {
struct proc_dir_entry *proc_net_rpc;
struct cache_detail *ip_map_cache;
+
+ struct vfsmount *rpc_mnt;
+ int rpc_mount_count;
};
extern int sunrpc_net_id;
diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
index b181e34..ebc5e1c 100644
--- a/net/sunrpc/rpc_pipe.c
+++ b/net/sunrpc/rpc_pipe.c
@@ -28,8 +28,7 @@
#include <linux/sunrpc/rpc_pipe_fs.h>
#include <linux/sunrpc/cache.h>
-static struct vfsmount *rpc_mnt __read_mostly;
-static int rpc_mount_count;
+#include "netns.h"
static struct file_system_type rpc_pipe_fs_type;
@@ -421,20 +420,28 @@ struct rpc_filelist {
umode_t mode;
};
-struct vfsmount *rpc_get_mount(void)
+struct vfsmount *rpc_get_mount(struct net *net)
{
int err;
+ struct sunrpc_net *sn;
- err = simple_pin_fs(&rpc_pipe_fs_type, &rpc_mnt, &rpc_mount_count);
- if (err != 0)
+ sn = net_generic(get_net(net), sunrpc_net_id);
+ err = simple_pin_fs(&rpc_pipe_fs_type, &sn->rpc_mnt, &sn->rpc_mount_count);
+ if (err != 0) {
+ put_net(net);
return ERR_PTR(err);
- return rpc_mnt;
+ }
+ return sn->rpc_mnt;
}
EXPORT_SYMBOL_GPL(rpc_get_mount);
-void rpc_put_mount(void)
+void rpc_put_mount(struct net *net)
{
- simple_release_fs(&rpc_mnt, &rpc_mount_count);
+ struct sunrpc_net *sn;
+
+ sn = net_generic(net, sunrpc_net_id);
+ simple_release_fs(&sn->rpc_mnt, &sn->rpc_mount_count);
+ put_net(net);
}
EXPORT_SYMBOL_GPL(rpc_put_mount);
^ permalink raw reply related
* [PATCH 2/2] SUNRPC: RPC pipefs virtualization
From: Stanislav Kinsbursky @ 2011-09-12 14:19 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem
In-Reply-To: <20110912141633.6261.72180.stgit@localhost6.localdomain6>
Parametrize rpc_mount_get() and rpc_mount_put() with network namespace pointer.
Currently init_net is used, but later proper network context will be used
instead.
It actually means, that in future NFS cache have to be virtualied as well.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
fs/nfs/blocklayout/blocklayout.c | 2 +-
fs/nfs/cache_lib.c | 7 ++++---
net/sunrpc/clnt.c | 8 ++++----
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/fs/nfs/blocklayout/blocklayout.c b/fs/nfs/blocklayout/blocklayout.c
index 9561c8f..9904e70 100644
--- a/fs/nfs/blocklayout/blocklayout.c
+++ b/fs/nfs/blocklayout/blocklayout.c
@@ -979,7 +979,7 @@ static int __init nfs4blocklayout_init(void)
init_waitqueue_head(&bl_wq);
- mnt = rpc_get_mount();
+ mnt = rpc_get_mount(&init_net);
if (IS_ERR(mnt)) {
ret = PTR_ERR(mnt);
goto out_remove;
diff --git a/fs/nfs/cache_lib.c b/fs/nfs/cache_lib.c
index c98b439..777514b 100644
--- a/fs/nfs/cache_lib.c
+++ b/fs/nfs/cache_lib.c
@@ -11,6 +11,7 @@
#include <linux/mount.h>
#include <linux/namei.h>
#include <linux/slab.h>
+#include <net/net_namespace.h>
#include <linux/sunrpc/cache.h>
#include <linux/sunrpc/rpc_pipe_fs.h>
@@ -117,7 +118,7 @@ int nfs_cache_register(struct cache_detail *cd)
struct path path;
int ret;
- mnt = rpc_get_mount();
+ mnt = rpc_get_mount(&init_net);
if (IS_ERR(mnt))
return PTR_ERR(mnt);
ret = vfs_path_lookup(mnt->mnt_root, mnt, "/cache", 0, &path);
@@ -128,13 +129,13 @@ int nfs_cache_register(struct cache_detail *cd)
if (!ret)
return ret;
err:
- rpc_put_mount();
+ rpc_put_mount(&init_net);
return ret;
}
void nfs_cache_unregister(struct cache_detail *cd)
{
sunrpc_cache_unregister_pipefs(cd);
- rpc_put_mount();
+ rpc_put_mount(&init_net);
}
diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index c5347d2..4bebcc0 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -109,7 +109,7 @@ rpc_setup_pipedir(struct rpc_clnt *clnt, char *dir_name)
if (dir_name == NULL)
return 0;
- path.mnt = rpc_get_mount();
+ path.mnt = rpc_get_mount(clnt->cl_xprt->xprt_net);
if (IS_ERR(path.mnt))
return PTR_ERR(path.mnt);
error = vfs_path_lookup(path.mnt->mnt_root, path.mnt, dir_name, 0, &dir);
@@ -137,7 +137,7 @@ rpc_setup_pipedir(struct rpc_clnt *clnt, char *dir_name)
err_path_put:
path_put(&dir);
err:
- rpc_put_mount();
+ rpc_put_mount(clnt->cl_xprt->xprt_net);
return error;
}
@@ -248,7 +248,7 @@ static struct rpc_clnt * rpc_new_client(const struct rpc_create_args *args, stru
out_no_auth:
if (!IS_ERR(clnt->cl_path.dentry)) {
rpc_remove_client_dir(clnt->cl_path.dentry);
- rpc_put_mount();
+ rpc_put_mount(clnt->cl_xprt->xprt_net);
}
out_no_path:
kfree(clnt->cl_principal);
@@ -476,7 +476,7 @@ rpc_free_client(struct rpc_clnt *clnt)
clnt->cl_protname, clnt->cl_server);
if (!IS_ERR(clnt->cl_path.dentry)) {
rpc_remove_client_dir(clnt->cl_path.dentry);
- rpc_put_mount();
+ rpc_put_mount(clnt->cl_xprt->xprt_net);
}
if (clnt->cl_parent != clnt) {
rpc_release_client(clnt->cl_parent);
^ permalink raw reply related
* RE: [RFC/PATCH] net: add deferred flow cache flush function to be used in xfrm
From: Bucur Madalin-Cristian-B32716 @ 2011-09-12 14:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev@vger.kernel.org, davem@davemloft.net, timo.teras@iki.fi
In-Reply-To: <1315835887.2318.1.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> Behalf Of Eric Dumazet
> Sent: Monday, September 12, 2011 4:58 PM
>
> Le lundi 12 septembre 2011 à 15:17 +0300, Madalin Bucur a écrit :
> > The xfrm garbage collector calls flow_cache_flush() that might sleep.
> > The xfrm garbage collector can be called from softirq context, such as from
> > net_rx_action() through ip_forward(). Added flow_cache_flush_deferred()
> > function that uses the kernel-global work queue to leave the actual
> > cache flush processing outside the softirq context.
> >
>
> Problem is sometime we dont want to defer and are in process context.
>
> xfrm_dev_event( event == NETDEV_DOWN) is probably a place we dont want
> to defer the garbage collection.
>
Indeed, currently __xfrm_garbage_collect() is called through the garbage_collect
callback but also when an event NETDEV_DOWN is received. Maybe we should have
different functions for the two cases, one calling flow_cache_flush_deferred()
and the other flow_cache_flush().
^ permalink raw reply
* The Sum of £1,000,000.00
From: Liliam Cristina Agudelo Morimitsu @ 2011-09-12 15:35 UTC (permalink / raw)
The Sum of £1,000,000.00 has been awarded to your E-mail ID. Send;
Names.
Country.
Tel.
^ permalink raw reply
* Re: [PATCH net-next-2.6] can/sja1000: driver for PEAK PCAN PCI/PCIe cards
From: Oliver Hartkopp @ 2011-09-12 15:49 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Netdev, SocketCAN Core Mailing List, linux, Thomas Wiedemann
In-Reply-To: <4E6A2EB2.5070601@grandegger.com>
On 09/09/11 17:20, Wolfgang Grandegger wrote:
>
>> I'll also test your driver on Monday.
>
> Thanks,
Hi Wolfgang,
even if i only had my hardware-patched PEAK PCI ExpressCard hardware here
(which is to be removed in the supported PCI device list due to the missing
I2C initialization), i successfully tested your driver.
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
So let's wait for some feedback from Thomas, when he's back to the office ;-)
Tnx & best regards,
Oliver
^ permalink raw reply
* Mail Box Quota Exceeded
From: Deborah T. Cartwright @ 2011-09-12 16:04 UTC (permalink / raw)
Your web mail quota has exceeded the set quota which is 3GB. you are
currently running on 3.9 GB.
To re-activate and increase your web mail quota please click the link
below.
https://docs.google.com/spreadsheet/viewform?formkey=dDRwLWpBNjZrbVJpeUJnNVZZY1ZuN1E6MQ&theme=0AX42CRMsmRFbUy1jYWNjZmUzNi1iNzViLTRhZGUtYmIzNy1jYmE5MWFiMWQyZjU&ifq
Failure to do so may result in the cancellation of your web mail
account.
Thanks, and sorry for the inconvenience
Local-host.
^ permalink raw reply
* Re: [PATCH] per-cgroup tcp buffer limitation
From: Glauber Costa @ 2011-09-12 16:30 UTC (permalink / raw)
To: Greg Thelen
Cc: linux-kernel, linux-mm, containers, netdev, xemul,
David S. Miller, Hiroyouki Kamezawa, Eric W. Biederman,
Suleiman Souhlal
In-Reply-To: <CAHH2K0YbmE_tt-LQSB=4L0oYc+CwNAjMQr0YViPn9=M-epST7A@mail.gmail.com>
>>> With some more knobs such a uswapd could
>>> attempt to keep ahead of demand. But eventually direct reclaim would
>>> be needed to satisfy rapid growth spikes. Example: If the 100M container
>>> starts with limits of 20M kmem and 80M user memory but later its kernel
>>> memory needs grow to 70M. With separate user and kernel memory
>>> limits the kernel memory allocation could fail despite there being
>>> reclaimable user pages available.
>>
>> No no, this is a ratio, not a *limit*. A limit is something you
>> should not be allowed to go over. A good limit of kernel memory for
>> a 100 Mb container could be something like... 100 mb. But there is
>> more to that.
>>
>> Risking being a bit polemic here, I think that when we do
>> containers, we have to view the kernel a little bit like a shared resource
>> that is not accounted to anybody. It is easy to account things like tcp
>> buffer, but who do you account page tables for shared pages to? Or pinned
>> dentries for shared filesystems ?
>
> This is a tough challenge. If you don't account page tables, then
> fork bombs can grab lots of kernel memory. Containing such pigs is
> good. We are working on some patches that charge page tables to the
> memcg they are allocated from. This charge is checked against the
> memcg's limit and thus the page table allocation may fail due if over
> limit.
>
> I suggest charging dentries to the cgroup that allocated the dentry.
> If containers are used for isolation, then it seems that containers
> should typically not share files. That would break isolation. Of
> course there are shared files (/bin/bash, etc), but at least those are
> read-only.
You mean first allocated ? I actually considered that a while ago.
Specially with page tables, to whom do you account shared ptes ?
If we're doing first allocated, one way to fork bomb then, although
clearly harder, is to have a cgroup mapping ptes that were already
mapped before by other cgroups. A part of them is trivial to guess,
some others can be guessed more cleverly by the type of workload
you expect other containers in the box to be running.
This way you map a lot, and nothing is charged to you.
With dentries, first allocated might be possible if you assume files
are not shared, indeed... there are some shared use cases for exported
directories... humm, but maybe there are ways to contain those cases
as well.
>
>> Being the shared table under everybody, the kernel is more or less
>> like buffers inside a physical hdd, or cache lines. You know it is
>> there, you know it has a size, but provided you have some sane
>> protections, you don't really care - because in most cases you can't
>> - who is using it.
>
> I agree that it makes sense to not bother charging fixed sized
> resources (struct page, etc.) to containers; they are part of the
> platform. But the set of resources that a process can allocate are
> ideally charged to a cgroup to limit container memory usage (i.e.
> prevent DoS attacks, isolate performance).
>
Agreed.
>>> The job should have a way to
>>> transition to memory limits to 70M+ kernel and 30M- of user.
>>
>> Yes, and I don't see how what I propose prevents that.
>
> I don't think your current proposal prevents that. I was thinking
> about the future of the proposed kmem cgroup. I want to make sure the
> kernel has a way to apply reclaim pressure bidirectionally between
> cgroup kernel memory and cgroup user memory.
I see.
>>> If kmem expands to include reclaimable kernel memory (e.g. dentry) then I
>>> presume the kernel would have no way to exchange unused user pages for
>>> dentry
>>> pages even if the user memory in the container is well below its limit.
>>> This is
>>> motivation for the above user assisted direct reclaim.
>>
>> Dentry is not always reclaimable. If it is pinned, it is non
>> reclaimable. Speaking of it, Would you take a look at
>> https://lkml.org/lkml/2011/8/14/110 ?
>>
>> I am targetting dentry as well. But since it is hard to assign a
>> dentry to a process all the time, going through a different path. I
>> however, haven't entirely given up of doing it cgroups based, so any
>> ideas are welcome =)
>
> My hope is that dentry consumption can be effectively limited by
> limiting the memory needed to allocate the dentries. IOW: with a
> memcg aware slab allocator which, when possible, charges the calling
> process' cgroup.
If you have patches for that, even early patches, I'd like to take a
look at them.
>> Well, I am giving this an extra thought... Having separate knobs
>> adds flexibility, but - as usual - also complexity. For the goals I
>> have in mind, "kernel memory" would work just as fine.
>>
>> If you look carefully at the other patches in the series besides
>> this one, you'll see that it is just a matter of billing from kernel
>> memory instead of tcp-memory, and then all the rest is the same.
>>
>> Do you think that a single kernel-memory knob would be better for
>> your needs? I am willing to give it a try.
>
> Regarding the tcp buffers we're discussing, how does an application
> consume lots of buffer memory? IOW, what would a malicious app do to
> cause a grows of tcp buffer usage? Or is this the kind of resource
> that is difficult to directly exploit?
>
> Also, how does the pressure get applied. I see you have a
> per-protocol, per-cgroup pressure pressure setting. Once set, how
> does this pressure cause memory to be freed? It looks like the
> pressure is set when allocating memory and later when packets are
> freed the associated memory _might_ be freed if pressure was
> previously detected. Did I get this right?
See below:
> For me the primary concern is that both user and kernel memory are
> eventually charged to the same counter with an associated limit.
> Per-container memory pressure is based on this composite limit. So I
> don't have a strong opinion as to how many kernel memory counters
> there are so long as they also feed into container memory usage
> counter.
Okay.
>
>>> I think
>>> memcg aware slab accounting does a good job of limiting a job's
>>> memory allocations.
>>> Would such slab accounting meet your needs?
>>
>> Well, the slab alone, no. There are other objects - like tcp buffers
>> - that aren't covered by the slab. Others are usually shared among
>> many cgroups, and others don't really belong to anybody in
>> particular.igh
>
> Sorry, I am dumb wrt. networking. I thought that these tcp buffers
> were allocated using slab with __alloc_skb(). Are they done in
> container process context or arbitrary context?
You are right. They come from the slab with alloc_skb. But consider the
following code, from tcp.c:
skb = alloc_skb_fclone(size + sk->sk_prot->max_header, gfp);
if (skb) {
if (sk_wmem_schedule(sk, skb->truesize)) {
/*
* Make sure that we have exactly size bytes
* available to the caller, no more, no less.
*/
skb_reserve(skb, skb_tailroom(skb) - size);
return skb;
}
__kfree_skb(skb);
} else {
...
}
Limiting the slab may be enough to prevent kernel memory abuse (sorry, I
should have made this clear from the start). However, if the allocation
succeed, a container can then kfree it, because someone else
is starving the network.
Of course, my patchset also limits kernel memory usage. But I agree that
if we do slab accounting, only the network specific part remains.
>> How do you think then, about turning this into 2 files inside memcg:
>>
>> - kernel_memory_hard_limit.
>> - kernel_memory_soft_limit.
>>
>> tcp memory would be the one defined in /proc, except if it is
>> greater than any of the limits. Instead of testing for memory
>> allocation against kmem.tcp_allocated_memory, we'd test it against
>> memcg.kmem_pinned_memory.
>
> memcg control files currently include:
> memory.limit_in_bytes
> memory.soft_limit_in_bytes
> memory.usage_in_bytes
>
> If you want a kernel memory limit, then we can introduce two new memcg APIs:
> memory.kernel_limit_in_bytes
> memory.kernel_soft_limit_in_bytes
> memory.kernel_usage_in_bytes
>
> Any memory charged to memory.kernel_limit_in_bytes would also be
> charged to memory.limit_in_bytes. IOW, memory.limit_in_bytes would
> include both user pages (as it does today) and some kernel pages.
>
> With these new files there are two cgroup memory limits: total and
> kernel. The total limit is a combination of user and some kinds of
> kernel memory.
Nice.
> Kernel page reclaim would occur if memory.kernel_usage_in_bytes
> exceeds memory.kernel_limit_in_bytes. There would be no need to
> reclaim user pages in this situation. If kernel usage exceeds
> kernel_soft_limit_in_bytes, then the protocol pressure flags would be
> set.
SGTM. ATLAIJI as well.
> Memcg-wide page reclaim would occur if memory.usage_in_bytes exceeds
> memory.limit_in_bytes. This reclaim would consider either container
> kernel memory or user pages associated with the container.
>
> This would be a behavioral memcg change which would need to be
> carefully considered. Today the limit_in_bytes is just a user byte
> count that does not include kernel memory.
This makes me wonder that maybe I should just add a tcp-specific file to
memcg (so all memory-related information goes in the same place), but
not account this memory as kernel memory. When you have slab-aware
memcg, let it handle the accounting.
Alternatively, I could start doing basic accounting to pave the way, and
later on this accounting is removing in favor or the slab-based
one.
What do you think ?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] ipv6: Create module parameter for use_tempaddr
From: Paul Stewart @ 2011-09-12 16:37 UTC (permalink / raw)
To: netdev; +Cc: davem, brian.haley
In-Reply-To: <CAMcMvsgZ8t=dh5G=QuFKODCyrBX56nveztq=0QBwaUfO46KL9Q@mail.gmail.com>
Hello, folks. I've been trying to upstream (or open a discussion on)
adding a module parameter to enable IPv6 address privacy as a module
parameter. The author listed for if_inet6.c is not a bouncing email
address. Does anyone else have a suggestion for where to get this
change vetted? I'm now CC'ing the author and reviewer of the last
module parameter change for ipv6.
--
Paul
On Tue, Sep 6, 2011 at 4:56 PM, Paul Stewart <pstew@chromium.org> wrote:
> On Wed, Aug 31, 2011 at 11:03 PM, Paul Stewart <pstew@chromium.org> wrote:
>> When ipv6 is used as a module, there is no good place to set
>> the default value for use_tempaddr. Using sysctl.conf will
>> set this parameter too early -- before the module is loaded.
>> To solve this, create a module parameter that will set the
>> default value of use_tempaddr for all devices.
>>
>> Signed-off-by: Paul Stewart <pstew@chromium.org>
>> ---
>> include/linux/ipv6.h | 1 +
>> net/ipv6/addrconf.c | 3 +++
>> net/ipv6/af_inet6.c | 8 ++++++++
>> 3 files changed, 12 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
>> index 0c99776..0d45a7c 100644
>> --- a/include/linux/ipv6.h
>> +++ b/include/linux/ipv6.h
>> @@ -178,6 +178,7 @@ struct ipv6_devconf {
>> struct ipv6_params {
>> __s32 disable_ipv6;
>> __s32 autoconf;
>> + __s32 use_tempaddr;
>> };
>> extern struct ipv6_params ipv6_defaults;
>> #endif
>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>> index f012ebd..27314a2 100644
>> --- a/net/ipv6/addrconf.c
>> +++ b/net/ipv6/addrconf.c
>> @@ -4609,6 +4609,9 @@ static int __net_init addrconf_init_net(struct net *net)
>> /* these will be inherited by all namespaces */
>> dflt->autoconf = ipv6_defaults.autoconf;
>> dflt->disable_ipv6 = ipv6_defaults.disable_ipv6;
>> +#ifdef CONFIG_IPV6_PRIVACY
>> + dflt->use_tempaddr = ipv6_defaults.use_tempaddr;
>> +#endif
>> }
>>
>> net->ipv6.devconf_all = all;
>> diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
>> index 3b5669a..5022950 100644
>> --- a/net/ipv6/af_inet6.c
>> +++ b/net/ipv6/af_inet6.c
>> @@ -76,6 +76,9 @@ static DEFINE_SPINLOCK(inetsw6_lock);
>> struct ipv6_params ipv6_defaults = {
>> .disable_ipv6 = 0,
>> .autoconf = 1,
>> +#ifdef CONFIG_IPV6_PRIVACY
>> + .use_tempaddr = 0,
>> +#endif
>> };
>>
>> static int disable_ipv6_mod = 0;
>> @@ -89,6 +92,11 @@ MODULE_PARM_DESC(disable_ipv6, "Disable IPv6 on all interfaces");
>> module_param_named(autoconf, ipv6_defaults.autoconf, int, 0444);
>> MODULE_PARM_DESC(autoconf, "Enable IPv6 address autoconfiguration on all interfaces");
>>
>> +#ifdef CONFIG_IPV6_PRIVACY
>> +module_param_named(use_tempaddr, ipv6_defaults.use_tempaddr, int, 0444);
>> +MODULE_PARM_DESC(use_tempaddr, "Enable IPv6 address privacy for autoconfiguration by default");
>> +#endif
>> +
>> static __inline__ struct ipv6_pinfo *inet6_sk_generic(struct sock *sk)
>> {
>> const int offset = sk->sk_prot->obj_size - sizeof(struct ipv6_pinfo);
>> --
>> 1.7.3.1
>>
>>
>
^ permalink raw reply
* Re: [PATCH] per-cgroup tcp buffer limitation
From: Glauber Costa @ 2011-09-12 16:57 UTC (permalink / raw)
To: Paul Menage
Cc: Greg Thelen, linux-kernel, linux-mm, containers, netdev, xemul,
David S. Miller, Hiroyouki Kamezawa, Eric W. Biederman,
Suleiman Souhlal, Lennart Poettering
In-Reply-To: <CALdu-PCrYPZx38o44ZyFrbQ6H39-vNPKey_Tpm4HRUNHNFMpyA@mail.gmail.com>
On 09/12/2011 02:03 AM, Paul Menage wrote:
> On Thu, Sep 8, 2011 at 9:17 PM, Glauber Costa<glommer@parallels.com> wrote:
>> On 09/08/2011 06:53 PM, Greg Thelen wrote:
>>>
>>> On Wed, Sep 7, 2011 at 9:44 PM, Glauber Costa<glommer@parallels.com>
>>> wrote:
>>>
>>> Thanks for your ideas and patience.
>>
>> Likewise. It is turning out to be a very fruitful
>> discussion.
>>
>
> This also got a fair bit of attention at LPC on Thursday - shame you
> couldn't make it, but I hope you had no problems getting your visa!
Apart from the trip to the nearest consulate and 4 hours in a line, no
problems =) I can now legally enter the United States - so wait for me
next time!
>
> I definitely think that there was no consensus reached on unified
> versus split charging - but I think that we can work around that and
> keep everyone happy, see below.
I think at this point there is at least consensus that this could very
well live in memcg, right ?
>
>>
>> Risking being a bit polemic here, I think that when we do
>> containers, we have to view the kernel a little bit like a shared resource
>> that is not accounted to anybody. It is easy to account things like tcp
>> buffer, but who do you account page tables for shared pages to? Or pinned
>> dentries for shared filesystems ?
>
> I'd say that if filesystems (or page tables) are shared between
> containers / cgroups, then it's fair to do first-touch accounting. But
> if a filesystem is shared between multiple processes in just one
> container / cgroup then it should definitely be charged to that cgroup
> (which you get automatically with first-touch accounting).
>
> It might be reasonable to also allow the sysadmin to request a more
> expensive form of accounting (probably either charge-all or
> equal-share), if the code to support that didn't interfere with the
> performance of the normal first-touch charging mechanism, or
> complicate the code too much.
I personally think equal share is a nightmare. But charge-all for shared
resources is quite acceptable even as a default if people are not
heavily concerned about precise accounting, in the sense that all
containers should sum up to one (well, I am not)
> On the subject of filesystems specifically, see Greg Thelen's proposal
> for using bind mounts to account on a bind mount to a given cgroup -
> that could apply to dentries, page tables and other kernel memory as
> well as page cache.
Care to point me to it ?
>> Good that it scares you, it should. OTOH, userspace being
>> able to set parameters to it, has nothing scary at all. A daemon in
>> userspace can detect that you need more kernel space memory , and
>> then - according to a policy you abide to - write to a file allowing
>> it more, or maybe not - according to that same policy. It is very
>> far away from "userspace driven reclaim".
>
> It can do that, but it's a bit messy when all userspace really wants
> to do is say "limit the total to X GB".
>
>
>> No, I don't necessarily feel that need. I just thought it was
>> cleaner to have entities with different purposes in different
>> cgroups. If moving it to the memory controller would help you in any
>> way, I can just do it. 80 % of this work is independent of where a
>> cgroup file lives.
>
> My feeling is also that it's more appropriate for this to live in
> memcg. While the ability to mount subsystems separately gives nice
> flexibility, in the case of userspace versus kernel memory, I'm having
> trouble envisaging a realistic situation where you'd want them mounted
> on different hierarchies.
Right.
>> - kernel_memory_hard_limit.
>> - kernel_memory_soft_limit.
>>
>> tcp memory would be the one defined in /proc, except if it is
>> greater than any of the limits. Instead of testing for memory
>> allocation against kmem.tcp_allocated_memory, we'd test it against
>> memcg.kmem_pinned_memory.
>>
>
> This is definitely an improvement, but I'd say it's not enough. I
> think we should consider something like:
One step at a time =)
>
> - a root cgroup file (memory.unified?) that controls whether memory
> limits are unified or split.
> - this file can only be modified when there are no memory cgroups
> created (other than the root, which we shouldn't be charging, I think)
Okay.
> - the 'active' control determines whether (all) child cgroups will
> have memory.{limit,usage}_in_bytes files, or
> memory.{kernel,user}_{limit,usage}_in_bytes files
> - kernel memory will be charged either against 'kernel' or 'total'
> depending on the value of unified
You mean for display/pressure purposes, right? Internally, I think once
we have kernel memory, we always charge it to kernel memory, regardless
of anything else. The value in unified field will only take place when
we need to grab this value.
I don't personally see a reason for not having all files present at all
times.
> - userspace memory will be charged either against 'user' or 'total'
>
> That way the kernel doesn't force a unified or split decision on
> anyone, with I think zero performance hit and not much extra code.
Yes, I think not forcing it is not only an interesting way of settling
this, but also an interesting feature.
> You could even take this a step further. The following is probably
> straying into the realm of overly-flexible, but I'll throw it into the
> discussion anyway:
>
> - define counters for various types of memory (e.g. total, user,
> kernel, network, tcp, pagetables, dentries, etc)
Hummm, I like it, but I also fear that in the future we'll hit some
resource whose origin is hard to track... /me trying to think of such
potential monster...
It is overly flexible if we're exposing these counters and expecting the
user to do anything with them. It is perfectly fine if a single file,
when read, displays this information as statistics.
> - document what kind of memory is potentially charged against each
> counter. (e.g. TCP buffers would be potentially charged against 'tcp',
> 'network', 'kernel' and 'total')
That, I think, is overly flexible. I think what I said above makes sense
for very well defined entities such the slab. If we have something that
can be accounted to more to one general (kernel/user) and one specific
(slab) entity, we're getting too complex.
> - have a memory.counters root cgroup file that allows the user to
> specify which of the available counters are active. (only writeable
> when no child cgroups, to avoid inconsistencies caused by changes
> while memory is charged)
>
> - default memory.counters to 'total'
>
> - when memory.counters is updated, the memcg code builds the set of
> targets for each chargeable entity. (e.g. if you enabled 'network' and
> 'total', then we'd update the charge_tcp array to contain something
> like {&network_counter,&total_counter, NULL })
>
> - charging for an object (TCP allocation, pagecache page, pagetable,
> dentry, etc) just involves (trying to) charge all the counters set up
> in that object's array. Since these arrays will be immutable once
> child cgroups are being charged, they should be fairly well predicted.
>
> This would give complete flexibility to userspace on the policy for
> charging and reporting without incurring performance overhead for
> systems that didn't care about some particular counter. (And without
> complicating the code too much, I think).
While I do think it is overly complicated, I think that a sound use case
for this would bring it to the "complicated" realm only. It sounds like
a nice feature if there are users for it.
Not only for containers - that tend to be generic in most cases - but
maybe people enclosing services in isolated cgroups can come up with
profiles that will, for instance, disallow or allow very little disk
activity on a network-profiled cgroup and vice versa.
I am adding Lennart to this discussion, since if there is anyone crazy
enough to come up with an interesting use case for something strange,
it'll be systemd.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Roopa Prabhu @ 2011-09-12 17:02 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Sridhar Samudrala, netdev, dragos.tatulea, arnd, dwang2, benve,
kaber, davem, eric.dumazet, mchan, kvm
In-Reply-To: <20110911190325.GC4740@redhat.com>
On 9/11/11 12:03 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Sun, Sep 11, 2011 at 06:18:01AM -0700, Roopa Prabhu wrote:
>>
>>
>>
>> On 9/11/11 2:44 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>
>>>
>>> Yes, but what I mean is, if the size of the single filter table
>>> is limited, we need to decide how many addresses is
>>> each guest allowed. If we let one guest ask for
>>> as many as it wants, it can lock others out.
>>
>> Yes true. In these cases ie when the number of unicast addresses being
>> registered is more than it can handle, The VF driver will put the VF in
>> promiscuous mode (Or at least its supposed to do. I think all drivers do
>> that).
>>
>>
>> Thanks,
>> Roopa
>
> Right, so that works at least but likely performs worse
> than a hardware filter. So we better allocate it in
> some fair way, as a minimum. Maybe a way for
> the admin to control that allocation is useful.
Yes I think we will have to do something like that. There is a maximum that
hw can support. Might need to consider that too. But there is no interface
to get that today. I think the virtualization case gets a little trickier.
Virtio-net allows upto 64 unicast addresses. But the lowerdev may allow only
upto say 10 unicast addresses (I think intel supports 10 unicast addresses
on the VF). Am not sure if there is a good way to notify the guest of
blocked addresses. Maybe putting the lower dev in promiscuous mode could be
a policy decision too in this case.
One other thing, I had indicated that I will look up details on opening my
patch for non-passthru to enable hw filtering (without adding filtering
support in macvlan right away. Ie phase1). Turns out in current code in
macvlan_handle_frame, for non-passthru case, it does not fwd unicast pkts
destined to macs other than the ones in macvlan hash. So a filter or hash
lookup there for additional unicast addresses needs to be definitely added
for non-passthru.
Thanks,
Roopa
^ permalink raw reply
* Incorrect routing to lo in spite of correct record in routing table
From: Марк Коренберг @ 2011-09-12 17:14 UTC (permalink / raw)
To: netdev
Suppose this (note netowrk masks):
[mmarkk@mmarkk-devel ~]# uname -a
Linux mmarkk-devel 2.6.32-71.el6.x86_64 #1 SMP Wed Sep 1 01:33:01 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux
[mmarkk@mmarkk-devel ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
inet 127.0.0.1/32 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
inet 10.80.20.21/16 brd 10.80.255.255 scope global eth0
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN
inet 127.0.0.2/32 scope host dummy0
[mmarkk@mmarkk-devel ~]# ip route show
10.80.0.0/16 dev eth0 proto kernel scope link src 10.80.20.21
unreachable 127.0.0.0/8 <---------------------- has been added by hand
default via 10.80.90.40 dev eth0
[mmarkk@mmarkk-devel ~]# ip route show table local
broadcast 10.80.0.0 dev eth0 proto kernel scope link src 10.80.20.21
local 10.80.20.21 dev eth0 proto kernel scope host src 10.80.20.21
local 127.0.0.2 dev dummy0 proto kernel scope host src 127.0.0.2
broadcast 10.80.255.255 dev eth0 proto kernel scope link src 10.80.20.21
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
[mmarkk@mmarkk-devel ~]# ip route flush cache
[mmarkk@mmarkk-devel ~]# ip route get 127.0.0.3
RTNETLINK answers: Network is unreachable <------------ good, that is OK
[mmarkk@mmarkk-devel ~]# ip route get 127.0.0.1
local 127.0.0.1 dev lo src 127.0.0.1 <--------- Good, that's OK too
cache <local> mtu 16436 advmss 16396 hoplimit 64
[mmarkk@mmarkk-devel ~]# ip route get 127.0.0.2
local 127.0.0.2 dev lo src 127.0.0.2 <------------ HAY! this is not I
want. Why device is "lo" (instead of dummy0) ?!
cache <local> mtu 16436 advmss 16396 hoplimit 64
=========================
The problem is that I want to do DNAT to localhost. I know, why DNAT
to 127.0.0.1 (to interface "lo") does not work. I decide to do that
using interface dummy0. It works as expected if I choose any address
not in 127.0.0.0/8.
RFC 3330 said:
-------------
A datagram sent by a higher level protocol to an address anywhere
within this block should loop back inside the host. This is ordinarily
implemented using only 127.0.0.1/32 for loopback, but no addresses
within this block should ever appear on any network anywhere
-------------
So, my question: Why the kernel routes 127.0.0.2 to lo (instead of dummy0) ?
Well, If kernel is so smart to route any 127.0.0.0/8 to "lo", why it
routes 127.0.0.3 to default gateway if I remove "unreachable
127.0.0.0/8" ?!
I think there is some bug in kernel. What are you thinking about?
--
Segmentation fault
^ permalink raw reply
* Re: Memory leak in ip_dst_cache
From: Kumar S @ 2011-09-12 17:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Neil Horman, netdev
In-Reply-To: <1315808931.3174.17.camel@edumazet-laptop>
----- Original Message -----
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Kumar S <ps2kumar@yahoo.com>
Cc: Neil Horman <nhorman@tuxdriver.com>; netdev <netdev@vger.kernel.org>
Sent: Sunday, September 11, 2011 11:28 PM
Subject: Re: Memory leak in ip_dst_cache
Le dimanche 11 septembre 2011 à 23:07 -0700, Kumar S a écrit :
>> ----- Original Message -----
>> From: Eric Dumazet <eric.dumazet@gmail.com>
> >To: Kumar S <ps2kumar@yahoo.com>
> >Cc: Neil Horman <nhorman@tuxdriver.com>; netdev <netdev@vger.kernel.org>
> >Sent: Sunday, September 11, 2011 10:40 PM
> Subject: Re: Memory leak in ip_dst_cache
> >
>> Le dimanche 11 septembre 2011 à 20:38 -0700, Kumar S a écrit :
>>
>> Please dont top post.
>>
> >>> Thanks Neil. I did try with prink(). I do see entries getting aged
> >>> out, but they are not getting deallocated. This seems to be happening
> >>>because of "ref_cnt". When the route entries are added the ref_cnt is
> >>> set to 1. Looks this is causing trouble clearing the entries
> >>> completely. If I set the ref_cnt to 0, I can see it working. Now I'm
> >>> trying to understand whether this is right. Please let me know if you
> >>> have any thoughts on it.
>>
> >>I believe I already explained what was happening.
>>
> >>A tcp socket has a pointer to a dst, so it holds a reference on it, to
> >>make sure no freeing of dst can happen while at least some socket still
> >>can reference dst. (It could reference freed memory and crash)
>>
> >>As soon as the tcp socket will try to transmit some data, the dst will
> >>be checked and we notice its obsolete : We then release the refcount and
> >>dst pointer.
> >
> >>Later, the garbage collector can notice dst refcount is zero and can
> >>free dst.
> >
> >>If you have dormant tcp sockets (no trafic at all), they hold their dst.
> >>A dormant tcp socket has a pretty more expensive memory cost than its
> >>dst. (Socket structure, dentry, inode, and probably in user land a
> >>thread or process, and data)
> >
>> Thanks Eric for detailed explanation. You did mention this before.
>> What I see is the cache entries related to the TCP sockets are getting
> >cleared, whenever they age out. But the issue we see here is with the
> >broadcast messages such as SMB messages and network neighbor hood
>> messages. They never get freed. There is no traffic to those
> >destinations from our board.
>What do you mean ? Your box is a router only ?
>Those SMB messages are going through it ?
Our box is a stand-alone system with L2 Quick Engine. This QE forwards all broadcast to the other ports and also a copy to the CPU port.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Roopa Prabhu @ 2011-09-12 17:23 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: Michael S. Tsirkin, netdev, dragos.tatulea, arnd, dwang2, benve,
kaber, davem, eric.dumazet, mchan, kvm
In-Reply-To: <4E6D8AF3.7080406@us.ibm.com>
On 9/11/11 9:30 PM, "Sridhar Samudrala" <sri@us.ibm.com> wrote:
> On 9/11/2011 6:18 AM, Roopa Prabhu wrote:
>>
>>
>> On 9/11/11 2:44 AM, "Michael S. Tsirkin"<mst@redhat.com> wrote:
>>
>>>> AFAIK, though it might maintain a single filter table space in hw, hw does
>>>> know which filter belongs to which VF. And the OS driver does not need to
>>>> do
>>>> anything special. The VF driver exposes a VF netdev. And any uc/mc
>>>> addresses
>>>> registered with a VF netdev are registered with the hw by the driver. And
>>>> hw
>>>> will filter and send only pkts that the VF has expressed interest in.
>>>>
>>>> No special filter partitioning in hw is required.
>>>>
>>>> Thanks,
>>>> Roopa
>>> Yes, but what I mean is, if the size of the single filter table
>>> is limited, we need to decide how many addresses is
>>> each guest allowed. If we let one guest ask for
>>> as many as it wants, it can lock others out.
>> Yes true. In these cases ie when the number of unicast addresses being
>> registered is more than it can handle, The VF driver will put the VF in
>> promiscuous mode (Or at least its supposed to do. I think all drivers do
>> that).
>>
> What does putting VF in promiscuous mode mean? How can the NIC decide
> which set
> of mac addresses are passed to the VF? Does it mean VF sees all the
> packets received
> by the NIC including packets destined for other VFs/PF?
>
Yes I think so. After your question I looked at 2 other VF drivers and
looks like they return error if num unicast addresses exceeds the number
supported by hw and don't put the VF in promiscuous mode. But one could put
the VF in promiscuous mode by changing IFF_FLAGS I think.
The original in-kernel passthru mode code puts the VF in promiscuous mode by
default. Am assuming that works well with other sriov cards you got a chance
to try out with.
Thanks,
Roopa
^ permalink raw reply
* Re: Memory leak in ip_dst_cache
From: Eric Dumazet @ 2011-09-12 17:57 UTC (permalink / raw)
To: Kumar S; +Cc: Neil Horman, netdev
In-Reply-To: <1315847801.41447.YahooMailNeo@web113916.mail.gq1.yahoo.com>
Le lundi 12 septembre 2011 à 10:16 -0700, Kumar S a écrit :
> ----- Original Message -----
> From: Eric Dumazet <eric.dumazet@gmail.com>
> >What do you mean ? Your box is a router only ?
>
> >Those SMB messages are going through it ?
>
> Our box is a stand-alone system with L2 Quick Engine. This QE forwards
> all broadcast to the other ports and also a copy to the CPU port.
It sounds like a modified kernel, maybe you added a bug in the code...
^ permalink raw reply
* [PATCH] Check net->nfnl for NULL in ctnetlink_conntrack_event to, avoid Oops on container destroy
From: Tim Gardner @ 2011-09-12 18:03 UTC (permalink / raw)
To: kaber, linux-kernel
Cc: David Miller, netfilter-devel, netfilter, coreteam, netdev
[-- Attachment #1: Type: text/plain, Size: 331 bytes --]
Patrick,
I received this patch from a developer that uses lxc and network name
spaces. I don't know the locking semantics well enough for CT to judge
whether this fix is sufficient. Bug info can be found at
http://bugs.launchpad.net/bugs/843892 . See comment #7 for his analysis.
rtg
--
Tim Gardner tim.gardner@canonical.com
[-- Attachment #2: 0001-Check-net-nfnl-for-NULL-in-ctnetlink_conntrack_event.patch --]
[-- Type: text/x-patch, Size: 939 bytes --]
>From dcb64e27c7daaf4affe5b1a617b45a9a0364b4ad Mon Sep 17 00:00:00 2001
From: Alex Bligh <alex@alex.org.uk>
Date: Sat, 10 Sep 2011 13:29:12 +0100
Subject: [PATCH] Check net->nfnl for NULL in ctnetlink_conntrack_event to
avoid Oops on container destroy
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
net/netfilter/nf_conntrack_netlink.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index 482e90c..0790d0a 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -570,6 +570,11 @@ ctnetlink_conntrack_event(unsigned int events, struct nf_ct_event *item)
return 0;
net = nf_ct_net(ct);
+
+ /* container deinit, netlink may have died before death_by_timeout */
+ if (!net->nfnl)
+ return 0;
+
if (!item->report && !nfnetlink_has_listeners(net, group))
return 0;
--
1.7.5.4
^ permalink raw reply related
* Temporary(?) relocation of wireless git trees...
From: John W. Linville @ 2011-09-12 18:13 UTC (permalink / raw)
To: linux-wireless
Cc: David Woodhouse, Stephen Rothwell, David S. Miller, netdev,
linux-kernel
With no news on when the kernel.org trees will be accessible again
(which could be 10 minutes from now for all I know), I have pushed
my local copies to Infradead. This should be equivalent to what was
last pushed to kernel.org almost two weeks ago.
The "current" wireless tree is here:
git://git.infradead.org/users/linville/wireless.git
The "next" wireless tree is here:
git://git.infradead.org/users/linville/wireless-next.git
The "testing" wireless tree is here:
git://git.infradead.org/users/linville/wireless-testing.git
I don't know how long these trees will be on Infradead or when (or
if) they will return to kernel.org. Such changes will be determined
as conditions change. Please be flexible.
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] Check net->nfnl for NULL in ctnetlink_conntrack_event to, avoid Oops on container destroy
From: Tim Gardner @ 2011-09-12 18:42 UTC (permalink / raw)
To: kaber
Cc: linux-kernel, David Miller, netfilter-devel, netfilter, coreteam,
netdev
In-Reply-To: <4E6E4961.9070802@canonical.com>
On 09/12/2011 12:03 PM, Tim Gardner wrote:
> Patrick,
>
> I received this patch from a developer that uses lxc and network name
> spaces. I don't know the locking semantics well enough for CT to judge
> whether this fix is sufficient. Bug info can be found at
> http://bugs.launchpad.net/bugs/843892 . See comment #7 for his analysis.
>
> rtg
Never mind. Looks like Alex already sent this patch on Sept 10 with the
subject 'Fix repeatable Oops on container destroy with conntrack'.
rtg
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* Re: Incorrect routing to lo in spite of correct record in routing table
From: Eric Dumazet @ 2011-09-12 18:47 UTC (permalink / raw)
To: Марк Коренберг
Cc: netdev
In-Reply-To: <CAEmTpZGKnU4z4J43XGa-1YZ0WW6rnKdpTRJDFEeUTfVmZQH84g@mail.gmail.com>
Le lundi 12 septembre 2011 à 23:14 +0600, Марк Коренберг a écrit :
> Suppose this (note netowrk masks):
>
> [mmarkk@mmarkk-devel ~]# uname -a
> Linux mmarkk-devel 2.6.32-71.el6.x86_64 #1 SMP Wed Sep 1 01:33:01 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>
> [mmarkk@mmarkk-devel ~]# ip addr
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> inet 127.0.0.1/32 scope host lo
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
> inet 10.80.20.21/16 brd 10.80.255.255 scope global eth0
> 3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN
> inet 127.0.0.2/32 scope host dummy0
>
> [mmarkk@mmarkk-devel ~]# ip route show
> 10.80.0.0/16 dev eth0 proto kernel scope link src 10.80.20.21
> unreachable 127.0.0.0/8 <---------------------- has been added by hand
> default via 10.80.90.40 dev eth0
>
> [mmarkk@mmarkk-devel ~]# ip route show table local
> broadcast 10.80.0.0 dev eth0 proto kernel scope link src 10.80.20.21
> local 10.80.20.21 dev eth0 proto kernel scope host src 10.80.20.21
> local 127.0.0.2 dev dummy0 proto kernel scope host src 127.0.0.2
> broadcast 10.80.255.255 dev eth0 proto kernel scope link src 10.80.20.21
> local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
>
> [mmarkk@mmarkk-devel ~]# ip route flush cache
>
> [mmarkk@mmarkk-devel ~]# ip route get 127.0.0.3
> RTNETLINK answers: Network is unreachable <------------ good, that is OK
>
> [mmarkk@mmarkk-devel ~]# ip route get 127.0.0.1
> local 127.0.0.1 dev lo src 127.0.0.1 <--------- Good, that's OK too
> cache <local> mtu 16436 advmss 16396 hoplimit 64
>
> [mmarkk@mmarkk-devel ~]# ip route get 127.0.0.2
> local 127.0.0.2 dev lo src 127.0.0.2 <------------ HAY! this is not I
> want. Why device is "lo" (instead of dummy0) ?!
> cache <local> mtu 16436 advmss 16396 hoplimit 64
>
> =========================
> The problem is that I want to do DNAT to localhost. I know, why DNAT
> to 127.0.0.1 (to interface "lo") does not work. I decide to do that
> using interface dummy0. It works as expected if I choose any address
> not in 127.0.0.0/8.
>
> RFC 3330 said:
> -------------
> A datagram sent by a higher level protocol to an address anywhere
> within this block should loop back inside the host. This is ordinarily
> implemented using only 127.0.0.1/32 for loopback, but no addresses
> within this block should ever appear on any network anywhere
> -------------
> So, my question: Why the kernel routes 127.0.0.2 to lo (instead of dummy0) ?
>
> Well, If kernel is so smart to route any 127.0.0.0/8 to "lo", why it
> routes 127.0.0.3 to default gateway if I remove "unreachable
> 127.0.0.0/8" ?!
>
Because you have 127.0.0.1/32 on lo, not 127.0.0.1/8
> I think there is some bug in kernel. What are you thinking about?
>
I have no idea why you think there is a bug.
127.0.0.2 (dummy0) is a local address like 10.80.20.21 (eth0)
When you ping 10.80.20.21, the frame goes through loopback, not eth0.
# ip ro get 10.80.20.21
local 10.80.20.21 dev lo src 10.80.20.21
cache <local>
BTW, if you 'ifconfig lo down', ping to 10.80.20.21 doesnt work.
^ permalink raw reply
* Re: [PATCH net-next] af_unix: dont send SCM_CREDENTIALS by default
From: Tim Chen @ 2011-09-12 19:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: Yan, Zheng, Yan, Zheng, netdev@vger.kernel.org,
davem@davemloft.net, sfr@canb.auug.org.au, jirislaby@gmail.com,
sedat.dilek@gmail.com, Shi, Alex, Valdis Kletnieks
In-Reply-To: <1315544777.5410.19.camel@edumazet-laptop>
On Fri, 2011-09-09 at 07:06 +0200, Eric Dumazet wrote:
> Le jeudi 08 septembre 2011 à 02:24 -0700, Tim Chen a écrit :
>
> > Looking forward to the patch. This should improve the scalability of
> > af_unix.
>
> Here it is, based on top on previous one [af_unix: Fix use-after-free
> crashes]
>
> Thanks
>
> [PATCH net-next] af_unix: dont send SCM_CREDENTIALS by default
>
> Since commit 7361c36c5224 (af_unix: Allow credentials to work across
> user and pid namespaces) af_unix performance dropped a lot.
>
> This is because we now take a reference on pid and cred in each write(),
> and release them in read(), usually done from another process,
> eventually from another cpu. This triggers false sharing.
>
> # Events: 154K cycles
> #
> # Overhead Command Shared Object Symbol
> # ........ ....... .................. ...................................
> #
> 10.40% hackbench [kernel.kallsyms] [k] put_pid
> 8.60% hackbench [kernel.kallsyms] [k] unix_stream_recvmsg
> 7.87% hackbench [kernel.kallsyms] [k] unix_stream_sendmsg
> 6.11% hackbench [kernel.kallsyms] [k] do_raw_spin_lock
> 4.95% hackbench [kernel.kallsyms] [k] unix_scm_to_skb
> 4.87% hackbench [kernel.kallsyms] [k] pid_nr_ns
> 4.34% hackbench [kernel.kallsyms] [k] cred_to_ucred
> 2.39% hackbench [kernel.kallsyms] [k] unix_destruct_scm
> 2.24% hackbench [kernel.kallsyms] [k] sub_preempt_count
> 1.75% hackbench [kernel.kallsyms] [k] fget_light
> 1.51% hackbench [kernel.kallsyms] [k] __mutex_lock_interruptible_slowpath
> 1.42% hackbench [kernel.kallsyms] [k] sock_alloc_send_pskb
>
>
> This patch includes SCM_CREDENTIALS information in a af_unix message/skb
> only if requested by the sender, [man 7 unix for details how to include
> ancillary data using sendmsg() system call]
>
> Note: This might break buggy applications that expected SCM_CREDENTIAL
> from an unaware write() system call.
>
> Performance boost in hackbench : more than 50% gain on a 16 thread
> machine (2 quad-core cpus, 2 threads per core)
>
> hackbench 20 thread 2000
>
> 4.224 sec instead of 9.102 sec
>
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
This speeds up the case where we're not passing SCM_CREDENTIALS nicely.
Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
^ permalink raw reply
* [PATCH RFC v2 0/5] netfilter reverse path filter matches
From: Florian Westphal @ 2011-09-12 19:42 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev
Version 2 of the ipv4/v6 reverse path filter matches discussed during
nfws 2011.
The ipv4 match (ipt_rpfilter) tries to do exactly what the current
fib_validate_source does. The main problem with this is that
we need to do an additional fib lookup to get the oif in the match.
[ delaying until FORWARD is invoked is not possible because by
that point the stack might have already sent icmp errors ].
Patrick McHardy suggested to simply attach the result as the dst, so
ipv4 input path doesn't have to do it again.
This works, but does have a few side effects wrt. route-by-mark and
TPROXY, see patch changelog for details.
The ipv6 version does a pure 'reverse' lookup instead. This makes
things a lot easier (e.g. when multiple route entries exist), but has
the caveat that a real reply packet might be handled differently due to
policy routing rules.
Userspace part is stored in my iptables repository on
http://git.breakpoint.cc/cgi-bin/gitweb.cgi?p=fw/iptables.git (branch 'rpfilter').
Kernel patches are located in the 'xt_rpfilter_5' branch on
http://git.breakpoint.cc/cgi-bin/gitweb.cgi?p=fw/nf-next.git
(patches will be sent as followup to this email).
[ in case you are wondering: the earlier xt_rpfilter version was
removed -- causes too many module dependency issues and most of the
code cannot be shared anyway ].
Thanks,
Florian
^ permalink raw reply
* [RFC PATCH 1/5] net: ipv4: export fib_table_lookup
From: Florian Westphal @ 2011-09-12 19:42 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, Florian Westphal
In-Reply-To: <1315856552-1422-1-git-send-email-fw@strlen.de>
modules using fib_lookup() fail to link when
CONFIG_IP_MULTIPLE_TABLES is not set.
The reason is that in this case fib_lookup is a static inline
helper that calls fib_table_lookup.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/ipv4/fib_trie.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 58c25ea..e13eb24 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -1606,6 +1606,7 @@ found:
rcu_read_unlock();
return ret;
}
+EXPORT_SYMBOL_GPL(fib_table_lookup);
/*
* Remove the leaf and return parent.
--
1.7.3.4
^ permalink raw reply related
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