* Re: bcm43xx: "transmit timed out" and apparent hang with "preemptible periodic work" patches
From: Michael Buesch @ 2006-06-26 12:43 UTC (permalink / raw)
To: Paul Collins; +Cc: bcm43xx-dev, netdev
In-Reply-To: <87ac80ps5o.fsf@briny.internal.ondioline.org>
On Monday 26 June 2006 04:28, Paul Collins wrote:
> With the bcm43xx periodic work patches that recently made it into
> Linus's tree, my PowerBook does not survive running overnight.
>
> Yesterday I reverted
>
> 91769e7dd9cef7988dc4280f74ed168351beb5b8 [PATCH] bcm43xx: preemptible periodic work
> 78ff56a06edc3407996173daf63e48f6b90c7062 [PATCH] bcm43xx: redesign locking
>
> and it was still alive this morning.
>
> The following is logged, but that may not be all since the screen was
> turned off and kern.log was marked for no-fsync.
>
> Jun 24 06:53:41 briny kernel: NETDEV WATCHDOG: eth1: transmit timed out
> Jun 24 06:53:41 briny kernel: bcm43xx: Controller RESET (TX timeout) ...
> Jun 24 06:53:41 briny kernel: bcm43xx: Chip ID 0x4306, rev 0x3
> Jun 24 06:53:41 briny kernel: bcm43xx: Number of cores: 5
> Jun 24 06:53:41 briny kernel: bcm43xx: Core 0: ID 0x800, rev 0x4, vendor 0x4243, enabled
> Jun 24 06:53:41 briny kernel: bcm43xx: Core 1: ID 0x812, rev 0x5, vendor 0x4243, disabled
> Jun 24 06:53:41 briny kernel: bcm43xx: Core 2: ID 0x80d, rev 0x2, vendor 0x4243, enabled
> Jun 24 06:53:41 briny kernel: bcm43xx: Core 3: ID 0x807, rev 0x2, vendor 0x4243, disabled
> Jun 24 06:53:41 briny kernel: bcm43xx: Core 4: ID 0x804, rev 0x9, vendor 0x4243, enabled
> Jun 24 06:53:41 briny kernel: bcm43xx: PHY connected
> Jun 24 06:53:41 briny kernel: bcm43xx: Detected PHY: Version: 2, Type 2, Revision 2
> Jun 24 06:53:41 briny kernel: bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
> Jun 24 06:53:41 briny kernel: bcm43xx: Radio turned off
> Jun 24 06:53:41 briny kernel: bcm43xx: Radio turned off
> Jun 24 06:53:41 briny kernel: bcm43xx: Controller restarted
Try to get more logs.
I suggest to do a netconsole for logging.
--
Greetings Michael.
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Herbert Poetzl @ 2006-06-26 13:02 UTC (permalink / raw)
To: Andrey Savochkin
Cc: dlezcano, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, devel, sam, ebiederm, viro
In-Reply-To: <20060626134711.A28729@castle.nmd.msu.ru>
On Mon, Jun 26, 2006 at 01:47:11PM +0400, Andrey Savochkin wrote:
> Hi Daniel,
>
> It's good that you kicked off network namespace discussion Although I.
> wish you'd Cc'ed someone at OpenVZ so I could notice it earlier :) .
> Indeed, the first point to agree in this discussion is device list.
> In your patch, you essentially introduce a data structure parallel
> to the main device list, creating a "view" of this list.
> I see a fundamental problem with this approach. When a device presents
> an skb to the protocol layer, it needs to know to which namespace this
> skb belongs.
> Otherwise you would never get rid of problems with bind: what to do if
> device eth1 is visible in namespace1, namespace2, and root namespace,
> and each namespace has a socket bound to 0.0.0.0:80?
this is something which isn't a fundamental problem at
all, and IMHO there are at least three options here
(probably more)
- check at 'bind' time if the binding would overlap
and give the 'proper' error (as it happens right
now on the host)
(this is how Linux-VServer currently handles the
network isolation, and yes, it works quite fine :)
- allow arbitrary binds and 'tag' the packets according
to some 'host' policy (e.g. iptables or tc)
(this is how the Linux-VServer ngnet was designed)
- deliver packets to _all_ bound sockets/destinations
(this is probably a more unusable but quite thinkable
solution)
> We have to conclude that each device should be visible only in one
> namespace.
I disagree here, especially some supervisor context or
the host context should be able to 'see' and probably
manipulate _all_ of the devices
> In this case, instead of introducing net_ns_dev and net_ns_dev_list
> structures, we can simply have a separate dev_base list head in each
> namespace. Moreover, separate device list in each namespace will be in
> line with making namespace isolation complete.
> Complete isolation will allow each namespace to set up own tun/tap
> devices, have own routes, netfilter tables, and so on.
tun/tap devices are quite possible with this approach
too, I see no problem here ...
for iptables and routes, I'm worried about the required
'policy' to make them secure, i.e. how do you ensure
that the packets 'leaving' guest X do not contain
'evil' packets and/or disrupt your host system?
> My follow-up messages will contain the first set of patches with
> network namespaces implemented in the same way as network isolation
> in OpenVZ.
hmm, you probably mean 'network virtualization' here
> This patchset introduces namespaces for device list and IPv4
> FIB/routing. Two technical issues are omitted to make the patch idea
> clearer: device moving between namespaces, and selective routing cache
> flush + garbage collection.
>
> If this patchset is agreeable, the next patchset will finalize
> integration with nsproxy, add namespaces to socket lookup code and
> neighbour cache, and introduce a simple device to pass traffic between
> namespaces.
passing traffic 'between' namespaces should happen via
lo, no? what kind of 'device' is required there, and
what overhead does it add to the networking?
TIA,
Herbert
> Then we will turn to less obvious matters including
> netlink messages, network statistics, representation of network
> information in proc and sysfs, tuning of parameters through sysctl,
> IPv6 and other protocols, and per-namespace netfilters.
>
> Best regards
> Andrey
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Eric W. Biederman @ 2006-06-26 14:05 UTC (permalink / raw)
To: Andrey Savochkin
Cc: dlezcano, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, devel, sam, viro
In-Reply-To: <20060626130203.GA504@MAIL.13thfloor.at>
Herbert Poetzl <herbert@13thfloor.at> writes:
> On Mon, Jun 26, 2006 at 01:47:11PM +0400, Andrey Savochkin wrote:
>> Hi Daniel,
>>
>> It's good that you kicked off network namespace discussion Although I.
>> wish you'd Cc'ed someone at OpenVZ so I could notice it earlier :) .
>
>> Indeed, the first point to agree in this discussion is device list.
>> In your patch, you essentially introduce a data structure parallel
>> to the main device list, creating a "view" of this list.
>
>> I see a fundamental problem with this approach. When a device presents
>> an skb to the protocol layer, it needs to know to which namespace this
>> skb belongs.
>
>> Otherwise you would never get rid of problems with bind: what to do if
>> device eth1 is visible in namespace1, namespace2, and root namespace,
>> and each namespace has a socket bound to 0.0.0.0:80?
>
> this is something which isn't a fundamental problem at
> all, and IMHO there are at least three options here
> (probably more)
I agree that there are other implementations that can be used for
containers. However when you think namespaces this is what you need.
For several reasons.
1) So you can use AF_PACKET safely.
This allows a network namespace to use DHCP and all of the other
usual network autoconfiguration tools. 0.0.0.0:80 is just
a special subset of that.
2) It means the existing network stack can be used without
logic changes. All that is needed is a lookup of the appropriate
context. This is very straight forward to audit.
3) Since all of the network stack is trivially available all of
the advanced network stack features like iptables are easily
available.
4) There is no retraining or other rules for user to learn.
Because people understand what is going on it is more likely
a setup will be secure. Most of the other implementations
don't quite act like a normal network setup and the special
rules can be hard to learn.
> - check at 'bind' time if the binding would overlap
> and give the 'proper' error (as it happens right
> now on the host)
> (this is how Linux-VServer currently handles the
> network isolation, and yes, it works quite fine :)
It works yes but it limits you to a subset of the network
stack. And has serious problems with concepts like INADDR_ANY.
PF_PACKET is not an option.
> - allow arbitrary binds and 'tag' the packets according
> to some 'host' policy (e.g. iptables or tc)
> (this is how the Linux-VServer ngnet was designed)
A little more general but very weird.
> - deliver packets to _all_ bound sockets/destinations
> (this is probably a more unusable but quite thinkable
> solution)
>
>> We have to conclude that each device should be visible only in one
>> namespace.
>
> I disagree here, especially some supervisor context or
> the host context should be able to 'see' and probably
> manipulate _all_ of the devices
This part really is necessary. This does not preclude managing
a network namespace from outside of the namespace.
>> In this case, instead of introducing net_ns_dev and net_ns_dev_list
>> structures, we can simply have a separate dev_base list head in each
>> namespace. Moreover, separate device list in each namespace will be in
>> line with making namespace isolation complete.
>
>> Complete isolation will allow each namespace to set up own tun/tap
>> devices, have own routes, netfilter tables, and so on.
>
> tun/tap devices are quite possible with this approach
> too, I see no problem here ...
>
> for iptables and routes, I'm worried about the required
> 'policy' to make them secure, i.e. how do you ensure
> that the packets 'leaving' guest X do not contain
> 'evil' packets and/or disrupt your host system?
In the traditional ways. When you control the router and/or the switch
someone is directly connected to.
We don't need to reinvent the wheel if we do this properly.
>> This patchset introduces namespaces for device list and IPv4
>> FIB/routing. Two technical issues are omitted to make the patch idea
>> clearer: device moving between namespaces, and selective routing cache
>> flush + garbage collection.
>>
>> If this patchset is agreeable, the next patchset will finalize
>> integration with nsproxy, add namespaces to socket lookup code and
>> neighbour cache, and introduce a simple device to pass traffic between
>> namespaces.
>
> passing traffic 'between' namespaces should happen via
> lo, no? what kind of 'device' is required there, and
> what overhead does it add to the networking?
Definitely not. lo is a local loopback interface.
What is needed is a two headed device that is the cousin of lo.
But with one network interface in each network namespace.
Note even connecting network namespaces is optional.
Eric
^ permalink raw reply
* PHARISEE WATCH: British Lords, Homeless Folks, and a Phony Bible
From: info @ 2006-06-27 1:11 UTC (permalink / raw)
To: netdev
Reply-To: Kara
PHARISEE WATCH: British Lords, Homeless Folks, and a Phony Bible (with permission from author)
SUBSCRIBE FREE: http://straitgateministry.net
Two English Lords Gifted the Land of the Philistines to a Private Company and Funded a New Religion to Bless the Theft
By Charles E. Carlson
The State of Israel controls every gate into the Gaza Strip. One such gate called Rafah connects the tiny land with the Egyptian Sinai. But to get there you must cross a kilometer wide Israeli zone, and if you're lucky enough to be allowed passage to Gaza it is with Israel's permission; your passport shows you have entered Israel, not Palestine. Only yesterday two unnamed swimmers tried to bypass this checkpoint and were shot in the water by the crew of an Israeli Navy ship. http://straitgateministry.net (Unheralded News)
But even more strange and just as bloody a right of passage is practiced inside America's churches. For when you enter what is referred to generically as an evangelical church you are probably about to partake in a Zionist controlled religion as distant from traditional Christianity as is Pharisaism.
British Lord Balfour provided a forged deed for the State of Israel to enter Arab land. And at almost the same hour he wrote his famous letter, the new dispensational church movement in America was being hijacked for the specific purpose of blessing world Zionism. Dispensationalism, or evangelicalism, as it is often called, has its roots in and owes its success to British nobles who were, for the most part, above religion and called each other "Lord." Both Israel and dispensational Christianity received their baptismal blessings from the British Crown.
Click here to Continue to the amazing conclusion:
http://straitgateministry.net (PHARISEE WATCH)
TO BE DELETED FROM THIS LIST send a reply with 'delete'. Please type next to the subject so we can scan it.
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Andrey Savochkin @ 2006-06-26 14:08 UTC (permalink / raw)
To: Herbert Poetzl
Cc: dlezcano, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, devel, sam, ebiederm, viro, Alexey Kuznetsov
In-Reply-To: <20060626130203.GA504@MAIL.13thfloor.at>
Hi Herbert,
On Mon, Jun 26, 2006 at 03:02:03PM +0200, Herbert Poetzl wrote:
> On Mon, Jun 26, 2006 at 01:47:11PM +0400, Andrey Savochkin wrote:
>
> > I see a fundamental problem with this approach. When a device presents
> > an skb to the protocol layer, it needs to know to which namespace this
> > skb belongs.
>
> > Otherwise you would never get rid of problems with bind: what to do if
> > device eth1 is visible in namespace1, namespace2, and root namespace,
> > and each namespace has a socket bound to 0.0.0.0:80?
>
> this is something which isn't a fundamental problem at
> all, and IMHO there are at least three options here
> (probably more)
>
> - check at 'bind' time if the binding would overlap
> and give the 'proper' error (as it happens right
> now on the host)
> (this is how Linux-VServer currently handles the
> network isolation, and yes, it works quite fine :)
I'm not comfortable with this as a permanent mainstream solution.
It means that network namespaces are actually not namespaces: you can't run
some program (e.g., apache) with default configs in a new namespace without
regards to who runs what in other namespaces.
In other words, name "0.0.0.0:80" creates a collision in your implementation,
so socket "names" do not form isolated spaces.
>
> - allow arbitrary binds and 'tag' the packets according
> to some 'host' policy (e.g. iptables or tc)
> (this is how the Linux-VServer ngnet was designed)
>
> - deliver packets to _all_ bound sockets/destinations
> (this is probably a more unusable but quite thinkable
> solution)
Deliver TCP packets to all sockets?
How many connections do you expect to be established in this case?
>
> > We have to conclude that each device should be visible only in one
> > namespace.
>
> I disagree here, especially some supervisor context or
> the host context should be able to 'see' and probably
> manipulate _all_ of the devices
Right, manipulating all devices from some supervisor context is useful.
But this shouldn't necessarily be done by regular ip/ifconfig tools.
Besides, it could be quite confusing if in ifconfig output in the
supervisor context you see 325 "tun0" devices coming from
different namespaces :)
So I'm all for network namespace management mechanisms not bound
to existing tools/APIs.
>
> > Complete isolation will allow each namespace to set up own tun/tap
> > devices, have own routes, netfilter tables, and so on.
>
> tun/tap devices are quite possible with this approach
> too, I see no problem here ...
>
> for iptables and routes, I'm worried about the required
> 'policy' to make them secure, i.e. how do you ensure
> that the packets 'leaving' guest X do not contain
> 'evil' packets and/or disrupt your host system?
Sorry, I don't get your point.
How do you ensure that packets leaving your neighbor's computer
do not disrupt your system?
>From my point of view, network namespaces are just neighbors.
>
> > My follow-up messages will contain the first set of patches with
> > network namespaces implemented in the same way as network isolation
> > in OpenVZ.
>
> hmm, you probably mean 'network virtualization' here
I meant isolation between different network contexts/namespaces.
>
> > This patchset introduces namespaces for device list and IPv4
> > FIB/routing. Two technical issues are omitted to make the patch idea
> > clearer: device moving between namespaces, and selective routing cache
> > flush + garbage collection.
> >
> > If this patchset is agreeable, the next patchset will finalize
> > integration with nsproxy, add namespaces to socket lookup code and
> > neighbour cache, and introduce a simple device to pass traffic between
> > namespaces.
>
> passing traffic 'between' namespaces should happen via
> lo, no? what kind of 'device' is required there, and
> what overhead does it add to the networking?
OpenVZ provides 2 options.
1) A packet appears right inside some namespace, without any additional
overhead. Usually this implies that either all packets from this device
belong to this namespace, i.e. simple device->namespace assignment.
However, there is nothing conceptually wrong with having
namespace-aware device drivers or netfilter modules selecting namespaces
for each incoming packet. It all depends on how you want packets go
through various network layers, and how much network management abilities
you want to have in non-root namespaces.
My point is that for network namespaces being real namespaces, decision
making should be done somewhere before socket lookup.
2) Parent network namespace acts as a router forwarding packets to child
namespaces. This scheme is the preferred one in OpenVZ for various
reasons, most important being the simplicity of migration of network
namespaces. In this case flexibility has the cost of going through
packet handling layers two times.
Technically, this is implemented via a simple netdevice doing
netif_rx in hard_xmit.
Regards
Andrey
^ permalink raw reply
* Re: [PATCH 0/2][RFC] Network Event Notifier Mechanism
From: Steve Wise @ 2006-06-26 14:34 UTC (permalink / raw)
To: hadi; +Cc: caitlinb, netdev, David Miller
In-Reply-To: <1151159405.6716.106.camel@jzny2>
On Sat, 2006-06-24 at 10:30 -0400, jamal wrote:
> On Fri, 2006-23-06 at 08:24 -0500, Steve Wise wrote:
>
> >
> > > PS:- I do think what they need is to hear route cache generation
> > > as opposed to ARP+FIB updates; but lets wait and see how clever
> > > the patches would look.
> > >
>
> > Can you expand on your statement above? If hooking route cache
> > generation gets all the events I described, then I'd like to use that.
> > I'm still learning the Linux routing subsystem. Any help would be
> > GREAT!
> >
>
> If my understanding is correct of what you are trying to do is:
> for a destination IP you are going to figure the source and destination
> MAC address. Most of that info is available at the route + hh cache.
> There can be only one destination mac per device and so you only need to
> watch the device changes for that. The dst MAC per IP and any changes
> you can glean from the route cache created.
> But this is based on my understanding of what you are trying to do and
> so far i cant say i am 100% clear.
The route/hh cache insertions might work for the initial dst MAC per
next-hop IP. But this dst MAC can _change_ for various reasons (even
though the next-hop IP remains the same). Such a change, I think,
doesn't generate a new route + hh cache insertion, just a change to the
hh entry.
Also, I think the route cache entry is created _before_ the MAC addr is
known. So we really need to know when the neighbour entry is updated
with the MAC address as a result of ARP/ND. Hooking the correct spot in
the neighbour code where the mac address gets stored also gets us the
change event I described above.
Does this make sense?
Steve.
^ permalink raw reply
* netfilter and packets which are created locally
From: Ian Brown @ 2006-06-26 14:39 UTC (permalink / raw)
To: netdev
Hello,
I had looked at the diagrams and read the explanations
about netfilter in Netfilter Architecture page:
http://netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-3.html
I want to make sure wheter I undestood something regarding
packets which are created locally (as opposed
to packets that are received on the network interface).
My question is: Do I understand the follwing 2 sceanrios right?
For local packets which are sent out of the machine
it seems to me to be the case. (Am I right?):
Such packets , that are created locally on
the machine, first reach the NF_IP_LOCAL_OUT [5] hook.
Than they go to the routing stage, and than they go to
NF_IP_POST_ROUTING [4]. And then they go out ?
Such packets, which are created locally, don't pass at all
at the [1] stage, NF_IP_PRE_ROUTING [1] , and not
in NF_IP_LOCAL_IN [2] stage and not in NF_IP_FORWARD [3] .
Is it true?
Suppose I create locally packets which are destined to
myself (like ping myself). I assume that they will go first to the
NF_IP_LOCAL_OUT [5] , than to the routing stage, but will they go
to the NF_IP_POST_ROUTING [4].?
And again,such packets, which are created locally, don't pass at all
at the [1] stage, NF_IP_PRE_ROUTING [1] , and not
in NF_IP_LOCAL_IN [2] stage and not in NF_IP_FORWARD [3] .
Is it true?
IB
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Daniel Lezcano @ 2006-06-26 14:56 UTC (permalink / raw)
To: Andrey Savochkin
Cc: linux-kernel, netdev, serue, haveblue, clg, Andrew Morton, dev,
herbert, devel, sam, ebiederm, viro
In-Reply-To: <20060626134711.A28729@castle.nmd.msu.ru>
Andrey Savochkin wrote:
> Hi Daniel,
Hi Andrey,
>
> It's good that you kicked off network namespace discussion.
> Although I wish you'd Cc'ed someone at OpenVZ so I could notice it earlier :).
devel@openvz.org ?
> When a device presents an skb to the protocol layer, it needs to know to which
> namespace this skb belongs.
> Otherwise you would never get rid of problems with bind: what to do if device
> eth1 is visible in namespace1, namespace2, and root namespace, and each
> namespace has a socket bound to 0.0.0.0:80?
Exact. But, the idea was to retrieve the namespace from the routes.
IMHO, I think there are roughly 2 network isolation implementation:
- make all network ressources private to the namespace
- keep a "flat" model where network ressources have a new identifier
which is the network namespace pointer. The idea is to move only some
network informations private to the namespace (eg port range, stats, ...)
Daniel.
^ permalink raw reply
* Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
From: Daniel Lezcano @ 2006-06-26 14:56 UTC (permalink / raw)
To: Andrey Savochkin
Cc: linux-kernel, netdev, serue, haveblue, clg, Andrew Morton, dev,
herbert, devel, sam, ebiederm, viro
In-Reply-To: <20060626135427.C28942@castle.nmd.msu.ru>
Andrey Savochkin wrote:
> Structures related to IPv4 rounting (FIB and routing cache)
> are made per-namespace.
How do you handle ICMP_REDIRECT ?
^ permalink raw reply
* [PATCHSET] Towards accurate incoming interface information
From: Thomas Graf @ 2006-06-26 14:54 UTC (permalink / raw)
To: davem; +Cc: netdev
This patchset transforms skb->input_dev based on a device
reference to skb->iif based on an interface index moving
towards accurate iif information for routing and classification
through the following changesets:
[NET]: Use interface index to keep input device information
[VLAN]: Update iif when receiving via VLAN devic
[PKT_SCHED]: Add iif meta match
include/linux/skbuff.h | 4 ++--
include/linux/tc_ematch/tc_em_meta.h | 1 +
include/net/pkt_cls.h | 13 +++++++++----
net/8021q/vlan_dev.c | 2 ++
net/core/dev.c | 8 ++++----
net/core/skbuff.c | 2 +-
net/sched/act_api.c | 5 ++---
net/sched/act_mirred.c | 2 +-
net/sched/em_meta.c | 6 ++++++
9 files changed, 28 insertions(+), 15 deletions(-)
^ permalink raw reply
* [PATCH 1/3] [NET]: Use interface index to keep input device information
From: Thomas Graf @ 2006-06-25 22:00 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <20060626145446.948105000@postel.suug.ch>
[-- Attachment #1: input_dev --]
[-- Type: text/plain, Size: 4396 bytes --]
Using the interface index instead of a direct reference
allows a safe usage beyond the scope where an interface
could disappear.
The old input_dev field was incorrectly made dependant
on CONFIG_NET_CLS_ACT in skb_copy().
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Index: net-2.6.git/include/linux/skbuff.h
===================================================================
--- net-2.6.git.orig/include/linux/skbuff.h
+++ net-2.6.git/include/linux/skbuff.h
@@ -181,7 +181,6 @@ enum {
* @sk: Socket we are owned by
* @tstamp: Time we arrived
* @dev: Device we arrived on/are leaving by
- * @input_dev: Device we arrived on
* @h: Transport layer header
* @nh: Network layer header
* @mac: Link layer header
@@ -192,6 +191,7 @@ enum {
* @data_len: Data length
* @mac_len: Length of link layer header
* @csum: Checksum
+ * @iif: Device we arrived on
* @local_df: allow local fragmentation
* @cloned: Head may be cloned (check refcnt to be sure)
* @nohdr: Payload reference only, must not modify header
@@ -228,7 +228,6 @@ struct sk_buff {
struct sock *sk;
struct skb_timeval tstamp;
struct net_device *dev;
- struct net_device *input_dev;
union {
struct tcphdr *th;
@@ -266,6 +265,7 @@ struct sk_buff {
data_len,
mac_len,
csum;
+ int iif;
__u32 priority;
__u8 local_df:1,
cloned:1,
Index: net-2.6.git/include/net/pkt_cls.h
===================================================================
--- net-2.6.git.orig/include/net/pkt_cls.h
+++ net-2.6.git/include/net/pkt_cls.h
@@ -352,14 +352,19 @@ tcf_change_indev(struct tcf_proto *tp, c
static inline int
tcf_match_indev(struct sk_buff *skb, char *indev)
{
+ int ret = 1;
+
if (indev[0]) {
- if (!skb->input_dev)
- return 0;
- if (strcmp(indev, skb->input_dev->name))
+ struct net_device *dev;
+
+ dev = dev_get_by_index(skb->iif);
+ if (!dev)
return 0;
+ ret = !strcmp(indev, dev->name);
+ dev_put(dev);
}
- return 1;
+ return ret;
}
#endif /* CONFIG_NET_CLS_IND */
Index: net-2.6.git/net/core/dev.c
===================================================================
--- net-2.6.git.orig/net/core/dev.c
+++ net-2.6.git/net/core/dev.c
@@ -1715,8 +1715,8 @@ static int ing_filter(struct sk_buff *sk
if (dev->qdisc_ingress) {
__u32 ttl = (__u32) G_TC_RTTL(skb->tc_verd);
if (MAX_RED_LOOP < ttl++) {
- printk("Redir loop detected Dropping packet (%s->%s)\n",
- skb->input_dev->name, skb->dev->name);
+ printk("Redir loop detected Dropping packet (%d->%s)\n",
+ skb->iif, skb->dev->name);
return TC_ACT_SHOT;
}
@@ -1749,8 +1749,8 @@ int netif_receive_skb(struct sk_buff *sk
if (!skb->tstamp.off_sec)
net_timestamp(skb);
- if (!skb->input_dev)
- skb->input_dev = skb->dev;
+ if (!skb->iif)
+ skb->iif = skb->dev->ifindex;
orig_dev = skb_bond(skb);
Index: net-2.6.git/net/core/skbuff.c
===================================================================
--- net-2.6.git.orig/net/core/skbuff.c
+++ net-2.6.git/net/core/skbuff.c
@@ -463,10 +463,10 @@ struct sk_buff *skb_clone(struct sk_buff
n->tc_verd = SET_TC_VERD(skb->tc_verd,0);
n->tc_verd = CLR_TC_OK2MUNGE(n->tc_verd);
n->tc_verd = CLR_TC_MUNGED(n->tc_verd);
- C(input_dev);
#endif
skb_copy_secmark(n, skb);
#endif
+ C(iif);
C(truesize);
atomic_set(&n->users, 1);
C(head);
Index: net-2.6.git/net/sched/act_api.c
===================================================================
--- net-2.6.git.orig/net/sched/act_api.c
+++ net-2.6.git/net/sched/act_api.c
@@ -156,9 +156,8 @@ int tcf_action_exec(struct sk_buff *skb,
if (skb->tc_verd & TC_NCLS) {
skb->tc_verd = CLR_TC_NCLS(skb->tc_verd);
- D2PRINTK("(%p)tcf_action_exec: cleared TC_NCLS in %s out %s\n",
- skb, skb->input_dev ? skb->input_dev->name : "xxx",
- skb->dev->name);
+ D2PRINTK("(%p)tcf_action_exec: cleared TC_NCLS in %d out %s\n",
+ skb, skb->iif, skb->dev->name);
ret = TC_ACT_OK;
goto exec_done;
}
Index: net-2.6.git/net/sched/act_mirred.c
===================================================================
--- net-2.6.git.orig/net/sched/act_mirred.c
+++ net-2.6.git/net/sched/act_mirred.c
@@ -207,7 +207,7 @@ bad_mirred:
skb2->tc_verd = SET_TC_FROM(skb2->tc_verd, at);
skb2->dev = dev;
- skb2->input_dev = skb->dev;
+ skb2->iif = skb->dev->ifindex;
dev_queue_xmit(skb2);
spin_unlock(&p->lock);
return p->action;
--
^ permalink raw reply
* [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: Thomas Graf @ 2006-06-25 22:00 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <20060626145446.948105000@postel.suug.ch>
[-- Attachment #1: vlan_input_dev --]
[-- Type: text/plain, Size: 651 bytes --]
Updating iif to the VLAN device helps keeping routing
namespaces defined in case packets from multiple VLANs
collapse on a single device again.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Index: net-2.6.git/net/8021q/vlan_dev.c
===================================================================
--- net-2.6.git.orig/net/8021q/vlan_dev.c
+++ net-2.6.git/net/8021q/vlan_dev.c
@@ -156,6 +156,8 @@ int vlan_skb_recv(struct sk_buff *skb, s
return -1;
}
+ /* Make packets look like they have been received on the VLAN device */
+ skb->iif = skb->dev->ifindex;
skb->dev->last_rx = jiffies;
/* Bump the rx counters for the VLAN device. */
--
^ permalink raw reply
* [PATCH 3/3] [PKT_SCHED]: Add iif meta match
From: Thomas Graf @ 2006-06-25 22:00 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <20060626145446.948105000@postel.suug.ch>
[-- Attachment #1: iif_meta --]
[-- Type: text/plain, Size: 1285 bytes --]
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Index: net-2.6.git/include/linux/tc_ematch/tc_em_meta.h
===================================================================
--- net-2.6.git.orig/include/linux/tc_ematch/tc_em_meta.h
+++ net-2.6.git/include/linux/tc_ematch/tc_em_meta.h
@@ -81,6 +81,7 @@ enum
TCF_META_ID_SK_SNDTIMEO,
TCF_META_ID_SK_SENDMSG_OFF,
TCF_META_ID_SK_WRITE_PENDING,
+ TCF_META_ID_IIF,
__TCF_META_ID_MAX
};
#define TCF_META_ID_MAX (__TCF_META_ID_MAX - 1)
Index: net-2.6.git/net/sched/em_meta.c
===================================================================
--- net-2.6.git.orig/net/sched/em_meta.c
+++ net-2.6.git/net/sched/em_meta.c
@@ -170,6 +170,11 @@ META_COLLECTOR(var_dev)
*err = var_dev(skb->dev, dst);
}
+META_COLLECTOR(int_iif)
+{
+ dst->value = skb->iif;
+}
+
/**************************************************************************
* skb attributes
**************************************************************************/
@@ -525,6 +530,7 @@ static struct meta_ops __meta_ops[TCF_ME
[META_ID(SK_SNDTIMEO)] = META_FUNC(int_sk_sndtimeo),
[META_ID(SK_SENDMSG_OFF)] = META_FUNC(int_sk_sendmsg_off),
[META_ID(SK_WRITE_PENDING)] = META_FUNC(int_sk_write_pend),
+ [META_ID(IIF)] = META_FUNC(int_iif),
}
};
--
^ permalink raw reply
* Re: [patch 4/4] Network namespaces: playing and debugging
From: Daniel Lezcano @ 2006-06-26 15:04 UTC (permalink / raw)
To: Andrey Savochkin
Cc: linux-kernel, netdev, serue, haveblue, clg, Andrew Morton, dev,
herbert, devel, sam, ebiederm, viro
In-Reply-To: <20060626135537.D28942@castle.nmd.msu.ru>
Andrey Savochkin wrote:
> Temporary code to play with network namespaces in the simplest way.
> Do
> exec 7< /proc/net/net_ns
> in your bash shell and you'll get a brand new network namespace.
> There you can, for example, do
> ip link set lo up
> ip addr list
> ip addr add 1.2.3.4 dev lo
> ping -n 1.2.3.4
>
Is it possible to setup a network device to communicate with the outside ?
^ permalink raw reply
* Re: [RFC][patch 1/4] Network namespaces: cleanup of dev_base list use
From: Eric W. Biederman @ 2006-06-26 15:13 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>
Andrey Savochkin <saw@swsoft.com> writes:
> Cleanup of dev_base list use, with the aim to make device list per-namespace.
> In almost every occasion, use of dev_base variable and dev->next pointer
> could be easily replaced by for_each_netdev loop.
> A few most complicated places were converted to using
> first_netdev()/next_netdev().
As a proof of concept patch this is ok.
As a real world patch this is much too big, which prevents review.
Plus it takes a few actions that are more than replace just
iterators through the device list.
In addition I suspect several if not all of these iterators
can be replaced with the an appropriate helper function.
The normal structure for a patch like this would be to
introduce the new helper function. for_each_netdev.
And then to replace all of the users while cc'ing the
maintainers of those drivers. With each different
driver being a different patch.
There is another topic for discussion in this patch as well.
How much of the context should be implicit and how much
should be explicit.
If the changes from netchannels had already been implemented, and all of
the network processing was happening in a process context then I would
trivially agree that implicit would be the way to go.
However short of always having code always execute in the proper
context I'm not comfortable with implicit parameters to functions.
Not that this the contents of this patch should address this but the
later patches should.
When I went through this, my patchset just added an explicit
continue if the devices was not in the appropriate namespace.
I actually prefer the multiple list implementation but at
the same time I think it is harder to get a clean implementation
out of it.
Eric
> --- ./drivers/block/aoe/aoecmd.c.vedevbase Wed Jun 21 18:50:28 2006
> +++ ./drivers/block/aoe/aoecmd.c Thu Jun 22 12:03:07 2006
> @@ -204,14 +204,17 @@ aoecmd_cfg_pkts(ushort aoemajor, unsigne
> sl = sl_tail = NULL;
>
> read_lock(&dev_base_lock);
> - for (ifp = dev_base; ifp; dev_put(ifp), ifp = ifp->next) {
> + for_each_netdev(dev) {
> dev_hold(ifp);
> - if (!is_aoe_netif(ifp))
> + if (!is_aoe_netif(ifp)) {
> + dev_put(ifp);
> continue;
> + }
>
> skb = new_skb(ifp, sizeof *h + sizeof *ch);
> if (skb == NULL) {
> printk(KERN_INFO "aoe: aoecmd_cfg: skb alloc
> failure\n");
> + dev_put(ifp);
> continue;
> }
> if (sl_tail == NULL)
> @@ -229,6 +232,7 @@ aoecmd_cfg_pkts(ushort aoemajor, unsigne
>
> skb->next = sl;
> sl = skb;
> + dev_put(ifp);
> }
> read_unlock(&dev_base_lock);
These hunks should use for_each_netdev(ifp);
> --- ./include/linux/netdevice.h.vedevbase Wed Jun 21 18:53:17 2006
> +++ ./include/linux/netdevice.h Thu Jun 22 18:57:50 2006
> @@ -289,8 +289,8 @@ struct net_device
>
> unsigned long state;
>
> - struct net_device *next;
> -
> + struct list_head dev_list;
> +
> /* The device initialization function. Called only once. */
> int (*init)(struct net_device *dev);
>
> @@ -543,9 +543,27 @@ struct packet_type {
> #include <linux/interrupt.h>
> #include <linux/notifier.h>
>
> -extern struct net_device loopback_dev; /* The loopback */
> -extern struct net_device *dev_base; /* All devices */
> -extern rwlock_t dev_base_lock; /* Device list lock */
> +extern struct net_device loopback_dev; /* The loopback */
> +extern struct list_head dev_base_head; /* All devices */
> +extern rwlock_t dev_base_lock; /* Device list lock */
> +
No need to change the loopback_dev and dev_base_lock here.
What is the advantage of changing the type of dev_base?
I can guess but there should be an explanation of it.
> +#define for_each_netdev(p) list_for_each_entry(p, &dev_base_head, dev_list)
> +
> +/* DO NOT USE first_netdev/next_netdev, use loop defined above */
> +#define first_netdev() ({ \
> + list_empty(&dev_base_head) ? NULL : \
> + list_entry(dev_base_head.next, \
> + struct net_device, \
> + dev_list); \
> + })
> +#define next_netdev(dev) ({ \
> + struct list_head *__next; \
> + __next = (dev)->dev_list.next; \
> + __next == &dev_base_head ? NULL : \
> + list_entry(__next, \
> + struct net_device, \
> + dev_list); \
> + })
>
> extern int netdev_boot_setup_check(struct net_device *dev);
> extern unsigned long netdev_boot_base(const char *prefix, int unit);
> @@ -1903,7 +1902,7 @@ static int dev_ifconf(char __user *arg)
> */
>
> total = 0;
> - for (dev = dev_base; dev; dev = dev->next) {
> + for_each_netdev(dev) {
> for (i = 0; i < NPROTO; i++) {
> if (gifconf_list[i]) {
> int done;
> @@ -1935,26 +1934,25 @@ static int dev_ifconf(char __user *arg)
Hmm. The proc code here appears to be more than non-trivial
restructuring. I'm not certain it is but it looks that way
which make review harder.
> * This is invoked by the /proc filesystem handler to display a device
> * in detail.
> */
> -static __inline__ struct net_device *dev_get_idx(loff_t pos)
> -{
> - struct net_device *dev;
> - loff_t i;
> -
> - for (i = 0, dev = dev_base; dev && i < pos; ++i, dev = dev->next);
> -
> - return i == pos ? dev : NULL;
> -}
> -
> void *dev_seq_start(struct seq_file *seq, loff_t *pos)
> {
> + struct net_device *dev;
> + loff_t off = 1;
> read_lock(&dev_base_lock);
> - return *pos ? dev_get_idx(*pos - 1) : SEQ_START_TOKEN;
> + if (!*pos)
> + return SEQ_START_TOKEN;
> + for_each_netdev(dev) {
> + if (off++ == *pos)
> + return dev;
> + }
> + return NULL;
> }
>
> void *dev_seq_next(struct seq_file *seq, void *v, loff_t *pos)
> {
> + struct net_device *dev = v;
> ++*pos;
> - return v == SEQ_START_TOKEN ? dev_base : ((struct net_device *)v)->next;
> + return v == SEQ_START_TOKEN ? first_netdev() : next_netdev(dev);
> }
>
> void dev_seq_stop(struct seq_file *seq, void *v)
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Eric W. Biederman @ 2006-06-26 15:21 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Andrey Savochkin, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, herbert, devel, sam, viro
In-Reply-To: <449FF5A0.2000403@fr.ibm.com>
Daniel Lezcano <dlezcano@fr.ibm.com> writes:
> Andrey Savochkin wrote:
>> Hi Daniel,
>
> Hi Andrey,
>
>> It's good that you kicked off network namespace discussion.
>> Although I wish you'd Cc'ed someone at OpenVZ so I could notice it earlier :).
>
> devel@openvz.org ?
>
>> When a device presents an skb to the protocol layer, it needs to know to which
>> namespace this skb belongs.
>> Otherwise you would never get rid of problems with bind: what to do if device
>> eth1 is visible in namespace1, namespace2, and root namespace, and each
>> namespace has a socket bound to 0.0.0.0:80?
>
> Exact. But, the idea was to retrieve the namespace from the routes.
The problem is that if you start at the routes you have to do things
at layer 3 and you can't do anything at layer 2. (i.e. You can't use DHCP).
You loose a whole lot of flexibility and power when you make it a
layer 3 only mechanism.
> IMHO, I think there are roughly 2 network isolation implementation:
>
> - make all network ressources private to the namespace
>
> - keep a "flat" model where network ressources have a new identifier
> which is the network namespace pointer. The idea is to move only some network
> informations private to the namespace (eg port range, stats, ...)
The problem is that you have to add a lot of new logic which is very
hard to get right and has some really weird corner cases that are very
hard to understand.
- That makes the patches hard to review.
- It makes it hard for the implementors to get it right.
- It means that there will be corner cases that the users don't
understand.
- It is less flexible/powerful in what you can express?
I've been down that route it sucks. Anything more than the simple
filter at bind time is asking for real trouble until you do the whole
thing.
Eric
^ permalink raw reply
* Re: [PATCH REPOST 1/2] Network Event Notifier Mechanism.
From: Steve Wise @ 2006-06-26 15:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20060623.132647.39159829.davem@davemloft.net>
On Fri, 2006-06-23 at 13:26 -0700, David Miller wrote:
> From: Steve Wise <swise@opengridcomputing.com>
> Date: Fri, 23 Jun 2006 15:19:28 -0500
>
> > +struct netevent_route_change {
> > + int event;
> > + struct fib_info *fib_info;
> > +};
>
> It's not generic if you're putting ipv4 FIB route objects
> in the datastructure.
>
True.
I guess what I think we should do is pass the fib_info * when its a IPv4
route add/del, and a rt6_info * when its a IPv6 add/del. This avoids
having to create some new family independent struct. What I'll have to
do, however, is have specific notifier event enums for each:
NETEVENT_IPV4_ROUTE_ADD
NETEVENT_IPV4_ROUTE_DEL
NETEVENT_IPV6_ROUTE_ADD
NETEVENT_IPV6_ROUTE_DEL
This keeps it simple IMO...
Does that sound reasonable to you?
Steve.
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Andrey Savochkin @ 2006-06-26 15:27 UTC (permalink / raw)
To: Daniel Lezcano
Cc: linux-kernel, netdev, serue, haveblue, clg, Andrew Morton, dev,
herbert, devel, sam, ebiederm, viro, Alexey Kuznetsov
In-Reply-To: <449FF5A0.2000403@fr.ibm.com>
Daniel,
On Mon, Jun 26, 2006 at 04:56:32PM +0200, Daniel Lezcano wrote:
> Andrey Savochkin wrote:
> >
> > It's good that you kicked off network namespace discussion.
> > Although I wish you'd Cc'ed someone at OpenVZ so I could notice it earlier :).
>
> devel@openvz.org ?
devel@openvz.org is fine
>
> > When a device presents an skb to the protocol layer, it needs to know to which
> > namespace this skb belongs.
> > Otherwise you would never get rid of problems with bind: what to do if device
> > eth1 is visible in namespace1, namespace2, and root namespace, and each
> > namespace has a socket bound to 0.0.0.0:80?
>
> Exact. But, the idea was to retrieve the namespace from the routes.
Then you lose the ability for each namespace to have its own routing entries.
Which implies that you'll have difficulties with devices that should exist
and be visible in one namespace only (like tunnels), as they require IP
addresses and route.
>
> IMHO, I think there are roughly 2 network isolation implementation:
>
> - make all network ressources private to the namespace
>
> - keep a "flat" model where network ressources have a new identifier
> which is the network namespace pointer. The idea is to move only some
> network informations private to the namespace (eg port range, stats, ...)
Sorry, I don't get the second idea with only some information private to
namespace.
How do you want TCP_INC_STATS macro look?
In my concept, it would be something like
#define TCP_INC_STATS(field) SNMP_INC_STATS(current_net_ns->tcp_stat, field)
where tcp_stat is a TCP statistics array inside net_namespace.
Regards
Andrey
^ permalink raw reply
* Re: bcm43xx: "transmit timed out" and apparent hang with "preemptible periodic work" patches
From: Michael Buesch @ 2006-06-26 15:27 UTC (permalink / raw)
To: Paul Collins; +Cc: bcm43xx-dev, netdev, linville
In-Reply-To: <200606261443.47341.mb@bu3sch.de>
On Monday 26 June 2006 14:43, Michael Buesch wrote:
> On Monday 26 June 2006 04:28, Paul Collins wrote:
> > With the bcm43xx periodic work patches that recently made it into
> > Linus's tree, my PowerBook does not survive running overnight.
> >
> > Yesterday I reverted
> >
> > 91769e7dd9cef7988dc4280f74ed168351beb5b8 [PATCH] bcm43xx: preemptible periodic work
> > 78ff56a06edc3407996173daf63e48f6b90c7062 [PATCH] bcm43xx: redesign locking
> >
> > and it was still alive this morning.
> >
> > The following is logged, but that may not be all since the screen was
> > turned off and kern.log was marked for no-fsync.
> >
> > Jun 24 06:53:41 briny kernel: NETDEV WATCHDOG: eth1: transmit timed out
> > Jun 24 06:53:41 briny kernel: bcm43xx: Controller RESET (TX timeout) ...
> > Jun 24 06:53:41 briny kernel: bcm43xx: Chip ID 0x4306, rev 0x3
> > Jun 24 06:53:41 briny kernel: bcm43xx: Number of cores: 5
> > Jun 24 06:53:41 briny kernel: bcm43xx: Core 0: ID 0x800, rev 0x4, vendor 0x4243, enabled
> > Jun 24 06:53:41 briny kernel: bcm43xx: Core 1: ID 0x812, rev 0x5, vendor 0x4243, disabled
> > Jun 24 06:53:41 briny kernel: bcm43xx: Core 2: ID 0x80d, rev 0x2, vendor 0x4243, enabled
> > Jun 24 06:53:41 briny kernel: bcm43xx: Core 3: ID 0x807, rev 0x2, vendor 0x4243, disabled
> > Jun 24 06:53:41 briny kernel: bcm43xx: Core 4: ID 0x804, rev 0x9, vendor 0x4243, enabled
> > Jun 24 06:53:41 briny kernel: bcm43xx: PHY connected
> > Jun 24 06:53:41 briny kernel: bcm43xx: Detected PHY: Version: 2, Type 2, Revision 2
> > Jun 24 06:53:41 briny kernel: bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
> > Jun 24 06:53:41 briny kernel: bcm43xx: Radio turned off
> > Jun 24 06:53:41 briny kernel: bcm43xx: Radio turned off
> > Jun 24 06:53:41 briny kernel: bcm43xx: Controller restarted
>
> Try to get more logs.
> I suggest to do a netconsole for logging.
>
Also note that current softmac trees have a patch missing.
It seems it got lost somewhere after my merge request.
I already contacted John in private for this, but no reply, yet.
The patch is attached. Maybe it fixes your issue.
--
Suspend MAC (and make MAC-suspend refcounting) when doing
long periodic work.
On long periodic work, we disable IRQs on the device, so
we don't want the MAC to stay operating and probably miss
packets due do non-delivery of interrupts.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx.h
===================================================================
--- wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx.h 2006-06-05 18:19:59.000000000 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx.h 2006-06-12 16:20:28.000000000 +0200
@@ -723,6 +723,8 @@
u32 irq_savedstate;
/* Link Quality calculation context. */
struct bcm43xx_noise_calculation noisecalc;
+ /* if > 0 MAC is suspended. if == 0 MAC is enabled. */
+ int mac_suspended;
/* Threshold values. */
//TODO: The RTS thr has to be _used_. Currently, it is only set via WX.
Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-06-05 20:17:36.000000000 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-06-12 16:41:41.000000000 +0200
@@ -2284,13 +2284,17 @@
/* http://bcm-specs.sipsolutions.net/EnableMac */
void bcm43xx_mac_enable(struct bcm43xx_private *bcm)
{
- bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
- bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD)
- | BCM43xx_SBF_MAC_ENABLED);
- bcm43xx_write32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON, BCM43xx_IRQ_READY);
- bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD); /* dummy read */
- bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy read */
- bcm43xx_power_saving_ctl_bits(bcm, -1, -1);
+ bcm->mac_suspended--;
+ assert(bcm->mac_suspended >= 0);
+ if (bcm->mac_suspended == 0) {
+ bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
+ bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD)
+ | BCM43xx_SBF_MAC_ENABLED);
+ bcm43xx_write32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON, BCM43xx_IRQ_READY);
+ bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD); /* dummy read */
+ bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy read */
+ bcm43xx_power_saving_ctl_bits(bcm, -1, -1);
+ }
}
/* http://bcm-specs.sipsolutions.net/SuspendMAC */
@@ -2299,18 +2303,23 @@
int i;
u32 tmp;
- bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
- bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
- bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD)
- & ~BCM43xx_SBF_MAC_ENABLED);
- bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy read */
- for (i = 100000; i; i--) {
- tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
- if (tmp & BCM43xx_IRQ_READY)
- return;
- udelay(10);
+ assert(bcm->mac_suspended >= 0);
+ if (bcm->mac_suspended == 0) {
+ bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
+ bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
+ bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD)
+ & ~BCM43xx_SBF_MAC_ENABLED);
+ bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy read */
+ for (i = 100000; i; i--) {
+ tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
+ if (tmp & BCM43xx_IRQ_READY)
+ goto out;
+ udelay(10);
+ }
+ printkl(KERN_ERR PFX "MAC suspend failed\n");
}
- printkl(KERN_ERR PFX "MAC suspend failed\n");
+out:
+ bcm->mac_suspended++;
}
void bcm43xx_set_iwmode(struct bcm43xx_private *bcm,
@@ -3168,8 +3177,10 @@
/* Periodic work will take a long time, so we want it to
* be preemtible.
*/
- bcm43xx_lock_irqonly(bcm, flags);
netif_stop_queue(bcm->net_dev);
+ synchronize_net();
+ bcm43xx_lock_irqonly(bcm, flags);
+ bcm43xx_mac_suspend(bcm);
if (bcm43xx_using_pio(bcm))
bcm43xx_pio_freeze_txqueues(bcm);
savedirqs = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
@@ -3192,6 +3203,7 @@
bcm43xx_interrupt_enable(bcm, savedirqs);
if (bcm43xx_using_pio(bcm))
bcm43xx_pio_thaw_txqueues(bcm);
+ bcm43xx_mac_enable(bcm);
}
netif_wake_queue(bcm->net_dev);
mmiowb();
@@ -3774,6 +3786,7 @@
bcm->softmac->set_channel = bcm43xx_ieee80211_set_chan;
bcm->irq_savedstate = BCM43xx_IRQ_INITIAL;
+ bcm->mac_suspended = 1;
bcm->pci_dev = pci_dev;
bcm->net_dev = net_dev;
bcm->bad_frames_preempt = modparam_bad_frames_preempt;
--
Greetings Michael.
^ permalink raw reply
* Re: [RFC 3/7] NetLabel: CIPSOv4 engine
From: James Morris @ 2006-06-26 15:32 UTC (permalink / raw)
To: Paul Moore
Cc: Ted, netdev, David S. Miller, Stephen Smalley, Venkat Yekkirala
In-Reply-To: <449C7D2E.8000101@hp.com>
On Fri, 23 Jun 2006, Paul Moore wrote:
> James Morris wrote:
> >
> > Support for interoperability with legacy CIPSO systems is something that I
> > think would be nice to have, if it can be done in a way which doesn't
> > impact deeply on core kernel code, and plays nicely with native Linux
> > infrastructure.
> >
>
> I'm not sure if you have had a chance to look at the new patch set yet
> but I know you have seen earlier versions and are at least familiar with
> the approach I am taking ... in your opinion is the NetLabel patch
> acceptable in its approach?
The approach basically seems ok, although the priority needs to be on
getting the native xfrm labeling stuff implemented correctly first before
really thinking about adding support for legacy schemes.
Here's a possible architectural strategy for all of this:
1. Generic xfrm labeling
2. General MLS infrastructure
3. MLS enhanchements to xfrm labeling
4. CIPSO/RIPSO infrastructure
5. HP and PitBull CIPSO implementations
We have (1) and TCS are working on (3).
(2) would include various intra-kernel and userland API support for any
common MLS requirements across MLS xfrm labeling and CIPSO schemes. Also,
I'm not sure how network namespaces might or might not play into this.
There's also the question of if/how secmark labeling might be used in
conjunction with these distributed labeling schemes.
Also, the unresolved issue of whether to support CIPSO at all.
Even if the approach is technically acceptable, there's the issue of
maintaining a lot of complicated code in mainline for a very narrow
userbase to talk to near-obsolete legacy systems.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [patch 1/4] Network namespaces: cleanup of dev_base list use
From: Andrey Savochkin @ 2006-06-26 15:42 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: <m1odwguez3.fsf@ebiederm.dsl.xmission.com>
Hi Eric,
On Mon, Jun 26, 2006 at 09:13:52AM -0600, Eric W. Biederman wrote:
> Andrey Savochkin <saw@swsoft.com> writes:
>
> > Cleanup of dev_base list use, with the aim to make device list per-namespace.
> > In almost every occasion, use of dev_base variable and dev->next pointer
> > could be easily replaced by for_each_netdev loop.
> > A few most complicated places were converted to using
> > first_netdev()/next_netdev().
>
> As a proof of concept patch this is ok.
>
> As a real world patch this is much too big, which prevents review.
> Plus it takes a few actions that are more than replace just
> iterators through the device list.
dev_base list is historically not the cleanest part of Linux networking.
I've still spotted a place where the first device in dev_base list is assumed
to be loopback. In early days we had more, now only one place or two...
>
> In addition I suspect several if not all of these iterators
> can be replaced with the an appropriate helper function.
>
> The normal structure for a patch like this would be to
> introduce the new helper function. for_each_netdev.
> And then to replace all of the users while cc'ing the
> maintainers of those drivers. With each different
> driver being a different patch.
>
> There is another topic for discussion in this patch as well.
> How much of the context should be implicit and how much
> should be explicit.
>
> If the changes from netchannels had already been implemented, and all of
> the network processing was happening in a process context then I would
> trivially agree that implicit would be the way to go.
Why would we want all network processing happen in a process context?
>
> However short of always having code always execute in the proper
> context I'm not comfortable with implicit parameters to functions.
> Not that this the contents of this patch should address this but the
> later patches should.
We just have too many layers in networking code, and FIB/routing
illustrates it well.
>
> When I went through this, my patchset just added an explicit
> continue if the devices was not in the appropriate namespace.
> I actually prefer the multiple list implementation but at
> the same time I think it is harder to get a clean implementation
> out of it.
Certainly, dev_base list reorganization is not the crucial point in network
namespaces. But it has to be done some way or other.
If people vote for a single list with skipping devices from a wrong
namespace, it's fine with me, I can re-make this patch.
I personally prefer per-namespace device list since we have too many places
in the kernel where this list is walked in a linear fashion,
and with many namespaces this list may become quite long.
Regards
Andrey
^ permalink raw reply
* Re: [patch 4/4] Network namespaces: playing and debugging
From: Andrey Savochkin @ 2006-06-26 15:43 UTC (permalink / raw)
To: Daniel Lezcano
Cc: linux-kernel, netdev, serue, haveblue, clg, Andrew Morton, dev,
herbert, devel, sam, ebiederm, viro, Alexey Kuznetsov
In-Reply-To: <449FF77D.3080707@fr.ibm.com>
On Mon, Jun 26, 2006 at 05:04:29PM +0200, Daniel Lezcano wrote:
> Andrey Savochkin wrote:
> > Temporary code to play with network namespaces in the simplest way.
> > Do
> > exec 7< /proc/net/net_ns
> > in your bash shell and you'll get a brand new network namespace.
> > There you can, for example, do
> > ip link set lo up
> > ip addr list
> > ip addr add 1.2.3.4 dev lo
> > ping -n 1.2.3.4
> >
>
> Is it possible to setup a network device to communicate with the outside ?
Such device was planned for the second patchset :)
I perhaps can send the patch tomorrow.
Andrey
^ permalink raw reply
* Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
From: Andrey Savochkin @ 2006-06-26 15:46 UTC (permalink / raw)
To: Daniel Lezcano
Cc: linux-kernel, netdev, serue, haveblue, clg, Andrew Morton, dev,
herbert, devel, sam, ebiederm, viro, Alexey Kuznetsov
In-Reply-To: <449FF5AE.2040201@fr.ibm.com>
On Mon, Jun 26, 2006 at 04:56:46PM +0200, Daniel Lezcano wrote:
> Andrey Savochkin wrote:
> > Structures related to IPv4 rounting (FIB and routing cache)
> > are made per-namespace.
>
> How do you handle ICMP_REDIRECT ?
Are you talking about routing cache entries created on incoming redirects?
Or outgoing redirects?
Andrey
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Daniel Lezcano @ 2006-06-26 15:49 UTC (permalink / raw)
To: Andrey Savochkin
Cc: linux-kernel, netdev, serue, haveblue, clg, Andrew Morton, dev,
herbert, devel, sam, ebiederm, viro, Alexey Kuznetsov
In-Reply-To: <20060626192751.A989@castle.nmd.msu.ru>
> Then you lose the ability for each namespace to have its own routing entries.
> Which implies that you'll have difficulties with devices that should exist
> and be visible in one namespace only (like tunnels), as they require IP
> addresses and route.
I mean instead of having the route tables private to the namespace, the
routes have the information to which namespace they are associated.
>
> - keep a "flat" model where network ressources have a new identifier
>>which is the network namespace pointer. The idea is to move only some
>>network informations private to the namespace (eg port range, stats, ...)
>
>
> Sorry, I don't get the second idea with only some information private to
> namespace.
>
> How do you want TCP_INC_STATS macro look?
I was thinking in TCP_INC_STATS(net_ns, field)
SNMP_INC_STATS(net_ns->tcp_stat, field)
> In my concept, it would be something like
> #define TCP_INC_STATS(field) SNMP_INC_STATS(current_net_ns->tcp_stat, field)
> where tcp_stat is a TCP statistics array inside net_namespace.
^ permalink raw reply
* Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
From: Daniel Lezcano @ 2006-06-26 15:57 UTC (permalink / raw)
To: Andrey Savochkin
Cc: linux-kernel, netdev, serue, haveblue, clg, Andrew Morton, dev,
herbert, devel, sam, ebiederm, viro, Alexey Kuznetsov
In-Reply-To: <20060626194625.E989@castle.nmd.msu.ru>
Andrey Savochkin wrote:
> On Mon, Jun 26, 2006 at 04:56:46PM +0200, Daniel Lezcano wrote:
>
>>Andrey Savochkin wrote:
>>
>>>Structures related to IPv4 rounting (FIB and routing cache)
>>>are made per-namespace.
>>
>>How do you handle ICMP_REDIRECT ?
>
>
> Are you talking about routing cache entries created on incoming redirects?
> Or outgoing redirects?
>
> Andrey
incoming redirects
^ 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