* Re: tg3 driver and interrupt coalescence questions
From: Rick Jones @ 2006-06-27 18:33 UTC (permalink / raw)
To: Chris A. Icide; +Cc: netdev
In-Reply-To: <44A167EB.8000805@netgeeks.net>
Chris A. Icide wrote:
> I've been digging around trying to get some information on the
> current status of interrupt mitigation features for a Braodcom 5704 interface.
>
> Specifically I'm sending and receiving lots of VoIP packets (50 pps
> per stream, many streams).
>
> What I can't seem to determine is this:
>
> What version of the linux kernel & tg3 drivers are required to
> support both rx and tx mitigation?
> What do the ethtool coalescence settings actually do (I've not been
Delay interrupts and increase individual packet latency with the
intention being decreasing CPU utilization and allowing a higher
aggregate packet per second limit. IE bandwidth vs latency tradeoffs.
> able to find actual descriptions of the different parameters in the -C
> section)
> Is there anything special that needs to be done when compiling a
> kernel to enable this feature for both the kernel and the tg3 driver.
Are you looking to increase or decrease the settings? I would think
(initially at least) that for VOIP one might not want to increase them.
rick jones
^ permalink raw reply
* Re: [PATCH]: e1000: Janitor: Use #defined values for literals
From: Auke Kok @ 2006-06-27 18:03 UTC (permalink / raw)
To: Linas Vepstas
Cc: netdev, john.ronciak, jesse.brandeburg, jeffrey.t.kirsher,
Zhang, Yanmin, Jeff Garzik, linux-kernel
In-Reply-To: <20060627173224.GA31770@austin.ibm.com>
Linas Vepstas wrote:
> On Fri, Jun 23, 2006 at 01:07:21PM -0700, Auke Kok wrote:
>> Linas Vepstas wrote:
>>> Minor janitorial patch: use #defines for literal values.
>>> + pci_enable_wake(pdev, PCI_D3hot, 0);
>>> + pci_enable_wake(pdev, PCI_D3cold, 0);
>> I Acked this but that's silly - the patches sent yesterday already change
>> the code above and this patch is no longer needed (thanks Jesse for
>> spotting this).
>>
>> This patch would conflict with them so please don't apply.
>
> Maybe there's a backlog in the queue, but I not this is not
> yet in 2.6.17-mm3
It's part of the submission for 2.6.18 I sent to jgarzik on friday, which
cleans up this section in the way.
Auke
^ permalink raw reply
* Re: Network namespaces a path to mergable code.
From: Andrey Savochkin @ 2006-06-27 17:58 UTC (permalink / raw)
To: Eric W. Biederman
Cc: dlezcano, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, herbert, devel, sam, viro, Alexey Kuznetsov
In-Reply-To: <m14py6ldlj.fsf@ebiederm.dsl.xmission.com>
Eric,
On Tue, Jun 27, 2006 at 11:20:40AM -0600, Eric W. Biederman wrote:
>
> Thinking about this I am going to suggest a slightly different direction
> for get a patchset we can merge.
>
> First we concentrate on the fundamentals.
> - How we mark a device as belonging to a specific network namespace.
> - How we mark a socket as belonging to a specific network namespace.
I agree with the direction of your thoughts.
I was trying to do a similar thing, define clear steps in network
namespace merging.
My first patchset covers devices but not sockets.
The only difference from what you're suggesting is ipv4 routing.
For me, it is not less important than devices and sockets. May be even
more important, since routing exposes design deficiencies less obvious at
socket level.
>
> As part of the fundamentals we add a patch to the generic socket code
> that by default will disable it for protocol families that do not indicate
> support for handling network namespaces, on a non-default network namespace.
Fine
Can you summarize you objections against my way of handling devices, please?
And what was the typo you referred to in your letter to Kirill Korotaev?
Regards
Andrey
^ permalink raw reply
* Re: tg3 driver and interrupt coalescence questions
From: Michael Chan @ 2006-06-27 17:59 UTC (permalink / raw)
To: Chris A. Icide; +Cc: netdev
In-Reply-To: <44A167EB.8000805@netgeeks.net>
On Tue, 2006-06-27 at 10:16 -0700, Chris A. Icide wrote:
> What version of the linux kernel & tg3 drivers are required to support both rx and tx mitigation?
ethtool -C for tg3 was added around July of 2005. The version with this
change added was 3.33.
> What do the ethtool coalescence settings actually do (I've not been able to find actual descriptions of the different parameters in the -C section)
They set the delay between the tx and rx events and the generation of
interrupts for those events.
These are the only parameters that are relevant for tg3:
rx-frames[-irq]
rx-usecs[-irq]
tx-frames[-irq]
tx-usecs[-irq]
The frames parameters specify how many packets are received/transmitted
before generating an interrupt. The usecs parameters specify how many
microseconds after at least 1 packet is received/transmitted before
generating an interrupt. The [-irq] parameters are the corresponding
delays in updating the status when the interrupt is disabled.
> Is there anything special that needs to be done when compiling a kernel to enable this feature for both the kernel and the tg3 driver.
No.
> 05:01.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704S
> Gigabit Ethernet (rev 10)
> Subsystem: IBM: Unknown device 02e8
> Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 201
> Memory at dcfe0000 (64-bit, non-prefetchable) [size=64K]
> Capabilities: [40] PCI-X non-bridge device.
> Capabilities: [48] Power Management version 2
> Capabilities: [50] Vital Product Data
> Capabilities: [58] Message Signalled Interrupts: 64bit+
> Queue=0/3 Enable-
>
> Linux version 2.6.9-34.ELsmp (buildcentos@nasha.karan.org) (gcc version
> 3.4.5 20051201 (Red Hat 3.4.5-2)) #1 SMP Thu Mar 9 06:23:23 GMT 2006
>
> [root@db2 ~]# ethtool -c eth1
> Coalesce parameters for eth1:
> Adaptive RX: off TX: off
> stats-block-usecs: 1000000
> sample-interval: 0
> pkt-rate-low: 0
> pkt-rate-high: 0
>
> rx-usecs: 500
> rx-frames: 30
> rx-usecs-irq: 500
> rx-frames-irq: 20
>
This means that the first interrupt will be generated after 30 packets
are received or 500 microseconds after the nth packet is received (1 <=
n < 30). When irq is disabled, 20 packets instead of 30 before updating
status.
> tx-usecs: 400
> tx-frames: 53
> tx-usecs-irq: 490
> tx-frames-irq: 5
The first tx interrupt will be generated after 53 packets are
transmitted or 400 microseconds after the nth packet is transmitted (1
<= n < 53). When irq is disabled, 5 packets or 490 micosecs before
updating status.
If the condition for generating a tx or rx interrupt is met, you get all
the accumulated tx and rx status during the interrupt.
Hope this helps.
^ permalink raw reply
* Re: [PATCH]: e1000: Janitor: Use #defined values for literals
From: Linas Vepstas @ 2006-06-27 17:32 UTC (permalink / raw)
To: Auke Kok
Cc: netdev, john.ronciak, jesse.brandeburg, jeffrey.t.kirsher,
Zhang, Yanmin, Jeff Garzik, linux-kernel
In-Reply-To: <449C49F9.6090005@intel.com>
On Fri, Jun 23, 2006 at 01:07:21PM -0700, Auke Kok wrote:
> Linas Vepstas wrote:
> >Minor janitorial patch: use #defines for literal values.
> >+ pci_enable_wake(pdev, PCI_D3hot, 0);
> >+ pci_enable_wake(pdev, PCI_D3cold, 0);
>
> I Acked this but that's silly - the patches sent yesterday already change
> the code above and this patch is no longer needed (thanks Jesse for
> spotting this).
>
> This patch would conflict with them so please don't apply.
Maybe there's a backlog in the queue, but I not this is not
yet in 2.6.17-mm3
--linas
^ permalink raw reply
* [RFC] Network namespaces a path to mergable code.
From: Eric W. Biederman @ 2006-06-27 17:20 UTC (permalink / raw)
To: Andrey Savochkin
Cc: dlezcano, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, herbert, devel, sam, viro
In-Reply-To: <20060626134945.A28942@castle.nmd.msu.ru>
Thinking about this I am going to suggest a slightly different direction
for get a patchset we can merge.
First we concentrate on the fundamentals.
- How we mark a device as belonging to a specific network namespace.
- How we mark a socket as belonging to a specific network namespace.
As part of the fundamentals we add a patch to the generic socket code
that by default will disable it for protocol families that do not indicate
support for handling network namespaces, on a non-default network namespace.
I think that gives us a path that will allow us to convert the network stack
one protocol family at a time instead of in one big lump.
Stubbing off the sysfs and sysctl interfaces in the first round for the
non-default namespaces as you have done should be good enough.
The reason for the suggestion is that most of the work for the protocol
stacks ipv4 ipv6 af_packet af_unix is largely noise, and simple
replacement without real design work happening. Mostly it is just
tweaking the code to remove global variables, and doing a couple
lookups.
Eric
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Ben Greear @ 2006-06-27 17:19 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Herbert Poetzl, Daniel Lezcano, Andrey Savochkin, linux-kernel,
netdev, serue, haveblue, clg, Andrew Morton, dev, devel, sam,
viro, Alexey Kuznetsov
In-Reply-To: <m1psgulf4u.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
> Herbert Poetzl <herbert@13thfloor.at> writes:
>
>
>>On Tue, Jun 27, 2006 at 05:52:52AM -0600, Eric W. Biederman wrote:
>>
>>>Inside the containers I want all network devices named eth0!
>>
>>huh? even if there are two of them? also tun?
>>
>>I think you meant, you want to be able to have eth0 in
>>_more_ than one guest where eth0 in a guest can also
>>be/use/relate to eth1 on the host, right?
>
>
> Right I want to have an eth0 in each guest where eth0 is
> it's own network device and need have no relationship to
> eth0 on the host.
How does that help anything? Do you envision programs
that make special decisions on whether the interface is
called eth0 v/s eth151?
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
From: Patrick McHardy @ 2006-06-27 17:18 UTC (permalink / raw)
To: Russell Stuart
Cc: Russell Stuart, hadi, Alan Cox, Stephen Hemminger, netdev,
Jesper Dangaard Brouer
In-Reply-To: <44A0CE01.4010109@stuart.id.au>
Russell Stuart wrote:
> Without seeing your actual proposal it is difficult to
> judge whether this is a reasonable trade-off or not.
> Hopefully we will see your code soon. Do you have any
> idea when?
Probably not today, I'll try to get it into shape until tomomorrow.
^ permalink raw reply
* tg3 driver and interrupt coalescence questions
From: Chris A. Icide @ 2006-06-27 17:16 UTC (permalink / raw)
To: netdev
I've been digging around trying to get some information on the current status of interrupt mitigation features for a Braodcom 5704 interface.
Specifically I'm sending and receiving lots of VoIP packets (50 pps per stream, many streams).
What I can't seem to determine is this:
What version of the linux kernel & tg3 drivers are required to support both rx and tx mitigation?
What do the ethtool coalescence settings actually do (I've not been able to find actual descriptions of the different parameters in the -C section)
Is there anything special that needs to be done when compiling a kernel to enable this feature for both the kernel and the tg3 driver.
Just a warning, I'm not a C coder, so I've not had much luck digging around the code and looking for answers.
I've currently got a blade server with 10 blades I'm using 9 blades to generate this small packet high rate traffic to the 10th blade and trying to improve the ability of a blade to handle VoIP traffic. I made some guesses at settings for the -C options in ethtool on both the test blade and the traffic generators. Interestingly it seems to have had a very good effect on the test blade (%cpu for interrupt down from 99.9% to ~20%), but the same settings on the traffic generation servers seems to have had no effect.
Hardware is identical, kernel is identical.
Any help is GREATLY appreciated.
-Chris
05:01.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704S
Gigabit Ethernet (rev 10)
Subsystem: IBM: Unknown device 02e8
Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 201
Memory at dcfe0000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] PCI-X non-bridge device.
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data
Capabilities: [58] Message Signalled Interrupts: 64bit+
Queue=0/3 Enable-
Linux version 2.6.9-34.ELsmp (buildcentos@nasha.karan.org) (gcc version
3.4.5 20051201 (Red Hat 3.4.5-2)) #1 SMP Thu Mar 9 06:23:23 GMT 2006
[root@db2 ~]# ethtool -c eth1
Coalesce parameters for eth1:
Adaptive RX: off TX: off
stats-block-usecs: 1000000
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0
rx-usecs: 500
rx-frames: 30
rx-usecs-irq: 500
rx-frames-irq: 20
tx-usecs: 400
tx-frames: 53
tx-usecs-irq: 490
tx-frames-irq: 5
rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0
rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0
[root@db2 ~]# ethtool -i eth1
driver: tg3
version: 3.43-rh
firmware-version:
bus-info: 0000:05:01.1
[root@db2 ~]# ethtool eth1
Settings for eth1:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 1000baseT/Half 1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: g
Wake-on: d
Current message level: 0x000000ff (255)
Link detected: yes
^ permalink raw reply
* Re: [RFC][patch 1/4] Network namespaces: cleanup of dev_base list use
From: Eric W. Biederman @ 2006-06-27 16:54 UTC (permalink / raw)
To: Kirill Korotaev
Cc: Andrey Savochkin, dlezcano, linux-kernel, netdev, serue, haveblue,
clg, Andrew Morton, herbert, devel, sam, viro
In-Reply-To: <44A149F5.2060204@sw.ru>
Kirill Korotaev <dev@sw.ru> writes:
> This doesn't support anything. e.g. I caught quite a lot of bugs after Ingo
> Molnar, but this doesn't make his code "poor". People are people.
> Anyway, I would be happy to see the typo.
Look up thread. You replied to the message where I commented on it.
There are two ways to argue this.
- It is the linux kernel development style to do small simple
obviously patches that copy the maintainer of the code you are
changing.
- Explain why that is the style.
The basic idea is that on a simple patch that is well described, it is
trivial to check and trivial to verify.
Eric
^ permalink raw reply
* Re: Please pull 'upstream' branch of wireless-2.6
From: Joseph Jezak @ 2006-06-27 16:52 UTC (permalink / raw)
To: NetDev
In-Reply-To: <44A158EB.90406@garzik.org>
> No, that totally avoids my point. Your "otherwise idle machine" test is
> probably nowhere near worst case in the field, for loops that can
> potentially lock the CPU for a long time upon hardware fault. And then
> there are the huge delays in specific functions that I pointed out...
>
> Jeff
The problem is that these are the delays used in the original driver
that we've been writing the specs from. We don't know what they're
for or why they're so long. We don't know if reducing the delay
will cause issues on some hardware and work fine on others. Without
the actual specs from Broadcom, it's hard to say what's excessive
and what's not and whether changing it will break the driver.
-Joe
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Alexey Kuznetsov @ 2006-06-27 16:49 UTC (permalink / raw)
To: Eric W. Biederman, Daniel Lezcano, Andrey Savochkin, linux-kernel,
netdev, serue, haveblue, clg, Andrew Morton, dev, devel, sam,
viro, Alexey Kuznetsov
In-Reply-To: <20060627160241.GB28984@MAIL.13thfloor.at>
On Tue, Jun 27, 2006 at 06:02:42PM +0200, Herbert Poetzl wrote:
> - loopback traffic inside a guest is insignificantly
> slower than on a normal system
>
> - loopback traffic on the host is insignificantly
> slower than on a normal system
>
> - inter guest traffic is faster than on-wire traffic,
> and should be withing a small tolerance of the
> loopback case (as it really isn't different)
I do not follow what are you people arguing about?
Intra-guest, guest-guest and host-guest paths have _no_ differences
from host-host loopback. Only the device is different:
* virtual loopback for intra-guest
* virtual interface for guest-guest and host-guest
But the work is exactly the same, only the place where packets
looped back is different. How could this be issue to break a lance over? :-)
Alexey
PS. The only thing, which I can imagine is "optimized" out ip_route_input()
in the case of loopback. But this optimization was an obvious design mistake
(mine, sorry) and apparently will die together with removal of current
deficiences of routing cache. Actually, it is one of deficiences.
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Eric W. Biederman @ 2006-06-27 16:47 UTC (permalink / raw)
To: Herbert Poetzl
Cc: Daniel Lezcano, Andrey Savochkin, linux-kernel, netdev, serue,
haveblue, clg, Andrew Morton, dev, devel, sam, viro,
Alexey Kuznetsov
In-Reply-To: <20060627160241.GB28984@MAIL.13thfloor.at>
Herbert Poetzl <herbert@13thfloor.at> writes:
> On Tue, Jun 27, 2006 at 05:52:52AM -0600, Eric W. Biederman wrote:
>>
>> Inside the containers I want all network devices named eth0!
>
> huh? even if there are two of them? also tun?
>
> I think you meant, you want to be able to have eth0 in
> _more_ than one guest where eth0 in a guest can also
> be/use/relate to eth1 on the host, right?
Right I want to have an eth0 in each guest where eth0 is
it's own network device and need have no relationship to
eth0 on the host.
>> We need a clean abstraction that optimizes well.
>>
>> However local communication between containers is not what we
>> should benchmark. That can always be improved later. So long as
>> the performance is reasonable. What needs to be benchmarked is the
>> overhead of namespaces when connected to physical networking devices
>> and on their own local loopback, and comparing that to a kernel
>> without namespace support.
>
> well, for me (obviously advocating the lightweight case)
> it seems improtant that the following conditions are met:
>
> - loopback traffic inside a guest is insignificantly
> slower than on a normal system
>
> - loopback traffic on the host is insignificantly
> slower than on a normal system
>
> - inter guest traffic is faster than on-wire traffic,
> and should be withing a small tolerance of the
> loopback case (as it really isn't different)
>
> - network (on-wire) traffic should be as fast as without
> the namespace (i.e. within 1% or so, better not really
> measurable)
>
> - all this should be true in a setup with a significant
> number of guests, when only one guest is active, but
> all other guests are ready/configured
>
> - all this should scale well with a few hundred guests
Ultimately I agree. However. Only host performance should be
a merge blocker. Allowing us to go back and reclaim the few
percentage points we lost later.
>> If we don't hurt that core case we have an implementation we can
>> merge. There are a lot of optimization opportunities for local
>> communications and we can do that after we have a correct and accepted
>> implementation. Anything else is optimizing too soon, and will
>> just be muddying the waters.
>
> what I fear is that once something is in, the kernel will
> just become slower (as it already did in some areas) and
> nobody will care/be-able to fix that later on ...
If nobody cares it doesn't matter.
If no one can fix it that is a problem. Which is why we need
high standards and clean code, not early optimizations.
But on that front each step of the way must be justified on
it's own merits. Not because it will give us some holy grail.
The way to keep the inter guest performance from degrading is
to measure it an complain. But the linux network stack is too
big to get in one pass.
Eric
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Eric W. Biederman @ 2006-06-27 16:40 UTC (permalink / raw)
To: Herbert Poetzl
Cc: Daniel Lezcano, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, devel, sam, viro, Alexey Kuznetsov,
Andrey Savochkin
In-Reply-To: <20060627154818.GA28984@MAIL.13thfloor.at>
Herbert Poetzl <herbert@13thfloor.at> writes:
> On Tue, Jun 27, 2006 at 01:09:11PM +0400, Andrey Savochkin wrote:
>>
>> I'd like to caution about over-optimizing communications between
>> different network namespaces. Many optimizations of local traffic
>> (such as high MTU) don't look so appealing when you start to think
>> about live migration of namespaces.
>
> I think the 'optimization' (or to be precise: desire
> not to sacrifice local/loopback traffic for some use
> case as you describe it) does not interfere with live
> migration at all, we still will have 'local' and 'remote'
> traffic, and personally I doubt that the live migration
> is a feature for the masses ...
Several things.
- The linux loopback device is not strongly optimized, it is a compatibility
layer.
- Traffic between guests is an implementation detail.
There is nothing fundamental in our semantics that says the traffic
has to be slow for any workload (except for the limuts imposed by using
actual on the wire protocols). The lo shares the same problem.
Worry about this case now when it has clearly been shown that there are several
possible ways to optimize this and get back any lost local performance is
optimizing way too early.
Criticize the per namespace performance and all you want. That is pretty
much a merge blocker. Unless we do worse than a 1-5% penalty the communication
across namespaces is really a non-issue.
Even with your large communications flows between guests 1-5% is nothing.
Eric
^ permalink raw reply
* Re: [Patch 1/1] AF_UNIX Datagram getpeersec [Updated #2]
From: Xiaolan Zhang @ 2006-06-27 16:33 UTC (permalink / raw)
To: James Morris
Cc: Andrew Morton, chrisw, Catherine Zhang, czhang.us,
David S. Miller, George Wilson, Herbert Xu, jmorris, latten,
netdev, Stephen Smalley, Serge E Hallyn, tjaeger
In-Reply-To: <Pine.LNX.4.64.0606270954080.804@d.namei>
Some more fixes:
> diff -purN -X dontdiff linux-2.6.o/net/unix/af_unix.c linux-2.6.
> w/net/unix/af_unix.c
> --- linux-2.6.o/net/unix/af_unix.c 2006-06-21 00:02:30.000000000 -0400
> +++ linux-2.6.w/net/unix/af_unix.c 2006-06-27 09:30:12.000000000 -0400
> @@ -128,6 +128,28 @@ static atomic_t unix_nr_socks = ATOMIC_I
>
> #define UNIX_ABSTRACT(sk) (unix_sk(sk)->addr->hash != UNIX_HASH_SIZE)
>
> +#ifdef CONFIG_SECURITY_NETWORK
> +static void unix_get_peersec_dgram(struct sk_buff *skb)
> +{
add int err;
> + err = security_socket_getpeersec_dgram(skb, UNIXSECDATA(skb),
> + UNIXSECLEN(skb));
> + if (err)
> + *(UNIXSEC(skb)) = NULL;
change to *(UNIXSECDATA(skb)) = NULL;
> +}
> +
> +static inline void unix_set_secdata(struct scm_cookie *scm, struct
> sk_buff *skb)
> +{
> + scm->secdata = *UNIXSECDATA(skb);
> + scm->seclen = UNIXSECLEN(skb);
change to scm->seclen = *UNIXSECLEN(skb);
> +}
> +#else
> +static void unix_get_peersec_dgram(struct sk_buff *skb)
> +{ }
> +
> +static inline void unix_set_secdata(struct scm_cookie *scm, struct
> sk_buff *skb)
> +{ }
> +#endif /* CONFIG_SECURITY_NETWORKING */
> +
> /*
> * SMP locking strategy:
> * hash table is protected with spinlock unix_table_lock
> @@ -1291,6 +1313,8 @@ static int unix_dgram_sendmsg(struct kio
> if (siocb->scm->fp)
> unix_attach_fds(siocb->scm, skb);
>
> + unix_get_peersec_dgram(skb);
> +
> skb->h.raw = skb->data;
> err = memcpy_fromiovec(skb_put(skb,len), msg->msg_iov, len);
> if (err)
> @@ -1570,6 +1594,7 @@ static int unix_dgram_recvmsg(struct kio
> memset(&tmp_scm, 0, sizeof(tmp_scm));
> }
> siocb->scm->creds = *UNIXCREDS(skb);
> + unix_set_secdata(siocb->scm, skb);
>
> if (!(flags & MSG_PEEK))
> {
^ permalink raw reply
* Re: Please pull 'upstream' branch of wireless-2.6
From: Michael Buesch @ 2006-06-27 16:31 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bcm43xx-dev, Larry Finger, John W. Linville, netdev
In-Reply-To: <44A158EB.90406@garzik.org>
On Tuesday 27 June 2006 18:12, Jeff Garzik wrote:
> Michael Buesch wrote:
> > So, I will submit a patch to lower the udelay(10) to udelay(1)
> > and we can close the discussion? ;)
>
> No, that totally avoids my point. Your "otherwise idle machine" test is
> probably nowhere near worst case in the field, for loops that can
> potentially lock the CPU for a long time upon hardware fault. And then
> there are the huge delays in specific functions that I pointed out...
wtf are you requesting from me?
1) I proved you that the loop does only spin _once_ or even _less_.
2) If the hardware is faulty, the user must replace it.
Because, if the hardware is faulty, it can crash the whole
machine anyway, obviously.
3) There is no "huge delay". I proved it with my logs.
-> No CPU hog => Nothing to fix.
--
Greetings Michael.
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Eric W. Biederman @ 2006-06-27 16:29 UTC (permalink / raw)
To: Herbert Poetzl
Cc: Kirill Korotaev, Daniel Lezcano, Andrey Savochkin, linux-kernel,
netdev, serue, haveblue, clg, Andrew Morton, devel, sam, ebiederm,
viro, Alexey Kuznetsov
In-Reply-To: <20060627160908.GC28984@MAIL.13thfloor.at>
Herbert Poetzl <herbert@13thfloor.at> writes:
> On Tue, Jun 27, 2006 at 01:54:51PM +0400, Kirill Korotaev wrote:
>> >>My point is that if you make namespace tagging at routing time, and
>> >>your packets are being routed only once, you lose the ability
>> >>to have separate routing tables in each namespace.
>> >
>> >
>> >Right. What is the advantage of having separate the routing tables ?
>
>> it is impossible to have bridged networking, tun/tap and many other
>> features without it. I even doubt that it is possible to introduce
>> private netfilter rules w/o virtualization of routing.
>
> why? iptables work quite fine on a typical linux
> system when you 'delegate' certain functionality
> to certain chains (i.e. doesn't require access to
> _all_ of them)
>
>> The question is do we want to have fully featured namespaces which
>> allow to create isolated virtual environments with semantics and
>> behaviour of standalone linux box or do we want to introduce some
>> hacks with new rules/restrictions to meet ones goals only?
>
> well, soemtimes 'hacks' are not only simpler but also
> a much better solution for a given problem than the
> straight forward approach ...
Well I would like to see a hack that qualifies. I watched the
linux-vserver irc channel for a while and almost every network problem
was caused by the change in semantics vserver provides.
In this case when you allow a guest more than one IP your hack while
easy to maintain becomes much more complex. Especially as you address
each case people care about one at a time.
In one shot this goes the entire way. Given how many people miss
that you do the work at layer 2 than at layer 3 I would not call this
the straight forward approach. The straight forward implementation yes,
but not the straight forward approach.
> for example, you won't have multiple routing tables
> in a kernel where this feature is disabled, no?
> so why should it affect a guest, or require modified
> apps inside a guest when we would decide to provide
> only a single routing table?
>
>> From my POV, fully virtualized namespaces are the future.
>
> the future is already there, it's called Xen or UML, or QEMU :)
Yep. And now we need it to run fast.
>> It is what makes virtualization solution usable (w/o apps
>> modifications), provides all the features and doesn't require much
>> efforts from people to be used.
>
> and what if they want to use virtualization inside
> their guests? where do you draw the line?
The implementation doesn't have any problems with guests inside
of guests.
The only reason to restrict guests inside of guests is because
the we aren't certain which permissions make sense.
Eric
^ permalink raw reply
* Re: Please pull 'upstream' branch of wireless-2.6
From: Michael Buesch @ 2006-06-27 16:23 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bcm43xx-dev, Larry Finger, John W. Linville, netdev
In-Reply-To: <44A15864.6000408@garzik.org>
On Tuesday 27 June 2006 18:10, Jeff Garzik wrote:
> Michael Buesch wrote:
> > On Tuesday 27 June 2006 16:11, Jeff Garzik wrote:
> >> Overall, bcm43xx is _really really bad_ about this sort of thing. Just
> >> grepping for udelay in bcm43xx_radio.c shows some of the worst
> >> offenders. bcm43xx_radio_init2060() and bcm43xx_radio_selectchannel()
> >> both look like candidates for using msleep() rather than udelay().
> >
> > This is _all_ at initialization time.
> > select_channel.... How often do you select a channel?
>
> That question is irrelevant, because you have no idea what -else- is
> going on in the system, at the point when bcm43xx chooses to spin the
> CPU heavily.
>
> Initialization time means you are definitely not in a hot path, and can
> therefore sleep.
Ok, again:
If you are running a preemptible kernel (I am doing a patch for the
non-preemptible case), everything is _already_ fine.
We are not spinning long times with locks held or IRQs disabled.
I already fixed that.
And no, I don't really care for initialization time.
I am not going to potentially break the driver to remove
1ms of wasted CPU on ifconfig up.
In fact, initialization is and always was done lockless.
So we should be fine there, too, actually.
We don't know why these delays are there all. And we never will.
But as this are all some measuring an calibration routines,
they surely have some purpose. We don't know if longer delays
in some places may have ill effects. Making the whole thing
preemptible (as I am doing / have done) surely has its potential
to break the driver.
I prefer correct operation over an unnoticable 1ms CPU hog.
> > I recently reworked the periodically exectuted workhandlers,
> > so that they are preemptible.
>
> Major classes of users run their kernels without preempt. Please don't
> depend on that to avoid bad behavior.
I am doing a patch atm.
I will add voluntary preemption points, if the kernel is not preemptible.
--
Greetings Michael.
^ permalink raw reply
* Re: [Patch 1/1] AF_UNIX Datagram getpeersec [Updated #2]
From: Xiaolan Zhang @ 2006-06-27 16:22 UTC (permalink / raw)
To: James Morris
Cc: Andrew Morton, chrisw, Catherine Zhang, czhang.us,
David S. Miller, George Wilson, Herbert Xu, jmorris, latten,
netdev, Stephen Smalley, Serge E Hallyn, tjaeger
In-Reply-To: <Pine.LNX.4.64.0606270954080.804@d.namei>
Hi,
Thanks for the updates. I am testing the code now. Some minor fixes (so
far):
changed all
#ifdef CONFIG_SECURITY_NETWORKING
to
#ifdef CONFIG_SECURITY_NETWORK
cheers,
Catherine
James Morris <jmorris@namei.org> wrote on 06/27/2006 09:57:15 AM:
> On Tue, 27 Jun 2006, Stephen Smalley wrote:
>
> > What about saving the u32 seclen with the secdata, and using it later
> > rather than recomputing strlen(secdata)? That also avoids encoding an
> > assumption in the af_unix code about the content of the data (i.e.
> > NUL-terminated string), leaving that to the security module.
>
> Ok, this and other issues are addressed in the patch below, which is now
> back to a single patch.
>
> I also #ifdef'd the security fields in struct unix_skb_parms.
>
> Please review and test.
>
> ---
>
> include/asm-alpha/socket.h | 1 +
> include/asm-arm/socket.h | 1 +
> include/asm-arm26/socket.h | 1 +
> include/asm-cris/socket.h | 1 +
> include/asm-frv/socket.h | 1 +
> include/asm-h8300/socket.h | 1 +
> include/asm-i386/socket.h | 1 +
> include/asm-ia64/socket.h | 1 +
> include/asm-m32r/socket.h | 1 +
> include/asm-m68k/socket.h | 1 +
> include/asm-mips/socket.h | 1 +
> include/asm-parisc/socket.h | 1 +
> include/asm-powerpc/socket.h | 1 +
> include/asm-s390/socket.h | 1 +
> include/asm-sh/socket.h | 1 +
> include/asm-sparc/socket.h | 1 +
> include/asm-sparc64/socket.h | 1 +
> include/asm-v850/socket.h | 1 +
> include/asm-x86_64/socket.h | 1 +
> include/asm-xtensa/socket.h | 1 +
> include/linux/net.h | 1 +
> include/linux/selinux.h | 15 +++++++++++++++
> include/net/af_unix.h | 7 +++++++
> include/net/scm.h | 17 +++++++++++++++++
> net/core/sock.c | 11 +++++++++++
> net/unix/af_unix.c | 25 +++++++++++++++++++++++++
> security/selinux/exports.c | 11 +++++++++++
> security/selinux/hooks.c | 8 +++++++-
> 28 files changed, 114 insertions(+), 1 deletion(-)
>
> diff -purN -X dontdiff linux-2.6.o/include/asm-alpha/socket.h
> linux-2.6.w/include/asm-alpha/socket.h
> --- linux-2.6.o/include/asm-alpha/socket.h 2006-06-21 00:02:08.
> 000000000 -0400
> +++ linux-2.6.w/include/asm-alpha/socket.h 2006-06-27 02:08:49.
> 000000000 -0400
> @@ -51,6 +51,7 @@
> #define SCM_TIMESTAMP SO_TIMESTAMP
>
> #define SO_PEERSEC 30
> +#define SO_PASSSEC 34
>
> /* Security levels - as per NRL IPv6 - don't actually do anything */
> #define SO_SECURITY_AUTHENTICATION 19
> diff -purN -X dontdiff linux-2.6.o/include/asm-arm/socket.h linux-2.
> 6.w/include/asm-arm/socket.h
> --- linux-2.6.o/include/asm-arm/socket.h 2006-06-21 00:02:10.000000000
-0400
> +++ linux-2.6.w/include/asm-arm/socket.h 2006-06-27 02:08:49.000000000
-0400
> @@ -48,5 +48,6 @@
> #define SO_ACCEPTCONN 30
>
> #define SO_PEERSEC 31
> +#define SO_PASSSEC 34
>
> #endif /* _ASM_SOCKET_H */
> diff -purN -X dontdiff linux-2.6.o/include/asm-arm26/socket.h
> linux-2.6.w/include/asm-arm26/socket.h
> --- linux-2.6.o/include/asm-arm26/socket.h 2006-06-21 00:02:10.
> 000000000 -0400
> +++ linux-2.6.w/include/asm-arm26/socket.h 2006-06-27 02:08:49.
> 000000000 -0400
> @@ -48,5 +48,6 @@
> #define SO_ACCEPTCONN 30
>
> #define SO_PEERSEC 31
> +#define SO_PASSSEC 34
>
> #endif /* _ASM_SOCKET_H */
> diff -purN -X dontdiff linux-2.6.o/include/asm-cris/socket.h
> linux-2.6.w/include/asm-cris/socket.h
> --- linux-2.6.o/include/asm-cris/socket.h 2006-06-21 00:02:11.
> 000000000 -0400
> +++ linux-2.6.w/include/asm-cris/socket.h 2006-06-27 02:08:49.
> 000000000 -0400
> @@ -50,6 +50,7 @@
> #define SO_ACCEPTCONN 30
>
> #define SO_PEERSEC 31
> +#define SO_PASSSEC 34
>
> #endif /* _ASM_SOCKET_H */
>
> diff -purN -X dontdiff linux-2.6.o/include/asm-frv/socket.h linux-2.
> 6.w/include/asm-frv/socket.h
> --- linux-2.6.o/include/asm-frv/socket.h 2006-06-21 00:02:11.000000000
-0400
> +++ linux-2.6.w/include/asm-frv/socket.h 2006-06-27 02:08:49.000000000
-0400
> @@ -48,6 +48,7 @@
> #define SO_ACCEPTCONN 30
>
> #define SO_PEERSEC 31
> +#define SO_PASSSEC 34
>
> #endif /* _ASM_SOCKET_H */
>
> diff -purN -X dontdiff linux-2.6.o/include/asm-h8300/socket.h
> linux-2.6.w/include/asm-h8300/socket.h
> --- linux-2.6.o/include/asm-h8300/socket.h 2006-06-21 00:02:11.
> 000000000 -0400
> +++ linux-2.6.w/include/asm-h8300/socket.h 2006-06-27 02:08:49.
> 000000000 -0400
> @@ -48,5 +48,6 @@
> #define SO_ACCEPTCONN 30
>
> #define SO_PEERSEC 31
> +#define SO_PASSSEC 34
>
> #endif /* _ASM_SOCKET_H */
> diff -purN -X dontdiff linux-2.6.o/include/asm-i386/socket.h
> linux-2.6.w/include/asm-i386/socket.h
> --- linux-2.6.o/include/asm-i386/socket.h 2006-06-21 00:02:12.
> 000000000 -0400
> +++ linux-2.6.w/include/asm-i386/socket.h 2006-06-27 02:08:49.
> 000000000 -0400
> @@ -48,5 +48,6 @@
> #define SO_ACCEPTCONN 30
>
> #define SO_PEERSEC 31
> +#define SO_PASSSEC 34
>
> #endif /* _ASM_SOCKET_H */
> diff -purN -X dontdiff linux-2.6.o/include/asm-ia64/socket.h
> linux-2.6.w/include/asm-ia64/socket.h
> --- linux-2.6.o/include/asm-ia64/socket.h 2006-06-21 00:02:12.
> 000000000 -0400
> +++ linux-2.6.w/include/asm-ia64/socket.h 2006-06-27 02:08:49.
> 000000000 -0400
> @@ -57,5 +57,6 @@
> #define SO_ACCEPTCONN 30
>
> #define SO_PEERSEC 31
> +#define SO_PASSSEC 34
>
> #endif /* _ASM_IA64_SOCKET_H */
> diff -purN -X dontdiff linux-2.6.o/include/asm-m32r/socket.h
> linux-2.6.w/include/asm-m32r/socket.h
> --- linux-2.6.o/include/asm-m32r/socket.h 2006-06-21 00:02:13.
> 000000000 -0400
> +++ linux-2.6.w/include/asm-m32r/socket.h 2006-06-27 02:08:49.
> 000000000 -0400
> @@ -48,5 +48,6 @@
> #define SO_ACCEPTCONN 30
>
> #define SO_PEERSEC 31
> +#define SO_PASSSEC 34
>
> #endif /* _ASM_M32R_SOCKET_H */
> diff -purN -X dontdiff linux-2.6.o/include/asm-m68k/socket.h
> linux-2.6.w/include/asm-m68k/socket.h
> --- linux-2.6.o/include/asm-m68k/socket.h 2006-06-21 00:02:13.
> 000000000 -0400
> +++ linux-2.6.w/include/asm-m68k/socket.h 2006-06-27 02:08:49.
> 000000000 -0400
> @@ -48,5 +48,6 @@
> #define SO_ACCEPTCONN 30
>
> #define SO_PEERSEC 31
> +#define SO_PASSSEC 34
>
> #endif /* _ASM_SOCKET_H */
> diff -purN -X dontdiff linux-2.6.o/include/asm-mips/socket.h
> linux-2.6.w/include/asm-mips/socket.h
> --- linux-2.6.o/include/asm-mips/socket.h 2006-06-21 00:02:15.
> 000000000 -0400
> +++ linux-2.6.w/include/asm-mips/socket.h 2006-06-27 02:08:49.
> 000000000 -0400
> @@ -69,6 +69,7 @@ To add: #define SO_REUSEPORT 0x0200 /* A
> #define SO_PEERSEC 30
> #define SO_SNDBUFFORCE 31
> #define SO_RCVBUFFORCE 33
> +#define SO_PASSSEC 34
>
> #ifdef __KERNEL__
>
> diff -purN -X dontdiff linux-2.6.o/include/asm-parisc/socket.h
> linux-2.6.w/include/asm-parisc/socket.h
> --- linux-2.6.o/include/asm-parisc/socket.h 2006-06-21 00:02:15.
> 000000000 -0400
> +++ linux-2.6.w/include/asm-parisc/socket.h 2006-06-27 02:08:49.
> 000000000 -0400
> @@ -48,5 +48,6 @@
> #define SO_ACCEPTCONN 0x401c
>
> #define SO_PEERSEC 0x401d
> +#define SO_PASSSEC 0x401e
>
> #endif /* _ASM_SOCKET_H */
> diff -purN -X dontdiff linux-2.6.o/include/asm-powerpc/socket.h
> linux-2.6.w/include/asm-powerpc/socket.h
> --- linux-2.6.o/include/asm-powerpc/socket.h 2006-06-21 00:02:16.
> 000000000 -0400
> +++ linux-2.6.w/include/asm-powerpc/socket.h 2006-06-27 02:08:49.
> 000000000 -0400
> @@ -55,5 +55,6 @@
> #define SO_ACCEPTCONN 30
>
> #define SO_PEERSEC 31
> +#define SO_PASSSEC 34
>
> #endif /* _ASM_POWERPC_SOCKET_H */
> diff -purN -X dontdiff linux-2.6.o/include/asm-s390/socket.h
> linux-2.6.w/include/asm-s390/socket.h
> --- linux-2.6.o/include/asm-s390/socket.h 2006-06-21 00:02:17.
> 000000000 -0400
> +++ linux-2.6.w/include/asm-s390/socket.h 2006-06-27 02:08:49.
> 000000000 -0400
> @@ -56,5 +56,6 @@
> #define SO_ACCEPTCONN 30
>
> #define SO_PEERSEC 31
> +#define SO_PASSSEC 34
>
> #endif /* _ASM_SOCKET_H */
> diff -purN -X dontdiff linux-2.6.o/include/asm-sh/socket.h linux-2.
> 6.w/include/asm-sh/socket.h
> --- linux-2.6.o/include/asm-sh/socket.h 2006-06-21 00:02:17.000000000
-0400
> +++ linux-2.6.w/include/asm-sh/socket.h 2006-06-27 02:08:49.000000000
-0400
> @@ -48,5 +48,6 @@
> #define SO_ACCEPTCONN 30
>
> #define SO_PEERSEC 31
> +#define SO_PASSSEC 34
>
> #endif /* __ASM_SH_SOCKET_H */
> diff -purN -X dontdiff linux-2.6.o/include/asm-sparc/socket.h
> linux-2.6.w/include/asm-sparc/socket.h
> --- linux-2.6.o/include/asm-sparc/socket.h 2006-06-21 00:02:18.
> 000000000 -0400
> +++ linux-2.6.w/include/asm-sparc/socket.h 2006-06-27 02:08:49.
> 000000000 -0400
> @@ -48,6 +48,7 @@
> #define SCM_TIMESTAMP SO_TIMESTAMP
>
> #define SO_PEERSEC 0x001e
> +#define SO_PASSSEC 0x001f
>
> /* Security levels - as per NRL IPv6 - don't actually do anything */
> #define SO_SECURITY_AUTHENTICATION 0x5001
> diff -purN -X dontdiff linux-2.6.o/include/asm-sparc64/socket.h
> linux-2.6.w/include/asm-sparc64/socket.h
> --- linux-2.6.o/include/asm-sparc64/socket.h 2006-06-21 00:02:19.
> 000000000 -0400
> +++ linux-2.6.w/include/asm-sparc64/socket.h 2006-06-27 02:08:49.
> 000000000 -0400
> @@ -48,6 +48,7 @@
> #define SCM_TIMESTAMP SO_TIMESTAMP
>
> #define SO_PEERSEC 0x001e
> +#define SO_PASSSEC 0x001f
>
> /* Security levels - as per NRL IPv6 - don't actually do anything */
> #define SO_SECURITY_AUTHENTICATION 0x5001
> diff -purN -X dontdiff linux-2.6.o/include/asm-v850/socket.h
> linux-2.6.w/include/asm-v850/socket.h
> --- linux-2.6.o/include/asm-v850/socket.h 2006-06-21 00:02:20.
> 000000000 -0400
> +++ linux-2.6.w/include/asm-v850/socket.h 2006-06-27 02:08:49.
> 000000000 -0400
> @@ -48,5 +48,6 @@
> #define SO_ACCEPTCONN 30
>
> #define SO_PEERSEC 31
> +#define SO_PASSSEC 34
>
> #endif /* __V850_SOCKET_H__ */
> diff -purN -X dontdiff linux-2.6.o/include/asm-x86_64/socket.h
> linux-2.6.w/include/asm-x86_64/socket.h
> --- linux-2.6.o/include/asm-x86_64/socket.h 2006-06-21 00:02:20.
> 000000000 -0400
> +++ linux-2.6.w/include/asm-x86_64/socket.h 2006-06-27 02:08:49.
> 000000000 -0400
> @@ -48,5 +48,6 @@
> #define SO_ACCEPTCONN 30
>
> #define SO_PEERSEC 31
> +#define SO_PASSSEC 34
>
> #endif /* _ASM_SOCKET_H */
> diff -purN -X dontdiff linux-2.6.o/include/asm-xtensa/socket.h
> linux-2.6.w/include/asm-xtensa/socket.h
> --- linux-2.6.o/include/asm-xtensa/socket.h 2006-06-21 00:02:21.
> 000000000 -0400
> +++ linux-2.6.w/include/asm-xtensa/socket.h 2006-06-27 02:08:49.
> 000000000 -0400
> @@ -59,5 +59,6 @@
>
> #define SO_ACCEPTCONN 30
> #define SO_PEERSEC 31
> +#define SO_PASSSEC 34
>
> #endif /* _XTENSA_SOCKET_H */
> diff -purN -X dontdiff linux-2.6.o/include/linux/net.h linux-2.6.
> w/include/linux/net.h
> --- linux-2.6.o/include/linux/net.h 2006-06-21 00:02:23.000000000
-0400
> +++ linux-2.6.w/include/linux/net.h 2006-06-27 02:08:49.000000000
-0400
> @@ -61,6 +61,7 @@ typedef enum {
> #define SOCK_ASYNC_WAITDATA 1
> #define SOCK_NOSPACE 2
> #define SOCK_PASSCRED 3
> +#define SOCK_PASSSEC 4
>
> #ifndef ARCH_HAS_SOCKET_TYPES
> /**
> diff -purN -X dontdiff linux-2.6.o/include/linux/selinux.h linux-2.
> 6.w/include/linux/selinux.h
> --- linux-2.6.o/include/linux/selinux.h 2006-06-21 00:02:23.000000000
-0400
> +++ linux-2.6.w/include/linux/selinux.h 2006-06-27 02:18:47.000000000
-0400
> @@ -18,6 +18,7 @@ struct selinux_audit_rule;
> struct audit_context;
> struct inode;
> struct kern_ipc_perm;
> +struct socket;
>
> #ifdef CONFIG_SECURITY_SELINUX
>
> @@ -119,6 +120,15 @@ void selinux_get_ipc_sid(const struct ke
> void selinux_get_task_sid(struct task_struct *tsk, u32 *sid);
>
> /**
> + * selinux_get_sock_sid - return the SID of socket
> + * @sock: the socket whose SID will be returned
> + * @sid: pointer to security context ID to be filled in.
> + *
> + * Returns nothing
> + */
> +void selinux_get_sock_sid(struct socket *sock, u32 *sid);
> +
> +/**
> * selinux_string_to_sid - map a security context string to a
security ID
> * @str: the security context string to be mapped
> * @sid: ID value returned via this.
> @@ -193,6 +203,11 @@ static inline void selinux_get_task_sid(
> *sid = 0;
> }
>
> +static inline void selinux_get_sock_sid(struct socket *sock, u32 *sid)
> +{
> + *sid = 0;
> +}
> +
> static inline int selinux_string_to_sid(const char *str, u32 *sid)
> {
> *sid = 0;
> diff -purN -X dontdiff linux-2.6.o/include/net/af_unix.h linux-2.6.
> w/include/net/af_unix.h
> --- linux-2.6.o/include/net/af_unix.h 2006-06-21 00:02:24.000000000
-0400
> +++ linux-2.6.w/include/net/af_unix.h 2006-06-27 09:28:04.000000000
-0400
> @@ -53,10 +53,17 @@ struct unix_address {
> struct unix_skb_parms {
> struct ucred creds; /* Skb credentials */
> struct scm_fp_list *fp; /* Passed files */
> +#ifdef CONFIG_SECURITY_NETWORKING
> + char *secdata; /* Security context */
> + u32 seclen; /* Security length */
> +#endif
> +
> };
>
> #define UNIXCB(skb) (*(struct unix_skb_parms*)&((skb)->cb))
> #define UNIXCREDS(skb) (&UNIXCB((skb)).creds)
> +#define UNIXSECDATA(skb) (&UNIXCB((skb)).secdata)
> +#define UNIXSECLEN(skb) (&UNIXCB((skb)).seclen)
>
> #define unix_state_rlock(s) spin_lock(&unix_sk(s)->lock)
> #define unix_state_runlock(s) spin_unlock(&unix_sk(s)->lock)
> diff -purN -X dontdiff linux-2.6.o/include/net/scm.h linux-2.6.
> w/include/net/scm.h
> --- linux-2.6.o/include/net/scm.h 2006-06-21 00:02:24.000000000 -0400
> +++ linux-2.6.w/include/net/scm.h 2006-06-27 09:32:27.000000000 -0400
> @@ -19,6 +19,10 @@ struct scm_cookie
> {
> struct ucred creds; /* Skb credentials */
> struct scm_fp_list *fp; /* Passed files */
> +#ifdef CONFIG_SECURITY_NETWORK
> + char *secdata; /* Security context */
> + u32 seclen; /* Security length */
> +#endif
> unsigned long seq; /* Connection seqno */
> };
>
> @@ -48,6 +52,17 @@ static __inline__ int scm_send(struct so
> return __scm_send(sock, msg, scm);
> }
>
> +#ifdef CONFIG_SECURITY_NETWORK
> +static inline void scm_passec(struct socket *sock, struct msghdr
> *msg, struct scm_cookie *scm)
> +{
> + if (test_bit(SOCK_PASSSEC, &sock->flags) && scm->secdata != NULL)
> + put_cmsg(msg, SOL_SOCKET, SCM_SECURITY, scm->seclen,
scm->secdata);
> +}
> +#else
> +static inline void scm_passec(struct socket *sock, struct msghdr
> *msg, struct scm_cookie *scm)
> +{ }
> +#endif /* CONFIG_SECURITY_NETWORK */
> +
> static __inline__ void scm_recv(struct socket *sock, struct msghdr
*msg,
> struct scm_cookie *scm, int flags)
> {
> @@ -62,6 +77,8 @@ static __inline__ void scm_recv(struct s
> if (test_bit(SOCK_PASSCRED, &sock->flags))
> put_cmsg(msg, SOL_SOCKET, SCM_CREDENTIALS,
> sizeof(scm->creds), &scm->creds);
>
> + scm_passec(sock, msg, scm);
> +
> if (!scm->fp)
> return;
>
> diff -purN -X dontdiff linux-2.6.o/net/core/sock.c
linux-2.6.w/net/core/sock.c
> --- linux-2.6.o/net/core/sock.c 2006-06-21 00:02:27.000000000 -0400
> +++ linux-2.6.w/net/core/sock.c 2006-06-27 02:08:49.000000000 -0400
> @@ -565,6 +565,13 @@ set_rcvbuf:
> ret = -ENONET;
> break;
>
> + case SO_PASSSEC:
> + if (valbool)
> + set_bit(SOCK_PASSSEC, &sock->flags);
> + else
> + clear_bit(SOCK_PASSSEC, &sock->flags);
> + break;
> +
> /* We implement the SO_SNDLOWAT etc to
> not be settable (1003.1g 5.3) */
> default:
> @@ -723,6 +730,10 @@ int sock_getsockopt(struct socket *sock,
> v.val = sk->sk_state == TCP_LISTEN;
> break;
>
> + case SO_PASSSEC:
> + v.val = test_bit(SOCK_PASSSEC, &sock->flags) ? 1 : 0;
> + break;
> +
> case SO_PEERSEC:
> return security_socket_getpeersec_stream(sock, optval, optlen,
len);
>
> diff -purN -X dontdiff linux-2.6.o/net/unix/af_unix.c linux-2.6.
> w/net/unix/af_unix.c
> --- linux-2.6.o/net/unix/af_unix.c 2006-06-21 00:02:30.000000000 -0400
> +++ linux-2.6.w/net/unix/af_unix.c 2006-06-27 09:30:12.000000000 -0400
> @@ -128,6 +128,28 @@ static atomic_t unix_nr_socks = ATOMIC_I
>
> #define UNIX_ABSTRACT(sk) (unix_sk(sk)->addr->hash != UNIX_HASH_SIZE)
>
> +#ifdef CONFIG_SECURITY_NETWORKING
> +static void unix_get_peersec_dgram(struct sk_buff *skb)
> +{
> + err = security_socket_getpeersec_dgram(skb, UNIXSECDATA(skb),
> + UNIXSECLEN(skb));
> + if (err)
> + *(UNIXSEC(skb)) = NULL;
> +}
> +
> +static inline void unix_set_secdata(struct scm_cookie *scm, struct
> sk_buff *skb)
> +{
> + scm->secdata = *UNIXSECDATA(skb);
> + scm->seclen = UNIXSECLEN(skb);
> +}
> +#else
> +static void unix_get_peersec_dgram(struct sk_buff *skb)
> +{ }
> +
> +static inline void unix_set_secdata(struct scm_cookie *scm, struct
> sk_buff *skb)
> +{ }
> +#endif /* CONFIG_SECURITY_NETWORKING */
> +
> /*
> * SMP locking strategy:
> * hash table is protected with spinlock unix_table_lock
> @@ -1291,6 +1313,8 @@ static int unix_dgram_sendmsg(struct kio
> if (siocb->scm->fp)
> unix_attach_fds(siocb->scm, skb);
>
> + unix_get_peersec_dgram(skb);
> +
> skb->h.raw = skb->data;
> err = memcpy_fromiovec(skb_put(skb,len), msg->msg_iov, len);
> if (err)
> @@ -1570,6 +1594,7 @@ static int unix_dgram_recvmsg(struct kio
> memset(&tmp_scm, 0, sizeof(tmp_scm));
> }
> siocb->scm->creds = *UNIXCREDS(skb);
> + unix_set_secdata(siocb->scm, skb);
>
> if (!(flags & MSG_PEEK))
> {
> diff -purN -X dontdiff linux-2.6.o/security/selinux/exports.c
> linux-2.6.w/security/selinux/exports.c
> --- linux-2.6.o/security/selinux/exports.c 2006-06-21 00:02:31.
> 000000000 -0400
> +++ linux-2.6.w/security/selinux/exports.c 2006-06-27 02:19:16.
> 000000000 -0400
> @@ -17,6 +17,7 @@
> #include <linux/selinux.h>
> #include <linux/fs.h>
> #include <linux/ipc.h>
> +#include <net/sock.h>
>
> #include "security.h"
> #include "objsec.h"
> @@ -72,6 +73,16 @@ void selinux_get_task_sid(struct task_st
> *sid = 0;
> }
>
> +void selinux_get_sock_sid(struct socket *sock, u32 *sid)
> +{
> + if (selinux_enabled) {
> + const struct inode *inode = SOCK_INODE(sock);
> + selinux_get_inode_sid(inode, sid);
> + return;
> + }
> + *sid = 0;
> +}
> +
> int selinux_string_to_sid(char *str, u32 *sid)
> {
> if (selinux_enabled)
> diff -purN -X dontdiff linux-2.6.o/security/selinux/hooks.c linux-2.
> 6.w/security/selinux/hooks.c
> --- linux-2.6.o/security/selinux/hooks.c 2006-06-26 14:47:31.000000000
-0400
> +++ linux-2.6.w/security/selinux/hooks.c 2006-06-27 02:08:49.000000000
-0400
> @@ -69,6 +69,7 @@
> #include <linux/sysctl.h>
> #include <linux/audit.h>
> #include <linux/string.h>
> +#include <linux/selinux.h>
>
> #include "avc.h"
> #include "objsec.h"
> @@ -3418,7 +3419,12 @@ out:
> static int selinux_socket_getpeersec_dgram(struct sk_buff *skb,
> char **secdata, u32 *seclen)
> {
> int err = 0;
> - u32 peer_sid = selinux_socket_getpeer_dgram(skb);
> + u32 peer_sid;
> +
> + if (skb->sk->sk_family == PF_UNIX)
> + selinux_get_sock_sid(skb->sk->sk_socket, &peer_sid);
> + else
> + peer_sid = selinux_socket_getpeer_dgram(skb);
>
> if (peer_sid == SECSID_NULL)
> return -EINVAL;
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Andrey Savochkin @ 2006-06-27 16:19 UTC (permalink / raw)
To: Herbert Poetzl
Cc: Eric W. Biederman, Daniel Lezcano, linux-kernel, netdev, serue,
haveblue, clg, Andrew Morton, dev, devel, sam, viro,
Alexey Kuznetsov
In-Reply-To: <20060627154818.GA28984@MAIL.13thfloor.at>
Herbert,
On Tue, Jun 27, 2006 at 05:48:19PM +0200, Herbert Poetzl wrote:
> On Tue, Jun 27, 2006 at 01:09:11PM +0400, Andrey Savochkin wrote:
> >
> > On Mon, Jun 26, 2006 at 10:02:25PM +0200, Herbert Poetzl wrote:
> > >
> > > - traffic between guests
> > > can be as high (or even higher) than the
> > > outbound traffic, just think web guest and
> > > database guest
> >
> > My experience with host-guest systems tells me the opposite: outside
> > traffic is a way higher than traffic between guests. People put web
> > server and database in different guests not more frequent than they
> > put them on separate physical server. Unless people are building a
> > really huge system when 1 server can't take the whole load, web and
> > database live together and benefit from communications over UNIX
> > sockets.
>
> well, that's probably because you (or your company)
> focuses on providers which simply (re)sell the entities
> to their customers, in which case it would be more
> expensive to put e.g. the database into a separate
> guest. but let me state here that this is not the only
> application for this technology
I'm just sharing my experience.
You have one experience, I have another, and your classification of traffic
importance is not the universal one.
My point was that we shouldn't overestimate the use of INET sockets vs. UNIX
ones in configurations where communications but not web/db operations play a
big role in overall performance.
And indeed I've talked with many different people, from universities to
large enterprises.
>
[snip]
> > I'd like to caution about over-optimizing communications between
> > different network namespaces. Many optimizations of local traffic
> > (such as high MTU) don't look so appealing when you start to think
> > about live migration of namespaces.
>
> I think the 'optimization' (or to be precise: desire
> not to sacrifice local/loopback traffic for some use
> case as you describe it) does not interfere with live
> migration at all, we still will have 'local' and 'remote'
> traffic, and personally I doubt that the live migration
> is a feature for the masses ...
Why not for the masses?
Andrey
^ permalink raw reply
* Re: [PATCH 17/21] e1000: add ich8lan core functions
From: Auke Kok @ 2006-06-27 16:12 UTC (permalink / raw)
To: Jeff Garzik
Cc: Kok, Auke, netdev, Brandeburg, Jesse, Kok, Auke, Ronciak, John
In-Reply-To: <44A08F59.6030700@pobox.com>
Jeff Garzik wrote:
> Kok, Auke wrote:
>> This implements the core new functions needed for ich8's internal
>> NIC. This includes:
>>
>> * ich8 specific read/write code
>> * flash/nvm access code
>> * software semaphore flag functions
>> * 10/100 PHY (fe - no gigabit speed) support for low-end versions
>> * A workaround for a powerdown sequence problem discovered that
>> affects a small number of motherboard.
>>
>> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
>> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
>> ---
>>
>> drivers/net/e1000/e1000_hw.c | 1000
>> +++++++++++++++++++++++++++++++++++++++
>> drivers/net/e1000/e1000_hw.h | 386 +++++++++++++++
>> drivers/net/e1000/e1000_osdep.h | 13 +
>> 3 files changed, 1392 insertions(+), 7 deletions(-)
>
> If it takes this much code to support ICH8, it seems like a e1000-ich8.c
> would be warranted...
that's work in progress - Jeb Cramer has been working on this for a while now
but unfortunately it's not ready, and getting ich8 supported in a way that we
know that doesn't introduce new bugs is more important. This patch adds tested
and validated support for these chipsets that has been hammered by our test team.
We are planning (working) on cleaning it all up (including whitespace!) - but
getting the ich8 support out is more important - people can buy the hardware
today.
Cheers,
Auke
^ permalink raw reply
* Re: Please pull 'upstream' branch of wireless-2.6
From: Jeff Garzik @ 2006-06-27 16:12 UTC (permalink / raw)
To: Michael Buesch; +Cc: bcm43xx-dev, Larry Finger, John W. Linville, netdev
In-Reply-To: <200606271725.26037.mb@bu3sch.de>
Michael Buesch wrote:
> So, I will submit a patch to lower the udelay(10) to udelay(1)
> and we can close the discussion? ;)
No, that totally avoids my point. Your "otherwise idle machine" test is
probably nowhere near worst case in the field, for loops that can
potentially lock the CPU for a long time upon hardware fault. And then
there are the huge delays in specific functions that I pointed out...
Jeff
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Ben Greear @ 2006-06-27 16:07 UTC (permalink / raw)
To: Ben Greear
Cc: Herbert Poetzl, Eric W. Biederman, Daniel Lezcano,
Andrey Savochkin, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, devel, sam, viro, Alexey Kuznetsov
In-Reply-To: <44A068E7.6080403@candelatech.com>
Ben Greear wrote:
> Herbert Poetzl wrote:
>
>> On Mon, Jun 26, 2006 at 03:13:17PM -0700, Ben Greear wrote:
>
>
>> yes, that sounds good to me, any numbers how that
>> affects networking in general (performance wise and
>> memory wise, i.e. caches and hashes) ...
>
>
> I'll run some tests later today. Based on my previous tests,
> I don't remember any significant overhead.
Here's a quick benchmark using my redirect devices (RDD). Each
RDD comes in a pair...when you tx on one, the pkt is rx'd on the peer.
The idea is that it is exactly like two physical ethernet interfaces
connected by a cross-over cable.
My test system is a 64-bit dual-core Intel system, 3.013 Ghz processor with 1GB RAM.
Fairly standard stuff..it's one of the Shuttle XPC systems.
Kernel is 2.6.16.16 (64-bit).
Test setup is: rdd1 -- rdd2 [bridge] rdd3 -- rdd4
I am using my proprietary module for the bridge logic...and the default
bridge should be at least this fast. I am injecting 1514 byte packets
on rdd1 and rdd4 with pktgen (bi-directional flow). My pktgen is also
receiving the pkts and gathering stats.
This setup sustains 1.7Gbps of generated and received traffic between
rdd1 and rdd4.
Running only the [bridge] between two 10/100/1000 ports on an Intel PCI-E
NIC will sustain about 870Mbps (bi-directional) on this system, so the
virtual devices are quite efficient, as suspected.
I have not yet had time to benchmark the mac-vlans...hopefully later today.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Please pull 'upstream' branch of wireless-2.6
From: Jeff Garzik @ 2006-06-27 16:10 UTC (permalink / raw)
To: Michael Buesch; +Cc: bcm43xx-dev, Larry Finger, John W. Linville, netdev
In-Reply-To: <200606271636.08473.mb@bu3sch.de>
Michael Buesch wrote:
> On Tuesday 27 June 2006 16:11, Jeff Garzik wrote:
>> Overall, bcm43xx is _really really bad_ about this sort of thing. Just
>> grepping for udelay in bcm43xx_radio.c shows some of the worst
>> offenders. bcm43xx_radio_init2060() and bcm43xx_radio_selectchannel()
>> both look like candidates for using msleep() rather than udelay().
>
> This is _all_ at initialization time.
> select_channel.... How often do you select a channel?
That question is irrelevant, because you have no idea what -else- is
going on in the system, at the point when bcm43xx chooses to spin the
CPU heavily.
Initialization time means you are definitely not in a hot path, and can
therefore sleep.
> I recently reworked the periodically exectuted workhandlers,
> so that they are preemptible.
Major classes of users run their kernels without preempt. Please don't
depend on that to avoid bad behavior.
> mac_suspend():
> It is always called in atomic context with IRQs disabled.
> We need to wait for the device here to signal "OK, MAC is down
> now and you can count on it". This takes a few usecs. I guess
> it sends out all queued packets, or whatever. We don't know
> really.
> I can actually measure how long it takes, if you really desire
> it.
> We _need_ to wait there. It is something like synchronize_irq(), or
> whatever. It is a synchronizing function and we need it to be
> synchronizing.
> And I don't think it is worth the pain to insert a preemption
> point there (or doing even fancier things with workqueues and
> completions).
>
> Overall, I don't think bcm43xx is still so bad at
> wasting CPU. Maybe we should still insert some voluntary
> preemption points, if the bcm43xx user does not run a fully
> preemptible kernel. But if a fully preemptible kernel is run,
> I think it is all OK.
Never assume a preemptible kernel will clean up problems for you :)
Jeff
^ permalink raw reply
* Re: [PATCH 1/3] mv643xx fixes - Disable interrupts on all ports during initialization
From: Nathaniel Case @ 2006-06-27 16:09 UTC (permalink / raw)
To: John Haller; +Cc: Brent Cook, netdev
In-Reply-To: <44A14BCC.5060708@lucent.com>
On Tue, 2006-06-27 at 10:16 -0500, John Haller wrote:
> Brent Cook wrote:
> > This patch disable interrupts on all ports during initialization. The current
> > assumes that the firmware has already disabled all interrupts on all ports.
> > We have encountered some boards that do not always disable interrupts (XES
> > XPedite 6200 for instance) on a soft reset. This patch prevents a kernel
> > panic if a packet is received before the DMA ring buffers are setup for a
> > port on which interrupts are left enabled by the firmware.
> You probably have bigger problems than the interrupt being left
> enabled. If the interrupt is left enabled, the DMA engine
> is probably left enabled, and if a packet happens
> to come in before the driver can properly configure them,
> some random part of memory will get overwritten.
> The firmware needs to disable this device before transferring
> control to the kernel, both the interrupts and the DMA,
> there is no way to fix this in the kernel.
I agree that the patch isn't the best fix for this problem.
Brent, for this particular case, I believe there's chip errata for the
Discovery bridge preventing it from resetting itself when the board
resets itself in non-monarch mode. That's why interrupts are left
enabled. This issue should never crop up if the board is monarch on the
PCI bus.
So the proper workaround would be for our firmware to account for this
case and disable interrupts, ethernet, etc. on a soft non-monarch reset.
We could also do this in the boot wrapper code as a safety measure.
Also, note that the firmware _will_ already explicitly disable ethernet
before transferring control over to the OS _if_ you're booting over
ethernet instead of flash.
- Nate Case <ncase@xes-inc.com>
^ 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