* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Michał Mirosław @ 2011-05-22 10:04 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jiri Pirko, Eric W. Biederman, Jesse Gross, Changli Gao,
David Miller, netdev, shemminger, kaber, fubar, eric.dumazet,
andy
In-Reply-To: <4DD8DD06.6070202@gmail.com>
2011/5/22 Nicolas de Pesloüan <nicolas.2p.debian@gmail.com>:
> Le 22/05/2011 11:36, Jiri Pirko a écrit :
>> Sun, May 22, 2011 at 11:20:09AM CEST, mirqus@gmail.com wrote:
>>> W dniu 22 maja 2011 11:10 użytkownik Nicolas de Pesloüan
>>> <nicolas.2p.debian@gmail.com> napisał:
>>>> Le 22/05/2011 10:52, Michał Mirosław a écrit :
>>>>> I assumed that this untaging Jiri is implementing does not remove the
>>>>> tag. It moves the information from skb->data to skb->vlan_tci, but the
>>>>> information contained is not otherwise changing. All your examples
>>>>> should work regardless of where the tag is stored.
>>>> I assumed (but didn't tested) that this untagging also change the
>>>> starting
>>>> point of the payload of the packet. So protocol handlers expecting to
>>>> have
>>>> the raw packet won't see the vlan header.
>>> That would also be the case with hardware stripped tags - they need to
>>> look into skb->vlan_tci anyway.
>> Exactly. Nicolas, I do not see anything wrong on always untagging in all
>> your setups. As Michal said, vlan_tci keeps the info.
>
> I understand this.
>
> But I don't understand how the bridge code is expected to know whether it
> should re-tag the packet or not before forwarding and which value to use as
> the egress vlan tag.
>
> 1/ eth0 - br0 - eth1 : the bridge is expected to retag using skb->vlan_tci
> value.
>
> 2/ eth0 - eth0.100 - br0 - eth1.200 - eth1 : the bridge is expected to retag
> using a different value than skb->vlan_tci.
> 3/ eth0 - eth0.100 - br0 - eth1 : the bridge is expected not to re-tag,
> because the expected behavior of this setup is to untag while crossing the
> bridge.
>
> 4/ eth0 - eth0.100 - eth0.100.300 - br0 - eth1.400 - eth1.200 - eth1 : the
> bridge is expected to retag using a different value than skb->vlan_tci. What
> value would skb->vlan_tci hold when the skb will be delivered to the bridge?
> 100 or 300?
>
> From my point of view, in both setup, the bridge will receive a single value
> in skb->vlan_tci and will lack any other indication to help it decide how to
> retag when forwarding.
Packets looking like they came from eth0.100 will have skb->vlan_tci
cleared (like taking packet out of a tunnel) and then possibly filled
again with inner tag. It's really convenient to thing of VLANs as
tunnels.
Best Regards,
Michał Mirosław
^ 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-22 9:53 UTC (permalink / raw)
To: Jiri Pirko
Cc: Michał Mirosław, Eric W. Biederman, Jesse Gross,
Changli Gao, David Miller, netdev, shemminger, kaber, fubar,
eric.dumazet, andy
In-Reply-To: <20110522093614.GB2611@jirka.orion>
Le 22/05/2011 11:36, Jiri Pirko a écrit :
> Sun, May 22, 2011 at 11:20:09AM CEST, mirqus@gmail.com wrote:
>> W dniu 22 maja 2011 11:10 użytkownik Nicolas de Pesloüan
>> <nicolas.2p.debian@gmail.com> napisał:
>>> Le 22/05/2011 10:52, Michał Mirosław a écrit :
>>>>
>>>> 2011/5/22 Nicolas de Pesloüan<nicolas.2p.debian@gmail.com>:
>>>>>
>>>>> Le 22/05/2011 08:34, Eric W. Biederman a écrit :
>>>>>>
>>>>>> Jiri Pirko<jpirko@redhat.com> writes:
>>>>>>
>>>>>>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com
>>>>>>> wrote:
>>>>>>>
>>>>>>> <snip>
>>>>>>>>
>>>>>>>> And because some setups may still require the skb not to be untagged,
>>>>>>>> may be we need the ability to re-tag the skb in some situations...
>>>>>>>> When a protocol handler or rx_handler is explicitly registered on a
>>>>>>>> net_device which expect to receive tagged skb, we should deliver
>>>>>>>> tagged skb to it... Arguably, this may sound incredible for the
>>>>>>>> general case, but may be required for not-so-special cases like
>>>>>>>> bridge or protocol analyzer.
>>>>>>>
>>>>>>> Wait, what setups/code require the skb not to be untagged? If there's
>>>>>>> such, it should be fixed.
>>>>>>
>>>>>> tcpdump on the non-vlan interface for one.
>>>>>
>>>>> bridge is another. More precisely, there is a difference between the
>>>>> following two setups:
>>>>>
>>>>> 1/ eth0 - eth0.100 - br0 - eth1.200 - eth1
>>>>>
>>>>> 2/ eth0 - br0 - eth1
>>>>>
>>>>> In case 1, it is normal and desirable for the bridge to see untagged skb.
>>>>>
>>>>> In case 2, it is desirable for the bridge to see untouched (possibly
>>>>> tagged)
>>>>> skb. If current bridge implementation is able to handle skb from which we
>>>>> removed a tag, in this situation, it means that bridge currently "fix
>>>>> improper untagging" by itself, by forcing re-tagging on output. I think
>>>>> is
>>>>> should not be the job of protocol handlers to fix this. Again, a generic
>>>>> feature should to it when necessary.
>>>>>
>>>>> Think of the following setups:
>>>>>
>>>>> 3/ eth0 - br0 - eth1.200 - eth1.
>>>>> 4/ eth0 - eth0.100 - br0 - eth1
>>>>>
>>>>> What if one expect this setup to add (3) or remove (4) one level of vlan
>>>>> nesting? This is precisely what this setup suggest. How can we instruct
>>>>> the
>>>>> bridge to do so? It is not the bridge responsibility to do any vlan
>>>>> processing. bridge is expected to... bridge !
>>>>
>>>> I assumed that this untaging Jiri is implementing does not remove the
>>>> tag. It moves the information from skb->data to skb->vlan_tci, but the
>>>> information contained is not otherwise changing. All your examples
>>>> should work regardless of where the tag is stored.
>>>
>>> I assumed (but didn't tested) that this untagging also change the starting
>>> point of the payload of the packet. So protocol handlers expecting to have
>>> the raw packet won't see the vlan header.
>>
>> That would also be the case with hardware stripped tags - they need to
>> look into skb->vlan_tci anyway.
>
> Exactly. Nicolas, I do not see anything wrong on always untagging in all
> your setups. As Michal said, vlan_tci keeps the info.
I understand this.
But I don't understand how the bridge code is expected to know whether it should re-tag the packet
or not before forwarding and which value to use as the egress vlan tag.
1/ eth0 - br0 - eth1 : the bridge is expected to retag using skb->vlan_tci value.
2/ eth0 - eth0.100 - br0 - eth1.200 - eth1 : the bridge is expected to retag using a different value
than skb->vlan_tci.
3/ eth0 - eth0.100 - br0 - eth1 : the bridge is expected not to re-tag, because the expected
behavior of this setup is to untag while crossing the bridge.
4/ eth0 - eth0.100 - eth0.100.300 - br0 - eth1.400 - eth1.200 - eth1 : the bridge is expected to
retag using a different value than skb->vlan_tci. What value would skb->vlan_tci hold when the skb
will be delivered to the bridge? 100 or 300?
From my point of view, in both setup, the bridge will receive a single value in skb->vlan_tci and
will lack any other indication to help it decide how to retag when forwarding.
I'm not against your idea to mimic hw-accel in software. But I'm concern about troubles for those
who expect to have access to untouched packet. Your patch didn't cause those troubles to start
happening, but cause them to always happen. Before your patch, someone had the option to use
non-hw-accel NIC or to disable hw-accel feature if possible. Now, it's no more possible.
Nicolas.
^ 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-22 9:37 UTC (permalink / raw)
To: Changli Gao
Cc: Nicolas de Pesloüan, Jesse Gross, David Miller, netdev,
shemminger, kaber, fubar, eric.dumazet, andy, ebiederm
In-Reply-To: <BANLkTinEnHLx1CVh8p0ejLkcaqoLHw2nOA@mail.gmail.com>
Sun, May 22, 2011 at 10:38:45AM CEST, xiaosuo@gmail.com wrote:
>On Sun, May 22, 2011 at 2:29 PM, Jiri Pirko <jpirko@redhat.com> wrote:
>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
>>
>> <snip>
>>>
>>>And because some setups may still require the skb not to be untagged,
>>>may be we need the ability to re-tag the skb in some situations...
>>>When a protocol handler or rx_handler is explicitly registered on a
>>>net_device which expect to receive tagged skb, we should deliver
>>>tagged skb to it... Arguably, this may sound incredible for the
>>>general case, but may be required for not-so-special cases like
>>>bridge or protocol analyzer.
>>
>> Wait, what setups/code require the skb not to be untagged? If there's
>> such, it should be fixed.
>>
>
>For a transparent bridge with ports: eth0 and eth1, the vlan tags
>need to be preserved.
Yet they are - in skb->vlan_tci. I see no problem here. It's the same as
if the NIC does hw-untagging itself.
Jirka
>
>--
>Regards,
>Changli Gao(xiaosuo@gmail.com)
^ 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-22 9:36 UTC (permalink / raw)
To: Michał Mirosław
Cc: Nicolas de Pesloüan, Eric W. Biederman, Jesse Gross,
Changli Gao, David Miller, netdev, shemminger, kaber, fubar,
eric.dumazet, andy
In-Reply-To: <BANLkTimQ6LAWbZMCjBhqA5By8jvxwnfjVg@mail.gmail.com>
Sun, May 22, 2011 at 11:20:09AM CEST, mirqus@gmail.com wrote:
>W dniu 22 maja 2011 11:10 użytkownik Nicolas de Pesloüan
><nicolas.2p.debian@gmail.com> napisał:
>> Le 22/05/2011 10:52, Michał Mirosław a écrit :
>>>
>>> 2011/5/22 Nicolas de Pesloüan<nicolas.2p.debian@gmail.com>:
>>>>
>>>> Le 22/05/2011 08:34, Eric W. Biederman a écrit :
>>>>>
>>>>> Jiri Pirko<jpirko@redhat.com> writes:
>>>>>
>>>>>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com
>>>>>> wrote:
>>>>>>
>>>>>> <snip>
>>>>>>>
>>>>>>> And because some setups may still require the skb not to be untagged,
>>>>>>> may be we need the ability to re-tag the skb in some situations...
>>>>>>> When a protocol handler or rx_handler is explicitly registered on a
>>>>>>> net_device which expect to receive tagged skb, we should deliver
>>>>>>> tagged skb to it... Arguably, this may sound incredible for the
>>>>>>> general case, but may be required for not-so-special cases like
>>>>>>> bridge or protocol analyzer.
>>>>>>
>>>>>> Wait, what setups/code require the skb not to be untagged? If there's
>>>>>> such, it should be fixed.
>>>>>
>>>>> tcpdump on the non-vlan interface for one.
>>>>
>>>> bridge is another. More precisely, there is a difference between the
>>>> following two setups:
>>>>
>>>> 1/ eth0 - eth0.100 - br0 - eth1.200 - eth1
>>>>
>>>> 2/ eth0 - br0 - eth1
>>>>
>>>> In case 1, it is normal and desirable for the bridge to see untagged skb.
>>>>
>>>> In case 2, it is desirable for the bridge to see untouched (possibly
>>>> tagged)
>>>> skb. If current bridge implementation is able to handle skb from which we
>>>> removed a tag, in this situation, it means that bridge currently "fix
>>>> improper untagging" by itself, by forcing re-tagging on output. I think
>>>> is
>>>> should not be the job of protocol handlers to fix this. Again, a generic
>>>> feature should to it when necessary.
>>>>
>>>> Think of the following setups:
>>>>
>>>> 3/ eth0 - br0 - eth1.200 - eth1.
>>>> 4/ eth0 - eth0.100 - br0 - eth1
>>>>
>>>> What if one expect this setup to add (3) or remove (4) one level of vlan
>>>> nesting? This is precisely what this setup suggest. How can we instruct
>>>> the
>>>> bridge to do so? It is not the bridge responsibility to do any vlan
>>>> processing. bridge is expected to... bridge !
>>>
>>> I assumed that this untaging Jiri is implementing does not remove the
>>> tag. It moves the information from skb->data to skb->vlan_tci, but the
>>> information contained is not otherwise changing. All your examples
>>> should work regardless of where the tag is stored.
>>
>> I assumed (but didn't tested) that this untagging also change the starting
>> point of the payload of the packet. So protocol handlers expecting to have
>> the raw packet won't see the vlan header.
>
>That would also be the case with hardware stripped tags - they need to
>look into skb->vlan_tci anyway.
Exactly. Nicolas, I do not see anything wrong on always untagging in all
your setups. As Michal said, vlan_tci keeps the info.
Jirka
>
>Best Regards,
>Michał Mirosław
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Michał Mirosław @ 2011-05-22 9:20 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jiri Pirko, Eric W. Biederman, Jesse Gross, Changli Gao,
David Miller, netdev, shemminger, kaber, fubar, eric.dumazet,
andy
In-Reply-To: <4DD8D2FE.4080204@gmail.com>
W dniu 22 maja 2011 11:10 użytkownik Nicolas de Pesloüan
<nicolas.2p.debian@gmail.com> napisał:
> Le 22/05/2011 10:52, Michał Mirosław a écrit :
>>
>> 2011/5/22 Nicolas de Pesloüan<nicolas.2p.debian@gmail.com>:
>>>
>>> Le 22/05/2011 08:34, Eric W. Biederman a écrit :
>>>>
>>>> Jiri Pirko<jpirko@redhat.com> writes:
>>>>
>>>>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com
>>>>> wrote:
>>>>>
>>>>> <snip>
>>>>>>
>>>>>> And because some setups may still require the skb not to be untagged,
>>>>>> may be we need the ability to re-tag the skb in some situations...
>>>>>> When a protocol handler or rx_handler is explicitly registered on a
>>>>>> net_device which expect to receive tagged skb, we should deliver
>>>>>> tagged skb to it... Arguably, this may sound incredible for the
>>>>>> general case, but may be required for not-so-special cases like
>>>>>> bridge or protocol analyzer.
>>>>>
>>>>> Wait, what setups/code require the skb not to be untagged? If there's
>>>>> such, it should be fixed.
>>>>
>>>> tcpdump on the non-vlan interface for one.
>>>
>>> bridge is another. More precisely, there is a difference between the
>>> following two setups:
>>>
>>> 1/ eth0 - eth0.100 - br0 - eth1.200 - eth1
>>>
>>> 2/ eth0 - br0 - eth1
>>>
>>> In case 1, it is normal and desirable for the bridge to see untagged skb.
>>>
>>> In case 2, it is desirable for the bridge to see untouched (possibly
>>> tagged)
>>> skb. If current bridge implementation is able to handle skb from which we
>>> removed a tag, in this situation, it means that bridge currently "fix
>>> improper untagging" by itself, by forcing re-tagging on output. I think
>>> is
>>> should not be the job of protocol handlers to fix this. Again, a generic
>>> feature should to it when necessary.
>>>
>>> Think of the following setups:
>>>
>>> 3/ eth0 - br0 - eth1.200 - eth1.
>>> 4/ eth0 - eth0.100 - br0 - eth1
>>>
>>> What if one expect this setup to add (3) or remove (4) one level of vlan
>>> nesting? This is precisely what this setup suggest. How can we instruct
>>> the
>>> bridge to do so? It is not the bridge responsibility to do any vlan
>>> processing. bridge is expected to... bridge !
>>
>> I assumed that this untaging Jiri is implementing does not remove the
>> tag. It moves the information from skb->data to skb->vlan_tci, but the
>> information contained is not otherwise changing. All your examples
>> should work regardless of where the tag is stored.
>
> I assumed (but didn't tested) that this untagging also change the starting
> point of the payload of the packet. So protocol handlers expecting to have
> the raw packet won't see the vlan header.
That would also be the case with hardware stripped tags - they need to
look into skb->vlan_tci anyway.
Best Regards,
Michał Mirosław
^ 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-22 9:10 UTC (permalink / raw)
To: Michał Mirosław
Cc: Jiri Pirko, Eric W. Biederman, Jesse Gross, Changli Gao,
David Miller, netdev, shemminger, kaber, fubar, eric.dumazet,
andy
In-Reply-To: <BANLkTi=B4c-A9ZC2apE+ZOQmgdzaJb0oEQ@mail.gmail.com>
Le 22/05/2011 10:52, Michał Mirosław a écrit :
> 2011/5/22 Nicolas de Pesloüan<nicolas.2p.debian@gmail.com>:
>> Le 22/05/2011 08:34, Eric W. Biederman a écrit :
>>>
>>> Jiri Pirko<jpirko@redhat.com> writes:
>>>
>>>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
>>>>
>>>> <snip>
>>>>>
>>>>> And because some setups may still require the skb not to be untagged,
>>>>> may be we need the ability to re-tag the skb in some situations...
>>>>> When a protocol handler or rx_handler is explicitly registered on a
>>>>> net_device which expect to receive tagged skb, we should deliver
>>>>> tagged skb to it... Arguably, this may sound incredible for the
>>>>> general case, but may be required for not-so-special cases like
>>>>> bridge or protocol analyzer.
>>>>
>>>> Wait, what setups/code require the skb not to be untagged? If there's
>>>> such, it should be fixed.
>>>
>>> tcpdump on the non-vlan interface for one.
>> bridge is another. More precisely, there is a difference between the
>> following two setups:
>>
>> 1/ eth0 - eth0.100 - br0 - eth1.200 - eth1
>>
>> 2/ eth0 - br0 - eth1
>>
>> In case 1, it is normal and desirable for the bridge to see untagged skb.
>>
>> In case 2, it is desirable for the bridge to see untouched (possibly tagged)
>> skb. If current bridge implementation is able to handle skb from which we
>> removed a tag, in this situation, it means that bridge currently "fix
>> improper untagging" by itself, by forcing re-tagging on output. I think is
>> should not be the job of protocol handlers to fix this. Again, a generic
>> feature should to it when necessary.
>>
>> Think of the following setups:
>>
>> 3/ eth0 - br0 - eth1.200 - eth1.
>> 4/ eth0 - eth0.100 - br0 - eth1
>>
>> What if one expect this setup to add (3) or remove (4) one level of vlan
>> nesting? This is precisely what this setup suggest. How can we instruct the
>> bridge to do so? It is not the bridge responsibility to do any vlan
>> processing. bridge is expected to... bridge !
>
> I assumed that this untaging Jiri is implementing does not remove the
> tag. It moves the information from skb->data to skb->vlan_tci, but the
> information contained is not otherwise changing. All your examples
> should work regardless of where the tag is stored.
I assumed (but didn't tested) that this untagging also change the starting point of the payload of
the packet. So protocol handlers expecting to have the raw packet won't see the vlan header.
Nicolas.
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Michał Mirosław @ 2011-05-22 8:52 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jiri Pirko, Eric W. Biederman, Jesse Gross, Changli Gao,
David Miller, netdev, shemminger, kaber, fubar, eric.dumazet,
andy
In-Reply-To: <4DD8CA87.8040905@gmail.com>
2011/5/22 Nicolas de Pesloüan <nicolas.2p.debian@gmail.com>:
> Le 22/05/2011 08:34, Eric W. Biederman a écrit :
>>
>> Jiri Pirko<jpirko@redhat.com> writes:
>>
>>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
>>>
>>> <snip>
>>>>
>>>> And because some setups may still require the skb not to be untagged,
>>>> may be we need the ability to re-tag the skb in some situations...
>>>> When a protocol handler or rx_handler is explicitly registered on a
>>>> net_device which expect to receive tagged skb, we should deliver
>>>> tagged skb to it... Arguably, this may sound incredible for the
>>>> general case, but may be required for not-so-special cases like
>>>> bridge or protocol analyzer.
>>>
>>> Wait, what setups/code require the skb not to be untagged? If there's
>>> such, it should be fixed.
>>
>> tcpdump on the non-vlan interface for one.
> bridge is another. More precisely, there is a difference between the
> following two setups:
>
> 1/ eth0 - eth0.100 - br0 - eth1.200 - eth1
>
> 2/ eth0 - br0 - eth1
>
> In case 1, it is normal and desirable for the bridge to see untagged skb.
>
> In case 2, it is desirable for the bridge to see untouched (possibly tagged)
> skb. If current bridge implementation is able to handle skb from which we
> removed a tag, in this situation, it means that bridge currently "fix
> improper untagging" by itself, by forcing re-tagging on output. I think is
> should not be the job of protocol handlers to fix this. Again, a generic
> feature should to it when necessary.
>
> Think of the following setups:
>
> 3/ eth0 - br0 - eth1.200 - eth1.
> 4/ eth0 - eth0.100 - br0 - eth1
>
> What if one expect this setup to add (3) or remove (4) one level of vlan
> nesting? This is precisely what this setup suggest. How can we instruct the
> bridge to do so? It is not the bridge responsibility to do any vlan
> processing. bridge is expected to... bridge !
I assumed that this untaging Jiri is implementing does not remove the
tag. It moves the information from skb->data to skb->vlan_tci, but the
information contained is not otherwise changing. All your examples
should work regardless of where the tag is stored.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [GIT PULL] Namespace file descriptors for 2.6.40
From: Ingo Molnar @ 2011-05-22 8:42 UTC (permalink / raw)
To: James Bottomley
Cc: Eric W. Biederman, Linus Torvalds, linux-kernel, Linux Containers,
netdev, Geert Uytterhoeven
In-Reply-To: <1306048393.4092.8.camel@mulgrave.site>
* James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> Traditionally, the arch trees tend to go a bit later because they wait to see
> if there's any fallout from x86; [...]
Not really - most of the arch trees 'traditionally' went late even when the x86
tree itself was monolithic and was itself sent late in the merge window (with
the notable exception of the powerpc tree).
> [...] but this time, I think it looks OK, [...]
That's not really a surprise, there hasn't been a serious 'problem' with the
x86 tree for a long time, roughly since we switched to the finegrained Git
topical split-up maintenance model about two years ago.
[ That split-up also means that there is no 'x86 tree' anymore as such: if you
check lkml we send roughly 20-30 independent trees in the merge window and
have done that for the past ~10 kernel cycles. ]
In fact exactly *because* there's few problems with the x86 topic trees can we
push them so soon: if problems were frequent then 1) we would not be able to be
ready on time and 2) i suspect we'd be pulled in later in the window as well as
a maintainer generally wants to pull low risk items first, high risk items
last, to maximize the utilization of testing capacity.
I agree with Linus's notion in this thread though, a core kernel change should
generally not worry about hooking up rare-arch system calls (concentrate on the
architectures that get tested most) - those are better enabled gradually
anyway.
Also, system call table conflicts are trivial to resolve. Merging in net-next
to avoid such a conflict is like cracking a nut with a sledgehammer.
Thanks,
Ingo
^ 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-22 8:38 UTC (permalink / raw)
To: Jiri Pirko
Cc: Nicolas de Pesloüan, Jesse Gross, David Miller, netdev,
shemminger, kaber, fubar, eric.dumazet, andy, ebiederm
In-Reply-To: <20110522062915.GA2611@jirka.orion>
On Sun, May 22, 2011 at 2:29 PM, Jiri Pirko <jpirko@redhat.com> wrote:
> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
>
> <snip>
>>
>>And because some setups may still require the skb not to be untagged,
>>may be we need the ability to re-tag the skb in some situations...
>>When a protocol handler or rx_handler is explicitly registered on a
>>net_device which expect to receive tagged skb, we should deliver
>>tagged skb to it... Arguably, this may sound incredible for the
>>general case, but may be required for not-so-special cases like
>>bridge or protocol analyzer.
>
> Wait, what setups/code require the skb not to be untagged? If there's
> such, it should be fixed.
>
For a transparent bridge with ports: eth0 and eth1, the vlan tags
need to be preserved.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ 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-22 8:34 UTC (permalink / raw)
To: Jiri Pirko
Cc: Eric W. Biederman, Jesse Gross, Changli Gao, David Miller, netdev,
shemminger, kaber, fubar, eric.dumazet, andy
In-Reply-To: <m17h9jp7js.fsf@fess.ebiederm.org>
Le 22/05/2011 08:34, Eric W. Biederman a écrit :
> Jiri Pirko<jpirko@redhat.com> writes:
>
>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
>>
>> <snip>
>>>
>>> And because some setups may still require the skb not to be untagged,
>>> may be we need the ability to re-tag the skb in some situations...
>>> When a protocol handler or rx_handler is explicitly registered on a
>>> net_device which expect to receive tagged skb, we should deliver
>>> tagged skb to it... Arguably, this may sound incredible for the
>>> general case, but may be required for not-so-special cases like
>>> bridge or protocol analyzer.
>>
>> Wait, what setups/code require the skb not to be untagged? If there's
>> such, it should be fixed.
>
> tcpdump on the non-vlan interface for one.
bridge is another. More precisely, there is a difference between the following two setups:
1/ eth0 - eth0.100 - br0 - eth1.200 - eth1
2/ eth0 - br0 - eth1
In case 1, it is normal and desirable for the bridge to see untagged skb.
In case 2, it is desirable for the bridge to see untouched (possibly tagged) skb. If current bridge
implementation is able to handle skb from which we removed a tag, in this situation, it means that
bridge currently "fix improper untagging" by itself, by forcing re-tagging on output. I think is
should not be the job of protocol handlers to fix this. Again, a generic feature should to it when
necessary.
Think of the following setups:
3/ eth0 - br0 - eth1.200 - eth1.
4/ eth0 - eth0.100 - br0 - eth1
What if one expect this setup to add (3) or remove (4) one level of vlan nesting? This is precisely
what this setup suggest. How can we instruct the bridge to do so? It is not the bridge
responsibility to do any vlan processing. bridge is expected to... bridge !
Nicolas.
^ permalink raw reply
* Adding syscalls (was: Re: [GIT PULL] Namespace file descriptors for 2.6.40)
From: Geert Uytterhoeven @ 2011-05-22 8:15 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linus Torvalds, linux-kernel, Linux Containers, netdev,
James Bottomley, linux-arch
On Sun, May 22, 2011 at 02:33, Eric W. Biederman <ebiederm@xmission.com> wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>> 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.
>
> Sure. I will try to be a little more patient and resend the pull
> request after James has sent the pull request for the parisc tree.
> At which point the only unique changes in my tree will be mine.
>
>> It's that simple. We don't do this. Ever.
>
> Hah. I seem to remember bits of pulling from non-rebasing trees being ok
> in well defined contexts. This seems like one. Especially when you
> have checked with the maintainers.
>
> Plus all of the parisc bits in addition to being in the linux-next
> are trivially correct.
>
>> Why the hell did you even worry about wiring up parisc system calls?
>> That's not your job.
>
> Because in general it is the job of he who changes something to fix up
> every possible place.
>
> Now maybe I went a little too far in trying to resolve the conflicts,
> but I did check with the David Miller and James Bottomley and they knew
> what I was doing.
>
> Quite honestly adding system calls is a mess that know one seems to
> know how to do right. So I flipped a coin and took a stab at it.
At first, I was delighted to see that somebody took care of adding
syscalls to the
non-popular architectures.
At second, I saw the conflicts in e.g. parisc and m68k due to this.
Hence now I think it's better to leave the wiring up to the
architecture maintainers, as
before.
I'm even thinking to suggest to first let go in the syscall (without
any wiring up, not
even on x86), and let all wiring up be handled afterwards. This would
enforce that
syscalls numbers are not cast in stone, until they hit mainline.
This does mean that scripts/checksyscalls.sh needs to be changed, as initially
new syscalls aren't wired up there neither. The implementation of the
syscalls needs
to announce somehow that it's there and that it's a syscall.
What do you think?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Linux 2.6.39
From: CaT @ 2011-05-22 7:22 UTC (permalink / raw)
To: Linus Torvalds, netdev; +Cc: Linux Kernel Mailing List
In-Reply-To: <BANLkTikB37AvEgh1MAFBbYvFaxsL6W11OQ@mail.gmail.com>
Um. Should my routing table be being displayed in reverse order all of
a sudden?
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth1
ip route list is similar. I'm sure this is going to break a script or two
(and, perhaps, a mind or two :).
--
"A search of his car uncovered pornography, a homemade sex aid, women's
stockings and a Jack Russell terrier."
- http://www.dailytelegraph.com.au/news/wacky/indeed/story-e6frev20-1111118083480
^ permalink raw reply
* Re: [GIT PULL] Namespace file descriptors for 2.6.40
From: James Bottomley @ 2011-05-22 7:13 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linux Containers, netdev-u79uwXL29TY76Z2rM5mHXA, Linus Torvalds,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven
In-Reply-To: <m1boyvpo9r.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
On Sat, 2011-05-21 at 17:33 -0700, Eric W. Biederman wrote:
> Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> writes:
>
> > On Sat, May 21, 2011 at 4:39 PM, Eric W. Biederman
> > <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> 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.
>
> Sure. I will try to be a little more patient and resend the pull
> request after James has sent the pull request for the parisc tree.
> At which point the only unique changes in my tree will be mine.
Right ... effectively you're running a postmerge tree, since you now
depend on bits I have in the parisc tree.
Traditionally, the arch trees tend to go a bit later because they wait
to see if there's any fallout from x86; but this time, I think it looks
OK, so I've sent the pull request:
http://marc.info/?l=linux-parisc&m=130604805417277
As soon as that's in, you should be good to go.
James
> > It's that simple. We don't do this. Ever.
>
> Hah. I seem to remember bits of pulling from non-rebasing trees being ok
> in well defined contexts. This seems like one. Especially when you
> have checked with the maintainers.
>
> Plus all of the parisc bits in addition to being in the linux-next
> are trivially correct.
>
> > Why the hell did you even worry about wiring up parisc system calls?
> > That's not your job.
>
> Because in general it is the job of he who changes something to fix up
> every possible place.
>
> Now maybe I went a little too far in trying to resolve the conflicts,
> but I did check with the David Miller and James Bottomley and they knew
> what I was doing.
>
> Quite honestly adding system calls is a mess that know one seems to
> know how to do right. So I flipped a coin and took a stab at it.
Right, the solution is reasonable and means linux-next doesn't have to
carry a conflict resolution patch for this. It also means we agree on
the syscall numbering ...
The only real mistake was not waiting for the merge sequence: the base
trees have to go first before you can push a postmerge tree.
James
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Eric W. Biederman @ 2011-05-22 6:34 UTC (permalink / raw)
To: Jiri Pirko
Cc: Nicolas de Pesloüan, Jesse Gross, Changli Gao, David Miller,
netdev, shemminger, kaber, fubar, eric.dumazet, andy
In-Reply-To: <20110522062915.GA2611@jirka.orion>
Jiri Pirko <jpirko@redhat.com> writes:
> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
>
> <snip>
>>
>>And because some setups may still require the skb not to be untagged,
>>may be we need the ability to re-tag the skb in some situations...
>>When a protocol handler or rx_handler is explicitly registered on a
>>net_device which expect to receive tagged skb, we should deliver
>>tagged skb to it... Arguably, this may sound incredible for the
>>general case, but may be required for not-so-special cases like
>>bridge or protocol analyzer.
>
> Wait, what setups/code require the skb not to be untagged? If there's
> such, it should be fixed.
tcpdump on the non-vlan interface for one.
Eric
^ 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-22 6:29 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jesse Gross, Changli Gao, David Miller, netdev, shemminger, kaber,
fubar, eric.dumazet, andy, ebiederm
In-Reply-To: <4DD87C25.4030701@gmail.com>
Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
<snip>
>
>And because some setups may still require the skb not to be untagged,
>may be we need the ability to re-tag the skb in some situations...
>When a protocol handler or rx_handler is explicitly registered on a
>net_device which expect to receive tagged skb, we should deliver
>tagged skb to it... Arguably, this may sound incredible for the
>general case, but may be required for not-so-special cases like
>bridge or protocol analyzer.
Wait, what setups/code require the skb not to be untagged? If there's
such, it should be fixed.
^ permalink raw reply
* [PATCH] net: skb_trim explicitely check the linearity instead of data_len
From: emmanuel.grumbach @ 2011-05-22 5:46 UTC (permalink / raw)
To: davem, netdev; +Cc: Emmanuel Grumbach
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The purpose of the check on data_len is to check linearity, so use the inline
helper for this. No overhead and more explicit.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
---
include/linux/skbuff.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index bf221d6..a4f680c 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1439,7 +1439,7 @@ extern int ___pskb_trim(struct sk_buff *skb, unsigned int len);
static inline void __skb_trim(struct sk_buff *skb, unsigned int len)
{
- if (unlikely(skb->data_len)) {
+ if (unlikely(skb_is_nonlinear(skb))) {
WARN_ON(1);
return;
}
--
1.7.1
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* Re: [PATCH 0/7] Network namespace manipulation with file descriptors
From: Renato Westphal @ 2011-05-22 4:19 UTC (permalink / raw)
To: David Lamparter
Cc: Eric W. Biederman, Alex Bligh, linux-arch, netdev, linux-kernel,
Linux Containers, linux-fsdevel
In-Reply-To: <20110517153546.GB3762520@jupiter.n2.diac24.net>
Eric,
I'm happy to see that these patches have been integrated into the
mainstream kernel, as you know I'm using them for a while and they are
a essential part of my MPLS/BGP VPN solution, which I will release to
the open-source community anytime soon.
It would also be good if the MPLS core get integrated into mainstream,
but that's another discussion ;)
--
Renato Westphal
^ permalink raw reply
* Re: [PATCH 0/2] bna: Add Debugfs & Generic Netlink Interfaces to BNA Driver
From: David Miller @ 2011-05-22 3:31 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <E5313AF6F2BFD14293E5FD0F94750F86A5D76F7AC6@HQ1-EXCH01.corp.brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Sat, 21 May 2011 16:06:27 -0700
> Can you please tell what is the state of this patch set? We are wondering if the patches are still under review.
The review feedback you received was that a whole new genetlink protocol
was overkill for the facilities you are providiing at the moment, so the
state of the patch moved to "changed requested"
I saw your response, and I simply disagree with it, so the patches
are staying in that state.
In any event, you don't need to ask me, check patchwork. You make
patchwork absolutely pointless if you ask me what the state of the
patch is, and this makes a lot of extra unnecessary work for me.
Don't do it.
^ 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-22 2:59 UTC (permalink / raw)
To: Jesse Gross
Cc: Changli Gao, Jiri Pirko, David Miller, netdev, shemminger, kaber,
fubar, eric.dumazet, andy, ebiederm
In-Reply-To: <BANLkTinqFJa-B7E7tonzOKGV4etZHUkUug@mail.gmail.com>
Le 21/05/2011 19:54, Jesse Gross a écrit :
> 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.
Thanks for clarifying.
So, because many limited/buggy hardware exist, we must mimic the behavior in software. 'Sounds good
to me.
And because some setups may still require the skb not to be untagged, may be we need the ability to
re-tag the skb in some situations... When a protocol handler or rx_handler is explicitly registered
on a net_device which expect to receive tagged skb, we should deliver tagged skb to it... Arguably,
this may sound incredible for the general case, but may be required for not-so-special cases like
bridge or protocol analyzer.
Of course, I don't say we should always re-tag: if no protocol handler nor rx_handler were
registered on the parent interface, we don't need the extra work of re-tagging.
What I say is that it shouldn't be the job of protocol handlers or rx_handlers that expect the skb
to be tagged to fix the improper untagging. A generic feature should do it when necessary.
And all this being said, it doesn't mean that we should pollute __netif_receive_skb with special
code for vlan handling.
May be, as suggested by Eric W. Biederman in the V1 thread for this patch, software untagging for
the first level of header should happen before __netif_receive_skb if we only try to mimic hardware
behavior.
And possible later untagging (due to vlan nesting) should be done generically inside
__netif_receive_skb, using rx_handler when appropriate. This would cleanup the general case where no
vlan is involved at all.
Nicolas.
^ permalink raw reply
* Re: [GIT PULL] Namespace file descriptors for 2.6.40
From: Eric W. Biederman @ 2011-05-22 0:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Linux Containers, netdev, James Bottomley,
Geert Uytterhoeven
In-Reply-To: <BANLkTim4q5dK6nOb=pVKbk1c8b-Nh_hBfA@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> 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.
Sure. I will try to be a little more patient and resend the pull
request after James has sent the pull request for the parisc tree.
At which point the only unique changes in my tree will be mine.
> It's that simple. We don't do this. Ever.
Hah. I seem to remember bits of pulling from non-rebasing trees being ok
in well defined contexts. This seems like one. Especially when you
have checked with the maintainers.
Plus all of the parisc bits in addition to being in the linux-next
are trivially correct.
> Why the hell did you even worry about wiring up parisc system calls?
> That's not your job.
Because in general it is the job of he who changes something to fix up
every possible place.
Now maybe I went a little too far in trying to resolve the conflicts,
but I did check with the David Miller and James Bottomley and they knew
what I was doing.
Quite honestly adding system calls is a mess that know one seems to
know how to do right. So I flipped a coin and took a stab at it.
Eric
^ permalink raw reply
* 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
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