* Re: Please pull 'upstream' branch of wireless-2.6
From: Michael Buesch @ 2006-06-28 14:34 UTC (permalink / raw)
To: Larry Finger; +Cc: John W. Linville, netdev
In-Reply-To: <44A19712.40702@lwfinger.net>
On Tuesday 27 June 2006 22:37, Larry Finger wrote:
> Michael Buesch wrote:
> > On Tuesday 27 June 2006 22:06, Larry Finger wrote:
> >> John,
> >>
> >> I would like to find a diplomatic solution to this impasse between Michael and Jeff, which is why
> >> I'm writing to you privately. Michael is correct in that the loop in question will not usually delay
> >
> > private?
>
> I meant it to be private, but screwed up.
>
> >> long; however, on some hardware it takes longer than on his. On mine, I have seen delays as long as
> >> 550 usec.
> >
> > What's the chip?
>
> bcm43xx: Chip ID 0x4306, rev 0x2
> bcm43xx: Number of cores: 6
> bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled
> bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, disabled
> bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled
> bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled
> bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled
> bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled
> bcm43xx: Ignoring additional 802.11 core.
> bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1
> bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
It appears to be an older card. There are quite some
special codepaths for this, I think.
> >> This would make the worst-case delay be 5 msec, but would provide a cushion of 10X the longest I
> >> have seen and should be safe.
> >>
> >> Do you have any suggestions on what should be done next?
> >
> > Leave it as is and find out why it takes so long for your strange card. ;)
>
> I once offered you my second, duplicate card for testing, but never heard back. Do you have any
> ideas regarding diagnostics to see why it takes so long? Remember, this card used to time-out on the
> 1 second delay before the periodic work was restructured.
Well, we did not want to have the card, because at this point
it did not make sense. We all have 4306 cards.
But now it appears that this card seems to have some special
things (because it is older than ours).
Well, how to debug.
We are waiting for the IRQ Reason register there.
Actually, we are waiting for the "no IRQ pending, but READY signal"
state. Your card does not completely (?) clear the bits after MAC
shutdown. So very helpful would be to print out in the loop the
value. We know, that the card generates silly IRQs, that we did
not ask for. That may happen here, too. So it _may_ help to
mask out unwanted IRQs before the if-check. But I would first
like to see a log of the reason-value on each iteration until it succeeds.
--
Greetings Michael.
^ permalink raw reply
* Re: TOE, etc. (was Re: [PATCH Round 3 0/2][RFC] Network Event Notifier Mechanism)
From: Steve Wise @ 2006-06-28 14:31 UTC (permalink / raw)
To: Herbert Xu; +Cc: Jeff Garzik, davem, netdev
In-Reply-To: <20060628042959.GA5561@gondor.apana.org.au>
On Wed, 2006-06-28 at 14:29 +1000, Herbert Xu wrote:
> On Wed, Jun 28, 2006 at 12:18:25AM -0400, Jeff Garzik wrote:
> >
> > A PCI device that presents itself as a SCSI controller, but under the
> > hood is really iSCSI-over-TCP smells like TOE. Running a virtualized
> > Linux guest on top of a proprietary stack [which provides networking
> > services to guests] also smells like TOE. :)
>
> Agreed. However, when they start adding hooks to the ARP table, the
> routing table, and PMTU management, it begs the question what more is
> there to add for TOE (well, user-space driven TOE at least)?
>
> > Unfortunately I don't have more details, so you just get a generalized
> > rant :)
>
> OK, the patch under discussion here adds hooks to all the stuff in the
> previous paragraph for the purpose of RDMA over TCP (well I must say
> that the exact RDMA application/hardware has never been clearly given
> but this is what I can gather from the previous posts).
There are Ammasso and Chelsio RDMA/Ethernet drivers in the openib.org
svn iwarp branch today. The goal is to submit them for review and
inclusion into linux. The Ammasso driver has been through 3 review
cycles on lkml and netdev. There are other vendors with drivers, but
they're currently not disclosing any information to me about their
status.
Applications:
kernel: NFS-RDMA, iSER, RDP.
user: MPI, uDAPL (both middle ware).
The Ammasso driver is a different model. It actually has a full
TCP/ARP/ICMP stack and doesn't require these hooks. But the RDMA/TCP
model defined and implemented, I think, by most vendors is a model where
the HW is doing a limited TCP offload, relying on the native stack for
L2 and L3 integration (as described in the netevent patch).
> Put it another way, I think the dividing line between TOE and iSCSI or
> virtualisation is exactly the interface between them and the Linux kernel.
> If the interface is an existing one such as SCSI or standard IP then it's
> OK. However, when it starts poking in the guts of the Linux stack I'd say
> that it has crossed the line.
>
Don't these netevent hooks have utility for other purposes? IE: Should
we really shoot changes to linux _just because_ they might possibly
enable TOE?
Steve.
^ permalink raw reply
* Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
From: Andrey Savochkin @ 2006-06-28 14:30 UTC (permalink / raw)
To: Daniel Lezcano
Cc: linux-kernel, netdev, serue, haveblue, clg, Andrew Morton, dev,
herbert, devel, sam, ebiederm, viro, alexey
In-Reply-To: <44A28964.2090006@fr.ibm.com>
Daniel,
On Wed, Jun 28, 2006 at 03:51:32PM +0200, Daniel Lezcano wrote:
> Daniel Lezcano wrote:
> > Andrey Savochkin wrote:
> >
> >> Structures related to IPv4 rounting (FIB and routing cache)
> >> are made per-namespace.
>
> Hi Andrey,
>
> if the ressources are private to the namespace, how do you will handle
> NFS mounted before creating the network namespace ? Do you take care of
> that or simply assume you can't access NFS anymore ?
This is a question that brings up another level of interaction between
networking and the rest of kernel code.
Solution that I use now makes the NFS communication part always run in
the root namespace. This is discussable, of course, but it's a far more
complicated matter than just device lists or routing :)
Best regards
Andrey
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Eric W. Biederman @ 2006-06-28 14:21 UTC (permalink / raw)
To: Herbert Poetzl
Cc: Alexey Kuznetsov, Dave Hansen, Ben Greear, Daniel Lezcano,
Andrey Savochkin, linux-kernel, netdev, serue, clg, Andrew Morton,
dev, devel, sam, viro, Alexey Kuznetsov
In-Reply-To: <20060628133640.GB5088@MAIL.13thfloor.at>
Herbert Poetzl <herbert@13thfloor.at> writes:
> last time I pointed to such 'misguided' apps which
> made assumptions that are not necessarily true
> inside a virtual environment (e.g. pstree, initpid)
> the general? position was that those apps should
> be fixed instead adding a 'workaround'
I agree that if it was solely misguided apps. There would be
no justification.
One of the standard applications interfaces we support is renaming
a network interface. So supporting those misguided apps is a actually
a side effect of supporting one the standard operations on a network interface.
Another way of looking at it is that the names of networking devices like the
names of devices in /dev are a user space policy (today). In the
configuration of the networking stack historically we had those identifiers
hard coded. It isn't until just recently that user space has been able to
cope with dynamically added/removed network devices.
As for initpid and friends. In the context where you are simply isolating
pids and not doing a full pid namespaces it was felt that changing the few
user space applications that care was easier and probably worth doing anyway.
> note: personally I'm absolutely not against virtualizing
> the device names so that each guest can have a separate
> name space for devices, but there should be a way to
> 'see' _and_ 'identify' the interfaces from outside
> (i.e. host or spectator context)
Yep. Basically that interface comes when we fix the sysfs support,
to support per namespace reporting.
Eric
^ permalink raw reply
* Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
From: Herbert Poetzl @ 2006-06-28 14:19 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Andrey Savochkin, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, devel, sam, ebiederm, viro
In-Reply-To: <44A28964.2090006@fr.ibm.com>
On Wed, Jun 28, 2006 at 03:51:32PM +0200, Daniel Lezcano wrote:
> Daniel Lezcano wrote:
> >Andrey Savochkin wrote:
> >
> >>Structures related to IPv4 rounting (FIB and routing cache)
> >>are made per-namespace.
>
> Hi Andrey,
>
> if the ressources are private to the namespace, how do you will
> handle NFS mounted before creating the network namespace ?
> Do you take care of that or simply assume you can't access NFS anymore ?
considering that many providers put their guests
on NFS (or similar) filers, and run them on nodes
(for distributing the CPU load), that is indeed an
interesting question ...
what will happen to AOE or iSCSI btw?
best,
Herbert
> Regards
>
> -Daniel
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Andrey Savochkin @ 2006-06-28 14:19 UTC (permalink / raw)
To: hadi
Cc: Herbert Poetzl, Alexey Kuznetsov, viro, sam, devel, dev,
Andrew Morton, clg, serue, netdev, linux-kernel, Daniel Lezcano,
Ben Greear, Dave Hansen, Eric W. Biederman
In-Reply-To: <1151502803.5203.101.camel@jzny2>
Hi Jamal,
On Wed, Jun 28, 2006 at 09:53:23AM -0400, jamal wrote:
>
> On Wed, 2006-28-06 at 15:36 +0200, Herbert Poetzl wrote:
>
> > note: personally I'm absolutely not against virtualizing
> > the device names so that each guest can have a separate
> > name space for devices, but there should be a way to
> > 'see' _and_ 'identify' the interfaces from outside
> > (i.e. host or spectator context)
> >
>
> Makes sense for the host side to have naming convention tied
> to the guest. Example as a prefix: guest0-eth0. Would it not
> be interesting to have the host also manage these interfaces
> via standard tools like ip or ifconfig etc? i.e if i admin up
> guest0-eth0, then the user in guest0 will see its eth0 going
> up.
Seeing guestXX-eth0 interfaces by standard tools has certain attractive
sides. But it creates a lot of undesired side effects.
For example, ntpd queries all network devices by the same ioctls as ifconfig,
and creates separate sockets bound to IP addresses of each device, which is
certainly not desired with namespaces.
Or more subtle question: do you want hotplug events to be generated when
guest0-eth0 interface comes up in the root namespace, and standard scripts
to try to set some IP address on this interface?..
In my opinion, the downside of this scheme overweights possible advantages,
and I'm personally quite happy with running commands with switched namespace,
like
vzctl exec guest0 ip addr list
vzctl exec guest0 ip link set eth0 up
and so on.
Best regards
Andrey
^ permalink raw reply
* Re: TOE, etc. (was Re: [PATCH Round 3 0/2][RFC] Network Event Notifier Mechanism)
From: Steve Wise @ 2006-06-28 14:18 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Herbert Xu, davem, netdev
In-Reply-To: <44A20311.5050301@pobox.com>
On Wed, 2006-06-28 at 00:18 -0400, Jeff Garzik wrote:
> Herbert Xu wrote:
> > On Tue, Jun 27, 2006 at 11:24:25PM -0400, Jeff Garzik wrote:
> >> I don't see how that position has changed?
> >>
> >> http://linux-net.osdl.org/index.php/TOE
> >
> > Well I must say that RDMA over TCP smells very much like TOE. They've
> > got an ARP table, a routing table, and presumably a TCP stack.
>
> A PCI device that presents itself as a SCSI controller, but under the
> hood is really iSCSI-over-TCP smells like TOE. Running a virtualized
> Linux guest on top of a proprietary stack [which provides networking
> services to guests] also smells like TOE. :)
>
I wonder if the existing iSCSI solutions handle next host mac addr
changes, pmtu changes, etc? They _can_, if they implement the entire
ARP and ICMP suites in HW/FW. Just curious if these vendors also see
merit in the netevent changes I'm proposing...
> If a TOE vendors wants to do TOE in a way that is transparent to the
> kernel, more power to them. Such non-Linux TCP stack solutions still
> suffer many of the problems listed at the web page above, but at least
> they impose no burden on kernel maintenance.
>
> i.e. we really _do not_ want to get into the habit of co-managing arp
> tables, routing tables, filtering rules, and dozens of other such
> resources with multiple remote, independent TCP stack. We have enough
> complexity as it is today, coordinating between the random variations of
> SMP, uniprocessor, and NUMA machines out there. Not to mention
> competing with under-the-hood firmware actions (ASF) on NICs.
>
> As an aside, RDMA over TCP just seems silly. TCP was _not_ meant to do
> the things that RDMA users want. The infiniband/RDMA programming model
> is an ultra-low-latency polling model where one or two apps are allowed
> to completely consume the machine, either busy-waiting or processing
> messages.
>
With RDMA over TCP, you can get the same ultra-low-latency, interrupt
coalescing or avoidance, and copy avoidance as with Infiniband (with
newly arriving 10Gb RDMA NICs). The benefit over IB, IMO, is the fact
that your infrastructure is all IP.
If you're interested in a kernel-mode app that benfits from RDMA, then
check out NFS-RDMA, which runs today transparently over Infiniband and
RDMA/TCP devices using the Infiniband RDMA-CM and verbs with minor
changes to support RDMA/TCP devices.
http://sourceforge.net/projects/nfs-rdma/
Steve.
^ permalink raw reply
* Re: Network namespaces a path to mergable code.
From: Serge E. Hallyn @ 2006-06-28 14:15 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Cedric Le Goater, Sam Vilain, Andrey Savochkin, dlezcano,
linux-kernel, netdev, serue, haveblue, Andrew Morton, dev,
herbert, devel, viro, Alexey Kuznetsov, Mark Huang
In-Reply-To: <m1bqsdidhe.fsf@ebiederm.dsl.xmission.com>
Quoting Eric W. Biederman (ebiederm@xmission.com):
> > I think we're reaching the limits of namespaces. It would be much easier
> > with a container id in each kernel object we want to isolate.
>
> Nope. Except for the fact that names are peculiar (sockets, network
> device names, IP address, routes...) the network stack splits quite cleanly.
>
> I did all of this in a proof of concept mode several months ago and
> the code is still sitting in my git tree on kernel.org. I even got
> the generic stack reference counting fixed.
>
> Eric
Which branch?
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Herbert Poetzl @ 2006-06-28 14:15 UTC (permalink / raw)
To: Sam Vilain
Cc: Eric W. Biederman, Kirill Korotaev, Daniel Lezcano,
Andrey Savochkin, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, devel, viro, Alexey Kuznetsov
In-Reply-To: <44A22229.2090404@vilain.net>
On Wed, Jun 28, 2006 at 06:31:05PM +1200, Sam Vilain wrote:
> Eric W. Biederman wrote:
> > Have a few more network interfaces for a layer 2 solution
> > is fundamental. Believing without proof and after arguments
> > to the contrary that you have not contradicted that a layer 2
> > solution is inherently slower is non-productive. Arguing
> > that a layer 2 only solution most prove itself on guest to guest
> > communication is also non-productive.
> >
>
> Yes, it does break what some people consider to be a sanity condition
> when you don't have loopback anymore within a guest. I once experimented
> with using 127.* addresses for per-guest loopback devices with vserver
> to fix this, but that couldn't work without fixing glibc to not make
> assumptions deep in the bowels of the resolver. I logged a fault with
> gnu.org and you can guess where it went :-).
this is what the lo* patches address, by providing
the required loopback isolation and providing lo
inside a guest (i.e. it looks and feels like a
normal system, except that you cannot modify the
interfaces from inside)
> I don't think it's just the performance issue, though. Consider also
> that if you only have one set of interfaces to manage, the overall
> configuration of the network stack is simpler. `ip addr list' on the
> host shows all the addresses on the system, you only have one routing
> table to manage, one set of iptables, etc.
>
> That being said, perhaps if each guest got its own interface, and from
> some suitably privileged context you could see them all, perhaps it
> would be nicer and maybe just as fast. Perhaps then *devices* could get
> their own routing namespaces, and routing namespaces could get iptables
> namespaces, or something like that, to give the most options.
>
> > With a guest with 4 IPs
> > 10.0.0.1 192.168.0.1 172.16.0.1 127.0.0.1
> > How do you make INADDR_ANY work with just filtering at bind time?
> >
>
> It used to just bind to the first one. Don't know if it still does.
no, it _alway_ binds to INADDR_ANY and checks
against other sockets (in the same context)
comparing the lists of assigned IPs (the subset)
so all checks happen at bind/connect time and
always against the set of IPs, only exception is
a performance optimization we do for single IP
guests (where INADDR_ANY gets rewritten to the
single IP)
best,
Herbert
> Sam.
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Herbert Poetzl @ 2006-06-28 14:11 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Kirill Korotaev, Daniel Lezcano, Andrey Savochkin, linux-kernel,
netdev, serue, haveblue, clg, Andrew Morton, devel, sam, viro,
Alexey Kuznetsov
In-Reply-To: <m1irmlkjni.fsf@ebiederm.dsl.xmission.com>
On Tue, Jun 27, 2006 at 10:07:29PM -0600, Eric W. Biederman wrote:
> Herbert Poetzl <herbert@13thfloor.at> writes:
>
> > On Tue, Jun 27, 2006 at 10:29:39AM -0600, Eric W. Biederman wrote:
> >> Herbert Poetzl <herbert@13thfloor.at> writes:
> >
> >> I watched the linux-vserver irc channel for a while and almost
> >> every network problem was caused by the change in semantics
> >> vserver provides.
> >
> > the problem here is not the change in semantics compared
> > to a real linux system (as there basically is none) but
> > compared to _other_ technologies like UML or QEMU, which
> > add the need for bridging and additional interfaces, while
> > Linux-VServer only focuses on the IP layer ...
>
> Not being able to bind to INADDR_ANY is a huge semantic change.
> Unless things have changed recently you get that change when
> you have two IP addresses in Linux-Vserver.
not at all, you probably looked at a different
code, binding to INADDR_ANY actually _is_ the
default inside a guest, the only difference here
is that INADDR_ANY maps to a subset of _all_
available IPs ...
> Talking to the outsider world through the loop back interface
> is a noticeable semantics change.
this does not happen either, as I said several
times, networking happens as on a _normal_
linux system, local traffic uses loop back, while
outbound traffic uses the appropriate network
interfaces
> Having to be careful of who uses INADDR_ANY on the host
> when you have guests is essentially a semantics change.
this 'semantic' change is intentional, and it
would be quite easy to change that (by putting
the host in a network context too) but as the
mechanism is isolation the host, similar to the
chroot() semantic for filesystems, sees _all_
the interfaces and IPs and therefore can also
bind to all of them ...
> Being able to talk to the outside world with a server
> bound only to the loopback IP is a weird semantic
> change.
that does not happen either ...
IMHO you should have a closer look (or ask more
questions) before making false assumptions
> And I suspect I missed something, it is weird peculiar and
> I don't care to remember all of the exceptions.
there are no real exceptions, we have a legacy
mapping which basically 'remaps' localhost to
the first assigned IP (to make guest local traffic
secure without messing with the network stack)
but this can be avoided completely
> Have a few more network interfaces for a layer 2 solution
> is fundamental. Believing without proof and after arguments
> to the contrary that you have not contradicted that a layer 2
> solution is inherently slower is non-productive.
assuming that it will not be slower, although it
will now pass two network stacks and the bridging
code is non-productive too, let's see how it goes
but do not ignore the overhead just because it
might simplify the implementation ...
> Arguing that a layer 2 only solution most prove itself on
> guest to guest communication is also non-productive.
>
> So just to sink one additional nail in the coffin of the silly
> guest to guest communication issue. For any two guests where
> fast communication between them is really important I can run
> an additional interface pair that requires no routing or bridging.
> Given that the implementation of the tunnel device is essentially
> the same as the loopback interface and that I make only one
> trip through the network stack there will be no performance overhead.
that is a good argument and I think I'm perfectly
fine with this, given that the implementation
allows that (i.e. the network stack can handle
two interfaces with the same IP assigned and will
choose the local interface over the remote one
when the traffic will be between guests)
> Similarly for any critical guest communication to the outside world
> I can give the guest a real network adapter.
with a single MAC assigned, that is, I presume?
> That said I don't think those things will be necessary and that if
> they are it is an optimization opportunity to make various bits
> of the network stack faster.
>
> Bridging or routing between guests is an exercise in simplicity
> and control not a requirement.
>
> >> In this case when you allow a guest more than one IP your hack
> >> while easy to maintain becomes much more complex.
> >
> > why? a set of IPs is quite similar to a single IP (which
> > is actually a subset), so no real change there, only
> > IP_ANY means something different for a guest ...
>
> Which simply filtering at bind time makes impossible.
>
> With a guest with 4 IPs
> 10.0.0.1 192.168.0.1 172.16.0.1 127.0.0.1
> How do you make INADDR_ANY work with just filtering at bind time?
>
> The host has at least the additional IPs.
> 10.0.0.2 192.168.0.2 172.16.0.2 127.0.0.1
>
> Herbert I suspect we are talking about completely different
> implementations otherwise I can't possibly see how we have
> such different perceptions of their capabilities.
guess that's what this discussion is about,
finding out the various aspects how isolation
and/or vitrtualization can be accomplished and
what features we consider common/useful enough
for mainline ... for me that is still in the
brainstorming phase, although several 'working
prototypes' already exist. IMHO the next step
is to collect a set of representative use cases
and test them with each implementation, regarding
performance, usability and practicability
> I am talking precisely about filter IP addresses at connect
> or bind time that a guest can use. Which as I recall is
> what vserver implements. If you are thinking of your ngnet
> implementation that would explain things.
I'm thinking of all the various implementations
and 'prototypes' we did and tested, I agree
this might be confusing ...
> >> Especially as you address each case people care about one at a time.
> >
> > hmm?
>
> Multiple IPs, IPv6, additional protocols, firewalls. etc.
>
> >> 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.
> >
> > seems I lost you here ...
>
>
> >> > 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.
> >
> > hmm, maybe you should try to optimize linux for Xen then,
> > as I'm sure it will provide the optimal virtualization
> > and has all the features folks are looking for (regarding
> > virtualization)
> >
> > I thought we are trying to figure a light-weight subset
> > of isolation and virtualization technologies and methods
> > which make sense to have in mainline ...
>
> And you presume doing things at layer 2 is more expensive than
> layer 3.
not necessarily, but I _know_ that the overhead
added at layer 3 is unmeasureable, and it still
needs to be proven that this is true for a layer
2 solution (which I'd actually prefer, because
it solves the protocol _and_ setup issues)
> >From what I have seen of layer 3 solutions it is a
> bloody maintenance nightmare, and an inflexible mess.
that is your opinion, I really doubt that you
will have less maintenance when you apply policy
to the guests ...
example here (just to clarify):
- let's assume we have eth0 on the host and in
guest A and B, with the following setup:
eth0(H) 192.168.0.1/24
eth0(A) 10.0.1.1/16 10.0.1.2/16
eth0(B) 10.0.2.1/16
- now what keeps guest B from jsut assigning
10.0.2.2/16 to eth0? you need some kind of
mechanism to prevent that, and/or to block
the packets using inappropriate IPs
* in the first case, i.e. you prevent assigning
certain IPs inside a guest, you get a semantic
change in the behaviour compared to a normal
system, but there is no additional overhead
on the communication
* in the second case, you have to maintain the
policy mechanism and keep it in sync with the
guest configuration (somehow), and of course
you have to verify every communication
- OTOH, if you do not care about collisions
basically assuming the point "that's like
a hub on a network, if there are two guests
with the same ip, it will be trouble, but
that's okay" then this becomes a real issue
for providers with potentially 'evil' customers
best,
Herbert
> >> >> 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.
> >
> > well, we have not even touched the permission issues yet
>
> Agreed, permissions have not discussed but the point is that is the only
> reason to keep from nesting the networking stack the way I have described
> it.
>
> Eric
^ permalink raw reply
* Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
From: Daniel Lezcano @ 2006-06-28 13:51 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Andrey Savochkin, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, herbert, devel, sam, ebiederm, viro
In-Reply-To: <449FF5AE.2040201@fr.ibm.com>
Daniel Lezcano wrote:
> Andrey Savochkin wrote:
>
>> Structures related to IPv4 rounting (FIB and routing cache)
>> are made per-namespace.
Hi Andrey,
if the ressources are private to the namespace, how do you will handle
NFS mounted before creating the network namespace ? Do you take care of
that or simply assume you can't access NFS anymore ?
Regards
-Daniel
^ permalink raw reply
* Re: Network namespaces a path to mergable code.
From: Eric W. Biederman @ 2006-06-28 14:03 UTC (permalink / raw)
To: Cedric Le Goater
Cc: Sam Vilain, Andrey Savochkin, dlezcano, linux-kernel, netdev,
serue, haveblue, Andrew Morton, dev, herbert, devel, viro,
Alexey Kuznetsov, Mark Huang
In-Reply-To: <44A251F2.70707@fr.ibm.com>
Cedric Le Goater <clg@fr.ibm.com> writes:
> Eric W. Biederman wrote:
>
>> Despite what it might look like unix domain sockets do not live in the
>> filesystem. They store a cookie in the filesystem that roughly
>> corresponds to the port number of an AF_INET socket. When you open a
>> socket the lookup is done by the cookie retrieved from the filesystem.
>
> unix domain socket lookup uses a path_lookup for sockets in the filesystem
> namespace and a find_by_name for socket in the abstract namespace.
Right. And the abstract namespace does nothing with the current
filesystem.
>> So except for their cookies unix domain sockets are always in the
>> network stack.
>
> what is that cookie ? the file dentry and mnt ref ?
The socket entry in the filesystem but really the socket
inode number in that entry. This entry has nothing to with dentry's
or mount refs so if I read the correctly every path to that socket
should yield the same entry.
> so, ok, the resulting struct sock is part of the network namespace but
> there is a bridge with the filesystem namespace which does not prevent
> other namespaces to do a lookup. the lookup routine needs to be changed,
> this is any way necessary for the abstract namespace.
Yep.
> I think we're reaching the limits of namespaces. It would be much easier
> with a container id in each kernel object we want to isolate.
Nope. Except for the fact that names are peculiar (sockets, network
device names, IP address, routes...) the network stack splits quite cleanly.
I did all of this in a proof of concept mode several months ago and
the code is still sitting in my git tree on kernel.org. I even got
the generic stack reference counting fixed.
Eric
^ permalink raw reply
* Re: [Patch 1/1] AF_UNIX Datagram getpeersec (minor fix)
From: James Morris @ 2006-06-28 14:00 UTC (permalink / raw)
To: Catherine Zhang
Cc: netdev, davem, jmorris, chrisw, herbert, sds, tjaeger, akpm,
latten, sergeh, gcwilson, czhang.us
In-Reply-To: <20060628053432.GA27226@jiayuguan.watson.ibm.com>
On Wed, 28 Jun 2006, Catherine Zhang wrote:
> Hi,
>
> Minor fix (un-export selinux_get_sock_sid()).
Thanks, looks ok to me.
Acked-by: James Morris <jmorris@namei.org>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: jamal @ 2006-06-28 13:53 UTC (permalink / raw)
To: Herbert Poetzl
Cc: Alexey Kuznetsov, viro, sam, devel, dev, Andrew Morton, clg,
serue, netdev, linux-kernel, Andrey Savochkin, Daniel Lezcano,
Ben Greear, Dave Hansen, Alexey Kuznetsov, Eric W. Biederman
In-Reply-To: <20060628133640.GB5088@MAIL.13thfloor.at>
On Wed, 2006-28-06 at 15:36 +0200, Herbert Poetzl wrote:
> note: personally I'm absolutely not against virtualizing
> the device names so that each guest can have a separate
> name space for devices, but there should be a way to
> 'see' _and_ 'identify' the interfaces from outside
> (i.e. host or spectator context)
>
Makes sense for the host side to have naming convention tied
to the guest. Example as a prefix: guest0-eth0. Would it not
be interesting to have the host also manage these interfaces
via standard tools like ip or ifconfig etc? i.e if i admin up
guest0-eth0, then the user in guest0 will see its eth0 going
up.
Anyways, interesting discussion.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-28 13:46 UTC (permalink / raw)
To: Thomas Graf; +Cc: Patrick McHardy, David Miller, netdev
In-Reply-To: <20060628130124.GX1376@postel.suug.ch>
On Wed, 2006-28-06 at 15:01 +0200, Thomas Graf wrote:
> * jamal <hadi@cyberus.ca> 2006-06-28 08:22
[..]
> > Note, in such a case: iflink rewriting will do it just fine
> > but then you loose the original info (I think it would be good to not
> > loose such info to know the origin). I dont know if cmsg uses iflink at
> > all - they probably look at the ifindex.
>
> It's using rt_iif which is currently derived from skb->dev even
> though it would make sense to use skb->iif once that is well
> defined.
>
Why not use iflink?
It exists, by definition, specifically as "the ifindex of the down muxed
netdevice" (should probably add that definition in the .h).
This is semantically different from a message to the stack which says
"this came to you from input device X" (represented by input_dev).
> > Ok, now question: why are you binding on top of ifb? we could have
> > redirected this to ipip, or tun0 or loopback or eql etc where it may
> > equally not have made sense to bind to. I can see something like this
> > making sense for bonding or bridging but not as a generic answer for all
> > netdevices.
>
> What's special about that? It seems a perfectly fine and simple way
> to create namespaces for sockets without enforcing applications to
> bind to the correct vlan devices directly.
>
Can you achieve the same by binding to any arbitrary netdevice? If you
can then i would agree.
> This is clear, my question was for you to explain when you intend
> to update input_dev etc. By overwriting it in ifb you enforce that
> valueable information is lost.
It is design intent for this field to carry information on where the
packet came from. We may loop many times between devices (between
ingress->egress or ingress->ingress, within the ttl limit) and each time
the only meaningful thing is which was the last netdevice that was
sending it.
> There is nothing wrong with updating iif to point to ifb under
> certain circumstances but it's not required to strictly enforce
> this. Having mirred do so conditionally is a lot more flexible
> without losing any value.
>
Refer to what i said above.
> > Now that i pay attention to your patch i think i see the complications
> > it is introducing (i am not done yet)- and i did warn about this in the
> > discussion _and_ didnt we agree to leave this stuff alone? Can we drop
> > this change please?
>
> This statement doesn't make sense, it merely transforms a device
> reference to a reference by interface index because the current
> method of handling it doesn't make sense at all since the region
> where input_dev stays valid without the risk of the device
> disappearing is very limited.
>
Please refer to what i said above in that you could end up redirecting
many times. I have not added yet the code which allows mirred to also do
ingress redirection which would make it even more interesting.
The challenge is this, and if you can solve it we would be fine:
- I need to access both the input_dev and dev and their metadata.
I could clearly find them by their ifindices and then reference them
after that. For performance reasons that is not optimal in the fast
path.
[Note, we have had this discussion before and even then we came to some
consensus that it would be hard to achieve that hence my view, again, to
drop this].
> > It does work as it is right now (I only notice a pull - there is no
> > push).
>
> In order to pull in ifb you need to push in mirred, quite
> obvious, no?
I think that my thinking at the time was that ifb can only receive
packets via mirred and therefore the pull on ingress at ifb may have
been to counter the push that occurs at mirred. Let me look at my notes
and testcases when i get back home; it may make sense not to have it at
ifb - the fact that it works as is tells me there is more to it than the
obvious.
> Why are you enforcing users of ifb to fake an
> ethernet header that is of no use at all?
This may just be an artifact of inheriting things from dummy device.
The answer will be clear when i look at my notes.
cheers,
jamal
^ permalink raw reply
* [PATCH 4/4][ATM]: basic sysfs support for ATM devices
From: chas williams - CONTRACTOR @ 2006-06-28 13:45 UTC (permalink / raw)
To: netdev; +Cc: davem
please consider for 2.6.18 -- thanks!
[ATM]: basic sysfs support for ATM devices
From: Roman Kagan <rkagan@mail.ru>
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
---
commit 034e4008acda89bc2422541e077f2dbfd530b717
tree e528e0e6f2d69c729f2daf6618df22133b3e4818
parent 4768199f3a5582378164820cc74251e485a01292
author chas williams <chas@relax.cmf.nrl.navy.mil> Mon, 26 Jun 2006 20:24:44 -0400
committer chas williams <chas@relax.cmf.nrl.navy.mil> Mon, 26 Jun 2006 20:24:44 -0400
include/linux/atmdev.h | 4 +
net/atm/Makefile | 2 -
net/atm/atm_sysfs.c | 176 ++++++++++++++++++++++++++++++++++++++++++++++++
net/atm/common.c | 7 ++
net/atm/common.h | 2 +
net/atm/resources.c | 22 +++++-
net/atm/resources.h | 2 +
7 files changed, 209 insertions(+), 6 deletions(-)
diff --git a/include/linux/atmdev.h b/include/linux/atmdev.h
index 1eb238a..41788a3 100644
--- a/include/linux/atmdev.h
+++ b/include/linux/atmdev.h
@@ -7,6 +7,7 @@ #ifndef LINUX_ATMDEV_H
#define LINUX_ATMDEV_H
+#include <linux/device.h>
#include <linux/atmapi.h>
#include <linux/atm.h>
#include <linux/atmioc.h>
@@ -358,6 +359,7 @@ #ifdef CONFIG_PROC_FS
struct proc_dir_entry *proc_entry; /* proc entry */
char *proc_name; /* proc entry name */
#endif
+ struct class_device class_dev; /* sysfs class device */
struct list_head dev_list; /* linkage */
};
@@ -459,7 +461,7 @@ static inline void atm_dev_put(struct at
BUG_ON(!test_bit(ATM_DF_REMOVED, &dev->flags));
if (dev->ops->dev_close)
dev->ops->dev_close(dev);
- kfree(dev);
+ class_device_put(&dev->class_dev);
}
}
diff --git a/net/atm/Makefile b/net/atm/Makefile
index d581875..89656d6 100644
--- a/net/atm/Makefile
+++ b/net/atm/Makefile
@@ -2,7 +2,7 @@ #
# Makefile for the ATM Protocol Families.
#
-atm-y := addr.o pvc.o signaling.o svc.o ioctl.o common.o atm_misc.o raw.o resources.o
+atm-y := addr.o pvc.o signaling.o svc.o ioctl.o common.o atm_misc.o raw.o resources.o atm_sysfs.o
mpoa-objs := mpc.o mpoa_caches.o mpoa_proc.o
obj-$(CONFIG_ATM) += atm.o
diff --git a/net/atm/atm_sysfs.c b/net/atm/atm_sysfs.c
new file mode 100644
index 0000000..5df4b9a
--- /dev/null
+++ b/net/atm/atm_sysfs.c
@@ -0,0 +1,176 @@
+/* ATM driver model support. */
+
+#include <linux/config.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/kobject.h>
+#include <linux/atmdev.h>
+#include "common.h"
+#include "resources.h"
+
+#define to_atm_dev(cldev) container_of(cldev, struct atm_dev, class_dev)
+
+static ssize_t show_type(struct class_device *cdev, char *buf)
+{
+ struct atm_dev *adev = to_atm_dev(cdev);
+ return sprintf(buf, "%s\n", adev->type);
+}
+
+static ssize_t show_address(struct class_device *cdev, char *buf)
+{
+ char *pos = buf;
+ struct atm_dev *adev = to_atm_dev(cdev);
+ int i;
+
+ for (i = 0; i < (ESI_LEN - 1); i++)
+ pos += sprintf(pos, "%02x:", adev->esi[i]);
+ pos += sprintf(pos, "%02x\n", adev->esi[i]);
+
+ return pos - buf;
+}
+
+static ssize_t show_atmaddress(struct class_device *cdev, char *buf)
+{
+ unsigned long flags;
+ char *pos = buf;
+ struct atm_dev *adev = to_atm_dev(cdev);
+ struct atm_dev_addr *aaddr;
+ int bin[] = { 1, 2, 10, 6, 1 }, *fmt = bin;
+ int i, j;
+
+ spin_lock_irqsave(&adev->lock, flags);
+ list_for_each_entry(aaddr, &adev->local, entry) {
+ for(i = 0, j = 0; i < ATM_ESA_LEN; ++i, ++j) {
+ if (j == *fmt) {
+ pos += sprintf(pos, ".");
+ ++fmt;
+ j = 0;
+ }
+ pos += sprintf(pos, "%02x", aaddr->addr.sas_addr.prv[i]);
+ }
+ pos += sprintf(pos, "\n");
+ }
+ spin_unlock_irqrestore(&adev->lock, flags);
+
+ return pos - buf;
+}
+
+static ssize_t show_carrier(struct class_device *cdev, char *buf)
+{
+ char *pos = buf;
+ struct atm_dev *adev = to_atm_dev(cdev);
+
+ pos += sprintf(pos, "%d\n",
+ adev->signal == ATM_PHY_SIG_LOST ? 0 : 1);
+
+ return pos - buf;
+}
+
+static ssize_t show_link_rate(struct class_device *cdev, char *buf)
+{
+ char *pos = buf;
+ struct atm_dev *adev = to_atm_dev(cdev);
+ int link_rate;
+
+ /* show the link rate, not the data rate */
+ switch (adev->link_rate) {
+ case ATM_OC3_PCR:
+ link_rate = 155520000;
+ break;
+ case ATM_OC12_PCR:
+ link_rate = 622080000;
+ break;
+ case ATM_25_PCR:
+ link_rate = 25600000;
+ break;
+ default:
+ link_rate = adev->link_rate * 8 * 53;
+ }
+ pos += sprintf(pos, "%d\n", link_rate);
+
+ return pos - buf;
+}
+
+static CLASS_DEVICE_ATTR(address, S_IRUGO, show_address, NULL);
+static CLASS_DEVICE_ATTR(atmaddress, S_IRUGO, show_atmaddress, NULL);
+static CLASS_DEVICE_ATTR(carrier, S_IRUGO, show_carrier, NULL);
+static CLASS_DEVICE_ATTR(type, S_IRUGO, show_type, NULL);
+static CLASS_DEVICE_ATTR(link_rate, S_IRUGO, show_link_rate, NULL);
+
+static struct class_device_attribute *atm_attrs[] = {
+ &class_device_attr_atmaddress,
+ &class_device_attr_address,
+ &class_device_attr_carrier,
+ &class_device_attr_type,
+ &class_device_attr_link_rate,
+ NULL
+};
+
+static int atm_uevent(struct class_device *cdev, char **envp, int num_envp, char *buf, int size)
+{
+ struct atm_dev *adev;
+ int i = 0, len = 0;
+
+ if (!cdev)
+ return -ENODEV;
+
+ adev = to_atm_dev(cdev);
+ if (!adev)
+ return -ENODEV;
+
+ if (add_uevent_var(envp, num_envp, &i, buf, size, &len,
+ "NAME=%s%d", adev->type, adev->number))
+ return -ENOMEM;
+
+ envp[i] = NULL;
+ return 0;
+}
+
+static void atm_release(struct class_device *cdev)
+{
+ struct atm_dev *adev = to_atm_dev(cdev);
+
+ kfree(adev);
+}
+
+static struct class atm_class = {
+ .name = "atm",
+ .release = atm_release,
+ .uevent = atm_uevent,
+};
+
+int atm_register_sysfs(struct atm_dev *adev)
+{
+ struct class_device *cdev = &adev->class_dev;
+ int i, err;
+
+ cdev->class = &atm_class;
+ class_set_devdata(cdev, adev);
+
+ snprintf(cdev->class_id, BUS_ID_SIZE, "%s%d", adev->type, adev->number);
+ err = class_device_register(cdev);
+ if (err < 0)
+ return err;
+
+ for (i = 0; atm_attrs[i]; i++)
+ class_device_create_file(cdev, atm_attrs[i]);
+
+ return 0;
+}
+
+void atm_unregister_sysfs(struct atm_dev *adev)
+{
+ struct class_device *cdev = &adev->class_dev;
+
+ class_device_del(cdev);
+}
+
+int __init atm_sysfs_init(void)
+{
+ return class_register(&atm_class);
+}
+
+void __exit atm_sysfs_exit(void)
+{
+ class_unregister(&atm_class);
+}
diff --git a/net/atm/common.c b/net/atm/common.c
index ae00222..35ab1a6 100644
--- a/net/atm/common.c
+++ b/net/atm/common.c
@@ -791,8 +791,14 @@ static int __init atm_init(void)
printk(KERN_ERR "atm_proc_init() failed with %d\n",error);
goto out_atmsvc_exit;
}
+ if ((error = atm_sysfs_init()) < 0) {
+ printk(KERN_ERR "atm_sysfs_init() failed with %d\n",error);
+ goto out_atmproc_exit;
+ }
out:
return error;
+out_atmproc_exit:
+ atm_proc_exit();
out_atmsvc_exit:
atmsvc_exit();
out_atmpvc_exit:
@@ -805,6 +811,7 @@ out_unregister_vcc_proto:
static void __exit atm_exit(void)
{
atm_proc_exit();
+ atm_sysfs_exit();
atmsvc_exit();
atmpvc_exit();
proto_unregister(&vcc_proto);
diff --git a/net/atm/common.h b/net/atm/common.h
index 4887c31..a422da7 100644
--- a/net/atm/common.h
+++ b/net/atm/common.h
@@ -28,6 +28,8 @@ int atmpvc_init(void);
void atmpvc_exit(void);
int atmsvc_init(void);
void atmsvc_exit(void);
+int atm_sysfs_init(void);
+void atm_sysfs_exit(void);
#ifdef CONFIG_PROC_FS
int atm_proc_init(void);
diff --git a/net/atm/resources.c b/net/atm/resources.c
index 18ac806..534baf7 100644
--- a/net/atm/resources.c
+++ b/net/atm/resources.c
@@ -114,14 +114,27 @@ struct atm_dev *atm_dev_register(const c
printk(KERN_ERR "atm_dev_register: "
"atm_proc_dev_register failed for dev %s\n",
type);
- mutex_unlock(&atm_dev_mutex);
- kfree(dev);
- return NULL;
+ goto out_fail;
+ }
+
+ if (atm_register_sysfs(dev) < 0) {
+ printk(KERN_ERR "atm_dev_register: "
+ "atm_register_sysfs failed for dev %s\n",
+ type);
+ atm_proc_dev_deregister(dev);
+ goto out_fail;
}
+
list_add_tail(&dev->dev_list, &atm_devs);
- mutex_unlock(&atm_dev_mutex);
+out:
+ mutex_unlock(&atm_dev_mutex);
return dev;
+
+out_fail:
+ kfree(dev);
+ dev = NULL;
+ goto out;
}
@@ -140,6 +153,7 @@ void atm_dev_deregister(struct atm_dev *
mutex_unlock(&atm_dev_mutex);
atm_dev_release_vccs(dev);
+ atm_unregister_sysfs(dev);
atm_proc_dev_deregister(dev);
atm_dev_put(dev);
diff --git a/net/atm/resources.h b/net/atm/resources.h
index ac7222f..6449899 100644
--- a/net/atm/resources.h
+++ b/net/atm/resources.h
@@ -43,4 +43,6 @@ static inline void atm_proc_dev_deregist
#endif /* CONFIG_PROC_FS */
+int atm_register_sysfs(struct atm_dev *adev);
+void atm_unregister_sysfs(struct atm_dev *adev);
#endif
^ permalink raw reply related
* [PATCH 3/4][ATM]: [suni] change suni_init to __devinit
From: chas williams - CONTRACTOR @ 2006-06-28 13:45 UTC (permalink / raw)
To: netdev; +Cc: davem
please consider for 2.6.18 -- thanks!
[ATM]: [suni] change suni_init to __devinit
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
---
commit 4768199f3a5582378164820cc74251e485a01292
tree fd27293baebffd029ae53a6efe18913cfb68cada
parent 3d63ef0340a7f49a72f5eaa33f08b38fa78d48e1
author chas williams <chas@relax.cmf.nrl.navy.mil> Mon, 26 Jun 2006 19:56:00 -0400
committer chas williams <chas@relax.cmf.nrl.navy.mil> Mon, 26 Jun 2006 19:56:00 -0400
drivers/atm/he.c | 2 +-
drivers/atm/suni.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index fde9334..a486eb1 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -1018,7 +1018,7 @@ he_init_irq(struct he_dev *he_dev)
return 0;
}
-static int __init
+static int __devinit
he_start(struct atm_dev *dev)
{
struct he_dev *he_dev;
diff --git a/drivers/atm/suni.c b/drivers/atm/suni.c
index b1d063c..f04f39c 100644
--- a/drivers/atm/suni.c
+++ b/drivers/atm/suni.c
@@ -289,7 +289,7 @@ static const struct atmphy_ops suni_ops
};
-int suni_init(struct atm_dev *dev)
+int __devinit suni_init(struct atm_dev *dev)
{
unsigned char mri;
^ permalink raw reply related
* [PATCH 2/4][ATM]: [iphase] should be __devinit not __init
From: chas williams - CONTRACTOR @ 2006-06-28 13:44 UTC (permalink / raw)
To: netdev; +Cc: davem
please consider for 2.6.18 -- thanks!
[ATM]: [iphase] should be __devinit not __init
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
---
commit a6d3f9a19cc29d6ece38f057eb896c16a4372129
tree 109e40a1fb873f0105bb75ecf21456f25b1756ef
parent 51403ade3cedfc85f1f41d81cb3a227f9ce2366f
author chas williams <chas@relax.cmf.nrl.navy.mil> Sun, 28 May 2006 22:22:31 -0400
committer chas williams <chas@relax.cmf.nrl.navy.mil> Sun, 28 May 2006 22:22:31 -0400
drivers/atm/iphase.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/atm/iphase.c b/drivers/atm/iphase.c
index 42eb86f..d41196b 100644
--- a/drivers/atm/iphase.c
+++ b/drivers/atm/iphase.c
@@ -2283,7 +2283,7 @@ static int reset_sar(struct atm_dev *dev
}
-static int __init ia_init(struct atm_dev *dev)
+static int __devinit ia_init(struct atm_dev *dev)
{
IADEV *iadev;
unsigned long real_base;
@@ -2479,7 +2479,7 @@ static void ia_free_rx(IADEV *iadev)
iadev->rx_dle_dma);
}
-static int __init ia_start(struct atm_dev *dev)
+static int __devinit ia_start(struct atm_dev *dev)
{
IADEV *iadev;
int error;
^ permalink raw reply related
* [PATCH 1/4][ATM]: [idt77105] should be __devinit not __init
From: chas williams - CONTRACTOR @ 2006-06-28 13:44 UTC (permalink / raw)
To: netdev; +Cc: davem
please consider for 2.6.18 -- thanks!
[ATM]: [idt77105] should be __devinit not __init
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
---
commit 51403ade3cedfc85f1f41d81cb3a227f9ce2366f
tree f9cf0143466de92eda0080e27240d4b53c130c18
parent 982703b5b38b314081d79ebc657fc06b1b6fe6b6
author chas williams <chas@relax.cmf.nrl.navy.mil> Sun, 28 May 2006 22:14:23 -0400
committer chas williams <chas@relax.cmf.nrl.navy.mil> Sun, 28 May 2006 22:14:23 -0400
drivers/atm/idt77105.c | 2 +-
drivers/atm/idt77105.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/atm/idt77105.c b/drivers/atm/idt77105.c
index 0aabfc2..325325a 100644
--- a/drivers/atm/idt77105.c
+++ b/drivers/atm/idt77105.c
@@ -358,7 +358,7 @@ static const struct atmphy_ops idt77105_
};
-int idt77105_init(struct atm_dev *dev)
+int __devinit idt77105_init(struct atm_dev *dev)
{
dev->phy = &idt77105_ops;
return 0;
diff --git a/drivers/atm/idt77105.h b/drivers/atm/idt77105.h
index 8ba8218..3fd2bc8 100644
--- a/drivers/atm/idt77105.h
+++ b/drivers/atm/idt77105.h
@@ -76,7 +76,7 @@ #define IDT77105_CTRSEL_RCC 0x02 /* W, R
#define IDT77105_CTRSEL_RHEC 0x01 /* W, Rx HEC Error Counter */
#ifdef __KERNEL__
-int idt77105_init(struct atm_dev *dev) __init;
+int idt77105_init(struct atm_dev *dev);
#endif
/*
^ permalink raw reply related
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Herbert Poetzl @ 2006-06-28 13:36 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Alexey Kuznetsov, Dave Hansen, Ben Greear, Daniel Lezcano,
Andrey Savochkin, linux-kernel, netdev, serue, clg, Andrew Morton,
dev, devel, sam, viro, Alexey Kuznetsov
In-Reply-To: <m1mzbyj6ft.fsf@ebiederm.dsl.xmission.com>
On Tue, Jun 27, 2006 at 09:38:14PM -0600, Eric W. Biederman wrote:
> Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> writes:
>
> > Hello!
> >
> >> It may look weird, but do application really *need* to see eth0 rather
> >> than eth858354?
> >
> > Applications do not care, humans do. :-)
> >
> > What's about applications they just need to see exactly the same
> > device after migration. Not only name, but f.e. also its ifindex.
> > If you do not create a separate namespace for netdevices, you will
> > inevitably end up with some strange hack sort of VPIDs to translate
> > (or to partition) ifindices or to tell that "ping -I eth858354 xxx"
> > is too coimplicated application to survive migration.
>
>
> Actually there are applications with peculiar licensing practices that
> do look at devices like eth0 to verify you have the appropriate mac, and
> do really weird things if you don't have an eth0.
>
> Plus there are other cases where it can be simpler to hard code things
> if it is allowable. (The human factor) Otherwise your configuration
> must be done through hotplug scripts.
>
> But yes there are misguided applications that care.
last time I pointed to such 'misguided' apps which
made assumptions that are not necessarily true
inside a virtual environment (e.g. pstree, initpid)
the general? position was that those apps should
be fixed instead adding a 'workaround'
note: personally I'm absolutely not against virtualizing
the device names so that each guest can have a separate
name space for devices, but there should be a way to
'see' _and_ 'identify' the interfaces from outside
(i.e. host or spectator context)
best,
Herbert
> Eric
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: Thomas Graf @ 2006-06-28 13:01 UTC (permalink / raw)
To: jamal; +Cc: netdev, David Miller, Patrick McHardy
In-Reply-To: <1151497363.5203.47.camel@jzny2>
* jamal <hadi@cyberus.ca> 2006-06-28 08:22
> Let me see if i understood correctly:
> you have a device from both vlan1 and vlan2 both being redirected to
> ifb1? and vlan 3, 4=> ifb2?
> And i take it to make it interesting vlan1,2 on eth0 and vlan3,4 ontop
> of eth1? note the iflink would/should reflect eth1/2. If you had bonding
> or bridging in between it gets more interesting. But you are saying
> you are no longer interested in the info that it came via eth1/2 at some
> point, correct?
> Note, in such a case: iflink rewriting will do it just fine
> but then you loose the original info (I think it would be good to not
> loose such info to know the origin). I dont know if cmsg uses iflink at
> all - they probably look at the ifindex.
It's using rt_iif which is currently derived from skb->dev even
though it would make sense to use skb->iif once that is well
defined.
> Ok, now question: why are you binding on top of ifb? we could have
> redirected this to ipip, or tun0 or loopback or eql etc where it may
> equally not have made sense to bind to. I can see something like this
> making sense for bonding or bridging but not as a generic answer for all
> netdevices.
What's special about that? It seems a perfectly fine and simple way
to create namespaces for sockets without enforcing applications to
bind to the correct vlan devices directly.
> The concept is to use ifb as a transitionary device. Packets come into
> it from either the ingress side of the stack or egress and get returned
> on the same side/spot they were found - with ifb represented as the
> input device. What ifb does is independent of what mirred does (we could
> redirect to other devices other than ifb).
This is clear, my question was for you to explain when you intend
to update input_dev etc. By overwriting it in ifb you enforce that
valueable information is lost.
There is nothing wrong with updating iif to point to ifb under
certain circumstances but it's not required to strictly enforce
this. Having mirred do so conditionally is a lot more flexible
without losing any value.
> Now that i pay attention to your patch i think i see the complications
> it is introducing (i am not done yet)- and i did warn about this in the
> discussion _and_ didnt we agree to leave this stuff alone? Can we drop
> this change please?
This statement doesn't make sense, it merely transforms a device
reference to a reference by interface index because the current
method of handling it doesn't make sense at all since the region
where input_dev stays valid without the risk of the device
disappearing is very limited.
> It does work as it is right now (I only notice a pull - there is no
> push).
In order to pull in ifb you need to push in mirred, quite
obvious, no? Why are you enforcing users of ifb to fake an
ethernet header that is of no use at all?
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-28 12:22 UTC (permalink / raw)
To: Thomas Graf; +Cc: netdev, David Miller, Patrick McHardy
In-Reply-To: <20060628101832.GW1376@postel.suug.ch>
On Wed, 2006-28-06 at 12:18 +0200, Thomas Graf wrote:
> * jamal <hadi@cyberus.ca> 2006-06-27 09:07
[..]
> > Note the meta-setter (been sitting on it for too long) also set the
> > input_dev.
>
> Could you share that piece of code so I don't have to duplicate
> that effort?
>
I will look it up and send it your way - it is not complete (I have
changed machines twice since i first wrote it). Or maybe the intent of
your question was to ask how was the setting of input_dev was done?
> > BTW, in regards to the VLANs, what is wrong with using the
> > netdev->iflink to figure the real device?
>
>
> vlan1
> ifb1
> vlan2
> vlan3
> ifb2
> vlan4
>
> dhcp daemon would bind to ifb1 and use pktinfo cmsg to figure
> out whether the packet was received on vlan1 or vlan2, the
> actual physical device is of no interest anymore.
>
Let me see if i understood correctly:
you have a device from both vlan1 and vlan2 both being redirected to
ifb1? and vlan 3, 4=> ifb2?
And i take it to make it interesting vlan1,2 on eth0 and vlan3,4 ontop
of eth1? note the iflink would/should reflect eth1/2. If you had bonding
or bridging in between it gets more interesting. But you are saying
you are no longer interested in the info that it came via eth1/2 at some
point, correct?
Note, in such a case: iflink rewriting will do it just fine
but then you loose the original info (I think it would be good to not
loose such info to know the origin). I dont know if cmsg uses iflink at
all - they probably look at the ifindex.
Ok, now question: why are you binding on top of ifb? we could have
redirected this to ipip, or tun0 or loopback or eql etc where it may
equally not have made sense to bind to. I can see something like this
making sense for bonding or bridging but not as a generic answer for all
netdevices.
> Looking at your ifb code I see that you set skb->dev based on
> iif and update iif unconditionally. I see a lot of problems
> with this, firstly iif is already updated in the mirred action,
> secondly iif doesn't necessarily point to the device the packet
> was last seen on. Could you maybe explain the policy of iif
> you have in mind, it doesn't seem very consistent.
>
The concept is to use ifb as a transitionary device. Packets come into
it from either the ingress side of the stack or egress and get returned
on the same side/spot they were found - with ifb represented as the
input device. What ifb does is independent of what mirred does (we could
redirect to other devices other than ifb).
Now that i pay attention to your patch i think i see the complications
it is introducing (i am not done yet)- and i did warn about this in the
discussion _and_ didnt we agree to leave this stuff alone? Can we drop
this change please?
> BTW, why does ifb have a hard header length? The resulting
> push and pull only slows things down.
Good question. I know there were a lot of oddities i had to deal with
when different link layers cross over (some have smaller headers than
other and yet others had none ;->)
I will have to go and look at my notes test cases and get back to you;
It does work as it is right now (I only notice a pull - there is no
push).
cheers,
jamal
^ permalink raw reply
* [PATCH 3/3] [TIPC] Initial activation message now includes TIPC version number
From: Per Liden @ 2006-06-28 12:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Allan Stephens
In-Reply-To: <Pine.LNX.4.64.0606281358100.6341@ulinpc219.uab.ericsson.se>
From: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Per Liden <per.liden@ericsson.com>
---
net/tipc/core.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/tipc/core.c b/net/tipc/core.c
index 5003acb..0539a83 100644
--- a/net/tipc/core.c
+++ b/net/tipc/core.c
@@ -191,7 +191,8 @@ static int __init tipc_init(void)
int res;
tipc_log_reinit(CONFIG_TIPC_LOG);
- info("Activated (compiled " __DATE__ " " __TIME__ ")\n");
+ info("Activated (version " TIPC_MOD_VER
+ " compiled " __DATE__ " " __TIME__ ")\n");
tipc_own_addr = 0;
tipc_remote_management = 1;
--
1.4.0
^ permalink raw reply related
* [PATCH 1/3] [TIPC] Fixed skb_under_panic caused by tipc_link_bundle_buf
From: Per Liden @ 2006-06-28 12:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Allan Stephens
In-Reply-To: <Pine.LNX.4.64.0606281358100.6341@ulinpc219.uab.ericsson.se>
From: Allan Stephens <allan.stephens@windriver.com>
Now determines tailroom of bundle buffer by directly inspection of buffer.
Previously, buffer was assumed to have a max capacity equal to the link MTU,
but the addition of link MTU negotiation means that the link MTU can increase
after the bundle buffer is allocated.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Per Liden <per.liden@ericsson.com>
---
net/tipc/link.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index d646580..c6831c7 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -2,7 +2,7 @@
* net/tipc/link.c: TIPC link code
*
* Copyright (c) 1996-2006, Ericsson AB
- * Copyright (c) 2004-2005, Wind River Systems
+ * Copyright (c) 2004-2006, Wind River Systems
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -988,17 +988,18 @@ static int link_bundle_buf(struct link *
struct tipc_msg *bundler_msg = buf_msg(bundler);
struct tipc_msg *msg = buf_msg(buf);
u32 size = msg_size(msg);
- u32 to_pos = align(msg_size(bundler_msg));
- u32 rest = link_max_pkt(l_ptr) - to_pos;
+ u32 bundle_size = msg_size(bundler_msg);
+ u32 to_pos = align(bundle_size);
+ u32 pad = to_pos - bundle_size;
if (msg_user(bundler_msg) != MSG_BUNDLER)
return 0;
if (msg_type(bundler_msg) != OPEN_MSG)
return 0;
- if (rest < align(size))
+ if (skb_tailroom(bundler) < (pad + size))
return 0;
- skb_put(bundler, (to_pos - msg_size(bundler_msg)) + size);
+ skb_put(bundler, pad + size);
memcpy(bundler->data + to_pos, buf->data, size);
msg_set_size(bundler_msg, to_pos + size);
msg_set_msgcnt(bundler_msg, msg_msgcnt(bundler_msg) + 1);
--
1.4.0
^ permalink raw reply related
* [PATCH 2/3] [TIPC] Improve response to requests for node/link information
From: Per Liden @ 2006-06-28 12:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Allan Stephens
In-Reply-To: <Pine.LNX.4.64.0606281358100.6341@ulinpc219.uab.ericsson.se>
From: Allan Stephens <allan.stephens@windriver.com>
Now allocates reply space for "get links" request based on number of actual
links, not number of potential links. Also, limits reply to "get links" and
"get nodes" requests to 32KB to match capabilities of tipc-config utility
that issued request.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Per Liden <per.liden@ericsson.com>
---
net/tipc/node.c | 26 +++++++++++++++++---------
net/tipc/zone.h | 4 ++--
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index ce9678e..bf24168 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -2,7 +2,7 @@
* net/tipc/node.c: TIPC node management routines
*
* Copyright (c) 2000-2006, Ericsson AB
- * Copyright (c) 2005, Wind River Systems
+ * Copyright (c) 2005-2006, Wind River Systems
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -592,6 +592,7 @@ struct sk_buff *tipc_node_get_nodes(cons
struct sk_buff *buf;
struct node *n_ptr;
struct tipc_node_info node_info;
+ u32 payload_size;
if (!TLV_CHECK(req_tlv_area, req_tlv_space, TIPC_TLV_NET_ADDR))
return tipc_cfg_reply_error_string(TIPC_CFG_TLV_ERROR);
@@ -608,8 +609,11 @@ struct sk_buff *tipc_node_get_nodes(cons
/* For now, get space for all other nodes
(will need to modify this when slave nodes are supported */
- buf = tipc_cfg_reply_alloc(TLV_SPACE(sizeof(node_info)) *
- (tipc_max_nodes - 1));
+ payload_size = TLV_SPACE(sizeof(node_info)) * (tipc_max_nodes - 1);
+ if (payload_size > 32768u)
+ return tipc_cfg_reply_error_string(TIPC_CFG_NOT_SUPPORTED
+ " (too many nodes)");
+ buf = tipc_cfg_reply_alloc(payload_size);
if (!buf)
return NULL;
@@ -633,6 +637,7 @@ struct sk_buff *tipc_node_get_links(cons
struct sk_buff *buf;
struct node *n_ptr;
struct tipc_link_info link_info;
+ u32 payload_size;
if (!TLV_CHECK(req_tlv_area, req_tlv_space, TIPC_TLV_NET_ADDR))
return tipc_cfg_reply_error_string(TIPC_CFG_TLV_ERROR);
@@ -645,12 +650,15 @@ struct sk_buff *tipc_node_get_links(cons
if (!tipc_nodes)
return tipc_cfg_reply_none();
-
- /* For now, get space for 2 links to all other nodes + bcast link
- (will need to modify this when slave nodes are supported */
-
- buf = tipc_cfg_reply_alloc(TLV_SPACE(sizeof(link_info)) *
- (2 * (tipc_max_nodes - 1) + 1));
+
+ /* Get space for all unicast links + multicast link */
+
+ payload_size = TLV_SPACE(sizeof(link_info)) *
+ (tipc_net.zones[tipc_zone(tipc_own_addr)]->links + 1);
+ if (payload_size > 32768u)
+ return tipc_cfg_reply_error_string(TIPC_CFG_NOT_SUPPORTED
+ " (too many links)");
+ buf = tipc_cfg_reply_alloc(payload_size);
if (!buf)
return NULL;
diff --git a/net/tipc/zone.h b/net/tipc/zone.h
index 267999c..5ab3d08 100644
--- a/net/tipc/zone.h
+++ b/net/tipc/zone.h
@@ -2,7 +2,7 @@
* net/tipc/zone.h: Include file for TIPC zone management routines
*
* Copyright (c) 2000-2006, Ericsson AB
- * Copyright (c) 2005, Wind River Systems
+ * Copyright (c) 2005-2006, Wind River Systems
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -45,7 +45,7 @@ #include "net.h"
* struct _zone - TIPC zone structure
* @addr: network address of zone
* @clusters: array of pointers to all clusters within zone
- * @links: (used for inter-zone communication)
+ * @links: number of (unicast) links to zone
*/
struct _zone {
--
1.4.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox