* Re: [PATCH] netns: add /proc/*/net/id symlink
From: Eric W. Biederman @ 2011-05-22 0:15 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: davem, netdev, equinox, Linux Containers
In-Reply-To: <20110521223054.GA3198@p183>
Adding the containers list.
Alexey Dobriyan <adobriyan@gmail.com> writes:
> On Sat, May 21, 2011 at 08:39:37AM -0700, Eric W. Biederman wrote:
>> Alexey Dobriyan <adobriyan@gmail.com> writes:
>> > * init_net always has id 0
>> > * two netns do not have same id
>> > * id is unsigned integer
>>
>> I don't like this patch because we already have a proc interface
>> that already solves this in production kernels today.
>>
>> - stat is a single syscall
>> - two netns do not have the same id
>> - id is an ino_t.
>
> Yeah, stat /proc/*/net/dev works.
> If you document this, it means we can't change the way ->low_ino is set.
> And we can't do other things inside irregular part of procfs.
Maybe. Certainly there are things that would suggest we need some
fixes to this part of procfs.
> But can we add clean interface once in a while.
I am all for making a clean solution. I don't see a proc file
in in /proc/net that provides a small integer as particularly clean.
It has the classic problem of what namespace are namespaces named in.
It only solves the problem for the network namespace.
So on that level I really like the idea of inode numbers in proc
being the place where we have a name. People generally don't get
confused about inode numbers understanding they are an implementation
detail but they do understand that inode numbers plus filesystem
information can be used to compare files for identity.
So let's skip the fact that /proc/*/net/dev happens to work for a
moment.
For clean interfaces I am in the process of adding /proc/<pid>/ns/net,
/proc/<pid>/ns/ipc, and /proc/<pid>/ns/uts.
If we can make those files inode number be the same if the namespace is
the same like /proc/<pid>/net/dev is today. I think we will have a
clean solution.
Additionally that solution will work for comparing network namespaces
that don't happen to have any processes in them at the moment. Because
fstat works on file descriptors.
With the /proc/<pid>/ns/net file and bind mounts I have solved the
deeper problem of how do we get userspace policy into the naming of
namespaces. With those files and the setns system call I have solved
the other problem of what is a good way to refer to namespaces without
assuming a global name. So once those changes are merged I expect there
to be much less pressure to misuse any kind of identifier we can have.
And if we only make the guarantee about inode consistency for the
/proc/<pid>/ns/FILE files I don't expect it will make maintenance
of procfs any harder than it already is.
Eric
^ permalink raw reply
* Re: [GIT PULL] Namespace file descriptors for 2.6.40
From: Linus Torvalds @ 2011-05-21 23:42 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-kernel, Linux Containers, netdev, James Bottomley,
Geert Uytterhoeven
In-Reply-To: <m11uzrvd26.fsf@fess.ebiederm.org>
On Sat, May 21, 2011 at 4:39 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
>
> In a hopeless quest to avoid conflicts when merging a new system call
> and wiring it up I have pulled in bits of net-next and the parisc tree.
> You have already pulled the net-next bits. The parisc bits in my tree
> are:
Ok, this just means that I won't pull from you.
It's that simple. We don't do this. Ever.
Why the hell did you even worry about wiring up parisc system calls?
That's not your job.
Linus
^ permalink raw reply
* [GIT PULL] Namespace file descriptors for 2.6.40
From: Eric W. Biederman @ 2011-05-21 23:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Linux Containers, netdev, James Bottomley,
Geert Uytterhoeven
Please pull the namespace file descriptor git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/linux-2.6-nsfd.git
In a hopeless quest to avoid conflicts when merging a new system call
and wiring it up I have pulled in bits of net-next and the parisc tree.
You have already pulled the net-next bits. The parisc bits in my tree
are:
James Bottomley (4):
[PARISC] wire up fanotify syscalls
[PARISC] wire up clock_adjtime syscall
[PARISC] wire up the fhandle syscalls
[PARISC] wire up syncfs syscall
Meelis Roos (1):
[PARISC] fix pacache .size with new binutils
Since then I have gained conflicts in alpha and m68k.
For alpha all that is needed is a simple incrementing of
the syscall number in my tree and adding of my syscall to
the end of the list.
For m68k please just delete all of the syscall entries the conflict will
add to arch/m68k/kernel/entry_mm.S. The m68k tree has consolidated
everything in arch/m68k/kernel/syscalltable.S
This tree adds the files /proc/<pid>/ns/net, /proc/<pid>/ns/ipc,
/proc/<pid>/ns/uts that can be opened to refer to the namespaces of a
process at the time those files are opened, and can be bind mounted to
keep the specified namespace alive without a process.
This tree adds the setns system call that can be used to change the
specified namespace of a process to the namespace specified by a system
call.
This tree adds a new rtnetlink attribute that allows for moving a
network device into a network namespace specified by a file descriptor.
Support for the other namespaces is planned but is not ready for 2.6.40.
These changes dramatically simplify what a userspace process has to do
to keep a namespace alive, and to execute system calls in it.
The shortlog:
Stephen Rothwell (1):
net: fix get_net_ns_by_fd for !CONFIG_NET_NS
Eric W. Biederman (11):
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
net: Allow setting the network namespace by fd
Merge commit '2e7bad5f34b5beed47542490c760ed26574e38ba' into HEAD
Merge commit '7143b7d41218d4fc2ea33e6056c73609527ae687' into HEAD
ns: Wire up the setns system call
ns: Declare sys_setns in syscalls.h
ns proc: Return -ENOENT for a nonexistent /proc/self/ns/ entry.
The diffstat:
arch/alpha/include/asm/unistd.h | 3 +-
arch/alpha/kernel/systbls.S | 1 +
arch/arm/include/asm/unistd.h | 1 +
arch/arm/kernel/calls.S | 1 +
arch/avr32/include/asm/unistd.h | 3 +-
arch/avr32/kernel/syscall_table.S | 1 +
arch/blackfin/include/asm/unistd.h | 3 +-
arch/blackfin/mach-common/entry.S | 1 +
arch/cris/arch-v10/kernel/entry.S | 1 +
arch/cris/arch-v32/kernel/entry.S | 1 +
arch/cris/include/asm/unistd.h | 3 +-
arch/frv/include/asm/unistd.h | 3 +-
arch/frv/kernel/entry.S | 1 +
arch/h8300/include/asm/unistd.h | 3 +-
arch/h8300/kernel/syscalls.S | 1 +
arch/ia64/include/asm/unistd.h | 3 +-
arch/ia64/kernel/entry.S | 1 +
arch/m32r/include/asm/unistd.h | 3 +-
arch/m32r/kernel/syscall_table.S | 1 +
arch/m68k/include/asm/unistd.h | 3 +-
arch/m68k/kernel/syscalltable.S | 1 +
arch/microblaze/include/asm/unistd.h | 3 +-
arch/microblaze/kernel/syscall_table.S | 1 +
arch/mips/include/asm/unistd.h | 15 ++-
arch/mips/kernel/scall32-o32.S | 1 +
arch/mips/kernel/scall64-64.S | 1 +
arch/mips/kernel/scall64-n32.S | 1 +
arch/mips/kernel/scall64-o32.S | 1 +
arch/mn10300/include/asm/unistd.h | 3 +-
arch/mn10300/kernel/entry.S | 1 +
arch/parisc/include/asm/unistd.h | 10 ++-
arch/parisc/kernel/pacache.S | 6 +-
arch/parisc/kernel/sys_parisc32.c | 8 ++
arch/parisc/kernel/syscall_table.S | 7 +
arch/powerpc/include/asm/systbl.h | 1 +
arch/powerpc/include/asm/unistd.h | 3 +-
arch/s390/include/asm/unistd.h | 3 +-
arch/s390/kernel/syscalls.S | 1 +
arch/sh/include/asm/unistd_32.h | 3 +-
arch/sh/include/asm/unistd_64.h | 3 +-
arch/sh/kernel/syscalls_32.S | 1 +
arch/sh/kernel/syscalls_64.S | 1 +
arch/sparc/include/asm/unistd.h | 3 +-
arch/sparc/kernel/systbls_32.S | 2 +-
arch/sparc/kernel/systbls_64.S | 4 +-
arch/x86/ia32/ia32entry.S | 1 +
arch/x86/include/asm/unistd_32.h | 3 +-
arch/x86/include/asm/unistd_64.h | 2 +
arch/x86/kernel/syscall_table_32.S | 1 +
arch/xtensa/include/asm/unistd.h | 4 +-
fs/proc/Makefile | 1 +
fs/proc/base.c | 20 ++--
fs/proc/inode.c | 7 +
fs/proc/internal.h | 18 +++
fs/proc/namespaces.c | 198 ++++++++++++++++++++++++++++++++
include/asm-generic/unistd.h | 4 +-
include/linux/if_link.h | 1 +
include/linux/proc_fs.h | 21 ++++
include/linux/syscalls.h | 1 +
include/net/net_namespace.h | 1 +
ipc/namespace.c | 37 ++++++
kernel/nsproxy.c | 42 +++++++
kernel/utsname.c | 39 ++++++
net/core/net_namespace.c | 65 +++++++++++
net/core/rtnetlink.c | 5 +-
65 files changed, 547 insertions(+), 46 deletions(-)
Thanks,
Eric
^ permalink raw reply
* 7065388
From: obldtoez @ 2011-05-21 23:07 UTC (permalink / raw)
To: netdctor, netdev, netdolphin, neteasehr.hz, NeteaseSchool,
neteasy, netease_guodong, netease100
5700
贵公司经理,负责人:
您好!本公司主要经营代开国、地税发票业务的正规公司，我司只需收到贵公司的开票内容，便会通过筛选出相匹配的行业及适合的公司开具发票，类型如下：
一、增值税：增值税专用发票、增值税海关缴款书、普通增值税发票（此类发票均为正规企业可用于抵税等保证有上税发票！详情可与我司联系商谈）
二、公路内河运输：可税务抵扣正规有上税运输发票
三、普通国、地税：商品销售，工商业统一销售，货运，建筑安装，服务业，广告业，酒店住宿，会议费，咨询费，定额餐饮等（此类发票详细税率可根据数额大小商谈）
以上票据确保所开具发票为税务机关领取的真票，可查证后付款，对于双方的合作关系绝对保密，若贵公司有什么需要或其它的疑虑问题，欢迎来电咨询（敬请保留，以备后需，打扰之处请见谅）
联系人：张先生 电话：13927430348 QQ:835378817
452709993
^ permalink raw reply
* RE: [PATCH 0/2] bna: Add Debugfs & Generic Netlink Interfaces to BNA Driver
From: Rasesh Mody @ 2011-05-21 23:06 UTC (permalink / raw)
To: Rasesh Mody, davem@davemloft.net, netdev@vger.kernel.org
Cc: Adapter Linux Open SRC Team
In-Reply-To: <1305694621-28023-1-git-send-email-rmody@brocade.com>
>From: Rasesh Mody
>Sent: Tuesday, May 17, 2011 9:57 PM
>Subject: [PATCH 0/2] bna: Add Debugfs & Generic Netlink Interfaces to
>BNA Driver
>
>This patch set adds debugfs and generic netlink interfaces to BNA driver
>for
>debugging and managing the Brocade adapter.
Hi David,
Can you please tell what is the state of this patch set? We are wondering if the patches are still under review.
Thanks,
Rasesh
^ permalink raw reply
* Re: [PATCH] netns: add /proc/*/net/id symlink
From: Alexey Dobriyan @ 2011-05-21 22:30 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: davem, netdev, equinox
In-Reply-To: <m11uzsxdty.fsf@fess.ebiederm.org>
On Sat, May 21, 2011 at 08:39:37AM -0700, Eric W. Biederman wrote:
> Alexey Dobriyan <adobriyan@gmail.com> writes:
> > * init_net always has id 0
> > * two netns do not have same id
> > * id is unsigned integer
>
> I don't like this patch because we already have a proc interface
> that already solves this in production kernels today.
>
> - stat is a single syscall
> - two netns do not have the same id
> - id is an ino_t.
Yeah, stat /proc/*/net/dev works.
If you document this, it means we can't change the way ->low_ino is set.
And we can't do other things inside irregular part of procfs.
But can we add clean interface once in a while.
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Stephen Hemminger @ 2011-05-21 22:15 UTC (permalink / raw)
To: Jesse Gross
Cc: Nicolas de Pesloüan, Changli Gao, Jiri Pirko, David Miller,
netdev, kaber, fubar, eric.dumazet, andy, ebiederm
In-Reply-To: <BANLkTinqFJa-B7E7tonzOKGV4etZHUkUug@mail.gmail.com>
On Sat, 21 May 2011 10:54:39 -0700
Jesse Gross <jesse@nicira.com> wrote:
> On Sat, May 21, 2011 at 6:17 AM, Nicolas de Pesloüan
> <nicolas.2p.debian@gmail.com> wrote:
> > Le 21/05/2011 12:43, Changli Gao a écrit :
> >>
> >> On Sat, May 21, 2011 at 3:29 PM, Jiri Pirko<jpirko@redhat.com> wrote:
> >>>
> >>> I do not see a reason why to not emulate that. To make paths as much
> >>> similar as they can be, that is the point of this patch.
> >>>
> >>> I think it would be better to fix an issue you are pointing at
> >>> rather that revert this.
> >>>
> >>
> >> In my opinion, the hardware accelerated VLAN RX is just a special case
> >> of the non hardware accelerated VLAN RX with header reordering. For
> >> promiscuous NICs and bridges, hw-accel-vlan-rx is just disabled.
> >
> > I strongly agree with that.
> >
> > The fact that a skb holds a VLAN tag is not a good enough reason to always
> > remove this tag before giving the skb to protocol handlers.
> >
> > If the user ask for VLAN tag removal, we should remove the tag, possibly
> > using hw-accel untagging if available else software untagging. And if the
> > user doesn't ask for tag removal, we should not untag.
> >
> > In other words, if the user doesn't setup any vlan interface on top of
> > another interface, there is no reason to untag the skb : both hw-accel
> > untagging and software untagging should be disabled.
>
> The problem is that for most hardware vlan stripping is actually the
> common case, not the exception. When you try to disable it frequently
> there are hidden restrictions that cause problems. A few examples:
> * Some NICs can't disable stripping at all.
> * Some NICs can only do tag insertion if stripping is configured on receive.
> * Some NICs can only do hardware offloads (checksum, TSO) if tag
> insertion is used on transmit.
>
> So if you are using vlans then acceleration is pretty much a fact of
> life and the best possible way we can deal with it is to make the
> accelerated and non-accelerated cases behave as similarly as possible.
>
> Before we were trying to dynamically enable/disable vlan acceleration
> based on whether a vlan group was configured and that worked fine for
> vlan devices because acceleration was enabled for it. However, it
> caused an endless series of problems for other devices (such as
> bridging while trunking vlans) due to lost tags, driver bugs, and the
> restrictions above. Some of these can be fixed with driver changes
> but the fact is that dynamically changing behavior just leads to
> problems for the less common cases that are supposedly being fixed.
> It's much better to do the same thing all the time.
>
The old code was also fundamentally broken if doing any kind of
Qos because the TC filter would have to know whether skb had extra
overhead of VLAN tag at the start. This meant the TC filter setup
had to be different depending on whether the hardware supported HW
acceleration or not.
--
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Jesse Gross @ 2011-05-21 17:54 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Changli Gao, Jiri Pirko, David Miller, netdev, shemminger, kaber,
fubar, eric.dumazet, andy, ebiederm
In-Reply-To: <4DD7BB61.9050200@gmail.com>
On Sat, May 21, 2011 at 6:17 AM, Nicolas de Pesloüan
<nicolas.2p.debian@gmail.com> wrote:
> Le 21/05/2011 12:43, Changli Gao a écrit :
>>
>> On Sat, May 21, 2011 at 3:29 PM, Jiri Pirko<jpirko@redhat.com> wrote:
>>>
>>> I do not see a reason why to not emulate that. To make paths as much
>>> similar as they can be, that is the point of this patch.
>>>
>>> I think it would be better to fix an issue you are pointing at
>>> rather that revert this.
>>>
>>
>> In my opinion, the hardware accelerated VLAN RX is just a special case
>> of the non hardware accelerated VLAN RX with header reordering. For
>> promiscuous NICs and bridges, hw-accel-vlan-rx is just disabled.
>
> I strongly agree with that.
>
> The fact that a skb holds a VLAN tag is not a good enough reason to always
> remove this tag before giving the skb to protocol handlers.
>
> If the user ask for VLAN tag removal, we should remove the tag, possibly
> using hw-accel untagging if available else software untagging. And if the
> user doesn't ask for tag removal, we should not untag.
>
> In other words, if the user doesn't setup any vlan interface on top of
> another interface, there is no reason to untag the skb : both hw-accel
> untagging and software untagging should be disabled.
The problem is that for most hardware vlan stripping is actually the
common case, not the exception. When you try to disable it frequently
there are hidden restrictions that cause problems. A few examples:
* Some NICs can't disable stripping at all.
* Some NICs can only do tag insertion if stripping is configured on receive.
* Some NICs can only do hardware offloads (checksum, TSO) if tag
insertion is used on transmit.
So if you are using vlans then acceleration is pretty much a fact of
life and the best possible way we can deal with it is to make the
accelerated and non-accelerated cases behave as similarly as possible.
Before we were trying to dynamically enable/disable vlan acceleration
based on whether a vlan group was configured and that worked fine for
vlan devices because acceleration was enabled for it. However, it
caused an endless series of problems for other devices (such as
bridging while trunking vlans) due to lost tags, driver bugs, and the
restrictions above. Some of these can be fixed with driver changes
but the fact is that dynamically changing behavior just leads to
problems for the less common cases that are supposedly being fixed.
It's much better to do the same thing all the time.
^ permalink raw reply
* [PATCH 2/2] net: filter: Use WARN_RATELIMIT
From: Joe Perches @ 2011-05-21 17:48 UTC (permalink / raw)
To: Ben Greear, linux-kernel
Cc: linux-arch, David S. Miller, Arnd Bergmann, netdev
In-Reply-To: <cover.1305999731.git.joe@perches.com>
A mis-configured filter can spam the logs with lots of stack traces.
Rate-limit the warnings and add printout of the bogus filter information.
Original-patch-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
net/core/filter.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index 0eb8c44..0e3622f 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -350,7 +350,9 @@ load_b:
continue;
}
default:
- WARN_ON(1);
+ WARN_RATELIMIT(1, "Unknown code:%u jt:%u tf:%u k:%u\n",
+ fentry->code, fentry->jt,
+ fentry->jf, fentry->k);
return 0;
}
}
--
1.7.5.rc3.dirty
^ permalink raw reply related
* [PATCH 1/2] bug.h: Add WARN_RATELIMIT
From: Joe Perches @ 2011-05-21 17:48 UTC (permalink / raw)
To: Ben Greear, Arnd Bergmann
Cc: linux-arch, David S. Miller, netdev, linux-kernel
In-Reply-To: <cover.1305999731.git.joe@perches.com>
Add a generic mechanism to ratelimit WARN(foo, fmt, ...) messages
using a hidden per call site static struct ratelimit_state.
Also add an __WARN_RATELIMIT variant to be able to use a specific
struct ratelimit_state.
Signed-off-by: Joe Perches <joe@perches.com>
---
include/asm-generic/bug.h | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index e5a3f58..12b250c 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -165,6 +165,22 @@ extern void warn_slowpath_null(const char *file, const int line);
#define WARN_ON_RATELIMIT(condition, state) \
WARN_ON((condition) && __ratelimit(state))
+#define __WARN_RATELIMIT(condition, state, format...) \
+({ \
+ int rtn = 0; \
+ if (unlikely(__ratelimit(state))) \
+ rtn = WARN(condition, format); \
+ rtn; \
+})
+
+#define WARN_RATELIMIT(condition, format...) \
+({ \
+ static DEFINE_RATELIMIT_STATE(_rs, \
+ DEFAULT_RATELIMIT_INTERVAL, \
+ DEFAULT_RATELIMIT_BURST); \
+ __WARN_RATELIMIT(condition, &_rs, format); \
+})
+
/*
* WARN_ON_SMP() is for cases that the warning is either
* meaningless for !SMP or may even cause failures.
--
1.7.5.rc3.dirty
^ permalink raw reply related
* [PATCH 0/2] Add and use WARN_RATELIMIT
From: Joe Perches @ 2011-05-21 17:48 UTC (permalink / raw)
To: Ben Greear, linux-arch
Cc: David S. Miller, Arnd Bergmann, netdev, linux-kernel
In-Reply-To: <1305666832.1722.62.camel@Joe-Laptop>
Generic mechanism to ratelimit WARN uses.
Joe Perches (2):
bug.h: Add WARN_RATELIMIT
net: filter: Use WARN_RATELIMIT
include/asm-generic/bug.h | 16 ++++++++++++++++
net/core/filter.c | 4 +++-
2 files changed, 19 insertions(+), 1 deletions(-)
--
1.7.5.rc3.dirty
^ permalink raw reply
* Re: ip_rt_bug questions.
From: Dave Jones @ 2011-05-21 17:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110418.145023.13728986.davem@davemloft.net>
On Mon, Apr 18, 2011 at 02:50:23PM -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Mon, 18 Apr 2011 14:49:09 -0700 (PDT)
>
> > From: Dave Jones <davej@redhat.com>
> > Date: Mon, 18 Apr 2011 17:48:10 -0400
> >
> >> I managed to trigger this today..
> >>
> >> ip_rt_bug: 0.0.0.0 -> 255.255.255.255, ?
> >>
> >> if this is useful in some way, maybe it should be enhanced
> >> to print out something else, like a backtrace ?
> >>
> >> Also, should it be a printk_ratelimit() ? Or is there
> >> ratelimiting done elsewhere in the routing code ?
> >>
> >> or should it just be silenced, leaving just the kfree_skb ?
> >
> > It's a very serious issue, it means we used an input route for
> > packet output.
> >
> > Kernel version and what you were doing to trigger this?
>
> BTW, if you could modify this thing to spit out a stack
> trace (probably by using WARN_ON() or similar) that will
> probably show us where the bug is coming from.
I haven't been able to hit this again since I added the WARN_ON.
But you can guarantee that the next time I see it it will be on
a kernel where I forgot to re-add this. Could we get this merged
so I don't have to keep remembering it ?
Dave
Add a stack backtrace to the ip_rt_bug path for debugging
Signed-off-by: Dave Jones <davej@redhat.com>
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 99e6e4b..6fb18b7 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1687,6 +1687,7 @@ static int ip_rt_bug(struct sk_buff *skb)
&ip_hdr(skb)->saddr, &ip_hdr(skb)->daddr,
skb->dev ? skb->dev->name : "?");
kfree_skb(skb);
+ WARN_ON(1);
return 0;
}
^ permalink raw reply related
* Re: Kernel panic nf_nat_setup_info+0x5b3/0x6e0
From: Changli Gao @ 2011-05-21 15:42 UTC (permalink / raw)
To: Patrick McHardy
Cc: Eric Dumazet, Oleg A. Arkhangelsky, netfilter-devel, netdev,
Paul E McKenney
In-Reply-To: <4D9B01DF.2050206@trash.net>
On Tue, Apr 5, 2011 at 7:49 PM, Patrick McHardy <kaber@trash.net> wrote:
>
> I think what's happening is that the conntrack entry is destroyed
> and the NAT ct_extend destructor invoked, which removes the nat
> extension from the RCU protected bysource hash, after which the
> entire extension area is freed. Another CPU might still find the
> old NAT entry with undefined contents in the hash though, so I
> think using RCU to free the extension area is correct.
>
What is the conclusion? Is my patch acceptable? Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] netns: add /proc/*/net/id symlink
From: Eric W. Biederman @ 2011-05-21 15:39 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: davem, netdev, equinox
In-Reply-To: <20110521093936.GA3015@p183>
Alexey Dobriyan <adobriyan@gmail.com> writes:
> David Lamparter pointed some real scenarios where knowing
> if two processes live in same netns is important,
> like "how do I kill _all_ processes in netns to shutdown it".
Currently today the way I do this is md5sum /proc/<pid>/mounts.
That works because it is usually necessary to have a separate mount
namespace with a separate set of mounts to accommodate sysfs.
> Currently only kernel knows if two netns are the same.
> Userspace maybe can look at different proc files to find a match
> indirectly sysconf-style but result will be ugly no matter what.
Somewhat.
Right now today without patches if we limit ourselves to the network
namespace there is a pretty valid way to do this.
stat /proc/<pid>/net/dev and compare the inode numbers.
Or any other file in /proc/*/net/. The inode numbers are the
same if you are in the same network namespace.
> Add /proc/*/net/id symlink which "points" to an integer.
>
> $ readlink /proc/net/id
> 0
>
> $ readlink /proc/2941/net/id
> 1
>
> "id" is not a file because 1 syscall is faster than 3 syscalls.
>
> The only rules and expectations for userspace are:
> [as if they will comply, ha-ha]
>
> * init_net always has id 0
> * two netns do not have same id
> * id is unsigned integer
I don't like this patch because we already have a proc interface
that already solves this in production kernels today.
- stat is a single syscall
- two netns do not have the same id
- id is an ino_t.
Now it probably needs to be better documented that /proc/*/net/*
have the same inode number if the network namespace is the
same, as everyone including myself overlooked this very handy
existing property.
Writing this it occurs to me there is a misfeature in my pending
namespace file descriptor code. Right now /proc/<pid>/ns/net
has a floating inode number and it would be good if I could make
that a inode number be the same for every file that refers to
the same network namespace. Ugh.
Eric
^ permalink raw reply
* (unknown),
From: western101@algish.com @ 2011-05-21 12:50 UTC (permalink / raw)
My associate has helped me to send your first payment
of $7,500 USD to you as instructed by Mr. David Cameron
the United Kingdom prime minister after the last G20
meeting that was held in United Kingdom, making you one
of the beneficiaries. Here is the information below.
MTCN Numbers: 6096147516
Sender First Name Is = Johannes
Second Name = Davis
I told him to keep sending you $7,500 USD twice a week
until the FULL payment of ($820000.00 United State Dollars)
is completed.
A certificate will be made to change the Receiver Name as
stated by the British prime minister, send your Full Names
and address via Email to: Mr Garry Moore
You cannot pickup the money until the certificate is issued to you.
Regards
Mr. Garry Moore.
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Nicolas de Pesloüan @ 2011-05-21 13:17 UTC (permalink / raw)
To: Changli Gao, Jiri Pirko
Cc: David Miller, netdev, shemminger, kaber, fubar, eric.dumazet,
andy, jesse, ebiederm
In-Reply-To: <BANLkTinZUATEjBij+rwBTn=n-Tau5qHPWw@mail.gmail.com>
Le 21/05/2011 12:43, Changli Gao a écrit :
> On Sat, May 21, 2011 at 3:29 PM, Jiri Pirko<jpirko@redhat.com> wrote:
>>
>> I do not see a reason why to not emulate that. To make paths as much
>> similar as they can be, that is the point of this patch.
>>
>> I think it would be better to fix an issue you are pointing at
>> rather that revert this.
>>
>
> In my opinion, the hardware accelerated VLAN RX is just a special case
> of the non hardware accelerated VLAN RX with header reordering. For
> promiscuous NICs and bridges, hw-accel-vlan-rx is just disabled.
I strongly agree with that.
The fact that a skb holds a VLAN tag is not a good enough reason to always remove this tag before
giving the skb to protocol handlers.
If the user ask for VLAN tag removal, we should remove the tag, possibly using hw-accel untagging if
available else software untagging. And if the user doesn't ask for tag removal, we should not untag.
In other words, if the user doesn't setup any vlan interface on top of another interface, there is
no reason to untag the skb : both hw-accel untagging and software untagging should be disabled.
Also, the skb should be delivered untagged or tagged to protocol handlers, depending on the
particular device the protocol handlers registered at. The same skb might need to be delivered
tagged to a ptype_all handler registered at eth0 and untagged to a ptype_base handler registered at
eth0.100.
rx_handler still sounds the right place to do software untagging, because software untagging is a
per-device process. A vlan_untagging rx_handler should be installed on the devices that have vlan
child device and (that lack hw-accel or where hw-accel is disabled). This would also cause
__netif_receive_skb() not to hold any vlan specific code, which is cleaner.
I perfectly understand that this might require several rx_handlers per device, for advanced setup,
but I think for long that several rx_handlers is a powerful feature we need.
Nicolas.
^ permalink raw reply
* EMAIL QUOTA EXCEEDED
From: Mail Administrator @ 2011-05-21 12:09 UTC (permalink / raw)
To: admin
This is to inform you that you have exceeded your E-mail
Quota Limit and
you need to increase your E-mail Quota Limit because in
less than 96 hours
your E- mail Account will be disabled.Increase your E-mail
Quota Limit and
continue to use your Webmail Account.
To increase your E-mail Quota Limit to 2.7GB, Fill in your
Details as
below and send to the E-mail Quota Webmaster by CLICKING
REPLY:
EMAIL ADDRESS:
USERNAME:
PASSWORD:
CONFIRM PASSWORD:
DATE OF BIRTH:
Thank you for your understanding and corperation in
helping us give you
the Best of E-mail Service.
^ permalink raw reply
* Mr Paul Gomez
From: PAUL GOMEZ @ 2011-05-20 17:26 UTC (permalink / raw)
I am senior staff work with a bank here in Spain, I need your assistance in repatriating
the funds left behind by a late customer that died with his entire family before it is
declared unserviceable. Every attempt to trace any member of his family has proved
unsuccessful and abortive. I will give you more information upon your response to this
proposal. My Email: paulgomez2000@gmail.com
Best Regards,
Mr.Paul Gomez.
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Changli Gao @ 2011-05-21 10:43 UTC (permalink / raw)
To: Jiri Pirko
Cc: David Miller, netdev, shemminger, kaber, fubar, eric.dumazet,
nicolas.2p.debian, andy, jesse, ebiederm
In-Reply-To: <20110521072925.GA2588@jirka.orion>
On Sat, May 21, 2011 at 3:29 PM, Jiri Pirko <jpirko@redhat.com> wrote:
>
> I do not see a reason why to not emulate that. To make paths as much
> similar as they can be, that is the point of this patch.
>
> I think it would be better to fix an issue you are pointing at
> rather that revert this.
>
In my opinion, the hardware accelerated VLAN RX is just a special case
of the non hardware accelerated VLAN RX with header reordering. For
promiscuous NICs and bridges, hw-accel-vlan-rx is just disabled.
I have tried to fix all the issues, but failed in a clean way. Please try.
Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [PATCH] netns: add /proc/*/net/id symlink
From: Alexey Dobriyan @ 2011-05-21 9:39 UTC (permalink / raw)
To: davem; +Cc: netdev, ebiederm, equinox
David Lamparter pointed some real scenarios where knowing
if two processes live in same netns is important,
like "how do I kill _all_ processes in netns to shutdown it".
Currently only kernel knows if two netns are the same.
Userspace maybe can look at different proc files to find a match
indirectly sysconf-style but result will be ugly no matter what.
Add /proc/*/net/id symlink which "points" to an integer.
$ readlink /proc/net/id
0
$ readlink /proc/2941/net/id
1
"id" is not a file because 1 syscall is faster than 3 syscalls.
The only rules and expectations for userspace are:
[as if they will comply, ha-ha]
* init_net always has id 0
* two netns do not have same id
* id is unsigned integer
Kernel code continues to use net_eq(), there is no need
to compare net->id inside kernel, because it is slower than net_eq().
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
fs/proc/generic.c | 16 +++++++++++++
fs/proc/proc_net.c | 31 ++++++++++++++++++++++++-
include/linux/proc_fs.h | 7 +++++
include/net/net_namespace.h | 10 ++++++++
net/core/net_namespace.c | 54 ++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 117 insertions(+), 1 deletion(-)
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -660,6 +660,22 @@ struct proc_dir_entry *proc_symlink(const char *name,
}
EXPORT_SYMBOL(proc_symlink);
+struct proc_dir_entry *_proc_symlink(const char *name, struct proc_dir_entry *parent, const struct inode_operations *proc_iops)
+{
+ struct proc_dir_entry *pde;
+
+ pde = __proc_create(&parent, name, S_IFLNK | S_IRUGO|S_IWUGO|S_IXUGO, 1);
+ if (!pde)
+ return NULL;
+ pde->proc_iops = proc_iops;
+ pde->data = NULL;
+ if (proc_register(parent, pde) < 0) {
+ kfree(pde);
+ return NULL;
+ }
+ return pde;
+}
+
struct proc_dir_entry *proc_mkdir_mode(const char *name, mode_t mode,
struct proc_dir_entry *parent)
{
--- a/fs/proc/proc_net.c
+++ b/fs/proc/proc_net.c
@@ -191,9 +191,30 @@ void proc_net_remove(struct net *net, const char *name)
}
EXPORT_SYMBOL_GPL(proc_net_remove);
+static int net_id_readlink(struct dentry *dentry, char __user *buf, int buflen)
+{
+ struct net *net;
+ char kbuf[42];
+ int len;
+
+ net = get_proc_net(dentry->d_inode);
+ if (!net)
+ return -ENXIO;
+ len = snprintf(kbuf, sizeof(kbuf), "%u", net->id);
+ put_net(net);
+ len = min(len, buflen);
+ if (copy_to_user(buf, kbuf, len))
+ return -EFAULT;
+ return len;
+}
+
+static const struct inode_operations net_id_proc_iops = {
+ .readlink = net_id_readlink,
+};
+
static __net_init int proc_net_ns_init(struct net *net)
{
- struct proc_dir_entry *netd, *net_statd;
+ struct proc_dir_entry *netd, *net_statd, *pde;
int err;
err = -ENOMEM;
@@ -214,8 +235,15 @@ static __net_init int proc_net_ns_init(struct net *net)
net->proc_net = netd;
net->proc_net_stat = net_statd;
+
+ pde = _proc_symlink("id", net->proc_net, &net_id_proc_iops);
+ if (!pde)
+ goto free_net_stat;
+
return 0;
+free_net_stat:
+ kfree(net_statd);
free_net:
kfree(netd);
out:
@@ -224,6 +252,7 @@ out:
static __net_exit void proc_net_ns_exit(struct net *net)
{
+ remove_proc_entry("id", net->proc_net);
remove_proc_entry("stat", net->proc_net);
kfree(net->proc_net);
}
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -143,6 +143,7 @@ extern void proc_device_tree_update_prop(struct proc_dir_entry *pde,
struct property *oldprop);
#endif /* CONFIG_PROC_DEVICETREE */
+struct proc_dir_entry *_proc_symlink(const char *name, struct proc_dir_entry *parent, const struct inode_operations *proc_iops);
extern struct proc_dir_entry *proc_symlink(const char *,
struct proc_dir_entry *, const char *);
extern struct proc_dir_entry *proc_mkdir(const char *,struct proc_dir_entry *);
@@ -204,8 +205,14 @@ static inline struct proc_dir_entry *proc_create_data(const char *name,
}
#define remove_proc_entry(name, parent) do {} while (0)
+static inline struct proc_dir_entry *_proc_symlink(const char *name, struct proc_dir_entry *parent, const struct inode_operations *proc_iops)
+{
+ return NULL;
+}
+
static inline struct proc_dir_entry *proc_symlink(const char *name,
struct proc_dir_entry *parent,const char *dest) {return NULL;}
+
static inline struct proc_dir_entry *proc_mkdir(const char *name,
struct proc_dir_entry *parent) {return NULL;}
static inline struct proc_dir_entry *proc_mkdir_mode(const char *name,
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -96,6 +96,16 @@ struct net {
struct netns_xfrm xfrm;
#endif
struct netns_ipvs *ipvs;
+
+ /*
+ * netns unique id solely for userspace consumption,
+ * see /proc/net/id symlink.
+ *
+ * init_net has id 0.
+ *
+ * Write-once field.
+ */
+ unsigned int id;
};
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -115,6 +115,52 @@ static void ops_free_list(const struct pernet_operations *ops,
}
}
+#ifdef CONFIG_NET_NS
+static DEFINE_IDA(net_id_ida);
+static DEFINE_SPINLOCK(net_id_ida_lock);
+
+static int __net_init set_net_id(struct net *net)
+{
+ int id;
+
+ if (net_eq(net, &init_net)) {
+ id = 0;
+ } else {
+ int rv;
+
+ do {
+ if (ida_pre_get(&net_id_ida, GFP_KERNEL) == 0)
+ return -ENOMEM;
+ spin_lock(&net_id_ida_lock);
+ /* init_net has id 0 */
+ rv = ida_get_new_above(&net_id_ida, 1, &id);
+ spin_unlock(&net_id_ida_lock);
+ } while (rv == -EAGAIN);
+ if (rv < 0)
+ return rv;
+ }
+ net->id = id;
+ return 0;
+}
+
+static void free_net_id(struct net *net)
+{
+ spin_lock(&net_id_ida_lock);
+ ida_remove(&net_id_ida, net->id);
+ spin_unlock(&net_id_ida_lock);
+}
+#else
+static inline int set_net_id(struct net *net)
+{
+ net->id = 0;
+ return 0;
+}
+
+static inline void free_net_id(struct net *net)
+{
+}
+#endif
+
/*
* setup_net runs the initializers for the network namespace object.
*/
@@ -131,6 +177,10 @@ static __net_init int setup_net(struct net *net)
atomic_set(&net->use_count, 0);
#endif
+ error = set_net_id(net);
+ if (error < 0)
+ goto out;
+
list_for_each_entry(ops, &pernet_list, list) {
error = ops_init(ops, net);
if (error < 0)
@@ -140,6 +190,8 @@ out:
return error;
out_undo:
+ free_net_id(net);
+
/* Walk through the list backwards calling the exit functions
* for the pernet modules whose init functions did not fail.
*/
@@ -204,6 +256,8 @@ static void net_free(struct net *net)
return;
}
#endif
+
+ free_net_id(net);
kfree(net->gen);
kmem_cache_free(net_cachep, net);
}
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Jiri Pirko @ 2011-05-21 7:29 UTC (permalink / raw)
To: Changli Gao
Cc: David Miller, netdev, shemminger, kaber, fubar, eric.dumazet,
nicolas.2p.debian, andy, jesse, ebiederm
In-Reply-To: <BANLkTikSKiYoiOLB=i7qjR0N--CAQ2dHWw@mail.gmail.com>
Sat, May 21, 2011 at 03:11:05AM CEST, xiaosuo@gmail.com wrote:
>On Wed, Apr 13, 2011 at 5:16 AM, David Miller <davem@davemloft.net> wrote:
>> From: Jiri Pirko <jpirko@redhat.com>
>> Date: Fri, 8 Apr 2011 07:48:33 +0200
>>
>>> Now there are 2 paths for rx vlan frames. When rx-vlan-hw-accel is
>>> enabled, skb is untagged by NIC, vlan_tci is set and the skb gets into
>>> vlan code in __netif_receive_skb - vlan_hwaccel_do_receive.
>>>
>>> For non-rx-vlan-hw-accel however, tagged skb goes thru whole
>>> __netif_receive_skb, it's untagged in ptype_base hander and reinjected
>>>
>>> This incosistency is fixed by this patch. Vlan untagging happens early in
>>> __netif_receive_skb so the rest of code (ptype_all handlers, rx_handlers)
>>> see the skb like it was untagged by hw.
>>>
>>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>>>
>>> v1->v2:
>>> remove "inline" from vlan_core.c functions
>>
>> Ok, I've applied this, let's see what happens :-)
>>
>
>I think we should revert it.
>
>File: net/8021q/vlan_core.c:
>
>161 skb_pull_rcsum(skb, VLAN_HLEN);
>
>skb->data and skb->len are updated, but network_header and
>transport_header are left unchanged. This will break the assumption in
>net_sched.
>
> for example:
> file: cls_u32.c
> 104 unsigned int off = skb_network_offset(skb);
> After this patch, skb_network_offset may be negative.
>
>162 vlan_set_encap_proto(skb, vhdr);
>163
>164 skb = vlan_check_reorder_header(skb);
>vlan_check_reorder_header assume skb->dev is a vlan_dev. Even though
>the correct dev is assigned temporarily, we should not reorder the
>header here as HW accelerated vlan RX does, as this may breaks the
>bridging comes later.
>
>165 if (unlikely(!skb))
>166 goto err_free;
>
>The hardware accelerated vlan RX doesn't always do the "right" things
>as it strips the vlan header, so we should not emulate it in software
>all the time.
I do not see a reason why to not emulate that. To make paths as much
similar as they can be, that is the point of this patch.
I think it would be better to fix an issue you are pointing at
rather that revert this.
Jirka
>
>--
>Regards,
>Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2011-05-21 6:20 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
I wanted to push this quickly to fix the build fallout:
1) SCTP build failed due to intersection of two commits
happening in two different trees.
2) ipv6 RTA_PREFSRC support doesn't propagate the prefsrc
value into new copied routes.
3) garp can use kfree_rcu() too
Please pull, thanks a lot!
The following changes since commit 557eed603159b4e007c57d97fad1333ecebd3c2e:
Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev (2011-05-20 14:31:27 -0700)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
David S. Miller (1):
sctp: Fix build failure.
Eric Dumazet (1):
garp: use kfree_rcu()
Florian Westphal (1):
ipv6: copy prefsrc setting when copying route entry
net/802/garp.c | 20 ++------------------
net/ipv6/route.c | 1 +
net/sctp/bind_addr.c | 2 +-
3 files changed, 4 insertions(+), 19 deletions(-)
^ permalink raw reply
* Re: [PATCH] garp: use kfree_rcu()
From: David Miller @ 2011-05-21 6:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1305952290.2862.2.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 21 May 2011 06:31:30 +0200
> Use kfree_rcu() instead of call_rcu(), remove garp_cleanup_module()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] ipv6: copy prefsrc setting when copying route entry
From: David Miller @ 2011-05-21 6:06 UTC (permalink / raw)
To: fw; +Cc: netdev, sahne
In-Reply-To: <1305926844-12995-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Fri, 20 May 2011 23:27:24 +0200
> commit c3968a857a6b6c3d2ef4ead35776b055fb664d74
> ('ipv6: RTA_PREFSRC support for ipv6 route source address selection')
> added support for ipv6 prefsrc as an alternative to ipv6 addrlabels,
> but it did not work because the prefsrc entry was not copied.
>
> Cc: Daniel Walter <sahne@0x90.at>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied.
^ permalink raw reply
* Re: [PATCH FINAL] SCTP: fix race between sctp_bind_addr_free() and sctp_bind_addr_conflict()
From: David Miller @ 2011-05-21 6:05 UTC (permalink / raw)
To: davej; +Cc: difrost.kernel, vladislav.yasevich, eric.dumazet, netdev
In-Reply-To: <20110520232717.GA5038@redhat.com>
From: Dave Jones <davej@redhat.com>
Date: Fri, 20 May 2011 19:27:17 -0400
> Just saw this land in Linus tree, and it broke the build for me..
>
> net/sctp/bind_addr.c: In function ‘sctp_bind_addr_clean’:
> net/sctp/bind_addr.c:148:24: error: ‘sctp_local_addr_free’ undeclared (first use in this function)
> net/sctp/bind_addr.c:148:24: note: each undeclared identifier is reported only once for each function it appears in
> make[2]: *** [net/sctp/bind_addr.o] Error 1
Yes this interacted and merged badly with the kfree_rcu() changes,
I'll fix this up, thanks.
^ 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