* Re: [patch 4/4] Network namespaces: playing and debugging
From: Andrey Savochkin @ 2006-06-26 19:34 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: <44A01995.20802@fr.ibm.com>
On Mon, Jun 26, 2006 at 07:29:57PM +0200, Daniel Lezcano wrote:
> >>>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
> >>>
>
> Andrey,
>
> I began to play with your patchset. I am able to connect to 127.0.0.1
> from different namespaces. Is it the expected behavior ?
> Furthermore, I am not able to have several programs, running in
> different namespaces, to bind to the same INADDR_ANY:port.
>
> Will these features be included in the second patchset ?
Of course.
This patchset adds namespaces to routing code, which means that
you can define local IP addresses in each namespace independently.
But this first patchset doesn't include namespaces in socket lookup code.
Andrey
^ permalink raw reply
* Re: -git: Why is drivers/net/wan/hdlc_generic.c:hdlc_setup() exported?
From: Krzysztof Halasa @ 2006-06-26 19:28 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Jeff Garzik, linux-kernel, netdev
In-Reply-To: <20060625205137.GH23314@stusta.de>
Adrian Bunk <bunk@stusta.de> writes:
> hdlc_setup() is now EXPORTed as per David's request.
>
> Is a usage of this export pending for the near future
I'm told it is.
--
Krzysztof Halasa
^ permalink raw reply
* Re: FW: + qla3xxx-is-bust.patch added to -mm tree
From: Andrew Morton @ 2006-06-26 19:24 UTC (permalink / raw)
To: Ron Mercer; +Cc: jeff, bunk, netdev, linux-driver
In-Reply-To: <0BB3E5E7462EEA4295BC02D49691DC07176AB0@AVEXCH1.qlogic.org>
On Mon, 26 Jun 2006 12:02:21 -0700
"Ron Mercer" <ron.mercer@qlogic.com> wrote:
> The attached patch fixes the compile bugs you indicated plus some of
> Jeff Garzik's concerns.
>
> - Removed non-NAPI code.
> - Removed un-needed PCI_POSTING macro.
> - Converted msleep() to ssleep() where waiting > 1 sec.
> - Broke up ql_link_state_machine into two functions for indent purposes.
> - Cleaned up ql3xxx_remove().
> - Cleaned up banner print and moved to probe.
> - Got rid of tx_lock. Not needed.
> - Fix send routine for big endian mapping problem.
> - Version change to k35.
>
> Built and tested on the latest git tree on x86 and PPC64 platforms.
Thanks.
Is the device hotpluggable? If so, this:
qdev->index = cards_found;
in the probe() handler might do odd things - it'll just keep increasing as
the card is removed and re-added.
iirc, that's a common problem with net drivers. AFAICT it'll cause only
cosmetic oddities here.
^ permalink raw reply
* Re: [PATCH] bcm43xx: enable shared key authentication
From: Michael Buesch @ 2006-06-26 19:10 UTC (permalink / raw)
To: John W. Linville; +Cc: Daniel Drake, netdev
In-Reply-To: <200606262106.40278.mb@bu3sch.de>
On Monday 26 June 2006 21:06, Michael Buesch wrote:
> On Monday 26 June 2006 20:38, John W. Linville wrote:
> > On Fri, Jun 16, 2006 at 08:50:22PM +0100, Daniel Drake wrote:
> > > I recently patched softmac to enable shared key authentication. This small patch
> > > will enable crazy or unfortunate bcm43xx users to use this new capability.
> > >
> > > Signed-off-by: Daniel Drake <dsd@gentoo.org>
> > >
> > > Index: linux/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> > > ===================================================================
> > > --- linux.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> > > +++ linux/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> > > @@ -3599,6 +3599,10 @@ static void bcm43xx_ieee80211_set_securi
> > > secinfo->encrypt = sec->encrypt;
> > > dprintk(KERN_INFO PFX " .encrypt = %d\n", sec->encrypt);
> > > }
> > > + if (sec->flags & SEC_AUTH_MODE) {
> > > + secinfo->auth_mode = sec->auth_mode;
> > > + dprintk(KERN_INFO PFX " .auth_mode = %d\n", sec->auth_mode);
> > > + }
> > > if (bcm->initialized && !bcm->ieee->host_encrypt) {
> > > if (secinfo->enabled) {
> > > /* upload WEP keys to hardware */
> >
> > I had problems applying this one. I recall having a similar problem w/
> > a patch in the last round of merging as well.
> >
> > The version of bcm43xx_main.c in wireless-2.6 looks like this
> > (post patch):
> >
> >
> > secinfo->encrypt = sec->encrypt;
> > dprintk(", .encrypt = %d", sec->encrypt);
> > }
> > if (sec->flags & SEC_AUTH_MODE) {
> > secinfo->auth_mode = sec->auth_mode;
> > dprintk(", .auth_mode = %d\n", sec->auth_mode);
> > }
> > dprintk("\n");
> > if (bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED &&
> > !bcm->ieee->host_encrypt) {
> >
> > Am I missing a patch?
> >
> > Please make sure I get any patches that are missing from wireless-2.6
> > -- it is obviously better if we are all on the same page! :-)
>
> Daniel's patch is diffed to an older tree.
> wireless-2.6 recently removed bcm->initialized and friends
> and added a more usable and more correct bcm43xx_status() flag.
>
> So, basically the following just has to be added after
> the other if(sec->flags & FOO), but before the if(bcm43xx_status...)
>
> if (sec->flags & SEC_AUTH_MODE) {
> secinfo->auth_mode = sec->auth_mode;
> dprintk(KERN_INFO PFX " .auth_mode = %d\n", sec->auth_mode);
> }
Oh, the printk is wrong. The \n has to be removed.
--
Greetings Michael.
^ permalink raw reply
* Re: [PATCH] bcm43xx: enable shared key authentication
From: Michael Buesch @ 2006-06-26 19:06 UTC (permalink / raw)
To: John W. Linville; +Cc: Daniel Drake, netdev
In-Reply-To: <20060626183821.GB30706@tuxdriver.com>
On Monday 26 June 2006 20:38, John W. Linville wrote:
> On Fri, Jun 16, 2006 at 08:50:22PM +0100, Daniel Drake wrote:
> > I recently patched softmac to enable shared key authentication. This small patch
> > will enable crazy or unfortunate bcm43xx users to use this new capability.
> >
> > Signed-off-by: Daniel Drake <dsd@gentoo.org>
> >
> > Index: linux/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> > ===================================================================
> > --- linux.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> > +++ linux/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> > @@ -3599,6 +3599,10 @@ static void bcm43xx_ieee80211_set_securi
> > secinfo->encrypt = sec->encrypt;
> > dprintk(KERN_INFO PFX " .encrypt = %d\n", sec->encrypt);
> > }
> > + if (sec->flags & SEC_AUTH_MODE) {
> > + secinfo->auth_mode = sec->auth_mode;
> > + dprintk(KERN_INFO PFX " .auth_mode = %d\n", sec->auth_mode);
> > + }
> > if (bcm->initialized && !bcm->ieee->host_encrypt) {
> > if (secinfo->enabled) {
> > /* upload WEP keys to hardware */
>
> I had problems applying this one. I recall having a similar problem w/
> a patch in the last round of merging as well.
>
> The version of bcm43xx_main.c in wireless-2.6 looks like this
> (post patch):
>
>
> secinfo->encrypt = sec->encrypt;
> dprintk(", .encrypt = %d", sec->encrypt);
> }
> if (sec->flags & SEC_AUTH_MODE) {
> secinfo->auth_mode = sec->auth_mode;
> dprintk(", .auth_mode = %d\n", sec->auth_mode);
> }
> dprintk("\n");
> if (bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED &&
> !bcm->ieee->host_encrypt) {
>
> Am I missing a patch?
>
> Please make sure I get any patches that are missing from wireless-2.6
> -- it is obviously better if we are all on the same page! :-)
Daniel's patch is diffed to an older tree.
wireless-2.6 recently removed bcm->initialized and friends
and added a more usable and more correct bcm43xx_status() flag.
So, basically the following just has to be added after
the other if(sec->flags & FOO), but before the if(bcm43xx_status...)
if (sec->flags & SEC_AUTH_MODE) {
secinfo->auth_mode = sec->auth_mode;
dprintk(KERN_INFO PFX " .auth_mode = %d\n", sec->auth_mode);
}
--
Greetings Michael.
^ permalink raw reply
* FW: + qla3xxx-is-bust.patch added to -mm tree
From: Ron Mercer @ 2006-06-26 19:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: Jeff Garzik, Adrian Bunk, netdev, linux-driver
[-- Attachment #1: Type: text/plain, Size: 629 bytes --]
Andrew Morton,
The attached patch fixes the compile bugs you indicated plus some of
Jeff Garzik's concerns.
- Removed non-NAPI code.
- Removed un-needed PCI_POSTING macro.
- Converted msleep() to ssleep() where waiting > 1 sec.
- Broke up ql_link_state_machine into two functions for indent purposes.
- Cleaned up ql3xxx_remove().
- Cleaned up banner print and moved to probe.
- Got rid of tx_lock. Not needed.
- Fix send routine for big endian mapping problem.
- Version change to k35.
Built and tested on the latest git tree on x86 and PPC64 platforms.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
[-- Attachment #2: qla3xxx-v2.02.00-k35.patch --]
[-- Type: application/octet-stream, Size: 17071 bytes --]
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 0ff814b..11a31f2 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2258,10 +2258,6 @@ config QLA3XXX
To compile this driver as a module, choose M here: the module
will be called qla3xxx.
-config QLA3XXX_NAPI
- bool "NAPI Support"
- depends on QLA3XXX
-
endmenu
#
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index 4ab7b74..fd8997e 100644
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -38,7 +38,7 @@
#define DRV_NAME "qla3xxx"
#define DRV_STRING "QLogic ISP3XXX Network Driver"
-#define DRV_VERSION "v2.02.00-k33"
+#define DRV_VERSION "v2.02.00-k35"
#define PFX DRV_NAME " "
static const char ql3xxx_driver_name[] = DRV_NAME;
@@ -95,7 +95,7 @@ static void ql_sem_unlock(struct ql3_ada
spin_lock_irqsave(&qdev->hw_lock, hw_flags);
writel(sem_mask, &port_regs->CommonRegs.semaphoreReg);
- PCI_POSTING(&port_regs->CommonRegs.semaphoreReg);
+ readl(&port_regs->CommonRegs.semaphoreReg);
spin_unlock_irqrestore(&qdev->hw_lock, hw_flags);
}
@@ -122,7 +122,7 @@ static int ql_wait_for_drvr_lock(struct
(QL_RESOURCE_BITS_BASE_CODE | (qdev->mac_index)
* 2) << 1)) {
if (i < 10) {
- msleep(1000);
+ ssleep(1);
i++;
} else {
printk(KERN_ERR PFX "%s: Timed out waiting for "
@@ -184,7 +184,7 @@ static void ql_write_common_reg(struct q
spin_lock_irqsave(&qdev->hw_lock, hw_flags);
writel(value, (u32 *) reg);
- PCI_POSTING(reg);
+ readl(reg);
spin_unlock_irqrestore(&qdev->hw_lock, hw_flags);
return;
}
@@ -199,7 +199,7 @@ static void ql_write_page0_reg(struct ql
if (qdev->current_page != 0)
ql_set_register_page(qdev,0);
writel(value, (u32 *) reg);
- PCI_POSTING(reg);
+ readl(reg);
spin_unlock_irqrestore(&qdev->hw_lock, hw_flags);
return;
@@ -215,7 +215,7 @@ static void ql_write_page1_reg(struct ql
if (qdev->current_page != 1)
ql_set_register_page(qdev,1);
writel(value, (u32 *) reg);
- PCI_POSTING(reg);
+ readl(reg);
spin_unlock_irqrestore(&qdev->hw_lock, hw_flags);
return;
@@ -231,7 +231,7 @@ static void ql_write_page2_reg(struct ql
if (qdev->current_page != 2)
ql_set_register_page(qdev,2);
writel(value, (u32 *) reg);
- PCI_POSTING(reg);
+ readl(reg);
spin_unlock_irqrestore(&qdev->hw_lock, hw_flags);
return;
@@ -1241,6 +1241,67 @@ static int ql_port_start(struct ql3_adap
return 0;
}
+static void ql_finish_auto_neg(struct ql3_adapter *qdev)
+{
+ if (!ql_auto_neg_error(qdev)) {
+ if (test_bit(QL_LINK_MASTER,&qdev->flags)) {
+ /* configure the MAC */
+ if (netif_msg_link(qdev))
+ printk(KERN_DEBUG PFX
+ "%s: Configuring link.\n",
+ qdev->ndev->
+ name);
+ ql_mac_cfg_soft_reset(qdev, 1);
+ ql_mac_cfg_gig(qdev,
+ (ql_get_link_speed
+ (qdev) ==
+ SPEED_1000));
+ ql_mac_cfg_full_dup(qdev,
+ ql_is_link_full_dup
+ (qdev));
+ ql_mac_cfg_pause(qdev,
+ ql_is_neg_pause
+ (qdev));
+ ql_mac_cfg_soft_reset(qdev, 0);
+
+ /* enable the MAC */
+ if (netif_msg_link(qdev))
+ printk(KERN_DEBUG PFX
+ "%s: Enabling mac.\n",
+ qdev->ndev->
+ name);
+ ql_mac_enable(qdev, 1);
+ }
+
+ if (netif_msg_link(qdev))
+ printk(KERN_DEBUG PFX
+ "%s: Change port_link_state LS_DOWN to LS_UP.\n",
+ qdev->ndev->name);
+ qdev->port_link_state = LS_UP;
+ netif_start_queue(qdev->ndev);
+ netif_carrier_on(qdev->ndev);
+ if (netif_msg_link(qdev))
+ printk(KERN_INFO PFX
+ "%s: Link is up at %d Mbps, %s duplex.\n",
+ qdev->ndev->name,
+ ql_get_link_speed(qdev),
+ ql_is_link_full_dup(qdev)
+ ? "full" : "half");
+
+ } else { /* Remote error detected */
+
+ if (test_bit(QL_LINK_MASTER,&qdev->flags)) {
+ if (netif_msg_link(qdev))
+ printk(KERN_DEBUG PFX
+ "%s: Remote error detected. "
+ "Calling ql_port_start().\n",
+ qdev->ndev->
+ name);
+ ql_port_start(qdev); /* Restart port */
+ }
+ }
+}
+
static void ql_link_state_machine(struct ql3_adapter *qdev)
{
u32 curr_link_state;
@@ -1273,69 +1334,12 @@ static void ql_link_state_machine(struct
printk(KERN_DEBUG PFX
"%s: curr_link_state = LS_UP.\n",
qdev->ndev->name);
- if (ql_is_auto_neg_complete(qdev)) {
- if (!ql_auto_neg_error(qdev)) {
- if (test_bit(QL_LINK_MASTER,&qdev->flags)) {
- /* configure the MAC */
- if (netif_msg_link(qdev))
- printk(KERN_DEBUG PFX
- "%s: Configuring link.\n",
- qdev->ndev->
- name);
- ql_mac_cfg_soft_reset(qdev, 1);
- ql_mac_cfg_gig(qdev,
- (ql_get_link_speed
- (qdev) ==
- SPEED_1000));
- ql_mac_cfg_full_dup(qdev,
- ql_is_link_full_dup
- (qdev));
- ql_mac_cfg_pause(qdev,
- ql_is_neg_pause
- (qdev));
- ql_mac_cfg_soft_reset(qdev, 0);
-
- /* enable the MAC */
- if (netif_msg_link(qdev))
- printk(KERN_DEBUG PFX
- "%s: Enabling mac.\n",
- qdev->ndev->
- name);
- ql_mac_enable(qdev, 1);
- }
-
- if (netif_msg_link(qdev))
- printk(KERN_DEBUG PFX
- "%s: Change port_link_state LS_DOWN to LS_UP.\n",
- qdev->ndev->name);
- qdev->port_link_state = LS_UP;
- netif_start_queue(qdev->ndev);
- netif_carrier_on(qdev->ndev);
- if (netif_msg_link(qdev))
- printk(KERN_INFO PFX
- "%s: Link is up at %d Mbps, %s duplex.\n",
- qdev->ndev->name,
- ql_get_link_speed(qdev),
- ql_is_link_full_dup(qdev)
- ? "full" : "half");
-
- } else { /* Remote error detected */
-
- if (test_bit(QL_LINK_MASTER,&qdev->flags)) {
- if (netif_msg_link(qdev))
- printk(KERN_DEBUG PFX
- "%s: Remote error detected. "
- "Calling ql_port_start().\n",
- qdev->ndev->
- name);
- ql_port_start(qdev); /* Restart port */
- }
- }
- }
-
- if (qdev->port_link_state == LS_UP) {
+ if (ql_is_auto_neg_complete(qdev))
+ ql_finish_auto_neg(qdev);
+
+ if (qdev->port_link_state == LS_UP)
ql_link_down_detect_clear(qdev);
- }
+
}
break;
@@ -1689,11 +1693,7 @@ static void ql_process_mac_rx_intr(struc
skb->ip_summed = CHECKSUM_NONE;
skb->protocol = eth_type_trans(skb, qdev->ndev);
-#ifdef CONFIG_QLA3XXX_NAPI
netif_receive_skb(skb);
-#else
- netif_rx(skb);
-#endif
qdev->ndev->last_rx = jiffies;
lrg_buf_cb2->skb = NULL;
@@ -1768,11 +1768,7 @@ static void ql_process_macip_rx_intr(str
skb2->ip_summed = CHECKSUM_NONE;
skb2->protocol = eth_type_trans(skb2, qdev->ndev);
-#ifdef CONFIG_QLA3XXX_NAPI
netif_receive_skb(skb2);
-#else
- netif_rx(skb2);
-#endif
ndev->last_rx = jiffies;
lrg_buf_cb2->skb = NULL;
@@ -1780,109 +1776,6 @@ static void ql_process_macip_rx_intr(str
ql_release_to_lrg_buf_free_list(qdev, lrg_buf_cb2);
}
-#ifndef CONFIG_QLA3XXX_NAPI
-/*
- * Procedure: ql_intr_handler
- *
- */
-static int ql_intr_handler(unsigned long curr_adapter)
-{
- struct ql3_adapter *qdev = (struct ql3_adapter *)curr_adapter;
- struct ql3xxx_port_registers __iomem *port_regs = qdev->mem_map_registers;
- struct net_rsp_iocb *net_rsp;
- int max_ios_per_intr = 10;
- struct net_device *ndev = qdev->ndev;
-
- spin_lock(&qdev->adapter_lock);
-
- /* While there are entries in the completion queue. */
- while ((cpu_to_le32(*(qdev->prsp_producer_index)) !=
- qdev->rsp_consumer_index) && max_ios_per_intr) {
- max_ios_per_intr--;
- net_rsp = qdev->rsp_current;
- switch (net_rsp->opcode) {
-
- case OPCODE_OB_MAC_IOCB_FN0:
- case OPCODE_OB_MAC_IOCB_FN2:
- ql_process_mac_tx_intr(qdev,
- (struct ob_mac_iocb_rsp *) net_rsp);
- break;
-
- case OPCODE_IB_MAC_IOCB:
- ql_process_mac_rx_intr(qdev, (struct ib_mac_iocb_rsp *)
- net_rsp);
- break;
-
- case OPCODE_IB_IP_IOCB:
- ql_process_macip_rx_intr(qdev,
- (struct ib_ip_iocb_rsp *) net_rsp);
- break;
- default:
- {
- u32 *tmp = (u32 *) net_rsp;
- printk(KERN_ERR PFX
- "%s: Hit default case, "
- "not handled!\n"
- " dropping the packet, opcode = "
- "%x.\n",
- ndev->name, net_rsp->opcode);
- printk(KERN_ERR PFX
- "0x%08lx 0x%08lx 0x%08lx 0x%08lx \n",
- (unsigned long int)tmp[0],
- (unsigned long int)tmp[1],
- (unsigned long int)tmp[2],
- (unsigned long int)tmp[3]);
- }
- }
-
- qdev->rsp_consumer_index++;
-
- if (qdev->rsp_consumer_index == NUM_RSP_Q_ENTRIES) {
- qdev->rsp_consumer_index = 0;
- qdev->rsp_current = qdev->rsp_q_virt_addr;
- } else {
- qdev->rsp_current++;
- }
- }
-
- ql_update_lrg_bufq_prod_index(qdev);
-
- if (qdev->small_buf_release_cnt >= 16) {
- while (qdev->small_buf_release_cnt >= 16) {
- qdev->small_buf_q_producer_index++;
-
- if (qdev->small_buf_q_producer_index ==
- NUM_SBUFQ_ENTRIES)
- qdev->small_buf_q_producer_index = 0;
- qdev->small_buf_release_cnt -= 8;
- }
-
- ql_write_common_reg(qdev,
- (u32 *) & port_regs->CommonRegs.
- rxSmallQProducerIndex,
- qdev->small_buf_q_producer_index);
- }
-
- ql_write_common_reg(qdev,
- (u32 *) & port_regs->CommonRegs.rspQConsumerIndex,
- qdev->rsp_consumer_index);
-
- if (unlikely(netif_queue_stopped(qdev->ndev))) {
- spin_lock(&qdev->tx_cb_lock);
- if (netif_queue_stopped(qdev->ndev) &&
- (qdev->tx_free_count > (NUM_REQ_Q_ENTRIES / 4))) {
- printk(KERN_DEBUG PFX "%s: waking queue.\n",
- qdev->ndev->name);
- netif_wake_queue(qdev->ndev);
- }
- spin_unlock(&qdev->tx_cb_lock);
- }
-
- spin_unlock(&qdev->adapter_lock);
- return 10 - max_ios_per_intr;
-}
-
-#else /* !CONFIG_QLA3XXX_NAPI */
static int ql_tx_rx_clean(struct ql3_adapter *qdev,
int *tx_cleaned, int *rx_cleaned, int work_to_do)
{
@@ -2000,7 +1893,6 @@ quit_polling:
}
return 1;
}
-#endif /* CONFIG_QLA3XXX_NAPI */
static irqreturn_t ql3xxx_isr(int irq, void *dev_id, struct pt_regs *regs)
{
@@ -2048,15 +1940,11 @@ static irqreturn_t ql3xxx_isr(int irq, v
queue_work(qdev->workqueue, &qdev->reset_work);
spin_unlock(&qdev->adapter_lock);
} else if (value & ISP_IMR_DISABLE_CMPL_INT) {
-#ifdef CONFIG_QLA3XXX_NAPI
ql_disable_interrupts(qdev);
if (likely(netif_rx_schedule_prep(ndev)))
__netif_rx_schedule(ndev);
else
ql_enable_interrupts(qdev);
-#else
- handled = ql_intr_handler((unsigned long)qdev);
-#endif
} else {
return IRQ_NONE;
}
@@ -2072,9 +1960,6 @@ static int ql3xxx_send(struct sk_buff *s
struct ob_mac_iocb_req *mac_iocb_ptr;
u64 map;
- if (!spin_trylock(&qdev->tx_lock))
- return NETDEV_TX_LOCKED;
-
if (unlikely((tx_buf_ptr = ql_alloc_txbuf(qdev)) == NULL)) {
if (!netif_queue_stopped(ndev)) {
netif_stop_queue(ndev);
@@ -2083,7 +1968,6 @@ static int ql3xxx_send(struct sk_buff *s
"\r%s: No TX resources, stop queue.",
ndev->name);
}
- spin_unlock(&qdev->tx_lock);
return NETDEV_TX_BUSY;
}
@@ -2098,8 +1982,8 @@ static int ql3xxx_send(struct sk_buff *s
mac_iocb_ptr->buf_addr0_low = cpu_to_le32(LS_64BITS(map));
mac_iocb_ptr->buf_addr0_high = cpu_to_le32(MS_64BITS(map));
mac_iocb_ptr->buf_0_len = cpu_to_le32(skb->len | OB_MAC_IOCB_REQ_E);
- pci_unmap_addr_set(map_list, mapaddr, map);
- pci_unmap_len_set(map_list, maplen, skb->len);
+ pci_unmap_addr_set(tx_buf_ptr, mapaddr, map);
+ pci_unmap_len_set(tx_buf_ptr, maplen, skb->len);
/* Make sure all the descriptors written */
wmb();
@@ -2115,10 +1999,9 @@ static int ql3xxx_send(struct sk_buff *s
(u32 *) & port_regs->CommonRegs.reqQProducerIndex,
qdev->req_producer_index);
- spin_unlock(&qdev->tx_lock);
ndev->trans_start = jiffies;
if (netif_msg_tx_queued(qdev))
- printk(KERN_DEBUG PFX "%s: tx queued, slot %td, len %d\n",
+ printk(KERN_DEBUG PFX "%s: tx queued, slot %d, len %d\n",
ndev->name, qdev->req_producer_index, skb->len);
return NETDEV_TX_OK;
@@ -2848,7 +2731,7 @@ static int ql_adapter_reset(struct ql3_a
if ((value & ISP_CONTROL_SR) == 0)
break;
- msleep(1000);
+ ssleep(1);
} while ((--max_wait_time));
/*
@@ -2886,7 +2769,7 @@ static int ql_adapter_reset(struct ql3_a
if ((value & ISP_CONTROL_FSR) == 0) {
break;
}
- msleep(1000);
+ ssleep(1);
} while ((--max_wait_time));
}
if (max_wait_time == 0)
@@ -2951,25 +2834,25 @@ static void ql_display_dev_info(struct n
struct ql3_adapter *qdev = (struct ql3_adapter *)netdev_priv(ndev);
struct pci_dev *pdev = qdev->pdev;
- printk(KERN_ERR PFX
+ printk(KERN_INFO PFX
"\n%s Adapter %d RevisionID %d found on PCI slot %d.\n",
DRV_NAME, qdev->index, qdev->chip_rev_id, qdev->pci_slot);
- printk(KERN_ERR PFX
+ printk(KERN_INFO PFX
"%s Interface.\n",
test_bit(QL_LINK_OPTICAL,&qdev->flags) ? "OPTICAL" : "COPPER");
/*
* Print PCI bus width/type.
*/
- printk(KERN_ERR PFX
+ printk(KERN_INFO PFX
"Bus interface is %s %s.\n",
((qdev->pci_width == 64) ? "64-bit" : "32-bit"),
((qdev->pci_x) ? "PCI-X" : "PCI"));
- printk(KERN_ERR PFX
+ printk(KERN_INFO PFX
"mem IO base address adjusted = 0x%p\n",
qdev->mem_map_registers);
- printk(KERN_ERR PFX "Interrupt number = %d\n", pdev->irq);
+ printk(KERN_INFO PFX "Interrupt number = %d\n", pdev->irq);
if (netif_msg_probe(qdev))
printk(KERN_INFO PFX
@@ -3002,9 +2885,7 @@ static int ql_adapter_down(struct ql3_ad
del_timer_sync(&qdev->adapter_timer);
-#ifdef CONFIG_QLA3XXX_NAPI
netif_poll_disable(ndev);
-#endif
if (do_reset) {
int soft_reset;
@@ -3081,9 +2962,7 @@ static int ql_adapter_up(struct ql3_adap
mod_timer(&qdev->adapter_timer, jiffies + HZ * 1);
-#ifdef CONFIG_QLA3XXX_NAPI
netif_poll_enable(ndev);
-#endif
ql_enable_interrupts(qdev);
return 0;
@@ -3288,7 +3167,7 @@ static void ql_reset_work(struct ql3_ada
16) | ISP_CONTROL_RI));
}
- msleep(1000);
+ ssleep(1);
} while (--max_wait_time);
if (value & ISP_CONTROL_SR) {
@@ -3432,7 +3311,6 @@ static int __devinit ql3xxx_probe(struct
spin_lock_init(&qdev->adapter_lock);
spin_lock_init(&qdev->hw_lock);
- spin_lock_init(&qdev->tx_lock);
spin_lock_init(&qdev->tx_cb_lock);
/* Set driver entry points */
@@ -3447,10 +3325,8 @@ static int __devinit ql3xxx_probe(struct
ndev->tx_timeout = ql3xxx_tx_timeout;
ndev->watchdog_timeo = 5 * HZ;
-#ifdef CONFIG_QLA3XXX_NAPI
ndev->poll = &ql_poll;
ndev->weight = 64;
-#endif
qdev->irq = ndev->irq = pdev->irq;
@@ -3512,6 +3388,11 @@ static int __devinit ql3xxx_probe(struct
qdev->adapter_timer.expires = jiffies + HZ * 2; /* two second delay */
qdev->adapter_timer.data = (unsigned long)qdev;
+ if(!cards_found) {
+ printk(KERN_ALERT PFX "%s\n", DRV_STRING);
+ printk(KERN_ALERT PFX "Driver name: %s, Version: %s.\n",
+ DRV_NAME, DRV_VERSION);
+ }
ql_display_dev_info(ndev);
cards_found++;
@@ -3534,32 +3415,12 @@ static void __devexit ql3xxx_remove(stru
{
struct net_device *ndev = pci_get_drvdata(pdev);
struct ql3_adapter *qdev = netdev_priv(ndev);
- int index = 0;
-
- if (ndev == NULL) {
- printk(KERN_ERR PFX "%s: ndev == NULL, leaving.\n", qdev->ndev->name);
- return;
- }
unregister_netdev(ndev);
qdev = netdev_priv(ndev);
- if (qdev == NULL) {
- printk(KERN_ERR PFX "%s: qdev == NULL, leaving.\n",
- ndev->name);
- return;
- }
- /* Disable interrupts for this card. */
ql_disable_interrupts(qdev);
- /*
- * Wait for any resets to complete...
- */
- while (test_bit((QL_RESET_ACTIVE | QL_RESET_START | QL_RESET_PER_SCSI),
- &qdev->flags))
- msleep(1000);
-
- index = qdev->index;
if (qdev->workqueue) {
cancel_delayed_work(&qdev->reset_work);
cancel_delayed_work(&qdev->tx_timeout_work);
@@ -3583,9 +3444,6 @@ static struct pci_driver ql3xxx_driver =
static int __init ql3xxx_init_module(void)
{
- printk(KERN_ALERT PFX "%s\n", DRV_STRING);
- printk(KERN_ALERT PFX "Driver name: %s, Version: %s.\n",
- DRV_NAME, DRV_VERSION);
return pci_register_driver(&ql3xxx_driver);
}
diff --git a/drivers/net/qla3xxx.h b/drivers/net/qla3xxx.h
index 9e2629a..29e0275 100644
--- a/drivers/net/qla3xxx.h
+++ b/drivers/net/qla3xxx.h
@@ -749,7 +749,6 @@ struct ql3xxx_local_ram_registers {
/*
* I/O register
*/
-#define PCI_POSTING(a) (readl(a))
enum {
CONTROL_REG = 0,
@@ -965,7 +964,6 @@ struct eeprom_data {
* Below are a number compiler switches for controlling driver behavior.
* Some are not supported under certain conditions and are notated as such.
*/
-/* #define CONFIG_QLA3XXX_NAPI */
#define QL3XXX_VENDOR_ID 0x1077
#define QL3022_DEVICE_ID 0x3022
@@ -1138,7 +1136,6 @@ struct ql3_adapter {
u32 tx_count;
/* Transmit Buffers */
- spinlock_t tx_lock;
spinlock_t tx_cb_lock;
u32 tx_free_count;
struct ql_tx_buf_cb *tx_free_list;
^ permalink raw reply related
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Eric W. Biederman @ 2006-06-26 18:59 UTC (permalink / raw)
To: Andrey Savochkin
Cc: dlezcano, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, devel, sam, ebiederm, viro, Alexey Kuznetsov
In-Reply-To: <20060626182848.GA3368@MAIL.13thfloor.at>
Herbert Poetzl <herbert@13thfloor.at> writes:
> On Mon, Jun 26, 2006 at 06:08:03PM +0400, Andrey Savochkin wrote:
>
> not at all, maybe you should take a closer look at the
> current Linux-VServer implementation, which is quite
> simple and _does_ allow guests to bind to IP_ANY quite
> fine, only the host (which has all priviledes) has to
> be careful with binding to 0.0.0.0 ...
It works, and is a reasonable implementation. However the
semantics change.
The real practical problem is that you loose power, and
the ability to migrate applications. Not that this precludes
you from loading a security module and doing what you do now.
>> > > 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 :)
>
> isolation would not provide more than _one_ tun0
> interfaces, virtualization OTOH will ...
Think layer 2 isolation not layer 3 isolation.
>> So I'm all for network namespace management mechanisms not bound
>> to existing tools/APIs.
>
> well, I'm not against new APIs/tools, but I prefer
> to keep it simple, and elegant, which often includes
> reusing existing APIs and tools ...
And knowledge. Except for the single IP per guest case filtering
at BIND time starts show some surprising semantics.
> by having a strong 'policy' on the router/switch
> which will (hopefully) reject everything sent in error
> or to disrupt/harm other boxes ...
And linux has a software router and switch capabilities so
those can easily be used unmodified.
>> >From my point of view, network namespaces are just neighbors.
>
> yes, but you _need_ policy there the same way you need
> it for resources, i.e. you cannot simply allow everyone
> to do everything with his network interface, especially
> if that interface is _shared_ with all others ...
Agreed. And the network stack seems to have a perfectly good
set of utilities to handle that already.
>
> well, isolation is basically what we do in Linux-VServer
> by allowing to bind to certain IPs (or ranges) instead
> of binding _all_ available IPs ... this can be extended
> for routing and iptables as well, and does not require
> any 'virtualization' which would give each guest it's own
> set of interfaces, routes, iptables etc ... and it is
> usually more lightweight too ..
I disagree with the cost. Done properly we should have the cost
of the existing networking stack plus the cost of an extra pointer
dereference when we look at global variables.
This is layer 2 isolation. So we can use protocols like DHCP,
unmodified.
In the normally accepted definition it isn't virtualization because
we aren't emulating anything.
>> > > 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.
>
> well, I doubt that many providers will be able to put
> roughly hundred or more network interface cards into
> their machines, plus a proper switch to do the policy :)
Well switches exist. But yes because physical hardware
is limited this is a limited policy.
>> 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.
>
> which results in a duplicate stack traversal and kernel
> side policy to decide which goes where ... i.e. at least
> twice as much overhead than any isolation would have
Not twice because you don't traverse the entire network stack.
Just up to the routing layer and then across, and there are
optimization possibilities that should keep it down to a single
traversal of the network stack.
Note: We are not encouraging saying that the linux-vserver implementation
must die. Only that we are solving something with much larger scope.
If the first case does not at least pass packets as fast as the existing
network stack I doubt we will be allowed to merge it. By making the nic
drivers smarter we can have a single driver that creates multiple
network interfaces simply by looking at the destination mac address,
sort of like the bonding driver in reverse. That will trivially
remove the extra network stack traversals if we don't want
to apply before we let the packet out on the wire.
And there is not requirement that after the namespace is setup we
leave any applications on the inside with CAP_NET_ADMIN so we don't
need to worry about user space applications changing the network
configurations if we don't want to.
Eric
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: Thomas Graf @ 2006-06-26 18:44 UTC (permalink / raw)
To: David Miller; +Cc: kaber, netdev
In-Reply-To: <20060626.104654.98552111.davem@davemloft.net>
* David Miller <davem@davemloft.net> 2006-06-26 10:46
> From: Patrick McHardy <kaber@trash.net>
> Date: Mon, 26 Jun 2006 19:04:15 +0200
>
> > I know this was discussed before, but I can't remember the
> > exact outcome. Why don't we just unconditionally update iif
> > in netif_receive_skb()?
>
> Software devices might have interesting semantics that would
> make not setting iif desirable.
>
> Once you set iif, you can't just undo it because the information
> is lost.
>
> I also would really prefer to set it unconditionally in
> netif_receive_skb(), but Jamal's concerns in this area are real.
> We really need to evaluate this on a case-by-case basis.
I'm playing with a FIFO device based on Jamal's previous
work to replace the broken IMQ device and provide real
queueing at ingress. A set of VLAN devices could be redirected
to such a FIFO device and let applications bind to it in order
to implement trivial bind(INADDR_ANY) namespaces based on anything
that can be selected by classifiers. This example would benefit
from a conditional iif update (given that the mirred action is
extended to take a flag to steer this) so applications like a
dhcp daemon could use a raw socket on the FIFO device and thus
benefit from the bind namespace but still access the original
interface the packet was received from using pktinfo cmsg.
Maybe silly but the best I could come up with :-)
^ permalink raw reply
* Re: [PATCH] bcm43xx: enable shared key authentication
From: John W. Linville @ 2006-06-26 18:38 UTC (permalink / raw)
To: Daniel Drake; +Cc: netdev, mb
In-Reply-To: <20060616195022.E73CD8A3591@zog.reactivated.net>
On Fri, Jun 16, 2006 at 08:50:22PM +0100, Daniel Drake wrote:
> I recently patched softmac to enable shared key authentication. This small patch
> will enable crazy or unfortunate bcm43xx users to use this new capability.
>
> Signed-off-by: Daniel Drake <dsd@gentoo.org>
>
> Index: linux/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> ===================================================================
> --- linux.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> +++ linux/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> @@ -3599,6 +3599,10 @@ static void bcm43xx_ieee80211_set_securi
> secinfo->encrypt = sec->encrypt;
> dprintk(KERN_INFO PFX " .encrypt = %d\n", sec->encrypt);
> }
> + if (sec->flags & SEC_AUTH_MODE) {
> + secinfo->auth_mode = sec->auth_mode;
> + dprintk(KERN_INFO PFX " .auth_mode = %d\n", sec->auth_mode);
> + }
> if (bcm->initialized && !bcm->ieee->host_encrypt) {
> if (secinfo->enabled) {
> /* upload WEP keys to hardware */
I had problems applying this one. I recall having a similar problem w/
a patch in the last round of merging as well.
The version of bcm43xx_main.c in wireless-2.6 looks like this
(post patch):
secinfo->encrypt = sec->encrypt;
dprintk(", .encrypt = %d", sec->encrypt);
}
if (sec->flags & SEC_AUTH_MODE) {
secinfo->auth_mode = sec->auth_mode;
dprintk(", .auth_mode = %d\n", sec->auth_mode);
}
dprintk("\n");
if (bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED &&
!bcm->ieee->host_encrypt) {
Am I missing a patch?
Please make sure I get any patches that are missing from wireless-2.6
-- it is obviously better if we are all on the same page! :-)
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Herbert Poetzl @ 2006-06-26 18:36 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Daniel Lezcano, Andrey Savochkin, linux-kernel, netdev, serue,
haveblue, clg, Andrew Morton, dev, devel, sam, viro,
Alexey Kuznetsov
In-Reply-To: <m1hd27uaxw.fsf@ebiederm.dsl.xmission.com>
On Mon, Jun 26, 2006 at 10:40:59AM -0600, Eric W. Biederman wrote:
> Daniel Lezcano <dlezcano@fr.ibm.com> writes:
>
> >> 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.
>
> Is this an implementation difference or is this a user visible
> difference? As an implementation difference this is sensible, as it is
> pretty insane to allocate hash tables at run time.
>
> As a user visible difference that affects semantics of the operations
> this is not something we want to do.
well, I guess there are even more options here, for
example I'd like to propose the following idea, which
might be a viable solution for the policy/isolation
problem, with the actual overhead on the setup part
not the hot pathes for packet and connection handling
we could use the multiple routing tables to provide
a single routing table for each guest, which could
be used inside the guest to add arbitrary routes, but
would allow to keep the 'main' policy on the host, by
selecting the proper table based on IPs and guest tags
similar we could allow to have a separate iptables
chain for each guest (or several chains), which are
once again directed by the host system (applying the
required prolicy) which can be managed and configured
via normal iptable interfaces (both on the guest and
host) but actually provide at least to layers
note: this does not work for hierarchical network
contexts, but I do not see that the yet proposed
implementations would do, so I do not think that
is of concern here ...
best,
Herbert
> Eric
^ permalink raw reply
* RE: [3/5] [NET]: Add software TSOv4
From: Ravinandan Arakali @ 2006-06-26 18:33 UTC (permalink / raw)
To: 'YOSHIFUJI Hideaki / <g"!?p-?'; +Cc: davem, herbert, netdev
In-Reply-To: <20060624.103237.74578678.yoshfuji@linux-ipv6.org>
We are working on it.
Ravi
-----Original Message-----
From: YOSHIFUJI Hideaki / <g"!?p-? [mailto:yoshfuji@linux-ipv6.org]
Sent: Friday, June 23, 2006 6:33 PM
To: ravinandan.arakali@neterion.com
Cc: davem@davemloft.net; herbert@gondor.apana.org.au;
netdev@vger.kernel.org; yoshfuji@linux-ipv6.org
Subject: Re: [3/5] [NET]: Add software TSOv4
In article <004201c69725$14123700$4110100a@pc.s2io.com> (at Fri, 23 Jun 2006
17:28:12 -0700), "Ravinandan Arakali" <ravinandan.arakali@neterion.com>
says:
> Neterion's Xframe adapter supports TSO over IPv6.
I remember you posted some patches.
Would you post revised version reflecting Stephen's comment, please?
--yoshfuji
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Herbert Poetzl @ 2006-06-26 18:28 UTC (permalink / raw)
To: Andrey Savochkin
Cc: dlezcano, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, devel, sam, ebiederm, viro, Alexey Kuznetsov
In-Reply-To: <20060626180803.A31981@castle.nmd.msu.ru>
On Mon, Jun 26, 2006 at 06:08:03PM +0400, Andrey Savochkin wrote:
> 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.
not at all, maybe you should take a closer look at the
current Linux-VServer implementation, which is quite
simple and _does_ allow guests to bind to IP_ANY quite
fine, only the host (which has all priviledes) has to
be careful with binding to 0.0.0.0 ...
> 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?
well, roughly the same number of connections you'll
get when you have two boxes with the same IP on the
same subnet :)
in other words, if there are more than one guest
with the same ip and port open, then we have some
kind of misconfiguration (i.e. policy is required)
> > > 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 :)
isolation would not provide more than _one_ tun0
interfaces, virtualization OTOH will ...
> So I'm all for network namespace management mechanisms not bound
> to existing tools/APIs.
well, I'm not against new APIs/tools, but I prefer
to keep it simple, and elegant, which often includes
reusing existing APIs and tools ...
> > > 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?
by having a strong 'policy' on the router/switch
which will (hopefully) reject everything sent in error
or to disrupt/harm other boxes ...
> >From my point of view, network namespaces are just neighbors.
yes, but you _need_ policy there the same way you need
it for resources, i.e. you cannot simply allow everyone
to do everything with his network interface, especially
if that interface is _shared_ with all others ...
> > > 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.
well, isolation is basically what we do in Linux-VServer
by allowing to bind to certain IPs (or ranges) instead
of binding _all_ available IPs ... this can be extended
for routing and iptables as well, and does not require
any 'virtualization' which would give each guest it's own
set of interfaces, routes, iptables etc ... and it is
usually more lightweight too ..
> > > 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.
well, I doubt that many providers will be able to put
roughly hundred or more network interface cards into
their machines, plus a proper switch to do the policy :)
> 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.
which results in a duplicate stack traversal and kernel
side policy to decide which goes where ... i.e. at least
twice as much overhead than any isolation would have
best,
Herbert
> Regards
>
> Andrey
^ permalink raw reply
* Re: [PATCH REPOST 1/2] Network Event Notifier Mechanism.
From: Steve Wise @ 2006-06-26 18:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20060626.104311.111204162.davem@davemloft.net>
On Mon, 2006-06-26 at 10:43 -0700, David Miller wrote:
> From: Steve Wise <swise@opengridcomputing.com>
> Date: Mon, 26 Jun 2006 10:26:11 -0500
>
> > 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?
>
> You can avoid creating an event per address family by defining your
> data as:
>
> struct netevent_route_info {
> u16 family;
> void *data;
> };
>
> and passing that through the notifier.
>
> Then you just need NETEVENT_ROUTE_{ADD,DEL}
>
> Just an idea...
Seems reasonable.
Thanks,
Steve.
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: Patrick McHardy @ 2006-06-26 18:24 UTC (permalink / raw)
To: David Miller; +Cc: tgraf, netdev
In-Reply-To: <20060626.104654.98552111.davem@davemloft.net>
David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Mon, 26 Jun 2006 19:04:15 +0200
>
>
>>I know this was discussed before, but I can't remember the
>>exact outcome. Why don't we just unconditionally update iif
>>in netif_receive_skb()?
>
>
> Software devices might have interesting semantics that would
> make not setting iif desirable.
Right, I remember now.
> Once you set iif, you can't just undo it because the information
> is lost.
>
> I also would really prefer to set it unconditionally in
> netif_receive_skb(), but Jamal's concerns in this area are real.
> We really need to evaluate this on a case-by-case basis.
I still have a hard time imagining a case where this wouldn't fit,
netfilter is perfectly happy with just using skb->dev as input
device on the input path so far. I also think it will be confusing
to the user to have different notions of what constitutes the input
device. If anyone can think of an example where the user would
really expect the input device to be something different than
skb->dev I'd be really interested to hear it.
BTW, this is not meant to be an objection to Thomas's patch, just
me still wondering ..
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: David Miller @ 2006-06-26 17:46 UTC (permalink / raw)
To: kaber; +Cc: tgraf, netdev
In-Reply-To: <44A0138F.8050208@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Mon, 26 Jun 2006 19:04:15 +0200
> I know this was discussed before, but I can't remember the
> exact outcome. Why don't we just unconditionally update iif
> in netif_receive_skb()?
Software devices might have interesting semantics that would
make not setting iif desirable.
Once you set iif, you can't just undo it because the information
is lost.
I also would really prefer to set it unconditionally in
netif_receive_skb(), but Jamal's concerns in this area are real.
We really need to evaluate this on a case-by-case basis.
^ permalink raw reply
* Re: [PATCH REPOST 1/2] Network Event Notifier Mechanism.
From: David Miller @ 2006-06-26 17:43 UTC (permalink / raw)
To: swise; +Cc: netdev
In-Reply-To: <1151335571.2398.37.camel@stevo-desktop>
From: Steve Wise <swise@opengridcomputing.com>
Date: Mon, 26 Jun 2006 10:26:11 -0500
> 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?
You can avoid creating an event per address family by defining your
data as:
struct netevent_route_info {
u16 family;
void *data;
};
and passing that through the notifier.
Then you just need NETEVENT_ROUTE_{ADD,DEL}
Just an idea...
^ permalink raw reply
* Re: [patch 4/4] Network namespaces: playing and debugging
From: Daniel Lezcano @ 2006-06-26 17:29 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: <20060626194339.D989@castle.nmd.msu.ru>
>>>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
>>>
Andrey,
I began to play with your patchset. I am able to connect to 127.0.0.1
from different namespaces. Is it the expected behavior ?
Furthermore, I am not able to have several programs, running in
different namespaces, to bind to the same INADDR_ANY:port.
Will these features be included in the second patchset ?
>>
>>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.
Cool :)
^ permalink raw reply
* [patch 1/1] netlink: encapsulate eff_cap usage within security framework
From: Stephen Smalley @ 2006-06-26 17:19 UTC (permalink / raw)
To: netdev; +Cc: Darrel Goeddel, Chris Wright, James Morris, David S. Miller
From: Darrel Goeddel <dgoeddel@trustedcs.com>
This patch encapsulates the usage of eff_cap (in netlink_skb_params) within
the security framework by extending security_netlink_recv to include a required
capability parameter and converting all direct usage of eff_caps outside
of the lsm modules to use the interface. It also updates the SELinux
implementation of the security_netlink_send and security_netlink_recv
hooks to take advantage of the sid in the netlink_skb_params struct.
This also enables SELinux to perform auditing of netlink capability checks.
Please apply, for 2.6.18 if possible.
Signed-off-by: Darrel Goeddel <dgoeddel@trustedcs.com>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Acked-by: James Morris <jmorris@namei.org>
---
include/linux/security.h | 13 +++++++------
kernel/audit.c | 8 ++++----
net/core/rtnetlink.c | 2 +-
net/decnet/netfilter/dn_rtmsg.c | 2 +-
net/ipv4/netfilter/ip_queue.c | 2 +-
net/ipv6/netfilter/ip6_queue.c | 2 +-
net/netfilter/nfnetlink.c | 2 +-
net/netlink/genetlink.c | 2 +-
net/xfrm/xfrm_user.c | 2 +-
security/commoncap.c | 4 ++--
security/dummy.c | 4 ++--
security/selinux/hooks.c | 26 +++++++++++++-------------
12 files changed, 35 insertions(+), 34 deletions(-)
diff -X /home/sds/dontdiff -rup linux-2.6.17-git10/include/linux/security.h linux-2.6.17-git10-ss2/include/linux/security.h
--- linux-2.6.17-git10/include/linux/security.h 2006-06-26 09:34:30.000000000 -0400
+++ linux-2.6.17-git10-ss2/include/linux/security.h 2006-06-26 09:50:59.000000000 -0400
@@ -67,7 +67,7 @@ struct xfrm_state;
struct xfrm_user_sec_ctx;
extern int cap_netlink_send(struct sock *sk, struct sk_buff *skb);
-extern int cap_netlink_recv(struct sk_buff *skb);
+extern int cap_netlink_recv(struct sk_buff *skb, int cap);
/*
* Values used in the task_security_ops calls
@@ -656,6 +656,7 @@ struct swap_info_struct;
* Check permission before processing the received netlink message in
* @skb.
* @skb contains the sk_buff structure for the netlink message.
+ * @cap indicates the capability required
* Return 0 if permission is granted.
*
* Security hooks for Unix domain networking.
@@ -1265,7 +1266,7 @@ struct security_operations {
struct sembuf * sops, unsigned nsops, int alter);
int (*netlink_send) (struct sock * sk, struct sk_buff * skb);
- int (*netlink_recv) (struct sk_buff * skb);
+ int (*netlink_recv) (struct sk_buff * skb, int cap);
/* allow module stacking */
int (*register_security) (const char *name,
@@ -2031,9 +2032,9 @@ static inline int security_netlink_send(
return security_ops->netlink_send(sk, skb);
}
-static inline int security_netlink_recv(struct sk_buff * skb)
+static inline int security_netlink_recv(struct sk_buff * skb, int cap)
{
- return security_ops->netlink_recv(skb);
+ return security_ops->netlink_recv(skb, cap);
}
/* prototypes */
@@ -2669,9 +2670,9 @@ static inline int security_netlink_send
return cap_netlink_send (sk, skb);
}
-static inline int security_netlink_recv (struct sk_buff *skb)
+static inline int security_netlink_recv (struct sk_buff *skb, int cap)
{
- return cap_netlink_recv (skb);
+ return cap_netlink_recv (skb, cap);
}
static inline struct dentry *securityfs_create_dir(const char *name,
diff -X /home/sds/dontdiff -rup linux-2.6.17-git10/kernel/audit.c linux-2.6.17-git10-ss2/kernel/audit.c
--- linux-2.6.17-git10/kernel/audit.c 2006-06-26 09:34:30.000000000 -0400
+++ linux-2.6.17-git10-ss2/kernel/audit.c 2006-06-26 09:50:59.000000000 -0400
@@ -445,7 +445,7 @@ void audit_send_reply(int pid, int seq,
* Check for appropriate CAP_AUDIT_ capabilities on incoming audit
* control messages.
*/
-static int audit_netlink_ok(kernel_cap_t eff_cap, u16 msg_type)
+static int audit_netlink_ok(struct sk_buff *skb, u16 msg_type)
{
int err = 0;
@@ -459,13 +459,13 @@ static int audit_netlink_ok(kernel_cap_t
case AUDIT_DEL:
case AUDIT_DEL_RULE:
case AUDIT_SIGNAL_INFO:
- if (!cap_raised(eff_cap, CAP_AUDIT_CONTROL))
+ if (security_netlink_recv(skb, CAP_AUDIT_CONTROL))
err = -EPERM;
break;
case AUDIT_USER:
case AUDIT_FIRST_USER_MSG...AUDIT_LAST_USER_MSG:
case AUDIT_FIRST_USER_MSG2...AUDIT_LAST_USER_MSG2:
- if (!cap_raised(eff_cap, CAP_AUDIT_WRITE))
+ if (security_netlink_recv(skb, CAP_AUDIT_WRITE))
err = -EPERM;
break;
default: /* bad msg */
@@ -488,7 +488,7 @@ static int audit_receive_msg(struct sk_b
char *ctx;
u32 len;
- err = audit_netlink_ok(NETLINK_CB(skb).eff_cap, msg_type);
+ err = audit_netlink_ok(skb, msg_type);
if (err)
return err;
diff -X /home/sds/dontdiff -rup linux-2.6.17-git10/net/core/rtnetlink.c linux-2.6.17-git10-ss2/net/core/rtnetlink.c
--- linux-2.6.17-git10/net/core/rtnetlink.c 2006-06-26 09:34:30.000000000 -0400
+++ linux-2.6.17-git10-ss2/net/core/rtnetlink.c 2006-06-26 09:50:59.000000000 -0400
@@ -663,7 +663,7 @@ rtnetlink_rcv_msg(struct sk_buff *skb, s
sz_idx = type>>2;
kind = type&3;
- if (kind != 2 && security_netlink_recv(skb)) {
+ if (kind != 2 && security_netlink_recv(skb, CAP_NET_ADMIN)) {
*errp = -EPERM;
return -1;
}
diff -X /home/sds/dontdiff -rup linux-2.6.17-git10/net/decnet/netfilter/dn_rtmsg.c linux-2.6.17-git10-ss2/net/decnet/netfilter/dn_rtmsg.c
--- linux-2.6.17-git10/net/decnet/netfilter/dn_rtmsg.c 2006-06-26 09:34:30.000000000 -0400
+++ linux-2.6.17-git10-ss2/net/decnet/netfilter/dn_rtmsg.c 2006-06-26 09:50:59.000000000 -0400
@@ -107,7 +107,7 @@ static inline void dnrmg_receive_user_sk
if (nlh->nlmsg_len < sizeof(*nlh) || skb->len < nlh->nlmsg_len)
return;
- if (!cap_raised(NETLINK_CB(skb).eff_cap, CAP_NET_ADMIN))
+ if (security_netlink_recv(skb, CAP_NET_ADMIN))
RCV_SKB_FAIL(-EPERM);
/* Eventually we might send routing messages too */
diff -X /home/sds/dontdiff -rup linux-2.6.17-git10/net/ipv4/netfilter/ip_queue.c linux-2.6.17-git10-ss2/net/ipv4/netfilter/ip_queue.c
--- linux-2.6.17-git10/net/ipv4/netfilter/ip_queue.c 2006-06-26 09:34:30.000000000 -0400
+++ linux-2.6.17-git10-ss2/net/ipv4/netfilter/ip_queue.c 2006-06-26 09:50:59.000000000 -0400
@@ -507,7 +507,7 @@ ipq_rcv_skb(struct sk_buff *skb)
if (type <= IPQM_BASE)
return;
- if (security_netlink_recv(skb))
+ if (security_netlink_recv(skb, CAP_NET_ADMIN))
RCV_SKB_FAIL(-EPERM);
write_lock_bh(&queue_lock);
diff -X /home/sds/dontdiff -rup linux-2.6.17-git10/net/ipv6/netfilter/ip6_queue.c linux-2.6.17-git10-ss2/net/ipv6/netfilter/ip6_queue.c
--- linux-2.6.17-git10/net/ipv6/netfilter/ip6_queue.c 2006-06-26 09:34:30.000000000 -0400
+++ linux-2.6.17-git10-ss2/net/ipv6/netfilter/ip6_queue.c 2006-06-26 09:50:59.000000000 -0400
@@ -505,7 +505,7 @@ ipq_rcv_skb(struct sk_buff *skb)
if (type <= IPQM_BASE)
return;
- if (security_netlink_recv(skb))
+ if (security_netlink_recv(skb, CAP_NET_ADMIN))
RCV_SKB_FAIL(-EPERM);
write_lock_bh(&queue_lock);
diff -X /home/sds/dontdiff -rup linux-2.6.17-git10/net/netfilter/nfnetlink.c linux-2.6.17-git10-ss2/net/netfilter/nfnetlink.c
--- linux-2.6.17-git10/net/netfilter/nfnetlink.c 2006-06-26 09:34:30.000000000 -0400
+++ linux-2.6.17-git10-ss2/net/netfilter/nfnetlink.c 2006-06-26 09:50:59.000000000 -0400
@@ -229,7 +229,7 @@ static int nfnetlink_rcv_msg(struct sk_b
NFNL_SUBSYS_ID(nlh->nlmsg_type),
NFNL_MSG_TYPE(nlh->nlmsg_type));
- if (!cap_raised(NETLINK_CB(skb).eff_cap, CAP_NET_ADMIN)) {
+ if (security_netlink_recv(skb, CAP_NET_ADMIN)) {
DEBUGP("missing CAP_NET_ADMIN\n");
*errp = -EPERM;
return -1;
diff -X /home/sds/dontdiff -rup linux-2.6.17-git10/net/netlink/genetlink.c linux-2.6.17-git10-ss2/net/netlink/genetlink.c
--- linux-2.6.17-git10/net/netlink/genetlink.c 2006-06-26 09:34:30.000000000 -0400
+++ linux-2.6.17-git10-ss2/net/netlink/genetlink.c 2006-06-26 09:50:59.000000000 -0400
@@ -320,7 +320,7 @@ static int genl_rcv_msg(struct sk_buff *
goto errout;
}
- if ((ops->flags & GENL_ADMIN_PERM) && security_netlink_recv(skb)) {
+ if ((ops->flags & GENL_ADMIN_PERM) && security_netlink_recv(skb, CAP_NET_ADMIN)) {
err = -EPERM;
goto errout;
}
diff -X /home/sds/dontdiff -rup linux-2.6.17-git10/net/xfrm/xfrm_user.c linux-2.6.17-git10-ss2/net/xfrm/xfrm_user.c
--- linux-2.6.17-git10/net/xfrm/xfrm_user.c 2006-06-26 09:34:30.000000000 -0400
+++ linux-2.6.17-git10-ss2/net/xfrm/xfrm_user.c 2006-06-26 09:50:59.000000000 -0400
@@ -1435,7 +1435,7 @@ static int xfrm_user_rcv_msg(struct sk_b
link = &xfrm_dispatch[type];
/* All operations require privileges, even GET */
- if (security_netlink_recv(skb)) {
+ if (security_netlink_recv(skb, CAP_NET_ADMIN)) {
*errp = -EPERM;
return -1;
}
diff -X /home/sds/dontdiff -rup linux-2.6.17-git10/security/commoncap.c linux-2.6.17-git10-ss2/security/commoncap.c
--- linux-2.6.17-git10/security/commoncap.c 2006-06-26 09:34:30.000000000 -0400
+++ linux-2.6.17-git10-ss2/security/commoncap.c 2006-06-26 09:50:59.000000000 -0400
@@ -33,9 +33,9 @@ int cap_netlink_send(struct sock *sk, st
EXPORT_SYMBOL(cap_netlink_send);
-int cap_netlink_recv(struct sk_buff *skb)
+int cap_netlink_recv(struct sk_buff *skb, int cap)
{
- if (!cap_raised(NETLINK_CB(skb).eff_cap, CAP_NET_ADMIN))
+ if (!cap_raised(NETLINK_CB(skb).eff_cap, cap))
return -EPERM;
return 0;
}
diff -X /home/sds/dontdiff -rup linux-2.6.17-git10/security/dummy.c linux-2.6.17-git10-ss2/security/dummy.c
--- linux-2.6.17-git10/security/dummy.c 2006-06-26 09:34:30.000000000 -0400
+++ linux-2.6.17-git10-ss2/security/dummy.c 2006-06-26 09:50:59.000000000 -0400
@@ -675,9 +675,9 @@ static int dummy_netlink_send (struct so
return 0;
}
-static int dummy_netlink_recv (struct sk_buff *skb)
+static int dummy_netlink_recv (struct sk_buff *skb, int cap)
{
- if (!cap_raised (NETLINK_CB (skb).eff_cap, CAP_NET_ADMIN))
+ if (!cap_raised (NETLINK_CB (skb).eff_cap, cap))
return -EPERM;
return 0;
}
diff -X /home/sds/dontdiff -rup linux-2.6.17-git10/security/selinux/hooks.c linux-2.6.17-git10-ss2/security/selinux/hooks.c
--- linux-2.6.17-git10/security/selinux/hooks.c 2006-06-26 10:34:54.000000000 -0400
+++ linux-2.6.17-git10-ss2/security/selinux/hooks.c 2006-06-26 09:50:59.000000000 -0400
@@ -3622,32 +3622,32 @@ static unsigned int selinux_ipv6_postrou
static int selinux_netlink_send(struct sock *sk, struct sk_buff *skb)
{
- struct task_security_struct *tsec;
- struct av_decision avd;
int err;
err = secondary_ops->netlink_send(sk, skb);
if (err)
return err;
- tsec = current->security;
-
- avd.allowed = 0;
- avc_has_perm_noaudit(tsec->sid, tsec->sid,
- SECCLASS_CAPABILITY, ~0, &avd);
- cap_mask(NETLINK_CB(skb).eff_cap, avd.allowed);
-
if (policydb_loaded_version >= POLICYDB_VERSION_NLCLASS)
err = selinux_nlmsg_perm(sk, skb);
return err;
}
-static int selinux_netlink_recv(struct sk_buff *skb)
+static int selinux_netlink_recv(struct sk_buff *skb, int capability)
{
- if (!cap_raised(NETLINK_CB(skb).eff_cap, CAP_NET_ADMIN))
- return -EPERM;
- return 0;
+ int err;
+ struct avc_audit_data ad;
+
+ err = secondary_ops->netlink_recv(skb, capability);
+ if (err)
+ return err;
+
+ AVC_AUDIT_DATA_INIT(&ad, CAP);
+ ad.u.cap = capability;
+
+ return avc_has_perm(NETLINK_CB(skb).sid, NETLINK_CB(skb).sid,
+ SECCLASS_CAPABILITY, CAP_TO_MASK(capability), &ad);
}
static int ipc_alloc_security(struct task_struct *task,
--
Stephen Smalley
National Security Agency
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: Patrick McHardy @ 2006-06-26 17:04 UTC (permalink / raw)
To: Thomas Graf; +Cc: davem, netdev
In-Reply-To: <20060626145515.769648000@postel.suug.ch>
Thomas Graf wrote:
> 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;
I know this was discussed before, but I can't remember the
exact outcome. Why don't we just unconditionally update iif
in netif_receive_skb()?
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Eric W. Biederman @ 2006-06-26 16:40 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Andrey Savochkin, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, herbert, devel, sam, ebiederm, viro,
Alexey Kuznetsov
In-Reply-To: <44A00215.2040608@fr.ibm.com>
Daniel Lezcano <dlezcano@fr.ibm.com> writes:
>> 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.
Is this an implementation difference or is this a user visible difference?
As an implementation difference this is sensible, as it is pretty insane
to allocate hash tables at run time.
As a user visible difference that affects semantics of the operations
this is not something we want to do.
Eric
^ permalink raw reply
* Re: [PATCH] s2io: netpoll support
From: Brian Haley @ 2006-06-26 16:33 UTC (permalink / raw)
To: ravinandan.arakali
Cc: netdev, jgarzik, 'Ananda. Raju (E-mail)',
'Leonid. Grossman (E-mail)'
In-Reply-To: <001801c69634$6d3b33a0$4110100a@pc.s2io.com>
Ravinandan Arakali wrote:
> Since the poll_controller entry point will be used by utilities such as
> netdump, I am thinking we need to clear Tx interrupts as well here.
> Did you get a chance to test this patch with netdump ?
No, I've only been testing Kgdb over Ethernet on Debian, I think netdump
is a Red Hat thing. I can test any changes you'd want to make with this
patch if you post the diffs.
-Brian
> -----Original Message-----
> From: Brian Haley [mailto:brian.haley@hp.com]
> Sent: Thursday, June 15, 2006 11:37 AM
> To: netdev@vger.kernel.org
> Cc: ravinandan.arakali@neterion.com; jgarzik@pobox.com; Ananda. Raju
> (E-mail); Leonid. Grossman (E-mail)
> Subject: Re: [PATCH] s2io: netpoll support
>
>
> This adds netpoll support for things like netconsole/kgdboe to the s2io
> 10GbE driver.
>
> Signed-off-by: Brian Haley <brian.haley@hp.com>
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch 2/3] drivers/net/ns83820.c: add paramter to disable autonegotiation
From: Benjamin LaHaise @ 2006-06-26 16:29 UTC (permalink / raw)
To: akpm; +Cc: jeff, netdev, dan, dan, jgarzik
In-Reply-To: <200606250844.k5P8iasE020794@shell0.pdx.osdl.net>
On Sun, Jun 25, 2006 at 01:44:36AM -0700, akpm@osdl.org wrote:
>
> From: Dan Faerch <dan@scannet.dk>
>
> Adds "ethtool command" support to driver. Initially 2 commands are
> implemented: force fullduplex and toggle autoneg.
This part is good, although doing something for copper cards needs doing,
which probably means poking around to support the phy properly.
> Also added a "disable_autoneg" module argument to completely disable
> autoneg on all cards using this driver.
This is the part I disagree with. Are you sure it isn't a bug in the
link autonegotiation state machine for fibre cards? It should be defaulting
to 1Gbit/full duplex if no autonegotiation is happening, and if it isn't
then that should be fixed instead of papering over things with a config
option.
-ben
--
"Time is of no importance, Mr. President, only life is important."
Don't Email: <dont@kvack.org>.
^ permalink raw reply
* Re: [patch 1/4] Network namespaces: cleanup of dev_base list use
From: Eric W. Biederman @ 2006-06-26 16:26 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: <20060626194205.C989@castle.nmd.msu.ru>
Andrey Savochkin <saw@swsoft.com> writes:
> 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...
I agree. I'm just saying this should be several patches in a patchset
not just one big one.
>> 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?
The basic idea is that an interrupt comes in. A light weigh classifier
looks at the packet and throws it into the appropriate socket packet queue.
Beyond that everything can happen in the socket packet queue in process
context which reduces the number of locks you need, and increases cache
locality.
Van Jacobson's slides showed some impressive system load reductions by
doing that.
The increased locality aids the kind of work we are doing as well,
by meaning we don't have to guess.
It is a big enough problem that I don't think we want to gate on
that development but we need to be ready to take advantage of it when
it happens.
>> 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.
I don't follow this comment. How does a lot of layers affect
the choice of implicit or explicit parameters? If you are maintaining
a patch outside the kernel I could see how there could be a win for
touching the least amount of code possible but for merged code that
you only have to go through once I don't see how the number of layers
affects things.
As I recall for most of the FIB/routing code once you have removed
the global variable accesses and introduce namespace checks in
the hash table (because allocating hash tables at runtime isn't sane)
the rest of the code was agnostic about what was going on. So I think
you have touched everything that needs touching. So I don't see
a code size or complexity argument there.
I do agree that we do have a lot of code there.
>> 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.
I completely agree that cleaning up the list is a good thing to do,
regardless of how we implement things. So that can easily be a pre cursor
to the work. My only practical question is if we can remove the list
walks be calling some of the generic helper functions.
I would say just separate out the list walk cleanup code and submit it.
The important point is that the patch needs to stand on it's as a
cleanup rather than depending on network namespaces as a justification.
Eric
^ permalink raw reply
* Re: [PATCH 2/6] ehea: pHYP interface
From: Heiko J Schick @ 2006-06-26 16:17 UTC (permalink / raw)
To: Roland Dreier; +Cc: Jan-Bernd Themann, netdev, meder, raisch, schickhj, themann
In-Reply-To: <ada4pyemsgq.fsf@cisco.com>
Roland Dreier wrote:
> I think this code needs to be refactored so that it can share with the
> ehca InfiniBand driver (which should be merged upstream soon). For
> example, you have ehea_hcall_7arg_7ret() and the ehca driver has an
> identical ehca_hcall_7arg_7ret().
In genreral this is a good approach, but we think it will be a lengthy
process until the same code base is accepted from both - Network community
(keep it as simple as possible) vs. IB community (support full IB
functionallity). Another thing which makes it quite challenging is that
hypervisor calls have subtle little differences between eHCA and eHEA.
> Also:
>
> > +++ kernel/drivers/net/ehea/ehea_hcall.h 2006-06-21 04:44:50.158485520 -0700
>
> > +/**
> > + * This file contains HCALL defines that are to be included in the appropriate
> > + * kernel files later
> > + */
>
> this stuff should go in <asm-powerpc/hvcall.h> with the other
> constants, right?
Yes, that would be the next step.
Regards,
Heiko
^ 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