* Re: [PATCH, RFT] bcm43xx: AccessPoint mode
From: Francois Barre @ 2006-06-28 19:27 UTC (permalink / raw)
To: Michael Buesch; +Cc: bcm43xx-dev, netdev, Alexander Tsvyashchenko
In-Reply-To: <200606191107.34602.mb@bu3sch.de>
Hi all,
Sorry for answering years after the patch post, I didn't have time to
test this take2 patch before. I had a first look at it a couple of
days ago, but... you know, that was not my day.
> Well, it does not work 100%, but at least it's very promising.
> We are able to create a bssid and correctly send beacon frames out.
[...]
For my very own situation, that is :
- Apple Mini with a BCM 4306 (BigEndian)
- Linux/Win32 boxes with USB and PCMCIA wifi cards (mostly 802.11b usb
at the moment)
Current status is this one :
- master mode functionnal
- dhcp serving, good uptime
- no encryption, WEP or WPA of any kind tested yet
- a nice 1.2MB/s bandwidth (I'm testing with a 802.11b at client side,
and AFAIK, bcm43xx does not handle 802.11g yet, does it ?)
*BUT* a big issue : I got a per-connection hang-up at client side on
strong workloads, for both win32 and linux client side, with my usb
dongle (which is running ndiswrapper on *nux, sorry for that, I'm
ashamed of it, silly me, I know, but well... No choice, and the device
was given me free of charge so...).
Typical scenario is a ssh session on one hand and a ftp transfer on
the other. The ftp hangs, while the ssh session stays up and going.
I got no problem with the PCMCIA card (a rock-solid WG511T), on both
linux and win32.
Of course, the bcm43xx does not say anything about this (if it had
said so, I would have posted logs along with this complain), so my
conclusion would be :
Why on earth is this a per-connection issue ? where do I miss
something ? if I'm really missing packets on one connection, why is
the other one continuing to live ? I may have forgotten a subtle
detail of the TCP/IP behaviour here... Or may that be all about window
scaling and fragmentation ? I can not see anything else... I would at
least like to know what to test, as I'm a little bit confused here.
Yes, I'll try to dig around the ip window and timeout stuff by tonight...
Anyway, I would like to thank again and again Alexander and Michael
for the work done, that is really impressive. Great work !
Best regards,
F. B.
^ permalink raw reply
* Re: TOE, etc.
From: Steve Wise @ 2006-06-28 18:56 UTC (permalink / raw)
To: David Miller; +Cc: herbert, jgarzik, netdev
In-Reply-To: <20060628.113646.85408870.davem@davemloft.net>
On Wed, 2006-06-28 at 11:36 -0700, David Miller wrote:
> From: Steve Wise <swise@opengridcomputing.com>
> Date: Wed, 28 Jun 2006 09:54:57 -0500
>
> > Doesn't iSCSI have this same issue?
>
> Software iSCSI implementations don't have the issue because
> they go through the stack using normal sockets and normal
> device send and receive.
> -
Right. I was assuming, in this thread we were talking about iSCSI
devices where the TCP stack is in HW/FW on the adapter...
Steve.
^ permalink raw reply
* Re: Network namespaces a path to mergable code.
From: Andrey Savochkin @ 2006-06-28 18:51 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: <m1mzbxdu5q.fsf@ebiederm.dsl.xmission.com>
On Wed, Jun 28, 2006 at 12:14:41PM -0600, Eric W. Biederman wrote:
> Andrey Savochkin <saw@swsoft.com> writes:
>
> > On Wed, Jun 28, 2006 at 10:51:26AM -0600, Eric W. Biederman wrote:
> >> Andrey Savochkin <saw@swsoft.com> writes:
> >>
> >> > One possible option to resolve this question is to show 2 relatively short
> >> > patches just introducing namespaces for sockets in 2 ways: with explicit
> >> > function parameters and using implicit current context.
> >> > Then people can compare them and vote.
> >> > Do you think it's worth the effort?
> >>
> >> Given that we have two strong opinions in different directions I think it
> >> is worth the effort to resolve this.
> >
> > Do you have time to extract necessary parts of your old patch?
> > Or you aren't afraid of letting me draft an alternative version of socket
> > namespaces basing on your code? :)
>
> I'm not terribly afraid. I can always say you did it wrong. :)
:)
> I don't think I am going to have time today. But since this conversation
> is slowing down and we are to getting into the technical details.
> I will try and find some time.
Good.
I'll focus on my part then.
Andrey
^ permalink raw reply
* RE: TOE, etc.
From: Caitlin Bestler @ 2006-06-28 18:49 UTC (permalink / raw)
To: David Miller, swise; +Cc: herbert, jgarzik, netdev
netdev-owner@vger.kernel.org wrote:
> From: Steve Wise <swise@opengridcomputing.com>
> Date: Wed, 28 Jun 2006 09:54:57 -0500
>
>> Doesn't iSCSI have this same issue?
>
> Software iSCSI implementations don't have the issue because
> they go through the stack using normal sockets and normal
> device send and receive.
But hardware iSCSI implementations, which already exist,
do not work through normal sockets.
^ permalink raw reply
* [PATCH] bcm43xx-d80211: Lower mac_suspend timeout
From: Michael Buesch @ 2006-06-28 18:43 UTC (permalink / raw)
To: linville; +Cc: bcm43xx-dev, netdev, Larry Finger
Lower mac_suspend timeout.
This timeout won't ever trigger, if the hardware and driver is
not horribly faulty. It's just a safety net to not lock up the
kernel on bugs.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c 2006-06-28 20:37:15.000000000 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c 2006-06-28 20:40:47.000000000 +0200
@@ -2195,11 +2195,11 @@
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--) {
+ for (i = 10000; i; i--) {
tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
if (tmp & BCM43xx_IRQ_READY)
goto out;
- udelay(10);
+ udelay(1);
}
printkl(KERN_ERR PFX "MAC suspend failed\n");
}
--
Greetings Michael.
^ permalink raw reply
* [PATCH] bcm43xx-d80211: fix mac_suspend refcount
From: Michael Buesch @ 2006-06-28 18:38 UTC (permalink / raw)
To: linville; +Cc: bcm43xx-dev, netdev
This fixes mac_suspend reference counting for
ifconfig up
ifconfig down
ifconfig up
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c 2006-06-17 22:51:20.000000000 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c 2006-06-28 20:37:15.000000000 +0200
@@ -3756,6 +3756,8 @@
bcm43xx_lock_noirq(bcm);
bcm43xx_set_status(bcm, BCM43xx_STAT_INITIALIZING);
+ bcm->mac_suspended = 1;
+
err = bcm43xx_pctl_set_crystal(bcm, 1);
if (err)
goto out;
@@ -4383,7 +4385,6 @@
bcm->ieee = ieee;
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: TOE, etc.
From: David Miller @ 2006-06-28 18:36 UTC (permalink / raw)
To: swise; +Cc: herbert, jgarzik, netdev
In-Reply-To: <1151506497.14895.51.camel@stevo-desktop>
From: Steve Wise <swise@opengridcomputing.com>
Date: Wed, 28 Jun 2006 09:54:57 -0500
> Doesn't iSCSI have this same issue?
Software iSCSI implementations don't have the issue because
they go through the stack using normal sockets and normal
device send and receive.
^ permalink raw reply
* [PATCH] bcm43xx: fix mac_suspend refcount
From: Michael Buesch @ 2006-06-28 18:35 UTC (permalink / raw)
To: linville; +Cc: bcm43xx-dev, netdev
This fixes mac_suspend reference counting for
ifconfig up
ifconfig down
ifconfig up
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-06-28 20:12:03.000000000 +0200
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-06-28 20:31:22.000000000 +0200
@@ -3288,6 +3288,8 @@
bcm43xx_lock_noirq(bcm);
bcm43xx_set_status(bcm, BCM43xx_STAT_INITIALIZING);
+ bcm->mac_suspended = 1;
+
err = bcm43xx_pctl_set_crystal(bcm, 1);
if (err)
goto out;
@@ -3793,7 +3795,6 @@
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
* [PATCH] bcm43xx: voluntary preemtion in the calibration loops
From: Michael Buesch @ 2006-06-28 18:17 UTC (permalink / raw)
To: linville; +Cc: bcm43xx-dev, netdev
This patch adds voluntary preemption points into the
PHY calibration loops to allow non-CONFIG_PREEMPT machines
to not suffer from huge delays.
CONFIG_PREEMPT machines are already fine, because all this
code is run in non-atomic process context.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_phy.c 2006-06-24 22:13:44.000000000 +0200
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c 2006-06-28 18:24:59.000000000 +0200
@@ -81,6 +81,16 @@
static void bcm43xx_phy_initg(struct bcm43xx_private *bcm);
+static inline
+void bcm43xx_voluntary_preempt(void)
+{
+ assert(!in_atomic() && !in_irq() &&
+ !in_interrupt() && !irqs_disabled());
+#ifndef CONFIG_PREEMPT
+ cond_resched();
+#endif /* CONFIG_PREEMPT */
+}
+
void bcm43xx_raw_phy_lock(struct bcm43xx_private *bcm)
{
struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
@@ -133,22 +143,14 @@
void bcm43xx_phy_calibrate(struct bcm43xx_private *bcm)
{
struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
- unsigned long flags;
bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD); /* Dummy read. */
if (phy->calibrated)
return;
if (phy->type == BCM43xx_PHYTYPE_G && phy->rev == 1) {
- /* We do not want to be preempted while calibrating
- * the hardware.
- */
- local_irq_save(flags);
-
bcm43xx_wireless_core_reset(bcm, 0);
bcm43xx_phy_initg(bcm);
bcm43xx_wireless_core_reset(bcm, 1);
-
- local_irq_restore(flags);
}
phy->calibrated = 1;
}
@@ -1299,7 +1301,9 @@
{
int i;
u16 ret = 0;
+ unsigned long flags;
+ local_irq_save(flags);
for (i = 0; i < 10; i++){
bcm43xx_phy_write(bcm, 0x0015, 0xAFA0);
udelay(1);
@@ -1309,6 +1313,8 @@
udelay(40);
ret += bcm43xx_phy_read(bcm, 0x002C);
}
+ local_irq_restore(flags);
+ bcm43xx_voluntary_preempt();
return ret;
}
@@ -1435,6 +1441,7 @@
}
ret = bcm43xx_phy_read(bcm, 0x002D);
local_irq_restore(flags);
+ bcm43xx_voluntary_preempt();
return ret;
}
@@ -1760,6 +1767,7 @@
bcm43xx_radio_write16(bcm, 0x43, i);
bcm43xx_radio_write16(bcm, 0x52, radio->txctl2);
udelay(10);
+ bcm43xx_voluntary_preempt();
bcm43xx_phy_set_baseband_attenuation(bcm, j * 2);
@@ -1803,6 +1811,7 @@
radio->txctl2
| (3/*txctl1*/ << 4));//FIXME: shouldn't txctl1 be zero here and 3 in the loop above?
udelay(10);
+ bcm43xx_voluntary_preempt();
bcm43xx_phy_set_baseband_attenuation(bcm, j * 2);
@@ -1824,6 +1833,7 @@
bcm43xx_phy_write(bcm, 0x0812, (r27 << 8) | 0xA2);
udelay(2);
bcm43xx_phy_write(bcm, 0x0812, (r27 << 8) | 0xA3);
+ bcm43xx_voluntary_preempt();
} else
bcm43xx_phy_write(bcm, 0x0015, r27 | 0xEFA0);
bcm43xx_phy_lo_adjust(bcm, is_initializing);
@@ -2188,12 +2198,6 @@
{
struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
int err = -ENODEV;
- unsigned long flags;
-
- /* We do not want to be preempted while calibrating
- * the hardware.
- */
- local_irq_save(flags);
switch (phy->type) {
case BCM43xx_PHYTYPE_A:
@@ -2227,7 +2231,6 @@
err = 0;
break;
}
- local_irq_restore(flags);
if (err)
printk(KERN_WARNING PFX "Unknown PHYTYPE found!\n");
--
Greetings Michael.
^ permalink raw reply
* Re: Network namespaces a path to mergable code.
From: Eric W. Biederman @ 2006-06-28 18:14 UTC (permalink / raw)
To: Andrey Savochkin
Cc: dlezcano, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, herbert, devel, sam, viro, Alexey Kuznetsov
In-Reply-To: <20060628212240.A1833@castle.nmd.msu.ru>
Andrey Savochkin <saw@swsoft.com> writes:
> Hi Eric,
>
> On Wed, Jun 28, 2006 at 10:51:26AM -0600, Eric W. Biederman wrote:
>> Andrey Savochkin <saw@swsoft.com> writes:
>>
>> > One possible option to resolve this question is to show 2 relatively short
>> > patches just introducing namespaces for sockets in 2 ways: with explicit
>> > function parameters and using implicit current context.
>> > Then people can compare them and vote.
>> > Do you think it's worth the effort?
>>
>> Given that we have two strong opinions in different directions I think it
>> is worth the effort to resolve this.
>
> Do you have time to extract necessary parts of your old patch?
> Or you aren't afraid of letting me draft an alternative version of socket
> namespaces basing on your code? :)
I'm not terribly afraid. I can always say you did it wrong. :)
I don't think I am going to have time today. But since this conversation
is slowing down and we are to getting into the technical details.
I will try and find some time.
Eric
^ permalink raw reply
* Re: Network namespaces a path to mergable code.
From: Eric W. Biederman @ 2006-06-28 18:11 UTC (permalink / raw)
To: Andrey Savochkin
Cc: dlezcano, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, herbert, devel, sam, viro, Alexey Kuznetsov
In-Reply-To: <20060628212240.A1833@castle.nmd.msu.ru>
Andrey Savochkin <saw@swsoft.com> writes:
>> In a slightly different vein your second patch introduced a lot
>> of #ifdef CONFIG_NET_NS in C files. That is something we need to look closely
>> at.
>>
>> So I think the abstraction that we use to access per network namespace
>> variables needs some work if we are going to allow the ability to compile
>> out all of the namespace code. The explicit versus implicit lookup is just
>> one dimension of that problem.
>
> This is a good comment.
>
> Those ifdef's mostly correspond to places where we walk over lists
> and need to filter-out entities not belonging to a specific namespace.
> Those places about the same in your and my implementation.
> We can think what we can do with them.
> One trick that I used on several occasions is net_ns_same macro
> which doesn't evalute its arguments if CONFIG_NET_NS not defined,
> and thus can be used without ifdef's.
>
> Returning to implicit vs explicit function arguments, I belive that implicit
> arguments are more promising in having zero impact on the code when
> CONFIG_NET_NS is disabled.
> Functions like inet_addr_type will translate into exactly the same code as
> they did without net namespace patches.
Which brings us to a basic question. Does it make sense to have
a define that completely disables namespace support.
I know all of the simple namespaces have been implemented like that,
and it was relatively easy there. I'm not at all certain in the long
term we want a configuration option. Especially if simply enabling
the code doesn't have an impact on performance. Which I think is
a merge requirement anyway.
As for inet_addr_type and friends I do agree that implicit arguments
make for an easier implementation of CONFIG_NET_NS. My gut feel
is though that the code with explicit arguments is probably more
comprehensible in the long term. Especially as we find more weird
exceptions where the process we are running in does not have the correct
network namespace.
In general unnecessary CONFIG options are a problem because they make
the entire testing process much harder and make the code harder to
write (so that both cases work and work cleanly).
So my feeling is that we actually want to kill all of those CONFIG_XXX_NS
options.
Which simply leaves us with the problem of implementing the code cleanly.
Eric
^ permalink raw reply
* Re: [2.6 patch] net/dccp/: possible cleanups
From: Ian McDonald @ 2006-06-28 18:11 UTC (permalink / raw)
To: Adrian Bunk; +Cc: acme, dccp, linux-kernel, netdev
In-Reply-To: <20060628165430.GM13915@stusta.de>
Comments below:
On 6/29/06, Adrian Bunk <bunk@stusta.de> wrote:
> This patch contains the following possible cleanups:
> - sysctl.c: the Kconfig rules already disallow CONFIG_SYSCTL=n,
> there's no need for an additional check
Agree
> - proper extern declarations for some variables in dccp.h
NAK - have sent another patch to shift these to feat.h. Arnaldo is
reviewing patches next week.
> - make the following needlessly global function static:
> - ipv4.c: dccp_v4_checksum()
Agree
> - #if 0 the following unused functions:
> - ackvec.c: dccp_ackvector_print()
> - ackvec.c: dccp_ackvec_print()
> - output.c: dccp_send_delayed_ack()
NAK on the first two. These are for debugging and DCCP still needs
improving so I think worthwhile having there in short term so we can
quickly call them if needed.
I will leave Arnaldo or Andrea to comment on last one...
Ian
--
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand
^ permalink raw reply
* Re: Please pull 'upstream' branch of wireless-2.6
From: Michael Buesch @ 2006-06-28 18:02 UTC (permalink / raw)
To: Larry Finger; +Cc: John W. Linville, netdev
In-Reply-To: <44A2BD36.3010601@lwfinger.net>
On Wednesday 28 June 2006 19:32, Larry Finger wrote:
> Michael Buesch wrote:
> > On Wednesday 28 June 2006 18:04, Larry Finger wrote:
> >
> > Oh, well. Forget it all.
> > I remembered the code wrong.
> > At the moment I looked at the code and it has the opposite semantics.
> > It loops to wait for the READY bit to appear.
> >
> > Well, I would say your old device simply takes this long
> > to disable and there is no bug.
> >
> > Oh, well...
>
> So the conclusion is that my card is really slow. As mine is likely to be the worst of the lot, I
> propose the following structure for the loop in question:
>
> for (i = 10000; i; i--) {
> tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
> if (tmp & BCM43xx_IRQ_READY) {
> if (i < 9998)
> printkl(KERN_INFO PFX "MAC suspend delay %d usec, IRQ_REASON "
> "0x%08x\n", 10000-i, tmp & ~BCM43xx_IRQ_READY);
> goto out;
> }
> udelay(1);
> }
> printkl(KERN_ERR PFX "MAC suspend failed\n");
>
> My maximum delay (so far) is 796 usec, thus this loop gives me a safety factor of more than 10, but
> it should satisfy Jeff and let this patch in question be accepted.
Ok, I will send a patch to lower the limit to 10000 usec.
This won't do _any_ good (or bad), but well... If everybody likes
placebos, I will add it to the driver.
It's a bit complicated for me to say why your card takes 800usec
to suspend MAC. And additionally it is not really possible for
me to try to find a way making the card respond earlier (if possible)
remotely through you. ;)
How problematic might a 800usec delay with IRQs disabled be?
> Of course, the 'if (i < 9998)'
> statement with the printkl is optional.
It is to be removed. ;)
--
Greetings Michael.
^ permalink raw reply
* [PATCH 2/2] bnx2: Turn off link during shutdown
From: Michael Chan @ 2006-06-28 17:59 UTC (permalink / raw)
To: davem; +Cc: netdev
Minor change in shutdown logic to effect a link down.
Update version to 1.4.43.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index e59cb59..d55b0f7 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -57,8 +57,8 @@
#define DRV_MODULE_NAME "bnx2"
#define PFX DRV_MODULE_NAME ": "
-#define DRV_MODULE_VERSION "1.4.42"
-#define DRV_MODULE_RELDATE "June 12, 2006"
+#define DRV_MODULE_VERSION "1.4.43"
+#define DRV_MODULE_RELDATE "June 28, 2006"
#define RUN_AT(x) (jiffies + (x))
@@ -4541,7 +4541,7 @@ bnx2_close(struct net_device *dev)
bnx2_netif_stop(bp);
del_timer_sync(&bp->timer);
if (bp->flags & NO_WOL_FLAG)
- reset_code = BNX2_DRV_MSG_CODE_UNLOAD;
+ reset_code = BNX2_DRV_MSG_CODE_UNLOAD_LNK_DN;
else if (bp->wol)
reset_code = BNX2_DRV_MSG_CODE_SUSPEND_WOL;
else
@@ -5978,7 +5978,7 @@ bnx2_suspend(struct pci_dev *pdev, pm_me
netif_device_detach(dev);
del_timer_sync(&bp->timer);
if (bp->flags & NO_WOL_FLAG)
- reset_code = BNX2_DRV_MSG_CODE_UNLOAD;
+ reset_code = BNX2_DRV_MSG_CODE_UNLOAD_LNK_DN;
else if (bp->wol)
reset_code = BNX2_DRV_MSG_CODE_SUSPEND_WOL;
else
diff --git a/drivers/net/bnx2.h b/drivers/net/bnx2.h
index 5845e33..658c5ee 100644
--- a/drivers/net/bnx2.h
+++ b/drivers/net/bnx2.h
@@ -4174,6 +4174,7 @@ struct fw_info {
#define BNX2_DRV_MSG_CODE_PULSE 0x06000000
#define BNX2_DRV_MSG_CODE_DIAG 0x07000000
#define BNX2_DRV_MSG_CODE_SUSPEND_NO_WOL 0x09000000
+#define BNX2_DRV_MSG_CODE_UNLOAD_LNK_DN 0x0b000000
#define BNX2_DRV_MSG_DATA 0x00ff0000
#define BNX2_DRV_MSG_DATA_WAIT0 0x00010000
^ permalink raw reply related
* [PATCH 1/2] bnx2: Use dev_kfree_skb() instead of the _irq version
From: Michael Chan @ 2006-06-28 17:59 UTC (permalink / raw)
To: davem; +Cc: netdev
Change all dev_kfree_skb_irq() and dev_kfree_skb_any() to
dev_kfree_skb(). These calls are never used in irq context.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index e89d5df..e59cb59 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -1676,7 +1676,7 @@ bnx2_tx_int(struct bnx2 *bp)
tx_free_bd += last + 1;
- dev_kfree_skb_irq(skb);
+ dev_kfree_skb(skb);
hw_cons = bp->hw_tx_cons =
sblk->status_tx_quick_consumer_index0;
@@ -1824,7 +1824,7 @@ reuse_rx:
if ((len > (bp->dev->mtu + ETH_HLEN)) &&
(ntohs(skb->protocol) != 0x8100)) {
- dev_kfree_skb_irq(skb);
+ dev_kfree_skb(skb);
goto next_rx;
}
@@ -3643,7 +3643,7 @@ bnx2_free_tx_skbs(struct bnx2 *bp)
skb_shinfo(skb)->frags[j].size,
PCI_DMA_TODEVICE);
}
- dev_kfree_skb_any(skb);
+ dev_kfree_skb(skb);
i += j + 1;
}
@@ -3669,7 +3669,7 @@ bnx2_free_rx_skbs(struct bnx2 *bp)
rx_buf->skb = NULL;
- dev_kfree_skb_any(skb);
+ dev_kfree_skb(skb);
}
}
@@ -3999,7 +3999,7 @@ bnx2_run_loopback(struct bnx2 *bp, int l
udelay(5);
pci_unmap_single(bp->pdev, map, pkt_size, PCI_DMA_TODEVICE);
- dev_kfree_skb_irq(skb);
+ dev_kfree_skb(skb);
if (bp->status_blk->status_tx_quick_consumer_index0 != bp->tx_prod) {
goto loopback_test_done;
^ permalink raw reply related
* Re: Network namespaces a path to mergable code.
From: Eric W. Biederman @ 2006-06-28 17:50 UTC (permalink / raw)
To: Andrey Savochkin
Cc: dlezcano, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, herbert, devel, sam, viro, Alexey Kuznetsov
In-Reply-To: <20060628212240.A1833@castle.nmd.msu.ru>
Andrey Savochkin <saw@swsoft.com> writes:
>> A general pattern that happens in cleanups is the discovery
>> that code using an old interface in a problematic way really
>> could be done much better another way. I didn't dig enough
>> to see if that was the case in any of the code that you changed.
>
> Well, there is obvious improvement of this kind: many protocols walk over
> device list to find devices with non-NULL protocol specific pointers.
> For example, IPv6, decnet and others do it on module unloading to clean up.
> Those places just ask for some simpler standard way of doing it, but I wasn't
> bold enough for such radical change.
> Do you think I should try?
It probably makes sense to asses that after the patches are split up.
Unless you run into something obvious.
Eric
^ permalink raw reply
* Re: Network namespaces a path to mergable code.
From: Herbert Poetzl @ 2006-06-28 17:40 UTC (permalink / raw)
To: Andrey Savochkin
Cc: Eric W. Biederman, dlezcano, linux-kernel, netdev, serue,
haveblue, clg, Andrew Morton, dev, devel, sam, viro,
Alexey Kuznetsov
In-Reply-To: <20060628212240.A1833@castle.nmd.msu.ru>
On Wed, Jun 28, 2006 at 09:22:40PM +0400, Andrey Savochkin wrote:
> Hi Eric,
>
> On Wed, Jun 28, 2006 at 10:51:26AM -0600, Eric W. Biederman wrote:
> > Andrey Savochkin <saw@swsoft.com> writes:
> >
> > > One possible option to resolve this question is to show 2
> > > relatively short patches just introducing namespaces for sockets
> > > in 2 ways: with explicit function parameters and using implicit
> > > current context. Then people can compare them and vote. Do you
> > > think it's worth the effort?
> >
> > Given that we have two strong opinions in different directions I
> > think it is worth the effort to resolve this.
>
> Do you have time to extract necessary parts of your old patch? Or you
> aren't afraid of letting me draft an alternative version of socket
> namespaces basing on your code? :)
>
> > In a slightly different vein your second patch introduced a lot of
> > #ifdef CONFIG_NET_NS in C files. That is something we need to look
> > closely at.
> >
> > So I think the abstraction that we use to access per network
> > namespace variables needs some work if we are going to allow the
> > ability to compile out all of the namespace code. The explicit
> > versus implicit lookup is just one dimension of that problem.
> This is a good comment.
>
> Those ifdef's mostly correspond to places where we walk over lists and
> need to filter-out entities not belonging to a specific namespace.
> Those places about the same in your and my implementation. We can
> think what we can do with them. One trick that I used on several
> occasions is net_ns_same macro which doesn't evalute its arguments if
> CONFIG_NET_NS not defined, and thus can be used without ifdef's.
yes, I think almost all of those cases can be avoided
while making the code even more readable by using
proper preprocessor (or even inline) mechanisms
> Returning to implicit vs explicit function arguments, I belive that
> implicit arguments are more promising in having zero impact on the
> code when CONFIG_NET_NS is disabled. Functions like inet_addr_type
> will translate into exactly the same code as they did without net
> namespace patches.
maybe a preprocessor wrapper can help here too ...
> > >> I'm still curious why many of those chunks can't use existing helper
> > >> functions, to be cleaned up.
> > >
> > > What helper functions are you referring to?
> >
> > Basically most of the device list walker functions live in.
> > net/core/dev.c
> >
> > I don't know if the cases you fixed could have used any of those
> > helper functions but it certainly has me asking that question.
> >
> > A general pattern that happens in cleanups is the discovery
> > that code using an old interface in a problematic way really
> > could be done much better another way. I didn't dig enough
> > to see if that was the case in any of the code that you changed.
>
> Well, there is obvious improvement of this kind: many protocols walk
> over device list to find devices with non-NULL protocol specific
> pointers. For example, IPv6, decnet and others do it on module
> unloading to clean up. Those places just ask for some simpler standard
> way of doing it, but I wasn't bold enough for such radical change.
> Do you think I should try?
IMHO it could not hurt to have some kind of protocol
helper library functions or macros ...
best,
Herbert
> Best regards
>
> Andrey
^ permalink raw reply
* Please pull 'zd1211rw' branch of wireless-2.6 (new driver)
From: John W. Linville @ 2006-06-28 17:36 UTC (permalink / raw)
To: jeff; +Cc: netdev
In-Reply-To: <20060628004838.GA15906@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 5037 bytes --]
For easier review, a tarball of drivers/net/wireless/zd1211rw is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/zd1211rw.tar.gz
>From Daniel's initial zd1211rw changelog:
[PATCH] ZyDAS ZD1211 USB-WLAN driver
There are 60+ USB wifi adapters available on the market based on the ZyDAS
ZD1211 chip.
Unlike the predecessor (ZD1201), ZD1211 does not have a hardware MAC, so most
data operations are coordinated by the device driver. The ZD1211 chip sits
alongside an RF transceiver which is also controlled by the driver. Our driver
currently supports 2 RF types, we know of one other available in a few marketed
products which we will be supporting soon.
Our driver also supports the newer revision of ZD1211, called ZD1211B. The
initialization and RF operations are slightly different for the new revision,
but the main difference is 802.11e support. Our driver does not support the
QoS features yet, but we think we know how to use them.
This driver is based on ZyDAS's own GPL driver available from www.zydas.com.tw.
ZyDAS engineers have been responsive and supportive of our efforts, so thumbs
up to them. Additionally, the firmware is redistributable and they have
provided device specs.
This driver has been written primarily by Ulrich Kunitz and myself. Graham
Gower, Greg KH, Remco and Bryan Rittmeyer have also contributed. The
developers of ieee80211 and softmac have made our lives so much easier- thanks
We maintain a small info-page: http://zd1211.ath.cx/wiki/DriverRewrite
If there is enough time for review, we would like to aim for inclusion in
2.6.18. The driver works nicely as a STA, and can connect to both open and
encrypted networks (we are using software-based encryption for now). We will
work towards supporting more advanced features in the future (ad-hoc, master
mode, 802.11a, ...).
Please review!
Thanks,
John
---
The following changes since commit 70a332b048e4d90635dfa47fc5d91cf87b5cc3a5:
John W. Linville:
softmac: fix build-break from 881ee6999d66c8fc903b429b73bbe6045b38c549
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git zd1211rw
Daniel Drake:
ZyDAS ZD1211 USB-WLAN driver
zd1211rw: disable TX queue during stop
drivers/net/wireless/Kconfig | 1
drivers/net/wireless/Makefile | 1
drivers/net/wireless/zd1211rw/Kconfig | 19
drivers/net/wireless/zd1211rw/Makefile | 11
drivers/net/wireless/zd1211rw/zd_chip.c | 1615 ++++++++++++++++++++++++++
drivers/net/wireless/zd1211rw/zd_chip.h | 825 +++++++++++++
drivers/net/wireless/zd1211rw/zd_def.h | 48 +
drivers/net/wireless/zd1211rw/zd_ieee80211.c | 191 +++
drivers/net/wireless/zd1211rw/zd_ieee80211.h | 85 +
drivers/net/wireless/zd1211rw/zd_mac.c | 1057 +++++++++++++++++
drivers/net/wireless/zd1211rw/zd_mac.h | 190 +++
drivers/net/wireless/zd1211rw/zd_netdev.c | 267 ++++
drivers/net/wireless/zd1211rw/zd_netdev.h | 45 +
drivers/net/wireless/zd1211rw/zd_rf.c | 151 ++
drivers/net/wireless/zd1211rw/zd_rf.h | 82 +
drivers/net/wireless/zd1211rw/zd_rf_al2230.c | 308 +++++
drivers/net/wireless/zd1211rw/zd_rf_rf2959.c | 279 ++++
drivers/net/wireless/zd1211rw/zd_types.h | 71 +
drivers/net/wireless/zd1211rw/zd_usb.c | 1316 +++++++++++++++++++++
drivers/net/wireless/zd1211rw/zd_usb.h | 240 ++++
drivers/net/wireless/zd1211rw/zd_util.c | 82 +
drivers/net/wireless/zd1211rw/zd_util.h | 29
22 files changed, 6913 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/wireless/zd1211rw/Kconfig
create mode 100644 drivers/net/wireless/zd1211rw/Makefile
create mode 100644 drivers/net/wireless/zd1211rw/zd_chip.c
create mode 100644 drivers/net/wireless/zd1211rw/zd_chip.h
create mode 100644 drivers/net/wireless/zd1211rw/zd_def.h
create mode 100644 drivers/net/wireless/zd1211rw/zd_ieee80211.c
create mode 100644 drivers/net/wireless/zd1211rw/zd_ieee80211.h
create mode 100644 drivers/net/wireless/zd1211rw/zd_mac.c
create mode 100644 drivers/net/wireless/zd1211rw/zd_mac.h
create mode 100644 drivers/net/wireless/zd1211rw/zd_netdev.c
create mode 100644 drivers/net/wireless/zd1211rw/zd_netdev.h
create mode 100644 drivers/net/wireless/zd1211rw/zd_rf.c
create mode 100644 drivers/net/wireless/zd1211rw/zd_rf.h
create mode 100644 drivers/net/wireless/zd1211rw/zd_rf_al2230.c
create mode 100644 drivers/net/wireless/zd1211rw/zd_rf_rf2959.c
create mode 100644 drivers/net/wireless/zd1211rw/zd_types.h
create mode 100644 drivers/net/wireless/zd1211rw/zd_usb.c
create mode 100644 drivers/net/wireless/zd1211rw/zd_usb.h
create mode 100644 drivers/net/wireless/zd1211rw/zd_util.c
create mode 100644 drivers/net/wireless/zd1211rw/zd_util.h
Full (history-free) patch attached as zd1211rw.patch.bz2
--
John W. Linville
linville@tuxdriver.com
[-- Attachment #2: zd1211rw.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 36554 bytes --]
^ permalink raw reply
* Re: Please pull 'upstream' branch of wireless-2.6
From: Larry Finger @ 2006-06-28 17:32 UTC (permalink / raw)
To: Michael Buesch; +Cc: John W. Linville, netdev
In-Reply-To: <200606281832.01108.mb@bu3sch.de>
Michael Buesch wrote:
> On Wednesday 28 June 2006 18:04, Larry Finger wrote:
>
> Oh, well. Forget it all.
> I remembered the code wrong.
> At the moment I looked at the code and it has the opposite semantics.
> It loops to wait for the READY bit to appear.
>
> Well, I would say your old device simply takes this long
> to disable and there is no bug.
>
> Oh, well...
So the conclusion is that my card is really slow. As mine is likely to be the worst of the lot, I
propose the following structure for the loop in question:
for (i = 10000; i; i--) {
tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
if (tmp & BCM43xx_IRQ_READY) {
if (i < 9998)
printkl(KERN_INFO PFX "MAC suspend delay %d usec, IRQ_REASON "
"0x%08x\n", 10000-i, tmp & ~BCM43xx_IRQ_READY);
goto out;
}
udelay(1);
}
printkl(KERN_ERR PFX "MAC suspend failed\n");
My maximum delay (so far) is 796 usec, thus this loop gives me a safety factor of more than 10, but
it should satisfy Jeff and let this patch in question be accepted. Of course, the 'if (i < 9998)'
statement with the printkl is optional. BTW, as you suspected, the IRQ_REASON value is still at
0x580 when the READY bit is set.
Thanks for the help,
Larry
^ permalink raw reply
* Re: Network namespaces a path to mergable code.
From: Andrey Savochkin @ 2006-06-28 17:22 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: <m1sllpfckx.fsf@ebiederm.dsl.xmission.com>
Hi Eric,
On Wed, Jun 28, 2006 at 10:51:26AM -0600, Eric W. Biederman wrote:
> Andrey Savochkin <saw@swsoft.com> writes:
>
> > One possible option to resolve this question is to show 2 relatively short
> > patches just introducing namespaces for sockets in 2 ways: with explicit
> > function parameters and using implicit current context.
> > Then people can compare them and vote.
> > Do you think it's worth the effort?
>
> Given that we have two strong opinions in different directions I think it
> is worth the effort to resolve this.
Do you have time to extract necessary parts of your old patch?
Or you aren't afraid of letting me draft an alternative version of socket
namespaces basing on your code? :)
>
> In a slightly different vein your second patch introduced a lot
> of #ifdef CONFIG_NET_NS in C files. That is something we need to look closely
> at.
>
> So I think the abstraction that we use to access per network namespace
> variables needs some work if we are going to allow the ability to compile
> out all of the namespace code. The explicit versus implicit lookup is just
> one dimension of that problem.
This is a good comment.
Those ifdef's mostly correspond to places where we walk over lists
and need to filter-out entities not belonging to a specific namespace.
Those places about the same in your and my implementation.
We can think what we can do with them.
One trick that I used on several occasions is net_ns_same macro
which doesn't evalute its arguments if CONFIG_NET_NS not defined,
and thus can be used without ifdef's.
Returning to implicit vs explicit function arguments, I belive that implicit
arguments are more promising in having zero impact on the code when
CONFIG_NET_NS is disabled.
Functions like inet_addr_type will translate into exactly the same code as
they did without net namespace patches.
>
> >> I'm still curious why many of those chunks can't use existing helper
> >> functions, to be cleaned up.
> >
> > What helper functions are you referring to?
>
> Basically most of the device list walker functions live in.
> net/core/dev.c
>
> I don't know if the cases you fixed could have used any of those
> helper functions but it certainly has me asking that question.
>
> A general pattern that happens in cleanups is the discovery
> that code using an old interface in a problematic way really
> could be done much better another way. I didn't dig enough
> to see if that was the case in any of the code that you changed.
Well, there is obvious improvement of this kind: many protocols walk over
device list to find devices with non-NULL protocol specific pointers.
For example, IPv6, decnet and others do it on module unloading to clean up.
Those places just ask for some simpler standard way of doing it, but I wasn't
bold enough for such radical change.
Do you think I should try?
Best regards
Andrey
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Herbert Poetzl @ 2006-06-28 17:18 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Sam Vilain, Kirill Korotaev, Daniel Lezcano, Andrey Savochkin,
linux-kernel, netdev, serue, haveblue, clg, Andrew Morton, devel,
viro, Alexey Kuznetsov
In-Reply-To: <m11wt9gulz.fsf@ebiederm.dsl.xmission.com>
On Wed, Jun 28, 2006 at 09:36:40AM -0600, Eric W. Biederman wrote:
> Herbert Poetzl <herbert@13thfloor.at> writes:
>
> > 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)
>
> Ok. This is new. How do you talk between guests now?
> Before those patches it was through IP addresses on the loopback
> interface as I recall.
no, that was probably your assumption, the IPs are
assigned (in a perfectly normal way) to the interfaces
(e.g. eth0 carries some IPs for guest A and B, eth1
carries others for guest C). the way the linux network
stack works, local addresses (i.e. those of A,B and C)
will automatically communicate via loopback (as they
are local) while outbound traffic will use the proper
interface (nothing is changed here)
the difference in the lo patches is, that we allow to
use the 'localhost' ip range (127.x.x.x) by isolating
traffic (in this range) on the loopback interface
(which typically allows to have 127.0.0.1 and lo
visible inside a guest)
> >> > 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)
>
> What is the mechanism there?
>
> My rough extrapolation says this mechanism causes problems when
> migrating between machines.
that might be, as we do not consider migration such
important as other folks do :)
> In particular it sounds like only one process can bind to *:80, even
> if it is only allowed to accept connections from a subset of those
> IPs.
no, guest A,B and C can all bind to *:80 and coexist
quite fine, given that they do not have any IP in
the intersection of their subsets (which is checked
at bind time)
> So if on another machine I bound something to *:80 and only allowed to
> use a different set of IPs and then attempted to migrate it, the
> migration would fail because I could not restart the application,
> with all of it's layer 3 resources.
actually I do not see why, unless the destination
has a conflict on the ip subset, in which case you
would end up with a migrated, but not working guest :)
> To be clear I assume when I migrate I always take my IP address or
> addresses with me.
that's fine, the only requirement would be that the
host has a superset of the IP addresses used by the
guests ...
HTC,
Herbert
> Eric
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Eric W. Biederman @ 2006-06-28 17:17 UTC (permalink / raw)
To: hadi
Cc: Andrey Savochkin, Dave Hansen, Ben Greear, Daniel Lezcano,
linux-kernel, netdev, serue, clg, Andrew Morton, dev, devel, sam,
viro, Alexey Kuznetsov, Herbert Poetzl
In-Reply-To: <1151511455.5160.48.camel@jzny2>
jamal <hadi@cyberus.ca> writes:
> Andrey,
>
> On Wed, 2006-28-06 at 18:19 +0400, Andrey Savochkin wrote:
>> Hi Jamal,
>>
>> On Wed, Jun 28, 2006 at 09:53:23AM -0400, jamal wrote:
>> >
>
>>
>> Seeing guestXX-eth0 interfaces by standard tools has certain attractive
>> sides. But it creates a lot of undesired side effects.
>>
>
> I apologize because i butted into the discussion without perhaps reading
> the full thread.
This thread is serving as an educational vehicle, and the more people
from outside of our little biased group that begin to understand what
we are about the better.
>> 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.
>>
>
> Ok, so the problem is that ntp in this case runs on the host side as
> opposed to the guest? This would explain why Eric is reacting vehemently
> to the suggestion.
Yes, that would be one problem case.
>> 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?..
>>
>
> yes, thats what i was thinking. Even go further and actually create
> guestxx-eth0 on the host (which results in creating eth0 on the guest)
> and other things.
>
>> 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.
>
> Ok, above may be good enough and doesnt require any state it seems on
> the host side.
> I got motivated when the word "migration" was mentioned. I understood it
> to be meaning that a guest may become inoperative for some reason and
> that its info will be transfered to another guest which may be local or
> even remote. In such a case, clearly one would need a protocol and the
> state of all guests sitting at the host. Maybe i am over-reaching.
Not really. Network namespaces while useful in their own right lay
the foundation for some more interesting applications. Application
migration between machines in particular.
The biggest fundamental problem in migration is after checkpointing your
application you can not acquire the resources you need on the new machine
because of name conflicts.
So for those of us concerned with migration a question we ask is can
we successfully import resource names that another machine has assigned without
consulting us.
The context for all of this goes to other discussion that we have been having
since January. Breaking all of this into small pieces that can be merged and
tested a little at a time is a challenge.
Eric
^ permalink raw reply
* Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
From: Ben Greear @ 2006-06-28 17:10 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Kirill Korotaev, Andrey Savochkin, linux-kernel, netdev, serue,
haveblue, clg, Andrew Morton, herbert, devel, sam, ebiederm, viro,
alexey
In-Reply-To: <44A2B4D7.9080007@fr.ibm.com>
Daniel Lezcano wrote:
> Kirill Korotaev 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 :)
>>
>>
>> if we had containers (not namespaces) then it would be also possible
>> to run NFS in context of the appropriate container and thus each user
>> could mount NFS itself with correct networking context.
With a relatively small patch, I was able to make NFS bind to a particular
local IP (poor man's namespace with existing code). I also changed it so
that multiple mounts to the same destination (and with unique local mount
points) are treated as unique mounts. This patch was done so that I could
stress test NFS servers, but similar logic might work for namespace isolation
as well...
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Herbert Poetzl @ 2006-06-28 17:04 UTC (permalink / raw)
To: Andrey Savochkin
Cc: hadi, 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: <20060628181900.A31885@castle.nmd.msu.ru>
On Wed, Jun 28, 2006 at 06:19:00PM +0400, Andrey Savochkin wrote:
> 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.
which all can be avoided by not using the host
context for that, but a special 'all seeing'
context (as we have in Linux-VServer) which
can see (and probably manipulate) those interfaces
from the 'admin' PoV without entering the guest
context
> 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.
applications scanning the interfaces at startup
are broken by design and should probably be
fixed instead of worked around ...
> 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?..
why not, would it do any harm when the hotplug
scripts on the host would take the appropriate
actions (i.e. do the required config for the guest)
for special guest interfaces?
but now that you mention it, what about hotplug
events inside the guest?
> 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
I do not consider this the best solution, especially
from the security PoV. don't forget you basically
enter the guest and execute arbitrary programs
(which might have been compromised) to do a setup
task you actually want to happen on the host
best,
Herbert
> and so on.
>
> Best regards
>
> Andrey
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Andrey Savochkin @ 2006-06-28 16:58 UTC (permalink / raw)
To: hadi
Cc: Eric W. Biederman, Dave Hansen, Ben Greear, Daniel Lezcano,
linux-kernel, netdev, serue, clg, Andrew Morton, dev, devel, sam,
viro, Alexey Kuznetsov, Herbert Poetzl
In-Reply-To: <1151511455.5160.48.camel@jzny2>
On Wed, Jun 28, 2006 at 12:17:35PM -0400, jamal wrote:
>
> On Wed, 2006-28-06 at 18:19 +0400, Andrey Savochkin wrote:
> >
> > Seeing guestXX-eth0 interfaces by standard tools has certain attractive
> > sides. But it creates a lot of undesired side effects.
> >
>
> I apologize because i butted into the discussion without perhaps reading
> the full thread.
Your comments are quite welcome
>
> > 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.
> >
>
> Ok, so the problem is that ntp in this case runs on the host side as
yes
> opposed to the guest? This would explain why Eric is reacting vehemently
> to the suggestion.
:)
And I actually do not want to distinguish host and guest sides much.
They are namespaces in the first place.
Parent namespace may have some capabilities to manipulate its child
namespaces, like donate its own device to one of its children.
But it comes secondary to having namespace isolation borders.
In particular, because most cases of cross-namespace interaction lead to
failures of formal security models and inability to migrate
namespaces between computers.
>
> > 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?..
> >
>
> yes, thats what i was thinking. Even go further and actually create
> guestxx-eth0 on the host (which results in creating eth0 on the guest)
> and other things.
This actually goes in the opposite direction to what I keep in mind.
I want to offload as much as possible of network administration work to
guests. Delegation of management is one of the motivating factors
behind covering not only sockets but devices, routes, and so on by the
namespace patches.
>
> > 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.
>
> Ok, above may be good enough and doesnt require any state it seems on
> the host side.
> I got motivated when the word "migration" was mentioned. I understood it
> to be meaning that a guest may become inoperative for some reason and
> that its info will be transfered to another guest which may be local or
> even remote. In such a case, clearly one would need a protocol and the
> state of all guests sitting at the host. Maybe i am over-reaching.
Migration will work inside the kernel, so it has full access
to whatever state information it needs.
Best regards
Andrey
^ 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