Re: [RFC PATCH 8/8] [PKTGEN]: uninline getCurUs
On Sun, 13 Jan 2008, David Miller wrote: > From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> > Date: Mon, 14 Jan 2008 09:43:08 +0200 (EET) > > > I'd prefer sending them as iso-8859-1 compliant (and I guess you are able > > to test your fix-to-utf-8 machinery with it as well :-)), as it would also > > make my mails compatible with other people's git apply tools you're not > > using (otherwise I'd probably forget to change it occassionally when > > interacting with others than you). > > For now either way is fine with me. If the situation changes I'll > let you know. Ok, I'll remain in iso-8859-1, it's something that is known to work from my end. Thanks anyway for fixing it, wasn't any big deal for me at any point of time but people started asking me privately to correct it which I of course couldn't... :-) > I'm surprised git-send-email can't get it purely utf8 correctly. The problem is that my system is ISO natively, so git-send-email might encode a ISO native .patch file's content while sending, which in this case was intentionally already utf-8. It might surprise you but it wasn't a long time ago when git-send-email wouldn't care less e.g. about header encoding and I got rejects from netdev due to my name which wasn't encoded properly, I've 1.5.0.6 currently and it seemed still fail to encode Cc addresses it adds from signed-offs unless I explicitly ask for it to not do that (I explicitly ask for especific, encoded, from header anyway because it was broken at some point of time and my sending template is copy-paste originating from that time). There was some recent fixes in the git's logs regarding that encoding, so I intend to check if a later g-s-e is more able and if it isn't I'll report it to git folks. > I wonder if there is some issue with how it gets your name > string for the commit author etc. I've had it working well since the encoding header got relatively recently added (wasn't available at early dawn of git era), before that it was just a mess locally. Funny enough, you were able to magically mangle my emails to utf-8'ed commits nicely back then so I got a "fixed" commit back after an RTT :-). > I wonder if getting it into your global GIT config file in proper > UTF8 encoding would fix things. > > Put something like this into ~/.gitconfig > > > [user] > name = Ilpo Järvinen > email = [EMAIL PROTECTED] > I have this. In addition I have this (required to make my local system consistent): [i18n] commitencoding = ISO-8859-1 The problem was just that the API (or better, ABI) between us wasn't properly working :-)). While Herbert was working as the replacement-Dave in November, correct commit entries were created, so git has been working fine (I guess he used git applying tools instead of handmade scripts and they handle email correclt based on it's encoding). I tried logOutputEncoding = utf-8 in the last patch sets I sent (now could again remove it) but git-send-email problem appeared with it because the system is ISO natively. > The GIT maintainer is Finnish which makes this situation even > more perplexing to me, you might want to discuss it with him :-) Junio? Never heard that a Finnish name... ;-) Perhaps git-send-email wasn't written by that Finnish guy... :-) ...Besides, that Finnish git aintainer doesn't have any funny characters in his name... ;-) Thanks anyway for the tips & all, I think we have it now working and I can return to inlines and rexmit_skb_hint things & other TCP stuff rather than this hinderance. I've some interesting results from net header inlines checks I ran overnight :-). -- i.
Re: Netperf TCP_RR(loopback) 10% regression in 2.6.24-rc6, comparing with 2.6.22
On Fri, 11 Jan 2008, Zhang, Yanmin wrote: > On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote: > > The regression is: > > 1)stoakley with 2 qual-core processors: 11%; > > 2)Tulsa with 4 dual-core(+hyperThread) processors:13%; > I have new update on this issue and also cc to netdev maillist. > Thank David Miller for pointing me the netdev maillist. > > > > > The test command is: > > #sudo taskset -c 7 ./netserver > > #sudo taskset -c 0 ./netperf -t TCP_RR -l 60 -H 127.0.0.1 -i 50,3 -I 99,5 > > -- -r 1,1 > > > > As a matter of fact, 2.6.23 has about 6% regression and 2.6.24-rc's > > regression is between 16%~11%. > > > > I tried to use bisect to locate the bad patch between 2.6.22 and 2.6.23-rc1, > > but the bisected kernel wasn't stable and went crazy. TCP work between that is very much non-existing. Using git-reset's to select a nearby merge point instead of default commit where bisection lands might be help in case the bisected kernel breaks. Also, limiting bisection under a subsystem might reduce probability of brokeness (might at least be able to narrow it down quite a lot), e.g. git bisect start net/ -- i. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ipw3945-devel] [PATCH 2/5] iwlwifi: iwl3945 synchronize interruptand tasklet for down iwlwifi
Joonwoo Park wrote:
2008/1/11, Chatre, Reinette <[EMAIL PROTECTED]>:
On Thursday, January 10, 2008 5:25 PM, Joonwoo Park wrote:
What modification are you considering?
Roughly, I'm considering make synchronize_irq() be moved into
iwl_disable_interrupts() and fix iwl_irq_tasket not to call
iwl_disable_interrupts with irq disabled.
For now iwl_irq_tasklet calls iwl_disable_interrupts() with local irq disabled.
like this:
static void iwl_irq_tasklet(struct iwl_priv *priv)
{
...
spin_lock_irqsave(&priv->lock, flags);
...
/* Now service all interrupt bits discovered above. */
if (inta & CSR_INT_BIT_HW_ERR) {
IWL_ERROR("Microcode HW error detected. Restarting.\n");
/* Tell the device to stop sending interrupts */
iwl_disable_interrupts(priv);
...
spin_unlock_irqrestore(&priv->lock, flags);
return;
}
After disabling interrupts, it's possible irq & tasklet is pending or running
This patch eleminates races for down iwlwifi
Since synchronize_irq can introduce iwl_irq_tasklet, tasklet_kill
should be called after doing synchronize_irq
To avoid races between iwl_synchronize_irq and iwl_irq_tasklet
STATUS_INT_ENABLED
flag is needed.
Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]>
---
drivers/net/wireless/iwlwifi/iwl3945-base.c | 33 ++-
1 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c
b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 6e20725..f98cd4f 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -4405,6 +4405,14 @@ static void iwl_print_rx_config_cmd(struct iwl_rxon_cmd
*rxon)
}
#endif
+static void iwl_synchronize_interrupts(struct iwl_priv *priv)
+{
+ synchronize_irq(priv->pci_dev->irq);
+ /* synchornize_irq introduces irq_tasklet,
+* tasklet_kill should be called after doing synchronize_irq */
+ tasklet_kill(&priv->irq_tasklet);
+}
+
static void iwl_enable_interrupts(struct iwl_priv *priv)
{
IWL_DEBUG_ISR("Enabling interrupts\n");
@@ -4413,7 +4421,7 @@ static void iwl_enable_interrupts(struct iwl_priv *priv)
iwl_flush32(priv, CSR_INT_MASK);
}
-static inline void iwl_disable_interrupts(struct iwl_priv *priv)
+static inline void __iwl_disable_interrupts(struct iwl_priv *priv)
{
clear_bit(STATUS_INT_ENABLED, &priv->status);
@@ -4427,6 +4435,13 @@ static inline void iwl_disable_interrupts(struct
iwl_priv *priv)
iwl_flush32(priv, CSR_INT);
iwl_write32(priv, CSR_FH_INT_STATUS, 0x);
iwl_flush32(priv, CSR_FH_INT_STATUS);
+}
+
+static inline void iwl_disable_interrupts(struct iwl_priv *priv)
+{
+ __iwl_disable_interrupts(priv);
+
+ iwl_synchronize_interrupts(priv);
IWL_DEBUG_ISR("Disabled interrupts\n");
}
@@ -4708,7 +4723,8 @@ static void iwl_irq_tasklet(struct iwl_priv *priv)
IWL_ERROR("Microcode HW error detected. Restarting.\n");
/* Tell the device to stop sending interrupts */
- iwl_disable_interrupts(priv);
+ __iwl_disable_interrupts(priv);
+ IWL_DEBUG_ISR("Disabled interrupts\n");
iwl_irq_handle_error(priv);
@@ -4814,8 +4830,11 @@ static void iwl_irq_tasklet(struct iwl_priv *priv)
IWL_WARNING(" with FH_INT = 0x%08x\n", inta_fh);
}
- /* Re-enable all interrupts */
- iwl_enable_interrupts(priv);
+ /* To avoid race when device goes down,
+* it should be discarded to enable interrupts */
+ if (test_bit(STATUS_INT_ENABLED, &priv->status))
+ /* Re-enable all interrupts */
+ iwl_enable_interrupts(priv);
#ifdef CONFIG_IWLWIFI_DEBUG
if (iwl_debug_level & (IWL_DL_ISR)) {
@@ -4876,8 +4895,10 @@ unplugged:
return IRQ_HANDLED;
none:
- /* re-enable interrupts here since we don't have anything to service. */
- iwl_enable_interrupts(priv);
+ if (test_bit(STATUS_INT_ENABLED, &priv->status))
+ /* re-enable interrupts here since we don't have anything
+* to service. */
+ iwl_enable_interrupts(priv);
spin_unlock(&priv->lock);
return IRQ_NONE;
}
---
Thanks,
Joonwoo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconf at conf.au 2008?
Hello, Sorry to hear that; I believe many would want to attend netconf in case it was a part of LCA08. I must add that I followed some of the presentations slides of netconf from recent years and it seemed very interesting and very advanced. I also watched the "Linux IPSEC Scaling" video (available on the internet) from LCA 2007 and found it really interesting . (I don't think that there is any video from netconf conferences from recent years). I wish that in LCA09 things will be different. (And of course I did not mean any netconf stuff from martin krafft, which I already knew before) Regards, Andy On Jan 14, 2008 4:08 AM, David Miller <[EMAIL PROTECTED]> wrote: > From: Glen Turner <[EMAIL PROTECTED]> > Date: Mon, 14 Jan 2008 01:23:45 +1030 > > > > > On Sat, 2008-01-12 at 08:52 +0200, Andy Johnson wrote: > > > I saw somewhere (maybe in this mailing list a while ago) that there > > > might be a Linux Kernel Developers' Netconf conference at conf.au > > > 2008. > > > > > > Does anyone here know if such a thing is planned ? > > > > I don't know. > > We wanted to do a netconf in Sydney right before LCA08, but an unnamed > company with a multi billion dollar market capitalization that uses > Linux networking technology on thousands upon thounsands of their > servers didn't want to pony up for some funding to cover airfare and > hotel expenses for several of the attendees. They wanted to provide > nothing more than a conference room and then get their names in bright > lights so they could say they "sponsored" netconf. > > So, no, there will be no netconf at LCA08. But many of us will be > there anyways and chatting in any event :-) > > Thanks for the offer for the network pipe. I'm not interested > personally as I like to relax during the conference not hack actively > on anything too seriously. I'm there to present, keep up semi > regularly with my email, and chat with folks. > > Now, if this were available outside of the conference so that we could > play with it remotely from where we work, that's more interesting. > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 8/8] [PKTGEN]: uninline getCurUs
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Mon, 14 Jan 2008 10:33:34 +0200 (EET) > Thanks anyway for the tips & all, I think we have it now working > and I can return to inlines and rexmit_skb_hint things & other TCP > stuff rather than this hinderance. I've some interesting results > from net header inlines checks I ran overnight :-). Great, I look forward to seeing it :) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netperf TCP_RR(loopback) 10% regression in 2.6.24-rc6, comparing with 2.6.22
On Mon, 14 Jan 2008, Ilpo Järvinen wrote: > On Fri, 11 Jan 2008, Zhang, Yanmin wrote: > > > On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote: > > > > > > As a matter of fact, 2.6.23 has about 6% regression and 2.6.24-rc's > > > regression is between 16%~11%. > > > > > > I tried to use bisect to locate the bad patch between 2.6.22 and > > > 2.6.23-rc1, > > > but the bisected kernel wasn't stable and went crazy. > > TCP work between that is very much non-existing. I _really_ meant 2.6.22 - 2.6.23-rc1, not 2.6.24-rc1 in case you had a typo there which is not that uncommon while typing kernel versions... :-) -- i.
Re: Netperf TCP_RR(loopback) 10% regression in 2.6.24-rc6, comparing with 2.6.22
On Mon, 2008-01-14 at 11:21 +0200, Ilpo J�rvinen wrote: > On Mon, 14 Jan 2008, Ilpo J�rvinen wrote: > > > On Fri, 11 Jan 2008, Zhang, Yanmin wrote: > > > > > On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote: > > > > > > > > As a matter of fact, 2.6.23 has about 6% regression and 2.6.24-rc's > > > > regression is between 16%~11%. > > > > > > > > I tried to use bisect to locate the bad patch between 2.6.22 and > > > > 2.6.23-rc1, > > > > but the bisected kernel wasn't stable and went crazy. > > > > TCP work between that is very much non-existing. > > I _really_ meant 2.6.22 - 2.6.23-rc1, not 2.6.24-rc1 in case you had a > typo I did bisect 2.6.22 - 2.6.23-rc1. I also tested it on the latest 2.6.24-rc. > there which is not that uncommon while typing kernel versions... :-) Thanks. I will retry bisect and bind the server/client to the same logical processor, where I hope the result is stable this time when bisecting. Manual testing showed there is still same or more regression if I bind the processes on the same cpu. Thanks a lot! -yanmin -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ipw3945-devel] [PATCH 2/5] iwlwifi: iwl3945 synchronize interruptand tasklet for down iwlwifi
I'm so sorry for mangled patch.
resending patch with preformat html from thunderbird.
After disabling interrupts, it's possible irq & tasklet is pending or running
This patch eleminates races for down iwlwifi.
Since synchronize_irq can introduce iwl_irq_tasklet, tasklet_kill should be
called after doing synchronize_irq.
To avoid races between iwl_synchronize_irq and iwl_irq_tasklet
STATUS_INT_ENABLED flag is needed.
Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]>
---
drivers/net/wireless/iwlwifi/iwl3945-base.c | 33 ++-
1 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c
b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 6e20725..f98cd4f 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -4405,6 +4405,14 @@ static void iwl_print_rx_config_cmd(struct iwl_rxon_cmd
*rxon)
}
#endif
+static void iwl_synchronize_interrupts(struct iwl_priv *priv)
+{
+ synchronize_irq(priv->pci_dev->irq);
+ /* synchornize_irq introduces irq_tasklet,
+* tasklet_kill should be called after doing synchronize_irq */
+ tasklet_kill(&priv->irq_tasklet);
+}
+
static void iwl_enable_interrupts(struct iwl_priv *priv)
{
IWL_DEBUG_ISR("Enabling interrupts\n");
@@ -4413,7 +4421,7 @@ static void iwl_enable_interrupts(struct iwl_priv *priv)
iwl_flush32(priv, CSR_INT_MASK);
}
-static inline void iwl_disable_interrupts(struct iwl_priv *priv)
+static inline void __iwl_disable_interrupts(struct iwl_priv *priv)
{
clear_bit(STATUS_INT_ENABLED, &priv->status);
@@ -4427,6 +4435,13 @@ static inline void iwl_disable_interrupts(struct
iwl_priv *priv)
iwl_flush32(priv, CSR_INT);
iwl_write32(priv, CSR_FH_INT_STATUS, 0x);
iwl_flush32(priv, CSR_FH_INT_STATUS);
+}
+
+static inline void iwl_disable_interrupts(struct iwl_priv *priv)
+{
+ __iwl_disable_interrupts(priv);
+
+ iwl_synchronize_interrupts(priv);
IWL_DEBUG_ISR("Disabled interrupts\n");
}
@@ -4708,7 +4723,8 @@ static void iwl_irq_tasklet(struct iwl_priv *priv)
IWL_ERROR("Microcode HW error detected. Restarting.\n");
/* Tell the device to stop sending interrupts */
- iwl_disable_interrupts(priv);
+ __iwl_disable_interrupts(priv);
+ IWL_DEBUG_ISR("Disabled interrupts\n");
iwl_irq_handle_error(priv);
@@ -4814,8 +4830,11 @@ static void iwl_irq_tasklet(struct iwl_priv *priv)
IWL_WARNING(" with FH_INT = 0x%08x\n", inta_fh);
}
- /* Re-enable all interrupts */
- iwl_enable_interrupts(priv);
+ /* To avoid race when device goes down,
+* it should be discarded to enable interrupts */
+ if (test_bit(STATUS_INT_ENABLED, &priv->status))
+ /* Re-enable all interrupts */
+ iwl_enable_interrupts(priv);
#ifdef CONFIG_IWLWIFI_DEBUG
if (iwl_debug_level & (IWL_DL_ISR)) {
@@ -4876,8 +4895,10 @@ unplugged:
return IRQ_HANDLED;
none:
- /* re-enable interrupts here since we don't have anything to service. */
- iwl_enable_interrupts(priv);
+ if (test_bit(STATUS_INT_ENABLED, &priv->status))
+ /* re-enable interrupts here since we don't have anything
+* to service. */
+ iwl_enable_interrupts(priv);
spin_unlock(&priv->lock);
return IRQ_NONE;
}
---
Thanks,
Joonwoo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][resend] add driver for enc28j60 ethernet chip
This patch add support for Microchip enc28j60 10Mbps Ethernet chip used in
embedded systems
due to its cheap SPI interface.
This 2nd version include changes from previous comments by Jeff and Stephen,
all but NAPI, see comments below at this regard.
I resend the patch because I didn't receive any feedback.
Changes to 1st version:
- use mutex instead of semaphore
- add carrier detect handling
- add ethtool support
- set_multicast_list when the interface is up using a workqueue
- add restart_work to reset the chip in case of tx_timeout
- removed kmalloc() for spi_transfer_buf (array defined in the priv struct)
Jeff Garzik wrote:
comments:
* Why do interrupt work in a kernel thread? Your comment says you
cannot, but does not explain.
The enc28j60 is a SPI to Ethernet adapter, so we cannot access register
with simple in() out() instructions, but we need to use the SPI
subsystem. The spi_sync() basic operation to read/write a register is a
blocking operation, so can't be done in interrupt context.
Since every basic operation like read interrupt flag register call
spi_sync() we need the work queue for almost everything.
* should use NAPI
For the reason I just explained I don't think NAPI is a viable way for
enc28j60.
Furthermore enc28j60 is a 10Mb only device and probably don't suffer to
interrupt overload.
I'm waiting for any comments, please.
Cheers,
Claudio Lanconelli
Signed-off-by: Claudio Lanconelli <[EMAIL PROTECTED]>
diff --git a/drivers/net/enc28j60.c b/drivers/net/enc28j60.c
new file mode 100644
index 000..0809a6a
--- /dev/null
+++ b/drivers/net/enc28j60.c
@@ -0,0 +1,1600 @@
+/*
+ * Microchip ENC28J60 ethernet driver (MAC + PHY)
+ *
+ * Copyright (C) 2007 Eurek srl
+ * Author: Claudio Lanconelli <[EMAIL PROTECTED]>
+ * based on enc28j60.c written by David Anders for 2.4 kernel version
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * $Id: enc28j60.c,v 1.22 2007/12/20 10:47:01 claudio Exp $
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "enc28j60_hw.h"
+
+#define DRV_NAME "enc28j60"
+#define DRV_VERSION "1.01"
+
+#define SPI_OPLEN 1
+
+#define ENC28J60_MSG_DEFAULT \
+ (NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN | NETIF_MSG_LINK)
+
+/* Buffer size required for the largest SPI transfer (i.e., reading a
+ * frame). */
+#define SPI_TRANSFER_BUF_LEN (4 + MAX_FRAMELEN)
+
+#define TX_TIMEOUT (4 * HZ)
+
+/* Max TX retries in case of collision as suggested by errata datasheet */
+#define MAX_TX_RETRYCOUNT 16
+
+enum {
+ RXFILTER_NORMAL,
+ RXFILTER_MULTI,
+ RXFILTER_PROMISC
+};
+
+/* Driver local data */
+struct enc28j60_net {
+ struct net_device *netdev;
+ struct spi_device *spi;
+ struct mutex lock;
+ struct sk_buff *tx_skb;
+ struct work_struct tx_work;
+ struct work_struct irq_work;
+ struct work_struct setrx_work;
+ struct work_struct restart_work;
+ u8 bank; /* current register bank selected */
+ u16 next_pk_ptr; /* next packet pointer within FIFO */
+ u16 max_pk_counter; /* statistics: max packet counter */
+ u16 tx_retry_count;
+ bool hw_enable;
+ bool full_duplex;
+ int rxfilter;
+ u32 msg_enable;
+ u8 spi_transfer_buf[SPI_TRANSFER_BUF_LEN];
+};
+
+/* use ethtool to change the level for any given device */
+static struct {
+ u32 msg_enable;
+} debug = { -1 };
+
+/*
+ * SPI read buffer
+ * wait for the SPI transfer and copy received data to destination
+ */
+static int
+spi_read_buf(struct enc28j60_net *priv, int len, u8 *data)
+{
+ u8 *rx_buf = priv->spi_transfer_buf + 4;
+ u8 *tx_buf = priv->spi_transfer_buf;
+ struct spi_transfer t = {
+ .tx_buf = tx_buf,
+ .rx_buf = rx_buf,
+ .len = SPI_OPLEN + len,
+ };
+ struct spi_message msg;
+ int ret;
+
+ tx_buf[0] = ENC28J60_READ_BUF_MEM;
+ tx_buf[1] = tx_buf[2] = tx_buf[3] = 0; /* don't care */
+
+ spi_message_init(&msg);
+ spi_message_add_tail(&t, &msg);
+ ret = spi_sync(priv->spi, &msg);
+ if (ret == 0) {
+ memcpy(data, &rx_buf[SPI_OPLEN], len);
+ ret = msg.status;
+ }
+ if (ret && netif_msg_drv(priv))
+ printk(KERN_DEBUG DRV_NAME ": %s() failed: ret = %d\n",
+ __FUNCTION__, ret);
+
+ return ret;
+}
+
+/*
+ * SPI write buffer
+ */
+static int spi_write_buf(struct enc28j60_net *priv, int len,
+ const u8 *data)
+{
+ int ret;
+
+ if (len > SPI_TRANSFER_BUF_LEN - 1 || len <= 0)
+ ret = -EINVAL;
+ else {
+ priv->spi_transfer_buf[0] = ENC28J60_WRITE_BUF_MEM;
+ memcpy(&priv->spi_transfer_buf[1], data, len);
+ ret = spi_write(priv->spi, priv->spi_transfer_buf, len + 1);
+ if (ret && netif_msg_drv(priv))
+ printk(KERN_DEBUG DRV_NAME ": %s() failed: ret = %d\n",
+__FUNCTION__, ret);
+ }
+ return ret;
+}
+
+/*
+ * basic SPI read operation
+ */
+stat
Re: Netconf at conf.au 2008?
also sprach David Miller <[EMAIL PROTECTED]> [2008.01.14.0312 +0100]: > > I think you may be mixing things up, and it may be my fault in > > ways. I am developing netconf: http://netconf.alioth.debian.org. > > I am aware of the NETCONF protocol and have considered renaming > > my project, but looking around, it seemed to me that NETCONF > > isn't really all that active, and so I chose to keep the name. > > If people think that wasn't wise, I'm willing to listen... > > Netconf is the name of the usually annual conference the core > Linux networking developer organize. Fun fun fun: name clashes. In Debian, we have debconf, the tool, the protocol and the conference. Now we have netconf, the tool, the protocol and the conference. -- martin | http://madduck.net/ | http://two.sentenc.es/ if you find a spelling mistake in the above, you get to keep it. spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: Netperf TCP_RR(loopback) 10% regression in 2.6.24-rc6, comparing with 2.6.22
On Mon, Jan 14, 2008 at 08:44:40AM +, Ilpo Järvinen wrote:
>
> > > I tried to use bisect to locate the bad patch between 2.6.22 and
> > > 2.6.23-rc1,
> > > but the bisected kernel wasn't stable and went crazy.
>
> TCP work between that is very much non-existing.
Make sure you haven't switched between SLAB/SLUB while testing this.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconf at conf.au 2008?
On Sun, 2008-01-13 at 18:08 -0800, David Miller wrote: > Now, if this were available outside of the conference so that we could > play with it remotely from where we work, that's more interesting. Hi David, As I posted to this list last year AARNet is willing to make a 10GE connected server in Perth available to the netdev and PFLDNet communities. There was a matching offer from the University of Manchester in England, which gives an impressive BDP (Perth-Sydney-Seattle-New York-London @ 10Gbps across production networks). Since there was no reply to the offer it went on the back burner and we've done a smaller rollout (Perth-Seattle) to suit our own immediate needs. We really appreciate your work and the work of everyone else on the netdev list, so I'll re-contact Manchester and get this back on track. If you have trouble hosting netconf next year please get in touch. Although AARNet could not sponsor the flights or accommodation we could provide everything else you require. We're not "name in bright lights" people so there would be plenty of room for other sponsors. [1] Alternatively, AARNet has been pretty successful in the past at attracting sponsorship for events which benefit our users, so if you and the netdev people were willing to hold a one-day training/workshop of interest to academic and research network users (say network host tuning) before/after your meeting then we'd have no trouble getting sponsorship via the training event that would be sufficient to cover the airfares and accommodation for the larger event. Anyway, to cut to the chase, the users of AARNet face large RTTs to get anywhere and we are very appreciative of the huge amount of work that you, John, Stephen and many others on this list have put into improving performance under the conditions we face. If we can help your work then please ask. Best wishes, Glen [1] Witness our sponsorship of linux.conf.au, where our only real request is that people don't place us in a difficult position by misusing the network we provide. -- Glen Turner, Network Engineer (08) 8303 3936 or +61 8 8303 3936 Australia's Academic & Research Network www.aarnet.edu.au -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconf at conf.au 2008?
In article <[EMAIL PROTECTED]> (at Sun, 13 Jan 2008 19:17:51 +0100), martin f krafft <[EMAIL PROTECTED]> says: > also sprach Andy Johnson <[EMAIL PROTECTED]> [2008.01.12.0752 +0100]: > > I saw somewhere (maybe in this mailing list a while ago) that > > there might be a Linux Kernel Developers' Netconf conference at > > conf.au 2008. > > I think you may be mixing things up, and it may be my fault in ways. > I am developing netconf: http://netconf.alioth.debian.org. I am > aware of the NETCONF protocol and have considered renaming my > project, but looking around, it seemed to me that NETCONF isn't > really all that active, and so I chose to keep the name. If people > think that wasn't wise, I'm willing to listen... Very confusing to me... --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] fix sparse warnings
Thanks for hacking and improving and the trie... another idea that could be also tested. If we look into routing table we see that most leafs only has one prefix Main: Aver depth: 2.57 Max depth: 7 Leaves: 231173 ip route | wc -l 241649 Thats 231173/241649 = 96% with the current Internet routing. How about if would have a fastpath and store one entry direct in the leaf struct this to avoid loading the leaf_info list in most cases? One could believe that both lookup and dump could improve. Cheers. --ro Stephen Hemminger writes: > Remember that the code should be optimized for lookup, not management > operations. We ran into this during testing (the test suite was looking > for number of routes), thats why I put in the size field. > > The existing dump code is really slow: > > 1) FIB_TRIE Under KVM: > load 164393 routes 12.436 sec > ip route | wc -l12.569 sec > grep /proc/net/route25.357 sec > > 99% of the cpu time is spent in nextleaf() during these dump operations. > > 2) FIB_HASH Under KVM: > load 164393 routes 10.833 sec > ip route | wc -l1.981 sec > grep /proc/net/route0.204 sec -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.23+] ingress classify to [nf]mark
jamal wrote: I in doubts only about "action continue". To "and/or" behaviour one of best usage are (example): I dont think you should be touching the action part at all primarily because actions can set the mark after classification. Yes, I only do it by inertia after "#define tc_index mark". I not understand why "tc_index" changed in this place. 1) there are ingress 2) there are "OK" action. Are "tc_index" will not changed after: "tc filter add dev eth0 parent : ... flowid 1:1 action continue" ? In general - are tc_index useful in ingress? (may be tc_index used in [nf]mark-style, but even in netfilter it feature migrate - IMHO, may be I time to time do not see in needed place) Sorry, I just change focus from existing "tc_index=..." to common behaviour ;) [...] Please refer to what i said above; if what i said still doesnt make sense i can create (the simple) patch. A bit vague... sorry... -- WBR, Denis Kaganovich, [EMAIL PROTECTED] http://mahatma.bspu.unibel.by -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] get rid of unused revision element
David Miller writes: > > The revision element must of been part of an earlier design, > > because currently it is set but never used. > > > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> > > I suspect Robert wanted to play around with some generation > ID optimizations but never got around to it. The idea was to have a selective flush of route cache entries when a fib insert/delete happened. From what I remember you added another/ better solution. Just a list with route cache entries pointing to parent route. So yes this was obsoleted by your/our effort to avoid total flushing of the route cache. Unfinished work. According to http://bgpupdates.potaroo.net/instability/bgpupd.html (last in page) we currently flush the route cache 2.80 times per second. when using full Internet routing with Linux. Maybe we're forced to pick up this thread again someday. Cheers. --ro -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconf at conf.au 2008?
From: Glen Turner <[EMAIL PROTECTED]> Date: Mon, 14 Jan 2008 21:31:20 +1030 > If you have trouble hosting netconf next year please get in > touch. Although AARNet could not sponsor the flights or > accommodation we could provide everything else you require. I appreciate the offer, but the funding is the one and only issue. I have more ways to get conference facilities and network connectivity for them than I need. > so if you and the netdev people were willing to hold a one-day > training/workshop of interest to academic and research network > users (say network host tuning) before/after your meeting then > we'd have no trouble getting sponsorship via the training > event that would be sufficient to cover the airfares and > accommodation for the larger event. We're really not interested in things like this, but thanks for mentioning. At best what we do is allow one or two representatives from a major sponsoring party to attend and give a presentation (netconf is invite only, so this is a big deal). And that presentation must be on practical work the presenter has done or is doing with the Linux networking upstream (ie. it can't be a "our company needs the Linux networking to do X", some sales/marketing pitch, or "here's cool proprietary Y we're doing with Linux") -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] get rid of unused revision element
From: Robert Olsson <[EMAIL PROTECTED]> Date: Mon, 14 Jan 2008 12:44:32 +0100 > The idea was to have a selective flush of route cache entries when > a fib insert/delete happened. From what I remember you added another/ > better solution. Just a list with route cache entries pointing to parent > route. So yes this was obsoleted by your/our effort to avoid total > flushing of the route cache. Unfinished work. Yes, that's right. The synchronization was very hard. But there is another issue, see below > According to http://bgpupdates.potaroo.net/instability/bgpupd.html > (last in page) we currently flush the route cache 2.80 times per second. > when using full Internet routing with Linux. Maybe we're forced to pick > up this thread again someday. This proves we need to solve this problem. The reason I've never gone back to that work is that I didn't want to do it while we still had multiple FIB data structure implementations. Someone needs to go over whatever deficiencies exist in fib_trie vs. fib_hash so that we can delete fib_hash and move over to using fib_trie always. It makes no sense to implement everything interfacing into that code twice. There was a full consensus that this was the way to move forward, we just need the dirty work to be done. If someone wants to show their gratitude for my getting rid of the multipath cached routing code, the above work would be a great way to do so (hint hint) :-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.23+] ingress classify to [nf]mark
On Mon, 2008-14-01 at 13:40 -0200, Dzianis Kahanovich wrote: > jamal wrote: > Yes, I only do it by inertia after "#define tc_index mark". And i am afraid this bothers me greatly. You already have ways to achieve what you need by setting proper policy, the difference in configuration is an extra one policy line you have to type in. Adding yet another #ifdef is really going overboard. > I not understand why "tc_index" changed in this place. 1) there are ingress > 2) > there are "OK" action. Are "tc_index" will not changed after: "tc filter add > dev eth0 parent : ... flowid 1:1 action continue" ? In general - are > tc_index useful in ingress? (may be tc_index used in [nf]mark-style, but even > in netfilter it feature migrate - IMHO, may be I time to time do not see in > needed place) tc_index could be used for classification actually. If you "continue" you could hit another classifier which looks at it. > Sorry, I just change focus from existing "tc_index=..." to common behaviour ;) > [...] > > Please refer to what i said above; if what i said still doesnt make > > sense i can create (the simple) patch. > > A bit vague... sorry... I mean: #ifdef CONFIG_NET_CLS_ACT leave this part alone which already sets tc_index ... #else ...set tc_index and mark here ... #endif And when we have a metadata action - we remove setting of tc_index from #ifdef CONFIG_NET_CLS_ACT Did that make sense? cheers, jamal -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25 2/4][NETNS][RAW]: Make /proc/net/raw(6) show per-namespace socket list.
Pull the struct net pointer up to the showing functions
to filter the sockets depending on their namespaces.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
include/net/raw.h |3 ++-
net/ipv4/raw.c| 20
net/ipv6/raw.c|4 ++--
3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/include/net/raw.h b/include/net/raw.h
index 4d1aba0..cca81d8 100644
--- a/include/net/raw.h
+++ b/include/net/raw.h
@@ -39,6 +39,7 @@ extern int raw_proc_init(void);
extern void raw_proc_exit(void);
struct raw_iter_state {
+ struct seq_net_private p;
int bucket;
unsigned short family;
struct raw_hashinfo *h;
@@ -48,7 +49,7 @@ struct raw_iter_state {
void *raw_seq_start(struct seq_file *seq, loff_t *pos);
void *raw_seq_next(struct seq_file *seq, void *v, loff_t *pos);
void raw_seq_stop(struct seq_file *seq, void *v);
-int raw_seq_open(struct file *file, struct raw_hashinfo *h,
+int raw_seq_open(struct inode *ino, struct file *file, struct raw_hashinfo *h,
unsigned short family);
#endif
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index a490a9d..4e95372 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -860,7 +860,8 @@ static struct sock *raw_get_first(struct seq_file *seq)
struct hlist_node *node;
sk_for_each(sk, node, &state->h->ht[state->bucket])
- if (sk->sk_family == state->family)
+ if (sk->sk_net == state->p.net &&
+ sk->sk_family == state->family)
goto found;
}
sk = NULL;
@@ -876,7 +877,8 @@ static struct sock *raw_get_next(struct seq_file *seq,
struct sock *sk)
sk = sk_next(sk);
try_again:
;
- } while (sk && sk->sk_family != state->family);
+ } while (sk && sk->sk_net != state->p.net &&
+ sk->sk_family != state->family);
if (!sk && ++state->bucket < RAW_HTABLE_SIZE) {
sk = sk_head(&state->h->ht[state->bucket]);
@@ -970,16 +972,18 @@ static const struct seq_operations raw_seq_ops = {
.show = raw_seq_show,
};
-int raw_seq_open(struct file *file, struct raw_hashinfo *h,
+int raw_seq_open(struct inode *ino, struct file *file, struct raw_hashinfo *h,
unsigned short family)
{
+ int err;
struct raw_iter_state *i;
- i = __seq_open_private(file, &raw_seq_ops,
+ err = seq_open_net(ino, file, &raw_seq_ops,
sizeof(struct raw_iter_state));
- if (i == NULL)
- return -ENOMEM;
+ if (err < 0)
+ return err;
+ i = raw_seq_private((struct seq_file *)file->private_data);
i->h = h;
i->family = family;
return 0;
@@ -988,7 +992,7 @@ EXPORT_SYMBOL_GPL(raw_seq_open);
static int raw_v4_seq_open(struct inode *inode, struct file *file)
{
- return raw_seq_open(file, &raw_v4_hashinfo, PF_INET);
+ return raw_seq_open(inode, file, &raw_v4_hashinfo, PF_INET);
}
static const struct file_operations raw_seq_fops = {
@@ -996,7 +1000,7 @@ static const struct file_operations raw_seq_fops = {
.open= raw_v4_seq_open,
.read= seq_read,
.llseek = seq_lseek,
- .release = seq_release_private,
+ .release = seq_release_net,
};
int __init raw_proc_init(void)
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 6f20086..026fa91 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -1259,7 +1259,7 @@ static const struct seq_operations raw6_seq_ops = {
static int raw6_seq_open(struct inode *inode, struct file *file)
{
- return raw_seq_open(file, &raw_v6_hashinfo, PF_INET6);
+ return raw_seq_open(inode, file, &raw_v6_hashinfo, PF_INET6);
}
static const struct file_operations raw6_seq_fops = {
@@ -1267,7 +1267,7 @@ static const struct file_operations raw6_seq_fops = {
.open = raw6_seq_open,
.read = seq_read,
.llseek = seq_lseek,
- .release = seq_release_private,
+ .release = seq_release_net,
};
int __init raw6_proc_init(void)
--
1.5.3.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25 4/4][NETNS][RAW]: Create the /proc/net/raw(6) in each namespace.
To do so, just register the proper subsystem and create files in
->init callbacks.
No other special per-namespace handling for raw sockets is required.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
net/ipv4/raw.c | 22 +++---
net/ipv6/raw.c | 22 +++---
2 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 206c869..91a5218 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -1003,15 +1003,31 @@ static const struct file_operations raw_seq_fops = {
.release = seq_release_net,
};
-int __init raw_proc_init(void)
+static __net_init int raw_init_net(struct net *net)
{
- if (!proc_net_fops_create(&init_net, "raw", S_IRUGO, &raw_seq_fops))
+ if (!proc_net_fops_create(net, "raw", S_IRUGO, &raw_seq_fops))
return -ENOMEM;
+
return 0;
}
+static __net_exit void raw_exit_net(struct net *net)
+{
+ proc_net_remove(net, "raw");
+}
+
+static __net_initdata struct pernet_operations raw_net_ops = {
+ .init = raw_init_net,
+ .exit = raw_exit_net,
+};
+
+int __init raw_proc_init(void)
+{
+ return register_pernet_subsys(&raw_net_ops);
+}
+
void __init raw_proc_exit(void)
{
- proc_net_remove(&init_net, "raw");
+ unregister_pernet_subsys(&raw_net_ops);
}
#endif /* CONFIG_PROC_FS */
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 970529e..4d88055 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -1270,16 +1270,32 @@ static const struct file_operations raw6_seq_fops = {
.release = seq_release_net,
};
-int __init raw6_proc_init(void)
+static int raw6_init_net(struct net *net)
{
- if (!proc_net_fops_create(&init_net, "raw6", S_IRUGO, &raw6_seq_fops))
+ if (!proc_net_fops_create(net, "raw6", S_IRUGO, &raw6_seq_fops))
return -ENOMEM;
+
return 0;
}
+static void raw6_exit_net(struct net *net)
+{
+ proc_net_remove(net, "raw6");
+}
+
+static struct pernet_operations raw6_net_ops = {
+ .init = raw6_init_net,
+ .exit = raw6_exit_net,
+};
+
+int __init raw6_proc_init(void)
+{
+ return register_pernet_subsys(&raw6_net_ops);
+}
+
void raw6_proc_exit(void)
{
- proc_net_remove(&init_net, "raw6");
+ unregister_pernet_subsys(&raw6_net_ops);
}
#endif /* CONFIG_PROC_FS */
--
1.5.3.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25 3/4][NETNS][RAW]: Eliminate explicit init_net references.
Happily, in all the rest places (->bind callbacks only), that require the
struct net, we have a socket, so get the net from it.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
net/ipv4/raw.c |2 +-
net/ipv6/raw.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 4e95372..206c869 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -625,7 +625,7 @@ static int raw_bind(struct sock *sk, struct sockaddr
*uaddr, int addr_len)
if (sk->sk_state != TCP_CLOSE || addr_len < sizeof(struct sockaddr_in))
goto out;
- chk_addr_ret = inet_addr_type(&init_net, addr->sin_addr.s_addr);
+ chk_addr_ret = inet_addr_type(sk->sk_net, addr->sin_addr.s_addr);
ret = -EADDRNOTAVAIL;
if (addr->sin_addr.s_addr && chk_addr_ret != RTN_LOCAL &&
chk_addr_ret != RTN_MULTICAST && chk_addr_ret != RTN_BROADCAST)
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 026fa91..970529e 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -291,7 +291,7 @@ static int rawv6_bind(struct sock *sk, struct sockaddr
*uaddr, int addr_len)
if (!sk->sk_bound_dev_if)
goto out;
- dev = dev_get_by_index(&init_net, sk->sk_bound_dev_if);
+ dev = dev_get_by_index(sk->sk_net, sk->sk_bound_dev_if);
if (!dev) {
err = -ENODEV;
goto out;
@@ -304,7 +304,7 @@ static int rawv6_bind(struct sock *sk, struct sockaddr
*uaddr, int addr_len)
v4addr = LOOPBACK4_IPV6;
if (!(addr_type & IPV6_ADDR_MULTICAST)) {
err = -EADDRNOTAVAIL;
- if (!ipv6_chk_addr(&init_net, &addr->sin6_addr,
+ if (!ipv6_chk_addr(sk->sk_net, &addr->sin6_addr,
dev, 0)) {
if (dev)
dev_put(dev);
--
1.5.3.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25 1/4][NETNS][RAW]: Make ipv[46] raw sockets lookup namespaces aware.
This requires just to pass the appropriate struct net pointer
into __raw_v[46]_lookup and skip sockets that do not belong
to a needed namespace.
The proper net is get from skb->dev in all the cases.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
net/ipv4/raw.c | 21 +
net/ipv6/raw.c | 18 +-
2 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 747911a..a490a9d 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -116,16 +116,15 @@ static void raw_v4_unhash(struct sock *sk)
raw_unhash_sk(sk, &raw_v4_hashinfo);
}
-static struct sock *__raw_v4_lookup(struct sock *sk, unsigned short num,
-__be32 raddr, __be32 laddr,
-int dif)
+static struct sock *__raw_v4_lookup(struct net *net, struct sock *sk,
+ unsigned short num, __be32 raddr, __be32 laddr, int dif)
{
struct hlist_node *node;
sk_for_each_from(sk, node) {
struct inet_sock *inet = inet_sk(sk);
- if (inet->num == num&&
+ if (sk->sk_net == net && inet->num == num &&
!(inet->daddr && inet->daddr != raddr) &&
!(inet->rcv_saddr && inet->rcv_saddr != laddr) &&
!(sk->sk_bound_dev_if && sk->sk_bound_dev_if != dif))
@@ -169,12 +168,15 @@ static int raw_v4_input(struct sk_buff *skb, struct iphdr
*iph, int hash)
struct sock *sk;
struct hlist_head *head;
int delivered = 0;
+ struct net *net;
read_lock(&raw_v4_hashinfo.lock);
head = &raw_v4_hashinfo.ht[hash];
if (hlist_empty(head))
goto out;
- sk = __raw_v4_lookup(__sk_head(head), iph->protocol,
+
+ net = skb->dev->nd_net;
+ sk = __raw_v4_lookup(net, __sk_head(head), iph->protocol,
iph->saddr, iph->daddr,
skb->dev->ifindex);
@@ -187,7 +189,7 @@ static int raw_v4_input(struct sk_buff *skb, struct iphdr
*iph, int hash)
if (clone)
raw_rcv(sk, clone);
}
- sk = __raw_v4_lookup(sk_next(sk), iph->protocol,
+ sk = __raw_v4_lookup(net, sk_next(sk), iph->protocol,
iph->saddr, iph->daddr,
skb->dev->ifindex);
}
@@ -273,6 +275,7 @@ void raw_icmp_error(struct sk_buff *skb, int protocol, u32
info)
int hash;
struct sock *raw_sk;
struct iphdr *iph;
+ struct net *net;
hash = protocol & (RAW_HTABLE_SIZE - 1);
@@ -280,8 +283,10 @@ void raw_icmp_error(struct sk_buff *skb, int protocol, u32
info)
raw_sk = sk_head(&raw_v4_hashinfo.ht[hash]);
if (raw_sk != NULL) {
iph = (struct iphdr *)skb->data;
- while ((raw_sk = __raw_v4_lookup(raw_sk, protocol, iph->daddr,
- iph->saddr,
+ net = skb->dev->nd_net;
+
+ while ((raw_sk = __raw_v4_lookup(net, raw_sk, protocol,
+ iph->daddr, iph->saddr,
skb->dev->ifindex)) != NULL) {
raw_err(raw_sk, skb, info);
raw_sk = sk_next(raw_sk);
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index cb0b110..6f20086 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -76,8 +76,9 @@ static void raw_v6_unhash(struct sock *sk)
}
-static struct sock *__raw_v6_lookup(struct sock *sk, unsigned short num,
- struct in6_addr *loc_addr, struct in6_addr *rmt_addr, int dif)
+static struct sock *__raw_v6_lookup(struct net *net, struct sock *sk,
+ unsigned short num, struct in6_addr *loc_addr,
+ struct in6_addr *rmt_addr, int dif)
{
struct hlist_node *node;
int is_multicast = ipv6_addr_is_multicast(loc_addr);
@@ -86,6 +87,9 @@ static struct sock *__raw_v6_lookup(struct sock *sk, unsigned
short num,
if (inet_sk(sk)->num == num) {
struct ipv6_pinfo *np = inet6_sk(sk);
+ if (sk->sk_net != net)
+ continue;
+
if (!ipv6_addr_any(&np->daddr) &&
!ipv6_addr_equal(&np->daddr, rmt_addr))
continue;
@@ -165,6 +169,7 @@ static int ipv6_raw_deliver(struct sk_buff *skb, int
nexthdr)
struct sock *sk;
int delivered = 0;
__u8 hash;
+ struct net *net;
saddr = &ipv6_hdr(skb)->saddr;
daddr = saddr + 1;
@@ -182,7 +187,8 @@ static int ipv6_raw_deliver(struct sk_buff *skb, int
nexthdr)
if (sk == NULL)
goto out;
- sk = __raw_v6_lookup(sk, nexthdr, dad
[PATCH net-2.6.25] [ARP] Remove forward declaration of neigh_changeaddr.
No need for this. It is declared in the neighbour.h Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]> --- net/core/neighbour.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/net/core/neighbour.c b/net/core/neighbour.c index 2eab6a5..9b0b773 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -59,7 +59,6 @@ static void neigh_timer_handler(unsigned long arg); static void __neigh_notify(struct neighbour *n, int type, int flags); static void neigh_update_notify(struct neighbour *neigh); static int pneigh_ifdown(struct neigh_table *tbl, struct net_device *dev); -void neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev); static struct neigh_table *neigh_tables; #ifdef CONFIG_PROC_FS -- 1.5.3.rc5 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25] [IPV4] fib_rules_unregister is essentially void.
fib_rules_unregister is called only after successful register and the return
code is never checked.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
---
include/net/fib_rules.h |2 +-
net/core/fib_rules.c| 21 -
2 files changed, 5 insertions(+), 18 deletions(-)
diff --git a/include/net/fib_rules.h b/include/net/fib_rules.h
index 88f870f..34349f9 100644
--- a/include/net/fib_rules.h
+++ b/include/net/fib_rules.h
@@ -104,7 +104,7 @@ static inline u32 frh_get_table(struct fib_rule_hdr *frh,
struct nlattr **nla)
}
extern int fib_rules_register(struct net *, struct fib_rules_ops *);
-extern int fib_rules_unregister(struct net *, struct fib_rules_ops *);
+extern void fib_rules_unregister(struct net *, struct fib_rules_ops *);
extern void fib_rules_cleanup_ops(struct fib_rules_ops *);
extern int fib_rules_lookup(struct fib_rules_ops *,
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index 0eecf4c..42ccaf5 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -115,29 +115,16 @@ void fib_rules_cleanup_ops(struct fib_rules_ops *ops)
}
EXPORT_SYMBOL_GPL(fib_rules_cleanup_ops);
-int fib_rules_unregister(struct net *net, struct fib_rules_ops *ops)
+void fib_rules_unregister(struct net *net, struct fib_rules_ops *ops)
{
- int err = 0;
- struct fib_rules_ops *o;
spin_lock(&net->rules_mod_lock);
- list_for_each_entry(o, &net->rules_ops, list) {
- if (o == ops) {
- list_del_rcu(&o->list);
- fib_rules_cleanup_ops(ops);
- goto out;
- }
- }
-
- err = -ENOENT;
-out:
+ list_del_rcu(&ops->list);
+ fib_rules_cleanup_ops(ops);
spin_unlock(&net->rules_mod_lock);
synchronize_rcu();
- if (!err)
- release_net(net);
-
- return err;
+ release_net(net);
}
EXPORT_SYMBOL_GPL(fib_rules_unregister);
--
1.5.3.rc5
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25] [NETNS] Make arp code network namespace consistent.
Some calls in the arp.c have network namespace as an argument. Getting
init_net inside these functions is simply inconsistent. Fix this.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
---
net/ipv4/arp.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 49c24ff..0db7d49 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -969,13 +969,13 @@ static int arp_req_set_public(struct net *net, struct
arpreq *r,
if (mask && mask != htonl(0x))
return -EINVAL;
if (!dev && (r->arp_flags & ATF_COM)) {
- dev = dev_getbyhwaddr(&init_net, r->arp_ha.sa_family,
+ dev = dev_getbyhwaddr(net, r->arp_ha.sa_family,
r->arp_ha.sa_data);
if (!dev)
return -ENODEV;
}
if (mask) {
- if (pneigh_lookup(&arp_tbl, &init_net, &ip, dev, 1) == NULL)
+ if (pneigh_lookup(&arp_tbl, net, &ip, dev, 1) == NULL)
return -ENOBUFS;
return 0;
}
@@ -1084,7 +1084,7 @@ static int arp_req_delete_public(struct net *net, struct
arpreq *r,
__be32 mask = ((struct sockaddr_in *)&r->arp_netmask)->sin_addr.s_addr;
if (mask == htonl(0x))
- return pneigh_delete(&arp_tbl, &init_net, &ip, dev);
+ return pneigh_delete(&arp_tbl, net, &ip, dev);
if (mask)
return -EINVAL;
@@ -1162,7 +1162,7 @@ int arp_ioctl(struct net *net, unsigned int cmd, void
__user *arg)
rtnl_lock();
if (r.arp_dev[0]) {
err = -ENODEV;
- if ((dev = __dev_get_by_name(&init_net, r.arp_dev)) == NULL)
+ if ((dev = __dev_get_by_name(net, r.arp_dev)) == NULL)
goto out;
/* Mmmm... It is wrong... ARPHRD_NETROM==0 */
--
1.5.3.rc5
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25] [ARP] Remove overkill checks from neigh_param_alloc.
Valid network device is always passed into neigh_param_alloc, so remove
extra checking for dev == NULL. Additionally, cleanup bogus netns assignment.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
net/core/neighbour.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index af49137..32f1a23 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1301,10 +1301,7 @@ struct neigh_parms *neigh_parms_alloc(struct net_device
*dev,
struct neigh_parms *p, *ref;
struct net *net;
- net = &init_net;
- if (dev)
- net = dev->nd_net;
-
+ net = dev->nd_net;
ref = lookup_neigh_params(tbl, net, 0);
if (!ref)
return NULL;
@@ -1316,15 +1313,14 @@ struct neigh_parms *neigh_parms_alloc(struct net_device
*dev,
INIT_RCU_HEAD(&p->rcu_head);
p->reachable_time =
neigh_rand_reach_time(p->base_reachable_time);
- if (dev) {
- if (dev->neigh_setup && dev->neigh_setup(dev, p)) {
- kfree(p);
- return NULL;
- }
- dev_hold(dev);
- p->dev = dev;
+ if (dev->neigh_setup && dev->neigh_setup(dev, p)) {
+ kfree(p);
+ return NULL;
}
+
+ dev_hold(dev);
+ p->dev = dev;
p->net = hold_net(net);
p->sysctl_table = NULL;
write_lock_bh(&tbl->lock);
--
1.5.3.rc5
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25] [ARP] neigh_parms_put(destroy) are essentially local to core/neighbour.c.
Make them static.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
---
include/net/neighbour.h |7 ---
net/core/neighbour.c| 11 ++-
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index a0d42a5..ebbfb50 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -213,7 +213,6 @@ extern struct neighbour *neigh_event_ns(struct
neigh_table *tbl,
extern struct neigh_parms *neigh_parms_alloc(struct net_device *dev,
struct neigh_table *tbl);
extern voidneigh_parms_release(struct neigh_table *tbl,
struct neigh_parms *parms);
-extern voidneigh_parms_destroy(struct neigh_parms *parms);
extern unsigned long neigh_rand_reach_time(unsigned long base);
extern voidpneigh_enqueue(struct neigh_table *tbl, struct
neigh_parms *p,
@@ -254,12 +253,6 @@ static inline void __neigh_parms_put(struct neigh_parms
*parms)
atomic_dec(&parms->refcnt);
}
-static inline void neigh_parms_put(struct neigh_parms *parms)
-{
- if (atomic_dec_and_test(&parms->refcnt))
- neigh_parms_destroy(parms);
-}
-
static inline struct neigh_parms *neigh_parms_clone(struct neigh_parms *parms)
{
atomic_inc(&parms->refcnt);
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 9b0b773..41394db 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -55,6 +55,8 @@
#define PNEIGH_HASHMASK0xF
+static inline void neigh_parms_put(struct neigh_parms *parms);
+
static void neigh_timer_handler(unsigned long arg);
static void __neigh_notify(struct neighbour *n, int type, int flags);
static void neigh_update_notify(struct neighbour *neigh);
@@ -1348,7 +1350,7 @@ void neigh_parms_release(struct neigh_table *tbl, struct
neigh_parms *parms)
NEIGH_PRINTK1("neigh_parms_release: not found\n");
}
-void neigh_parms_destroy(struct neigh_parms *parms)
+static void neigh_parms_destroy(struct neigh_parms *parms)
{
release_net(parms->net);
if (parms->dev)
@@ -1356,6 +1358,13 @@ void neigh_parms_destroy(struct neigh_parms *parms)
kfree(parms);
}
+static inline void neigh_parms_put(struct neigh_parms *parms)
+{
+ if (atomic_dec_and_test(&parms->refcnt))
+ neigh_parms_destroy(parms);
+}
+
+
static struct lock_class_key neigh_table_proxy_queue_class;
void neigh_table_init_no_netlink(struct neigh_table *tbl)
--
1.5.3.rc5
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25] [ARP] Move inet_addr_type call after simple error checks in arp_contructor.
The neighbour entry will be destroyed in the case of error, so it is pointless
to perform constly routing table lookup in this case.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
---
net/ipv4/arp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index b715ec0..49c24ff 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -235,8 +235,6 @@ static int arp_constructor(struct neighbour *neigh)
struct in_device *in_dev;
struct neigh_parms *parms;
- neigh->type = inet_addr_type(&init_net, addr);
-
rcu_read_lock();
in_dev = __in_dev_get_rcu(dev);
if (in_dev == NULL) {
@@ -244,6 +242,8 @@ static int arp_constructor(struct neighbour *neigh)
return -EINVAL;
}
+ neigh->type = inet_addr_type(&init_net, addr);
+
parms = in_dev->arp_parms;
__neigh_parms_put(neigh->parms);
neigh->parms = neigh_parms_clone(parms);
--
1.5.3.rc5
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.25 1/4][NETNS][RAW]: Make ipv[46] raw sockets lookup namespaces aware.
From: Pavel Emelyanov <[EMAIL PROTECTED]> Date: Mon, 14 Jan 2008 16:03:55 +0300 > This requires just to pass the appropriate struct net pointer > into __raw_v[46]_lookup and skip sockets that do not belong > to a needed namespace. > > The proper net is get from skb->dev in all the cases. > > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.25 2/4][NETNS][RAW]: Make /proc/net/raw(6) show per-namespace socket list.
From: Pavel Emelyanov <[EMAIL PROTECTED]> Date: Mon, 14 Jan 2008 16:08:42 +0300 > Pull the struct net pointer up to the showing functions > to filter the sockets depending on their namespaces. > > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.25 3/4][NETNS][RAW]: Eliminate explicit init_net references.
From: Pavel Emelyanov <[EMAIL PROTECTED]> Date: Mon, 14 Jan 2008 16:11:17 +0300 > Happily, in all the rest places (->bind callbacks only), that require the > struct net, we have a socket, so get the net from it. > > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.25 4/4][NETNS][RAW]: Create the /proc/net/raw(6) in each namespace.
From: Pavel Emelyanov <[EMAIL PROTECTED]> Date: Mon, 14 Jan 2008 16:13:08 +0300 > To do so, just register the proper subsystem and create files in > ->init callbacks. > > No other special per-namespace handling for raw sockets is required. > > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2 net-2.6.25] [NETNS] Process inet_confirm_addr in the correct namespace.
inet_confirm_addr can be called with NULL in_dev from arp_ignore iff
scope is RT_SCOPE_LINK.
Lets always pass the device and check for RT_SCOPE_LINK scope inside
inet_confirm_addr. This let us take network namespace from in_device a
need for an additional argument.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
---
net/ipv4/arp.c |1 -
net/ipv4/devinet.c |6 --
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index f38e1a9..b715ec0 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -402,7 +400,6 @@ static int arp_ignore(struct in_device *in_dev, __be32 sip,
__be32 tip)
case 3: /* Do not reply for scope host addresses */
sip = 0;
scope = RT_SCOPE_LINK;
- in_dev = NULL;
break;
case 4: /* Reserved */
case 5:
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index dc1665a..4569c69 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -978,13 +978,15 @@ __be32 inet_confirm_addr(struct in_device *in_dev,
{
__be32 addr = 0;
struct net_device *dev;
+ struct net *net;
- if (in_dev != NULL)
+ if (scope != RT_SCOPE_LINK)
return confirm_addr_indev(in_dev, dst, local, scope);
+ net = in_dev->dev->nd_net;
read_lock(&dev_base_lock);
rcu_read_lock();
- for_each_netdev(&init_net, dev) {
+ for_each_netdev(net, dev) {
if ((in_dev = __in_dev_get_rcu(dev))) {
addr = confirm_addr_indev(in_dev, dst, local, scope);
if (addr)
--
1.5.3.rc5
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 net-2.6.25] [IPV4] Remove extra argument from arp_ignore.
arp_ignore has two arguments: dev & in_dev. dev is used for inet_confirm_addr
calling only.
inet_confirm_addr, in turn, either gets in_dev from the device passed or
iterates over all network devices if the device passed is NULL. It seems
logical to directly pass in_dev into inet_confirm_addr.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
---
include/linux/inetdevice.h |2 +-
net/ipv4/arp.c | 11 +--
net/ipv4/devinet.c | 17 ++---
3 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index b3c5081..45f3731 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -135,7 +135,7 @@ extern int devinet_ioctl(unsigned int cmd, void
__user *);
extern voiddevinet_init(void);
extern struct in_device*inetdev_by_index(int);
extern __be32 inet_select_addr(const struct net_device *dev, __be32
dst, int scope);
-extern __be32 inet_confirm_addr(const struct net_device *dev, __be32
dst, __be32 local, int scope);
+extern __be32 inet_confirm_addr(struct in_device *in_dev, __be32 dst,
__be32 local, int scope);
extern struct in_ifaddr *inet_ifa_byprefix(struct in_device *in_dev, __be32
prefix, __be32 mask);
static __inline__ int inet_ifa_match(__be32 addr, struct in_ifaddr *ifa)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index e944d98..f38e1a9 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -382,8 +382,7 @@ static void arp_solicit(struct neighbour *neigh, struct
sk_buff *skb)
read_unlock_bh(&neigh->lock);
}
-static int arp_ignore(struct in_device *in_dev, struct net_device *dev,
- __be32 sip, __be32 tip)
+static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
{
int scope;
@@ -403,7 +402,7 @@ static int arp_ignore(struct in_device *in_dev, struct
net_device *dev,
case 3: /* Do not reply for scope host addresses */
sip = 0;
scope = RT_SCOPE_LINK;
- dev = NULL;
+ in_dev = NULL;
break;
case 4: /* Reserved */
case 5:
@@ -415,7 +414,7 @@ static int arp_ignore(struct in_device *in_dev, struct
net_device *dev,
default:
return 0;
}
- return !inet_confirm_addr(dev, sip, tip, scope);
+ return !inet_confirm_addr(in_dev, sip, tip, scope);
}
static int arp_filter(__be32 sip, __be32 tip, struct net_device *dev)
@@ -807,7 +806,7 @@ static int arp_process(struct sk_buff *skb)
if (sip == 0) {
if (arp->ar_op == htons(ARPOP_REQUEST) &&
inet_addr_type(&init_net, tip) == RTN_LOCAL &&
- !arp_ignore(in_dev,dev,sip,tip))
+ !arp_ignore(in_dev, sip, tip))
arp_send(ARPOP_REPLY, ETH_P_ARP, sip, dev, tip, sha,
dev->dev_addr, sha);
goto out;
@@ -825,7 +824,7 @@ static int arp_process(struct sk_buff *skb)
int dont_send = 0;
if (!dont_send)
- dont_send |=
arp_ignore(in_dev,dev,sip,tip);
+ dont_send |= arp_ignore(in_dev,sip,tip);
if (!dont_send && IN_DEV_ARPFILTER(in_dev))
dont_send |= arp_filter(sip,tip,dev);
if (!dont_send)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 03db15b..dc1665a 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -968,24 +968,19 @@ static __be32 confirm_addr_indev(struct in_device
*in_dev, __be32 dst,
/*
* Confirm that local IP address exists using wildcards:
- * - dev: only on this interface, 0=any interface
+ * - in_dev: only on this interface, 0=any interface
* - dst: only in the same subnet as dst, 0=any dst
* - local: address, 0=autoselect the local address
* - scope: maximum allowed scope value for the local address
*/
-__be32 inet_confirm_addr(const struct net_device *dev, __be32 dst, __be32
local, int scope)
+__be32 inet_confirm_addr(struct in_device *in_dev,
+__be32 dst, __be32 local, int scope)
{
__be32 addr = 0;
- struct in_device *in_dev;
-
- if (dev) {
- rcu_read_lock();
- if ((in_dev = __in_dev_get_rcu(dev)))
- addr = confirm_addr_indev(in_dev, dst, local, scope);
- rcu_read_unlock();
+ struct net_device *dev;
- return addr;
- }
+ if (in_dev != NULL)
+ return confirm_addr_indev(in_dev, dst, local, scope);
read_lock(&dev_base_lock);
rcu_read_lock();
--
1.5.3.rc5
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: [PATCH 1/2 net-2.6.25] [IPV4] Remove extra argument from arp_ignore.
This patch series is numbered, but your other patch series sent a few moments ago had no sequence numbers in the subject lines or changelog. How can I know what order to apply those in and do they need to go in before or after this set? I shouldn't have to ask questions like this, so please help avoid confusion of this nature in the future. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 net-2.6.25] [IPV4] Remove extra argument from arp_ignore.
David Miller wrote: > This patch series is numbered, but your other patch series sent a few > moments ago had no sequence numbers in the subject lines or changelog. > > How can I know what order to apply those in and do they need to go in > before or after this set? > > I shouldn't have to ask questions like this, so please help avoid > confusion of this nature in the future. > > Thanks. > non-numbered patches do not intersect with each other. numbered ones depends on each other but not from the rest. Sorry for inconvenience :( -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 net-2.6.25] [IPV4] Remove extra argument from arp_ignore.
Denis V. Lunev wrote: > David Miller wrote: >> This patch series is numbered, but your other patch series sent a few >> moments ago had no sequence numbers in the subject lines or changelog. >> >> How can I know what order to apply those in and do they need to go in >> before or after this set? >> >> I shouldn't have to ask questions like this, so please help avoid >> confusion of this nature in the future. >> >> Thanks. >> > > non-numbered patches do not intersect with each other. > > numbered ones depends on each other but not from the rest. > > Sorry for inconvenience :( I'll resend them for you convenience. Sorry again, I forget that git checks indexes and this can be a problem. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8 net-2.6.25] [NETNS] Make arp code network namespace consistent.
Some calls in the arp.c have network namespace as an argument. Getting
init_net inside these functions is simply inconsistent. Fix this.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
---
net/ipv4/arp.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 49c24ff..0db7d49 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -969,13 +969,13 @@ static int arp_req_set_public(struct net *net, struct
arpreq *r,
if (mask && mask != htonl(0x))
return -EINVAL;
if (!dev && (r->arp_flags & ATF_COM)) {
- dev = dev_getbyhwaddr(&init_net, r->arp_ha.sa_family,
+ dev = dev_getbyhwaddr(net, r->arp_ha.sa_family,
r->arp_ha.sa_data);
if (!dev)
return -ENODEV;
}
if (mask) {
- if (pneigh_lookup(&arp_tbl, &init_net, &ip, dev, 1) == NULL)
+ if (pneigh_lookup(&arp_tbl, net, &ip, dev, 1) == NULL)
return -ENOBUFS;
return 0;
}
@@ -1084,7 +1084,7 @@ static int arp_req_delete_public(struct net *net, struct
arpreq *r,
__be32 mask = ((struct sockaddr_in *)&r->arp_netmask)->sin_addr.s_addr;
if (mask == htonl(0x))
- return pneigh_delete(&arp_tbl, &init_net, &ip, dev);
+ return pneigh_delete(&arp_tbl, net, &ip, dev);
if (mask)
return -EINVAL;
@@ -1162,7 +1162,7 @@ int arp_ioctl(struct net *net, unsigned int cmd, void
__user *arg)
rtnl_lock();
if (r.arp_dev[0]) {
err = -ENODEV;
- if ((dev = __dev_get_by_name(&init_net, r.arp_dev)) == NULL)
+ if ((dev = __dev_get_by_name(net, r.arp_dev)) == NULL)
goto out;
/* Mmmm... It is wrong... ARPHRD_NETROM==0 */
--
1.5.3.rc5
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8 net-2.6.25] [ARP] Remove forward declaration of neigh_changeaddr.
No need for this. It is declared in the neighbour.h Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]> --- net/core/neighbour.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/net/core/neighbour.c b/net/core/neighbour.c index 2eab6a5..9b0b773 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -59,7 +59,6 @@ static void neigh_timer_handler(unsigned long arg); static void __neigh_notify(struct neighbour *n, int type, int flags); static void neigh_update_notify(struct neighbour *neigh); static int pneigh_ifdown(struct neigh_table *tbl, struct net_device *dev); -void neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev); static struct neigh_table *neigh_tables; #ifdef CONFIG_PROC_FS -- 1.5.3.rc5 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8 net-2.6.25] [IPV4] fib_rules_unregister is essentially void.
fib_rules_unregister is called only after successful register and the return
code is never checked.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
---
include/net/fib_rules.h |2 +-
net/core/fib_rules.c| 21 -
2 files changed, 5 insertions(+), 18 deletions(-)
diff --git a/include/net/fib_rules.h b/include/net/fib_rules.h
index 88f870f..34349f9 100644
--- a/include/net/fib_rules.h
+++ b/include/net/fib_rules.h
@@ -104,7 +104,7 @@ static inline u32 frh_get_table(struct fib_rule_hdr *frh,
struct nlattr **nla)
}
extern int fib_rules_register(struct net *, struct fib_rules_ops *);
-extern int fib_rules_unregister(struct net *, struct fib_rules_ops *);
+extern void fib_rules_unregister(struct net *, struct fib_rules_ops *);
extern void fib_rules_cleanup_ops(struct fib_rules_ops *);
extern int fib_rules_lookup(struct fib_rules_ops *,
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index 0eecf4c..42ccaf5 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -115,29 +115,16 @@ void fib_rules_cleanup_ops(struct fib_rules_ops *ops)
}
EXPORT_SYMBOL_GPL(fib_rules_cleanup_ops);
-int fib_rules_unregister(struct net *net, struct fib_rules_ops *ops)
+void fib_rules_unregister(struct net *net, struct fib_rules_ops *ops)
{
- int err = 0;
- struct fib_rules_ops *o;
spin_lock(&net->rules_mod_lock);
- list_for_each_entry(o, &net->rules_ops, list) {
- if (o == ops) {
- list_del_rcu(&o->list);
- fib_rules_cleanup_ops(ops);
- goto out;
- }
- }
-
- err = -ENOENT;
-out:
+ list_del_rcu(&ops->list);
+ fib_rules_cleanup_ops(ops);
spin_unlock(&net->rules_mod_lock);
synchronize_rcu();
- if (!err)
- release_net(net);
-
- return err;
+ release_net(net);
}
EXPORT_SYMBOL_GPL(fib_rules_unregister);
--
1.5.3.rc5
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8 net-2.6.25] [NETNS] Process inet_confirm_addr in the correct namespace.
inet_confirm_addr can be called with NULL in_dev from arp_ignore iff
scope is RT_SCOPE_LINK.
Lets always pass the device and check for RT_SCOPE_LINK scope inside
inet_confirm_addr. This let us take network namespace from in_device a
need for an additional argument.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
---
net/ipv4/arp.c |1 -
net/ipv4/devinet.c |6 --
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index f38e1a9..b715ec0 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -402,7 +400,6 @@ static int arp_ignore(struct in_device *in_dev, __be32 sip,
__be32 tip)
case 3: /* Do not reply for scope host addresses */
sip = 0;
scope = RT_SCOPE_LINK;
- in_dev = NULL;
break;
case 4: /* Reserved */
case 5:
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index dc1665a..4569c69 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -978,13 +978,15 @@ __be32 inet_confirm_addr(struct in_device *in_dev,
{
__be32 addr = 0;
struct net_device *dev;
+ struct net *net;
- if (in_dev != NULL)
+ if (scope != RT_SCOPE_LINK)
return confirm_addr_indev(in_dev, dst, local, scope);
+ net = in_dev->dev->nd_net;
read_lock(&dev_base_lock);
rcu_read_lock();
- for_each_netdev(&init_net, dev) {
+ for_each_netdev(net, dev) {
if ((in_dev = __in_dev_get_rcu(dev))) {
addr = confirm_addr_indev(in_dev, dst, local, scope);
if (addr)
--
1.5.3.rc5
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8 net-2.6.25] [ARP] neigh_parms_put(destroy) are essentially local to core/neighbour.c.
Make them static.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
---
include/net/neighbour.h |7 ---
net/core/neighbour.c| 11 ++-
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index a0d42a5..ebbfb50 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -213,7 +213,6 @@ extern struct neighbour *neigh_event_ns(struct
neigh_table *tbl,
extern struct neigh_parms *neigh_parms_alloc(struct net_device *dev,
struct neigh_table *tbl);
extern voidneigh_parms_release(struct neigh_table *tbl,
struct neigh_parms *parms);
-extern voidneigh_parms_destroy(struct neigh_parms *parms);
extern unsigned long neigh_rand_reach_time(unsigned long base);
extern voidpneigh_enqueue(struct neigh_table *tbl, struct
neigh_parms *p,
@@ -254,12 +253,6 @@ static inline void __neigh_parms_put(struct neigh_parms
*parms)
atomic_dec(&parms->refcnt);
}
-static inline void neigh_parms_put(struct neigh_parms *parms)
-{
- if (atomic_dec_and_test(&parms->refcnt))
- neigh_parms_destroy(parms);
-}
-
static inline struct neigh_parms *neigh_parms_clone(struct neigh_parms *parms)
{
atomic_inc(&parms->refcnt);
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 9b0b773..41394db 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -55,6 +55,8 @@
#define PNEIGH_HASHMASK0xF
+static inline void neigh_parms_put(struct neigh_parms *parms);
+
static void neigh_timer_handler(unsigned long arg);
static void __neigh_notify(struct neighbour *n, int type, int flags);
static void neigh_update_notify(struct neighbour *neigh);
@@ -1348,7 +1350,7 @@ void neigh_parms_release(struct neigh_table *tbl, struct
neigh_parms *parms)
NEIGH_PRINTK1("neigh_parms_release: not found\n");
}
-void neigh_parms_destroy(struct neigh_parms *parms)
+static void neigh_parms_destroy(struct neigh_parms *parms)
{
release_net(parms->net);
if (parms->dev)
@@ -1356,6 +1358,13 @@ void neigh_parms_destroy(struct neigh_parms *parms)
kfree(parms);
}
+static inline void neigh_parms_put(struct neigh_parms *parms)
+{
+ if (atomic_dec_and_test(&parms->refcnt))
+ neigh_parms_destroy(parms);
+}
+
+
static struct lock_class_key neigh_table_proxy_queue_class;
void neigh_table_init_no_netlink(struct neigh_table *tbl)
--
1.5.3.rc5
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8 net-2.6.25] [IPV4] Remove extra argument from arp_ignore.
arp_ignore has two arguments: dev & in_dev. dev is used for inet_confirm_addr
calling only.
inet_confirm_addr, in turn, either gets in_dev from the device passed or
iterates over all network devices if the device passed is NULL. It seems
logical to directly pass in_dev into inet_confirm_addr.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
---
include/linux/inetdevice.h |2 +-
net/ipv4/arp.c | 11 +--
net/ipv4/devinet.c | 17 ++---
3 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index b3c5081..45f3731 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -135,7 +135,7 @@ extern int devinet_ioctl(unsigned int cmd, void
__user *);
extern voiddevinet_init(void);
extern struct in_device*inetdev_by_index(int);
extern __be32 inet_select_addr(const struct net_device *dev, __be32
dst, int scope);
-extern __be32 inet_confirm_addr(const struct net_device *dev, __be32
dst, __be32 local, int scope);
+extern __be32 inet_confirm_addr(struct in_device *in_dev, __be32 dst,
__be32 local, int scope);
extern struct in_ifaddr *inet_ifa_byprefix(struct in_device *in_dev, __be32
prefix, __be32 mask);
static __inline__ int inet_ifa_match(__be32 addr, struct in_ifaddr *ifa)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index e944d98..f38e1a9 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -382,8 +382,7 @@ static void arp_solicit(struct neighbour *neigh, struct
sk_buff *skb)
read_unlock_bh(&neigh->lock);
}
-static int arp_ignore(struct in_device *in_dev, struct net_device *dev,
- __be32 sip, __be32 tip)
+static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
{
int scope;
@@ -403,7 +402,7 @@ static int arp_ignore(struct in_device *in_dev, struct
net_device *dev,
case 3: /* Do not reply for scope host addresses */
sip = 0;
scope = RT_SCOPE_LINK;
- dev = NULL;
+ in_dev = NULL;
break;
case 4: /* Reserved */
case 5:
@@ -415,7 +414,7 @@ static int arp_ignore(struct in_device *in_dev, struct
net_device *dev,
default:
return 0;
}
- return !inet_confirm_addr(dev, sip, tip, scope);
+ return !inet_confirm_addr(in_dev, sip, tip, scope);
}
static int arp_filter(__be32 sip, __be32 tip, struct net_device *dev)
@@ -807,7 +806,7 @@ static int arp_process(struct sk_buff *skb)
if (sip == 0) {
if (arp->ar_op == htons(ARPOP_REQUEST) &&
inet_addr_type(&init_net, tip) == RTN_LOCAL &&
- !arp_ignore(in_dev,dev,sip,tip))
+ !arp_ignore(in_dev, sip, tip))
arp_send(ARPOP_REPLY, ETH_P_ARP, sip, dev, tip, sha,
dev->dev_addr, sha);
goto out;
@@ -825,7 +824,7 @@ static int arp_process(struct sk_buff *skb)
int dont_send = 0;
if (!dont_send)
- dont_send |=
arp_ignore(in_dev,dev,sip,tip);
+ dont_send |= arp_ignore(in_dev,sip,tip);
if (!dont_send && IN_DEV_ARPFILTER(in_dev))
dont_send |= arp_filter(sip,tip,dev);
if (!dont_send)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 03db15b..dc1665a 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -968,24 +968,19 @@ static __be32 confirm_addr_indev(struct in_device
*in_dev, __be32 dst,
/*
* Confirm that local IP address exists using wildcards:
- * - dev: only on this interface, 0=any interface
+ * - in_dev: only on this interface, 0=any interface
* - dst: only in the same subnet as dst, 0=any dst
* - local: address, 0=autoselect the local address
* - scope: maximum allowed scope value for the local address
*/
-__be32 inet_confirm_addr(const struct net_device *dev, __be32 dst, __be32
local, int scope)
+__be32 inet_confirm_addr(struct in_device *in_dev,
+__be32 dst, __be32 local, int scope)
{
__be32 addr = 0;
- struct in_device *in_dev;
-
- if (dev) {
- rcu_read_lock();
- if ((in_dev = __in_dev_get_rcu(dev)))
- addr = confirm_addr_indev(in_dev, dst, local, scope);
- rcu_read_unlock();
+ struct net_device *dev;
- return addr;
- }
+ if (in_dev != NULL)
+ return confirm_addr_indev(in_dev, dst, local, scope);
read_lock(&dev_base_lock);
rcu_read_lock();
--
1.5.3.rc5
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[PATCH 1/8 net-2.6.25] [ARP] Move inet_addr_type call after simple error checks in arp_contructor.
The neighbour entry will be destroyed in the case of error, so it is pointless
to perform constly routing table lookup in this case.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
---
net/ipv4/arp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index b715ec0..49c24ff 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -235,8 +235,6 @@ static int arp_constructor(struct neighbour *neigh)
struct in_device *in_dev;
struct neigh_parms *parms;
- neigh->type = inet_addr_type(&init_net, addr);
-
rcu_read_lock();
in_dev = __in_dev_get_rcu(dev);
if (in_dev == NULL) {
@@ -244,6 +242,8 @@ static int arp_constructor(struct neighbour *neigh)
return -EINVAL;
}
+ neigh->type = inet_addr_type(&init_net, addr);
+
parms = in_dev->arp_parms;
__neigh_parms_put(neigh->parms);
neigh->parms = neigh_parms_clone(parms);
--
1.5.3.rc5
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8 net-2.6.25] [ARP] Remove overkill checks from neigh_param_alloc.
Valid network device is always passed into neigh_param_alloc, so remove
extra checking for dev == NULL. Additionally, cleanup bogus netns assignment.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
net/core/neighbour.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index af49137..32f1a23 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1301,10 +1301,7 @@ struct neigh_parms *neigh_parms_alloc(struct net_device
*dev,
struct neigh_parms *p, *ref;
struct net *net;
- net = &init_net;
- if (dev)
- net = dev->nd_net;
-
+ net = dev->nd_net;
ref = lookup_neigh_params(tbl, net, 0);
if (!ref)
return NULL;
@@ -1316,15 +1313,14 @@ struct neigh_parms *neigh_parms_alloc(struct net_device
*dev,
INIT_RCU_HEAD(&p->rcu_head);
p->reachable_time =
neigh_rand_reach_time(p->base_reachable_time);
- if (dev) {
- if (dev->neigh_setup && dev->neigh_setup(dev, p)) {
- kfree(p);
- return NULL;
- }
- dev_hold(dev);
- p->dev = dev;
+ if (dev->neigh_setup && dev->neigh_setup(dev, p)) {
+ kfree(p);
+ return NULL;
}
+
+ dev_hold(dev);
+ p->dev = dev;
p->net = hold_net(net);
p->sysctl_table = NULL;
write_lock_bh(&tbl->lock);
--
1.5.3.rc5
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: questions on NAPI processing latency and dropped network packets
Ray Lee wrote: On Jan 10, 2008 9:24 AM, Chris Friesen <[EMAIL PROTECTED]> wrote: After a recent userspace app change, we've started seeing packets being dropped by the ethernet hardware (e1000, NAPI is enabled). The error/dropped/fifo counts are going up in ethtool: Can you reproduce it with a simple userspace cpu hog? (Two, really, one per cpu.) Can you reproduce it with the newer e1000? Hmm...good questions and I haven't checked either. The first one is relatively straightforward. The second is a bit trickier...last time I tried the latest e1000 driver the card wouldn't boot (we use netboot). Can you reproduce it with git head? Unfortunately, I don't think I'll be able to try this. We require kernel mods for our userspace to run, and I doubt I'd be able to get the time to port all the changes forward to git head. If the answer to the first one is yes, the last no, then bisect until you get a kernel that doesn't show the problem. Backport the fix, unless the fix happens to be CFS. However, I suspect that your userpace app is just starving the system from time to time. It's conceivable that userspace is starving the kernel, but we have do about 45% idle on one cpu, and 7-10% idle on the other. We also have an odd situation where on an initial test run after bootup we have 18-24% idle on cpu1, but resetting the test tool drops that to the 7-10% I mentioned above. Based on profiling and instrumentation it seems like the cost of sctp_endpoint_lookup_assoc() more than triples, which means that the amount of time that bottom halves are disabled in that function also triples. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8 2.6.25] a set of small code cleanups
This set contains a set of small improvements found in IPv4 code during preparations to support ARP in the network namespace. These fixes are mostly independent except 2 last ones. Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: questions on NAPI processing latency and dropped network packets
David Miller wrote: From: "Chris Friesen" <[EMAIL PROTECTED]> Date: Fri, 11 Jan 2008 08:59:26 -0600 I'd love to work on newer kernels, but we have a commitment to our customers to support multiple releases for a significant amount of time. And by asking here for people to dig into it for you, you are asking people for free help providing that support. I'm not asking people to spend significant amounts of time...more like if anyone has any ideas "off the top of their heads". That's why there is such negative backlash to asking questions about such ancient kernel here, you're asking us to do your work, for free. I hadn't realized that you felt this strongly about asking questions regarding old kernels. How close to bleeding edge do we need to be for it to be considered acceptable to ask questions on netdev? Given that the embedded space tends to be perpetually stuck on older kernels (our "current" release is based on 2.6.14) do you have any suggestion on how we can obtain information that would be available on netdev if we were using newer kernels? Chris -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Sun, 13 Jan 2008 02:35:33 EST, [EMAIL PROTECTED] said: > I'm seeing problems with Sendmail on 24-rc6-mm1, where the main Sendmail is > listening on ::1/25, and Fetchmail connects to 127.0.0.1:25 to inject mail it > has just fetched from an outside server via IMAP - it will often just hang and > not make any further progress. Looking at netstat shows something interesting: > > % netstat -n -a -A inet | grep 25 > tcp0 5108 127.0.0.1:59355 127.0.0.1:25 > ESTABLISHED The IPv6 is apparently a red herring - this morning I'm seeing the same problem with another totally separate pair of programs that are IPv4-only, hanging on loopback. pgpCt449rgEtt.pgp Description: PGP signature
Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
On Sun, 13 Jan 2008 11:27:12 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Sun, 13 Jan 2008 16:08:38 +0100 supersud501 <[EMAIL PROTECTED]> wrote: > > > > > > > supersud501 wrote: > > > > > > > > > Rafael J. Wysocki wrote: > > > > > >> > > >> Since it seems to be 100% reproducible, it would be very helpful if > > >> you could > > >> use git-bisect to identify the offending commit. > > >> > > > > > > allright, bisect found the offending commit, here's what i've done: > > > > > > first i started bisect with the following command (since i assumed it is > > > a net-driver problem): > > > > > > git-bisect start 'v2.6.24-rc6' 'v2.6.23' '--' 'drivers/net/' > > > > > > after building many kernels and saying good/bad if wol worked/didn't > > > work etc. it identified the following commit: > > > > > > # bad: [ac93a3946b676025fa55356180e8321639744b31] sky2: enable PCI > > > config writes > > > > > > and refs/bisect/bad gives: > > > > > > 14:16:53 /usr/src/linux-2.6/.git # cat refs/bisect/bad > > > ac93a3946b676025fa55356180e8321639744b31 > > > > > > > > > need some more info? > > > > > > > i just checked it: commented out the passage of the commit in kernel > > 2.6.24-rc7-git4 and compiled it: wol WORKS. so this one line is causing > > my wol-disturbance... > > > > > > So simply reverting this: > > commit ac93a3946b676025fa55356180e8321639744b31 > Author: Stephen Hemminger <[EMAIL PROTECTED]> > Date: Mon Nov 5 15:52:08 2007 -0800 > > sky2: enable PCI config writes > > On some boards, PCI configuration space access is turned off by default. > The 2.6.24 driver doesn't turn it on, and should have. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> > Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> > > diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c > index c27c7d6..4f41a94 100644 > --- a/drivers/net/sky2.c > +++ b/drivers/net/sky2.c > @@ -2791,6 +2791,9 @@ static void sky2_reset(struct sky2_hw *hw) > sky2_write8(hw, B0_CTST, CS_RST_SET); > sky2_write8(hw, B0_CTST, CS_RST_CLR); > > + /* allow writes to PCI config */ > + sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON); > + > /* clear PCI errors, if any */ > pci_read_config_word(pdev, PCI_STATUS, &status); > status |= PCI_STATUS_ERROR_BITS; > > fixes this regression? > > If so, we should revert that change. > > > but i noticed another "bug" on 2.6.24-rc7-git with sky2: dmesg shows a > > lot of lines every 5 seconds: > > > > [...] > > [ 357.400462] sky2 :02:00.0: error interrupt status=0xc000 > > [ 362.442039] printk: 41 messages suppressed. > > [ 362.442043] sky2 :02:00.0: error interrupt status=0x8000 > > [ 367.439151] printk: 18 messages suppressed. > > [ 367.439156] sky2 :02:00.0: error interrupt status=0x8000 > > [ 372.436267] printk: 30 messages suppressed. > > [ 372.436271] sky2 :02:00.0: error interrupt status=0x8000 > > [ 377.350236] printk: 19 messages suppressed. > > [...] > > > > since i do not notice any errors (yet) i'll wait till next rc, maybe it > > will be gone then... > > That's not good. is this new behaviour? > No, reverting that change will break other systems (including mine). -- Stephen Hemminger <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Monday 14 January 2008 11:15:38 am [EMAIL PROTECTED] wrote: > On Sun, 13 Jan 2008 02:35:33 EST, [EMAIL PROTECTED] said: > > I'm seeing problems with Sendmail on 24-rc6-mm1, where the main Sendmail > > is listening on ::1/25, and Fetchmail connects to 127.0.0.1:25 to inject > > mail it has just fetched from an outside server via IMAP - it will often > > just hang and not make any further progress. Looking at netstat shows > > something interesting: > > > > % netstat -n -a -A inet | grep 25 > > tcp0 5108 127.0.0.1:59355 127.0.0.1:25 > > ESTABLISHED > > The IPv6 is apparently a red herring - this morning I'm seeing the same > problem with another totally separate pair of programs that are IPv4-only, > hanging on loopback. Are you still only seeing these problems on loopback? I can't help but wonder if this is the skb_clone() problem where it wasn't copying skb->iif causing SELinux to silently drop the packets. Then again, I'm not sure if there is a clone operation in the code path are going down. From what I can remember I only saw clones on some of the multicast stuff but I'm still learning some of the darker corners of the stack. If you've got some spare cycles, the kernel below should both have the clone/iif fix (it's in Linus' tree now) as well as some printks when errors occur so packet's are no longer silently dropped by SELinux. * git://git.infradead.org/users/pcmoore/lblnet-2.6_testing -- paul moore linux security @ hp -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] get rid of unused revision element
On Mon, 14 Jan 2008 04:06:57 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: > From: Robert Olsson <[EMAIL PROTECTED]> > Date: Mon, 14 Jan 2008 12:44:32 +0100 > > > The idea was to have a selective flush of route cache entries when > > a fib insert/delete happened. From what I remember you added another/ > > better solution. Just a list with route cache entries pointing to parent > > route. So yes this was obsoleted by your/our effort to avoid total > > flushing of the route cache. Unfinished work. > > Yes, that's right. The synchronization was very hard. > > But there is another issue, see below > > > According to http://bgpupdates.potaroo.net/instability/bgpupd.html > > (last in page) we currently flush the route cache 2.80 times per second. > > when using full Internet routing with Linux. Maybe we're forced to pick > > up this thread again someday. > > This proves we need to solve this problem. > > The reason I've never gone back to that work is that I didn't > want to do it while we still had multiple FIB data structure > implementations. > > Someone needs to go over whatever deficiencies exist in fib_trie > vs. fib_hash so that we can delete fib_hash and move over to using > fib_trie always. It makes no sense to implement everything > interfacing into that code twice. > > There was a full consensus that this was the way to move forward, > we just need the dirty work to be done. > > If someone wants to show their gratitude for my getting rid of > the multipath cached routing code, the above work would be a > great way to do so (hint hint) :-) I will be glad to get this working. Is there any point in doing the a small systems version as well? -- Stephen Hemminger <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconf at conf.au 2008?
also sprach YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> [2008.01.14.1206 +0100]: > Very confusing to me... FYI: http://lists.alioth.debian.org/pipermail/netconf-devel/2008-January/000214.html However, I am not entirely convinced. I think conference/tool/protocol are far apart enough so that the name does not clash. -- martin | http://madduck.net/ | http://two.sentenc.es/ "perhaps debian is concerned more about technical excellence rather than ease of use by breaking software. in the former we may excel. in the latter we have to concede the field to microsoft. guess where i want to go today?" -- manoj srivastava spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: questions on NAPI processing latency and dropped network packets
Chris Friesen a écrit : Ray Lee wrote: On Jan 10, 2008 9:24 AM, Chris Friesen <[EMAIL PROTECTED]> wrote: After a recent userspace app change, we've started seeing packets being dropped by the ethernet hardware (e1000, NAPI is enabled). The error/dropped/fifo counts are going up in ethtool: Can you reproduce it with a simple userspace cpu hog? (Two, really, one per cpu.) Can you reproduce it with the newer e1000? Hmm...good questions and I haven't checked either. The first one is relatively straightforward. The second is a bit trickier...last time I tried the latest e1000 driver the card wouldn't boot (we use netboot). Can you reproduce it with git head? Unfortunately, I don't think I'll be able to try this. We require kernel mods for our userspace to run, and I doubt I'd be able to get the time to port all the changes forward to git head. If the answer to the first one is yes, the last no, then bisect until you get a kernel that doesn't show the problem. Backport the fix, unless the fix happens to be CFS. However, I suspect that your userpace app is just starving the system from time to time. It's conceivable that userspace is starving the kernel, but we have do about 45% idle on one cpu, and 7-10% idle on the other. We also have an odd situation where on an initial test run after bootup we have 18-24% idle on cpu1, but resetting the test tool drops that to the 7-10% I mentioned above. Based on profiling and instrumentation it seems like the cost of sctp_endpoint_lookup_assoc() more than triples, which means that the amount of time that bottom halves are disabled in that function also triples. Any idea of the size of sctp hash size you have ? (your dmesg probably includes a message starting with SCTP: Hash tables configured... How many concurrent sctp sockets are handled ? Maybe sctp_assoc_hashfn() is too weak for your use, and some chains are *really* long. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
occasionally corrupted network stats in /proc/net/dev
I had posted the following on linux-net and haven't see any responses possibly because nobody had any or that list is obsolete. I have been told this is the current list for everything networking on linux so I thought I'd try again... I suspect the answer will be that it is what it is, but here's the deal. I have a tool I use for monitoring network traffic among other things - see http://collectl.sourceforge.net/ - and one of its benefits is that you can run it continuously as a daemon (similar to sar) and generate data in a format suitable for plotting. This means that you can automate your entire network monitoring infrastructure at fairly fine granularity, down to second if you like. Actually 1-second level monitoring will provide incorrect data on earlier kernels because the stats aren't updated on 1 second boundaries and you need to monitor at an interval of 0.9765 seconds, but that's a different story which is explained at http://collectl.sourceforge.net/NetworkStats.html But more importantly, I've found that occasionally (not that often) there is bogus data reported from /proc/net/dev. While I don't have a lot of details on this it seems to only show up in 64 bit kernels. Look at the following samples taken at 1 second intervals: eth0:135115809 1024897000 0 0 9 135458926 910340000 0 0 0 eth0:135118023 1024923000 0 0 9 135460952 910363000 0 0 0 eth0:0 884620000 0 0909397 9687563 1049736000 0 0 0 eth0:135121189 1024957000 0 0 9 135464222 910400000 0 0 0 eth0:135129565 1024995000 0 0 9 135473687 910435000 0 0 0 see the middle sample? When I look at the change between samples it generates a really big number since the difference is assumed to be caused a counter wrapping. The problem is it's not always straightforward when there is bad data. For example if the original and bogus values are close enough it's not even clear there is a problem. So the obvious question is, is there any way to prevent the bogus data from getting reported? If not, is there any way to set the values to something to indicate that the correct values can't be determined? Clearly this problem would be visible to any tool that looks at /proc but since many tools are not automated or don't take it to the level I do, nobody probably notices. As for the counter update frequency, even though they now appear to be updated closer to a 1 second boundary it also means tools that can monitor at sub-second intervals will report incorrect data since the counters only change once a second. -mark -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] synchronize_rcu(): high latency on idle system
On Sun, 13 Jan 2008 16:34:17 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > I think it should be in netdev_unregister_kobject(). But that would
> > only get rid of one of the two calls to synchronize_rcu() in the
> > unregister_netdev.
>
> Would be already an improvement.
>
> > The other synchronize_rcu() is for qdisc's and not sure if that one can
> > be removed?
>
> The standard way to remove such calls is to set a "deleted" flag in the
> object,
> then check and ignore such objects in the reader and finally remove the
> object with
> call_rcu
>
> I have not checked if that is really feasible for qdiscs.
>
> -Andi
Actually, the synchronize_rcu() is now acting a barrier between two sections
in the current unregister process. It can't be removed.
But, an alternative unregister_and_free_netdev() could be created that uses
call_rcu. Basically:
void unregistr_and_free_netdev() {
do stuff before barrier...
setup rcu callback
call_rcu();
}
static void netdev_after_rcu() {
rtnl_lock();
do stuff after barier
rtnl_unlock();
free_netdev
}
--
Stephen Hemminger <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netperf TCP_RR(loopback) 10% regression in 2.6.24-rc6, comparing with 2.6.22
*) netperf/netserver support CPU affinity within themselves with the global -T option to netperf. Is the result with taskset much different? The equivalent to the above would be to run netperf with: ./netperf -T 0,7 .. I checked the source codes and didn't find this option. I use netperf V2.3 (I found the number in the makefile). Indeed, that version pre-dates the -T option. If you weren't already chasing a regression I'd suggest an upgrade to 2.4.mumble. Once you are at a point where changing another variable won't muddle things you may want to consider upgrading. happy benchmarking, rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
On Thu, 10 Jan 2008 21:41:20 -0700 "Aggrwal Poonam" <[EMAIL PROTECTED]> wrote: > Hello All > > I am waiting for more feedback on the patches. > > If there are no objections please consider them for 2.6.25. > if this isn't going to go through Alessandro Rubini/misc drivers, can it go through the akpm/mm tree? Kim -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Mon, 14 Jan 2008 11:36:40 EST, Paul Moore said: > Are you still only seeing these problems on loopback? I can't help but > wonder > if this is the skb_clone() problem where it wasn't copying skb->iif causing > SELinux to silently drop the packets. Yes, I've only spotted it on loopback. The odd part is that I had reverted the one commit 9c6ad8f6895db7a517c04c2147cb5e7ffb83a315 "Convert the netif code to use ifindex values" - so either I managed to get the revert terribly wrong, or there's something else odd going on. The first time around, I was seeing hangs during a TCP 3-packet handshake - this time data flows for some number of packets before hanging. I'm pulling git://git.infradead.org/users/pcmoore/lblnet-2.6_testing at the moment, and seeing if there's already a fix in there for this. pgpK6KMHMPqiW.pgp Description: PGP signature
Re: occasionally corrupted network stats in /proc/net/dev
Mark Seger wrote: I had posted the following on linux-net and haven't see any responses possibly because nobody had any or that list is obsolete. I have been told this is the current list for everything networking on linux so I thought I'd try again... Do you see this with multiple network drivers, or just with one particular driver. If so, which one? Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Mon, 14 Jan 2008 13:05:48 EST, [EMAIL PROTECTED] said: > I'm pulling git://git.infradead.org/users/pcmoore/lblnet-2.6_testing at the > moment, and seeing if there's already a fix in there for this. Apparently the only new commit in there since the tree that was in 24-rc6-mm1 is 5d95575903fd3865b884952bd93c339d48725c33 adding some warning printk's. Would it be more productive to test against the full tree, or leaving out the one commit I already reverted? pgptYAqhsxkEy.pgp Description: PGP signature
Re: [patch 5/7] netxen: fix race in interrupt / napi
Ok, I will respin the failed patches. Thanks, -Dhananjay On Sat, 12 Jan 2008, Jeff Garzik wrote: > patch conflicted with > > commit 1706287f6eb58726a9a0e5cbbde87f49757615e3 > Author: David S. Miller <[EMAIL PROTECTED]> > Date: Mon Jan 7 20:51:29 2008 -0800 > > [NETXEN]: Fix ->poll() done logic. > > If work_done >= budget we should always elide the NAPI > completion. > > Signed-off-by: David S. Miller <[EMAIL PROTECTED]> > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] fix sparse warnings
Eric Dumazet writes: > > Thats 231173/241649 = 96% with the current Internet routing. > > > > How about if would have a fastpath and store one entry direct in the > > leaf struct this to avoid loading the leaf_info list in most cases? > > > > One could believe that both lookup and dump could improve. > > > You mean to include one "leaf_info" inside leaf structure, so that we > can access it without cache line miss ? Yes. Cheers --ro -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFT] sky2: wake-on-lan configuration issues
Please test this patch against Linus's current (approx 2.6.24-rc7-git5).
Ignore Andrew's premature reversion attempt...
This patch disables config mode access after clearing PCI settings.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.c2008-01-14 09:44:22.0 -0800
+++ b/drivers/net/sky2.c2008-01-14 09:44:51.0 -0800
@@ -621,6 +621,7 @@ static void sky2_phy_power(struct sky2_h
static const u32 phy_power[] = { PCI_Y2_PHY1_POWD, PCI_Y2_PHY2_POWD };
static const u32 coma_mode[] = { PCI_Y2_PHY1_COMA, PCI_Y2_PHY2_COMA };
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
/* Turn on/off phy power saving */
if (onoff)
@@ -632,7 +633,8 @@ static void sky2_phy_power(struct sky2_h
reg1 |= coma_mode[port];
sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
- reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
+ sky2_pci_read32(hw, PCI_DEV_REG1);
udelay(100);
}
@@ -2426,6 +2428,7 @@ static void sky2_hw_intr(struct sky2_hw
if (status & (Y2_IS_MST_ERR | Y2_IS_IRQ_STAT)) {
u16 pci_err;
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
pci_err = sky2_pci_read16(hw, PCI_STATUS);
if (net_ratelimit())
dev_err(&pdev->dev, "PCI hardware error (0x%x)\n",
@@ -2433,12 +2436,14 @@ static void sky2_hw_intr(struct sky2_hw
sky2_pci_write16(hw, PCI_STATUS,
pci_err | PCI_STATUS_ERROR_BITS);
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
}
if (status & Y2_IS_PCI_EXP) {
/* PCI-Express uncorrectable Error occurred */
u32 err;
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
err = sky2_read32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS);
sky2_write32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS,
0xul);
@@ -2446,6 +2451,7 @@ static void sky2_hw_intr(struct sky2_hw
dev_err(&pdev->dev, "PCI Express error (0x%x)\n", err);
sky2_read32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS);
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
}
if (status & Y2_HWE_L1_MASK)
@@ -2811,6 +2817,7 @@ static void sky2_reset(struct sky2_hw *h
}
sky2_power_on(hw);
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
for (i = 0; i < hw->ports; i++) {
sky2_write8(hw, SK_REG(i, GMAC_LINK_CTRL), GMLC_RST_SET);
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.23+] ingress classify to [nf]mark
jamal wrote: May be I am mix in mind other code (multi-class loop/walking) and this code. I am deprogramming... ;) Sorry, I just change focus from existing "tc_index=..." to common behaviour ;) [...] Please refer to what i said above; if what i said still doesnt make sense i can create (the simple) patch. A bit vague... sorry... I mean: #ifdef CONFIG_NET_CLS_ACT leave this part alone which already sets tc_index ... #else ...set tc_index and mark here ... #endif And when we have a metadata action - we remove setting of tc_index from #ifdef CONFIG_NET_CLS_ACT Did that make sense? After current "#endif" - may be. What "result" are with: 1) no filters? 2) 1 filter only, with "action continue"? -- WBR, Denis Kaganovich, [EMAIL PROTECTED] http://mahatma.bspu.unibel.by -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: occasionally corrupted network stats in /proc/net/dev
I'll try to get data on the other systems reporting it and as I said it does not happen all that often AND you have to be looking for it. The system I've personally seen it happen on several times is running RHEL4/U4 which redhat numbers 2.6.9-42 and from modinfo I see: version:7.0.33-k2-NAPI 51E97FEE51D0772AFC89130 description:Intel(R) PRO/1000 Network Driver -mark Ben Greear wrote: Mark Seger wrote: I had posted the following on linux-net and haven't see any responses possibly because nobody had any or that list is obsolete. I have been told this is the current list for everything networking on linux so I thought I'd try again... Do you see this with multiple network drivers, or just with one particular driver. If so, which one? Thanks, Ben -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: occasionally corrupted network stats in /proc/net/dev
Ignore that last one as it was pointed out to me that we have both nic installed on many of our systems and ethtool told me the one associated with the nic is actually the broadcom one. version:1.4.38 E1B1EC867DEEB8027B2DA0F license:GPL description:Broadcom NetXtreme II BCM5706/5708 Driver -mark Mark Seger wrote: I'll try to get data on the other systems reporting it and as I said it does not happen all that often AND you have to be looking for it. The system I've personally seen it happen on several times is running RHEL4/U4 which redhat numbers 2.6.9-42 and from modinfo I see: version:7.0.33-k2-NAPI 51E97FEE51D0772AFC89130 description:Intel(R) PRO/1000 Network Driver -mark Ben Greear wrote: Mark Seger wrote: I had posted the following on linux-net and haven't see any responses possibly because nobody had any or that list is obsolete. I have been told this is the current list for everything networking on linux so I thought I'd try again... Do you see this with multiple network drivers, or just with one particular driver. If so, which one? Thanks, Ben -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][v2] phylib: add module owner to the mii_bus structure
On Dec 28, 2007, at 11:31, Ionut Nicu wrote:
Prevent unloading mii bus driver module when other modules have
references to some
phydevs on that bus. Added a new member (module owner) to struct
mii_bus and added
code to increment the mii bus owner module usage count on
phy_connect and decrement
it on phy_disconnect
Set the module owner in the ucc_geth_mdio driver.
Signed-off-by: Ionut Nicu <[EMAIL PROTECTED]>
Tested-by: Emil Medve <[EMAIL PROTECTED]>
---
drivers/net/phy/phy_device.c |9 -
drivers/net/ucc_geth_mii.c |3 +++
diff --git a/drivers/net/ucc_geth_mii.c b/drivers/net/ucc_geth_mii.c
index a3af4ea..84c7295 100644
--- a/drivers/net/ucc_geth_mii.c
+++ b/drivers/net/ucc_geth_mii.c
@@ -217,6 +217,9 @@ static int uec_mdio_probe(struct of_device
*ofdev, const struct of_device_id *ma
}
}
+ /* register ourselves as the owner of this bus */
+ new_bus->owner = THIS_MODULE;
+
err = mdiobus_register(new_bus);
if (0 != err) {
printk(KERN_ERR "%s: Cannot register as MDIO bus\n",
Any reason you didn't update the other drivers?
> git grep mdiobus_register drivers/net/ // duplicates and
mdio_bus.c edited out
drivers/net/au1000_eth.c: mdiobus_register(&aup->mii_bus);
drivers/net/bfin_mac.c: mdiobus_register(&lp->mii_bus);
drivers/net/cpmac.c:res = mdiobus_register(&cpmac_mii);
drivers/net/fec_mpc52xx_phy.c: err = mdiobus_register(bus);
drivers/net/fs_enet/mii-bitbang.c: ret = mdiobus_register(new_bus);
drivers/net/fs_enet/mii-fec.c: ret = mdiobus_register(new_bus);
drivers/net/gianfar_mii.c: err = mdiobus_register(new_bus);
drivers/net/macb.c: if (mdiobus_register(&bp->mii_bus))
drivers/net/sb1250-mac.c: err = mdiobus_register(&sc->mii_bus);
drivers/net/ucc_geth_mii.c: err = mdiobus_register(new_bus);
I'm guessing this was only tested on the UEC, because unless I
misunderstand the code, any other driver would now crash when you try
to get the owner.
Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] fix sparse warnings
Robert Olsson a écrit : Thanks for hacking and improving and the trie... another idea that could be also tested. If we look into routing table we see that most leafs only has one prefix Main: Aver depth: 2.57 Max depth: 7 Leaves: 231173 ip route | wc -l 241649 Thats 231173/241649 = 96% with the current Internet routing. How about if would have a fastpath and store one entry direct in the leaf struct this to avoid loading the leaf_info list in most cases? One could believe that both lookup and dump could improve. You mean to include one "leaf_info" inside leaf structure, so that we can access it without cache line miss ? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Mon, 14 Jan 2008 13:22:10 EST, [EMAIL PROTECTED] said: > Apparently the only new commit in there since the tree that was in > 24-rc6-mm1 is 5d95575903fd3865b884952bd93c339d48725c33 adding some warning > printk's. Would it be more productive to test against the full tree, or > leaving out the one commit I already reverted? Nevermind... :) The new commit won't apply with the other one reverted - it patches security/selinux/netnode.c which was created by the problematic commit... pgpyVRuWWhuHY.pgp Description: PGP signature
Re: [PATCH]drivers/net/phy/: default return value in ioctl phy.c
On Dec 11, 2007, at 09:02, Rini van Zetten wrote: Hello Andy, This patch (to 2.6.23.9) add a default return value EOPNOTSUPP to the ioctl function. The problem with the always 0 return value is that the iwconfig (wireless) tool found a valid device when an ethernet device uses the phy abstraction layer. I 've tetsted this with the macb driver. Signed-off-by: Rini van Zetten <[EMAIL PROTECTED]> Acked-by: Andy Fleming <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: occasionally corrupted network stats in /proc/net/dev
Mark Seger wrote: Ignore that last one as it was pointed out to me that we have both nic installed on many of our systems and ethtool told me the one associated with the nic is actually the broadcom one. version:1.4.38 E1B1EC867DEEB8027B2DA0F license:GPL description:Broadcom NetXtreme II BCM5706/5708 Driver Ok, we do a similar stats polling, though through a private ioctl I hacked into the kernel to get the netdev->stats struct with a memcpy. I haven't noticed any problems with counters in the e1000 driver. I haven't done enough testing on bcm drivers to ascertain whether it's reliable or not w/regard to stats. If you can reproduce the problem with e1000, it would be worth looking at the logic that prints out the proc interface text for problems..and if you cannot, then maybe it's the bcm driver that is at issue. Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: occasionally corrupted network stats in /proc/net/dev
Mark Seger a écrit : Ignore that last one as it was pointed out to me that we have both nic installed on many of our systems and ethtool told me the one associated with the nic is actually the broadcom one. version:1.4.38 E1B1EC867DEEB8027B2DA0F license:GPL description:Broadcom NetXtreme II BCM5706/5708 Driver I remember some tg3 chips actually have bugs when reporting stats once in a while CCed to Michael Chan to get some details. -mark Mark Seger wrote: I'll try to get data on the other systems reporting it and as I said it does not happen all that often AND you have to be looking for it. The system I've personally seen it happen on several times is running RHEL4/U4 which redhat numbers 2.6.9-42 and from modinfo I see: version:7.0.33-k2-NAPI 51E97FEE51D0772AFC89130 description:Intel(R) PRO/1000 Network Driver -mark Ben Greear wrote: Mark Seger wrote: I had posted the following on linux-net and haven't see any responses possibly because nobody had any or that list is obsolete. I have been told this is the current list for everything networking on linux so I thought I'd try again... Do you see this with multiple network drivers, or just with one particular driver. If so, which one? Thanks, Ben -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Monday 14 January 2008 1:50:39 pm [EMAIL PROTECTED] wrote: > On Mon, 14 Jan 2008 13:22:10 EST, [EMAIL PROTECTED] said: > > Apparently the only new commit in there since the tree that was in > > 24-rc6-mm1 is 5d95575903fd3865b884952bd93c339d48725c33 adding some > > warning printk's. Would it be more productive to test against the full > > tree, or leaving out the one commit I already reverted? > > Nevermind... :) > > The new commit won't apply with the other one reverted - it patches > security/selinux/netnode.c which was created by the problematic commit... There have been quite a few changes in lblnet-2.6_testing since 2.6.24-rc6-mm1 so I would recommend taking the whole tree. I'm also not quite sure if simply reverting the "Convert the netif code to use ifindex values" patch would solve the problem as there are other patches in the rc6-mm1 tree that rely on skb->iif being valid (new code, not converted code). If you want to stick with a _relatively_ vanilla rc6-mm1 tree I would leave everything in and simply apply the following patch which solved the skb_clone()/iif problem: http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing;a=commitdiff;h=02f1c89d6e36507476f78108a3dcc78538be460b -- paul moore linux security @ hp -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[FIB]: Avoid using static variables without proper locking
fib_trie_seq_show() uses two helper functions, rtn_scope() and
rtn_type() that can
write to static storage without locking.
Just pass to them a temporary buffer to avoid potential corruption
(probably not triggerable but still...)
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 8d8c291..15a555a 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -2276,10 +2276,8 @@ static void seq_indent(struct seq_file *seq, int n)
while (n-- > 0) seq_puts(seq, " ");
}
-static inline const char *rtn_scope(enum rt_scope_t s)
+static inline const char *rtn_scope(char *buf, size_t len, enum rt_scope_t s)
{
- static char buf[32];
-
switch (s) {
case RT_SCOPE_UNIVERSE: return "universe";
case RT_SCOPE_SITE: return "site";
@@ -2287,7 +2285,7 @@ static inline const char *rtn_scope(enum rt_scope_t s)
case RT_SCOPE_HOST: return "host";
case RT_SCOPE_NOWHERE: return "nowhere";
default:
- snprintf(buf, sizeof(buf), "scope=%d", s);
+ snprintf(buf, len, "scope=%d", s);
return buf;
}
}
@@ -2307,13 +2305,11 @@ static const char *rtn_type_names[__RTN_MAX] = {
[RTN_XRESOLVE] = "XRESOLVE",
};
-static inline const char *rtn_type(unsigned t)
+static inline const char *rtn_type(char *buf, size_t len, unsigned t)
{
- static char buf[32];
-
if (t < __RTN_MAX && rtn_type_names[t])
return rtn_type_names[t];
- snprintf(buf, sizeof(buf), "type %d", t);
+ snprintf(buf, len, "type %d", t);
return buf;
}
@@ -2351,13 +2347,19 @@ static int fib_trie_seq_show(struct seq_file *seq, void
*v)
seq_printf(seq, " |-- %d.%d.%d.%d\n", NIPQUAD(val));
for (i = 32; i >= 0; i--) {
struct leaf_info *li = find_leaf_info(l, i);
+
if (li) {
struct fib_alias *fa;
+
list_for_each_entry_rcu(fa, &li->falh, fa_list)
{
+ char buf1[32], buf2[32];
+
seq_indent(seq, iter->depth+1);
seq_printf(seq, " /%d %s %s", i,
- rtn_scope(fa->fa_scope),
- rtn_type(fa->fa_type));
+ rtn_scope(buf1, sizeof(buf1),
+fa->fa_scope),
+ rtn_type(buf2, sizeof(buf2),
+fa->fa_type));
if (fa->fa_tos)
seq_printf(seq, "tos =%d\n",
fa->fa_tos);
Re: questions on NAPI processing latency and dropped network packets
Chris Friesen a écrit :
Eric Dumazet wrote:
Chris Friesen a écrit :
Based on profiling and instrumentation it seems like the cost of
sctp_endpoint_lookup_assoc() more than triples, which means that the
amount of time that bottom halves are disabled in that function also
triples.
Any idea of the size of sctp hash size you have ?
(your dmesg probably includes a message starting with SCTP: Hash
tables configured...
How many concurrent sctp sockets are handled ?
Our lab is currently rebooting, but I'll try and get this once it's
back up.
Maybe sctp_assoc_hashfn() is too weak for your use, and some chains
are *really* long.
Based on the profiling information we're spending time in
sctp_endpoint_lookup_assoc() which doesn't actually use hashes, so I
can't see how the hash would be related. I'm pretty new to SCTP
though, so I may be missing something.
Well, it does use hashes :)
hash = sctp_assoc_hashfn(ep->base.bind_addr.port, rport);
head = &sctp_assoc_hashtable[hash];
read_lock(&head->lock);
sctp_for_each_hentry(epb, node, &head->chain) {
/* maybe your machine is traversing here a *really* long
chain */
}
Here's the top results from readprofile, unfortunately these are
aggregated across both cpus so they don't really show what's going on.
The key thing is that sctp_endpoint_lookup_assoc() is the most
expensive kernel routine on this entire system.
3147 .power4_idle 22.4786
1712 .native_idle 20.3810
1234 .sctp_endpoint_lookup_assoc2.1725
1212 ._spin_unlock_irqrestore 6.4468
778 .do_futex 0.3791
447 ._spin_unlock_irq 4.2981
313 .fget 1.7784
277 .fput 3.8472
275 .kfree 0.7473
234 .__kmalloc 0.5571
131 SystemCall_common 0.3411
130 .sctp_assoc_is_match 0.6373
123 .lock_sock 0.4155
119 .find_vma 0.6919
116 .kmem_cache_alloc 0.3580
111 .kmem_cache_free 0.3343
106 .skb_release_data 0.4907
102 .__copy_tofrom_user0.0724
100 .exit_elf_binfmt 1.9231
100 .do_select 0.0820
Chris
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: questions on NAPI processing latency and dropped network packets
Eric Dumazet wrote: Chris Friesen a écrit : Based on profiling and instrumentation it seems like the cost of sctp_endpoint_lookup_assoc() more than triples, which means that the amount of time that bottom halves are disabled in that function also triples. Any idea of the size of sctp hash size you have ? (your dmesg probably includes a message starting with SCTP: Hash tables configured... How many concurrent sctp sockets are handled ? Our lab is currently rebooting, but I'll try and get this once it's back up. Maybe sctp_assoc_hashfn() is too weak for your use, and some chains are *really* long. Based on the profiling information we're spending time in sctp_endpoint_lookup_assoc() which doesn't actually use hashes, so I can't see how the hash would be related. I'm pretty new to SCTP though, so I may be missing something. Here's the top results from readprofile, unfortunately these are aggregated across both cpus so they don't really show what's going on. The key thing is that sctp_endpoint_lookup_assoc() is the most expensive kernel routine on this entire system. 3147 .power4_idle 22.4786 1712 .native_idle 20.3810 1234 .sctp_endpoint_lookup_assoc2.1725 1212 ._spin_unlock_irqrestore 6.4468 778 .do_futex 0.3791 447 ._spin_unlock_irq 4.2981 313 .fget 1.7784 277 .fput 3.8472 275 .kfree 0.7473 234 .__kmalloc 0.5571 131 SystemCall_common 0.3411 130 .sctp_assoc_is_match 0.6373 123 .lock_sock 0.4155 119 .find_vma 0.6919 116 .kmem_cache_alloc 0.3580 111 .kmem_cache_free 0.3343 106 .skb_release_data 0.4907 102 .__copy_tofrom_user0.0724 100 .exit_elf_binfmt 1.9231 100 .do_select 0.0820 Chris -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Mon, 14 Jan 2008 14:07:46 EST, Paul Moore said: > There have been quite a few changes in lblnet-2.6_testing since > 2.6.24-rc6-mm1 > so I would recommend taking the whole tree. I'm also not quite sure if Weird. I did a 'git clone git://git.infradead.org/users/pcmoore/lblnet-2.6_testing' into a new directory this morning, and doing a 'git log' against that only showed the one added commit: commit 5d95575903fd3865b884952bd93c339d48725c33 Author: Paul Moore <[EMAIL PROTECTED]> Date: Wed Jan 9 15:30:23 2008 -0500 SELinux: Add warning messages on network denial due to error Currently network traffic can be sliently dropped due to non-avc errors which can lead to much confusion when trying to debug the problem. This patch adds warning messages so that when these events occur there is a user visible notification. Signed-off-by: Paul Moore <[EMAIL PROTECTED]> commit 9259ca5fd8b9fbdd2c3edade593dead905d8391e Author: Paul Moore <[EMAIL PROTECTED]> Date: Wed Jan 9 15:30:23 2008 -0500 SELinux: Add network ingress and egress control permission checks (already in 24-rc6-mm1). Somebody please tell me it's my git-idiocy.. > simply reverting the "Convert the netif code to use ifindex values" patch > would solve the problem as there are other patches in the rc6-mm1 tree that > rely on skb->iif being valid (new code, not converted code). That would explain why I'm still seeing issues.. > If you want to > stick with a _relatively_ vanilla rc6-mm1 tree I would leave everything in > and simply apply the following patch which solved the skb_clone()/iif > problem: > > http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing;a=commitdiff;h=02f1c89d6e36507476f78108a3dcc78538be460b OK, I'll go look at that.. pgptELUzSUM99.pgp Description: PGP signature
Re: [PATCH 2/2] ixgb: enable sun hardware support for broadcom phy
Jeff Garzik wrote: Auke Kok wrote: From: Matheos Worku <[EMAIL PROTECTED]> Implement support for a SUN-specific PHY. SUN provides a modified 82597-based board with their own PHY that works with very little modification to the code. This patch implements this new PHY which is identified by the subvendor device ID. The device ID of the adapter remains the same. Signed-off-by: Matheos Worku <[EMAIL PROTECTED]> Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- drivers/net/ixgb/ixgb_hw.c | 82 +- drivers/net/ixgb/ixgb_hw.h |3 +- drivers/net/ixgb/ixgb_ids.h |4 ++ drivers/net/ixgb/ixgb_main.c | 10 +++-- 4 files changed, 91 insertions(+), 8 deletions(-) applied #upstream Jeff, Bleated Happy New Year. I was wondering when this patch will make it to Linus' and other trees. I just checked Linus's and other net trees, including git.kernel.org/?p=linux/kernel/git/jgarzik/netdev-2.6.git and I see only the other patch's commit: 3fd7131feacc01c1e23e46c416228f36ebdcc0d4, and not this patch. Regards Matheos -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: occasionally corrupted network stats in /proc/net/dev
On Mon, 2008-01-14 at 20:12 +0100, Eric Dumazet wrote: > Mark Seger a écrit : > > Ignore that last one as it was pointed out to me that we have both nic > > installed on many of our systems and ethtool told me the one > > associated with the nic is actually the broadcom one. > > > > version:1.4.38 E1B1EC867DEEB8027B2DA0F > > license:GPL > > description:Broadcom NetXtreme II BCM5706/5708 Driver > > > > I remember some tg3 chips actually have bugs when reporting stats > once in a while > > CCed to Michael Chan to get some details. Yes, that's right. Some BNX2 chips have this problem and we have a workaround: http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=02537b0676930b1bd9aff2139e0e645c79986931 The chip sometimes DMA wrong counter values if the chip is also internally gathering the counters at the time of the DMA. Driver 1.5.11 and later versions have this workaround. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] skge 0000:02:05: read data parity error
Hi All! It is fully reproductable under 2.6.22.15, 2.6.23.13 (all tainted and not tainted [4 different kernel] ) and 2 different PC: [BUG] skge :02:05: read data parity error [BUG] skge :02:05: read data parity error steps: 1. login as root 2. start mc 3. cd /sys/bus/pci/drivers/skge/:02:05.0 4. press F3 (mcview) on resource0 5. the system hang up, without panic or bug ... only this message printed 2x: [BUG] skge :02:05: read data parity error when I used cat for show what is in file , then bocome this message: cat: resource0: Input/output error but the permissions is: -rw--- 1 root root 16384 2008-01-14 20:36 resource0 when I used mcview for show whats in file, then the system hang up, and not reagiert neither for SysRQ-s, only for hard reset. --- PC1.: 00:00.0 Host bridge [0600]: Intel Corporation 945G/GZ/P/PL Express Memory Controller Hub [8086:2770] (rev 02) 00:01.0 PCI bridge [0604]: Intel Corporation 945G/GZ/P/PL Express PCI Express Root Port [8086:2771] (rev 02) 00:1b.0 Audio device [0403]: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8] (rev 01) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 [8086:27c8] (rev 01) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 [8086:27c9] (rev 01) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 [8086:27ca] (rev 01) 00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 [8086:27cb] (rev 01) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc] (rev 01) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev e1) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge [8086:27b8] (rev 01) 00:1f.2 IDE interface [0101]: Intel Corporation 82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller IDE [8086:27c0] (rev 01) 00:1f.3 SMBus [0c05]: Intel Corporation 82801G (ICH7 Family) SMBus Controller [8086:27da] (rev 01) 01:00.0 VGA compatible controller [0300]: nVidia Corporation GeForce 7300 GS [10de:01df] (rev a1) 02:01.0 Ethernet controller [0200]: Atheros Communications, Inc. AR5212 802.11abg NIC [168c:0013] (rev 01) 02:05.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller [11ab:4320] (rev 13) PC2: 00:00.0 Host bridge [0600]: Intel Corporation 82875P/E7210 Memory Controller Hub [8086:2578] (rev 02) 00:01.0 PCI bridge [0604]: Intel Corporation 82875P Processor to AGP Controller [8086:2579] (rev 02) 00:06.0 System peripheral [0880]: Intel Corporation 82875P/E7210 Processor to I/O Memory Interface [8086:257e] (rev 02) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 [8086:24d2] (rev 02) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 [8086:24d4] (rev 02) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller [8086:24dd] (rev 02) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev c2) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge [8086:24d0] (rev 02) 00:1f.1 IDE interface [0101]: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller [8086:24db] (rev 02) 00:1f.2 RAID bus controller [0104]: Intel Corporation 82801ER (ICH5R) SATA Controller [8086:24df] (rev 02) 00:1f.3 SMBus [0c05]: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller [8086:24d3] (rev 02) 00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller [8086:24d5] (rev 02) 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350 AP [Radeon 9600] [1002:4150] 01:00.1 Display controller [0380]: ATI Technologies Inc RV350 AP [Radeon 9600] (Secondary) [1002:4170] 02:05.0 Ethernet controller [0200]: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] [10b7:1700] (rev 12) 02:0a.0 Ethernet controller [0200]: Atheros Communications, Inc. AR5212/AR5213 Multiprotocol MAC/baseband processor [168c:0013] (rev 01) -- Thanks, Oliver -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: occasionally corrupted network stats in /proc/net/dev
outstanding! I'm just happy to hear it's not a bug in my monitoring code... 8-) -mark Michael Chan wrote: On Mon, 2008-01-14 at 20:12 +0100, Eric Dumazet wrote: Mark Seger a écrit : Ignore that last one as it was pointed out to me that we have both nic installed on many of our systems and ethtool told me the one associated with the nic is actually the broadcom one. version:1.4.38 E1B1EC867DEEB8027B2DA0F license:GPL description:Broadcom NetXtreme II BCM5706/5708 Driver I remember some tg3 chips actually have bugs when reporting stats once in a while CCed to Michael Chan to get some details. Yes, that's right. Some BNX2 chips have this problem and we have a workaround: http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=02537b0676930b1bd9aff2139e0e645c79986931 The chip sometimes DMA wrong counter values if the chip is also internally gathering the counters at the time of the DMA. Driver 1.5.11 and later versions have this workaround. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: questions on NAPI processing latency and dropped network packets
Eric Dumazet wrote:
Chris Friesen a écrit :
Based on the profiling information we're spending time in
sctp_endpoint_lookup_assoc() which doesn't actually use hashes, so I
can't see how the hash would be related. I'm pretty new to SCTP
though, so I may be missing something.
Well, it does use hashes :)
hash = sctp_assoc_hashfn(ep->base.bind_addr.port, rport);
head = &sctp_assoc_hashtable[hash];
read_lock(&head->lock);
sctp_for_each_hentry(epb, node, &head->chain) {
/* maybe your machine is traversing here a *really* long
chain */
}
The latest released kernel doesn't have this code, it was only added in
November. The SCTP maintainer just pointed me to the patch, and made
some other suggestions as well.
Chris
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Monday 14 January 2008 2:37:02 pm [EMAIL PROTECTED] wrote: > On Mon, 14 Jan 2008 14:07:46 EST, Paul Moore said: > > There have been quite a few changes in lblnet-2.6_testing since > > 2.6.24-rc6-mm1 so I would recommend taking the whole tree. I'm also not > > quite sure if > > Weird. I did a 'git clone > git://git.infradead.org/users/pcmoore/lblnet-2.6_testing' into a new > directory this morning, and doing a 'git log' against that only showed the > one added commit: > > commit 5d95575903fd3865b884952bd93c339d48725c33 > Author: Paul Moore <[EMAIL PROTECTED]> > Date: Wed Jan 9 15:30:23 2008 -0500 > > SELinux: Add warning messages on network denial due to error > > Currently network traffic can be sliently dropped due to non-avc errors > which can lead to much confusion when trying to debug the problem. This > patch adds warning messages so that when these events occur there is a user > visible notification. > > Signed-off-by: Paul Moore <[EMAIL PROTECTED]> > > commit 9259ca5fd8b9fbdd2c3edade593dead905d8391e > Author: Paul Moore <[EMAIL PROTECTED]> > Date: Wed Jan 9 15:30:23 2008 -0500 > > SELinux: Add network ingress and egress control permission checks > (already in 24-rc6-mm1). > > Somebody please tell me it's my git-idiocy.. It might be something on my end with managing the lblnet-2.6_testing git tree; I'm still pretty clueless when it comes to git. I've got a git tree on my dev machine which is backed against Linus' tree and managed via stacked-git. I update the patches in this tree, refresh them against new bits from Linus, etc and when something significant changes I update the git tree on infradead.org and post a new patchset to the related lists. The process of updating the git tree on infradead.org usually involves deleting the entire tree located there, re-creating it, and then doing a git-push from my dev machine. I have no idea if this is "correct" or not, but I've often wondered if this is a the "right" way to do it ... -- paul moore linux security @ hp -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Why are network counters only updated once a second?
I had mentioned this in my previous post but perhaps it might get more attention all by itself. I can't say for sure when this changed, but for the longest time network counters were only updated once every 0.9765 seconds and unless you used a tools like collectl that could monitor at fractional intervals, your traffic was under-reported AND you'd get periodic spikes of double the actual rate. See http://collectl.sourceforge.net/NetworkStats.html for a more complete explanation. Eventually the frequency became better aligned at a 1 second interval because now the number look better, but the problem I see is that when the sampling interval is very close to the monitoring interval you still get periodic incorrect data. Furthermore, you now need to know which way the counters are updated before you pick a sampling interval! But the real point is if anyone ever wants to do finer grained monitoring, say every 1/2 or even tenth of a second, they can't because the counters won't change between samples. Has this ever been discussed before? -mark -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why are network counters only updated once a second?
Mark Seger a écrit : I had mentioned this in my previous post but perhaps it might get more attention all by itself. I can't say for sure when this changed, but for the longest time network counters were only updated once every 0.9765 seconds and unless you used a tools like collectl that could monitor at fractional intervals, your traffic was under-reported AND you'd get periodic spikes of double the actual rate. See http://collectl.sourceforge.net/NetworkStats.html for a more complete explanation. Eventually the frequency became better aligned at a 1 second interval because now the number look better, but the problem I see is that when the sampling interval is very close to the monitoring interval you still get periodic incorrect data. Furthermore, you now need to know which way the counters are updated before you pick a sampling interval! But the real point is if anyone ever wants to do finer grained monitoring, say every 1/2 or even tenth of a second, they can't because the counters won't change between samples. Has this ever been discussed before? Yes it was discussed before. Some devices perform counters updates directly at the NIC level, and one in a while a transfert of counters is done to the host. This is supposed to be better, especially on SMP. Maybe you need to setup accounting rules with iptables, so that you can perform counter sampling at whatever rate you want ? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
On Mon, 14 Jan 2008 08:39:26 -0800 Stephen Hemminger <[EMAIL PROTECTED]> wrote: > > diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c > > index c27c7d6..4f41a94 100644 > > --- a/drivers/net/sky2.c > > +++ b/drivers/net/sky2.c > > @@ -2791,6 +2791,9 @@ static void sky2_reset(struct sky2_hw *hw) > > sky2_write8(hw, B0_CTST, CS_RST_SET); > > sky2_write8(hw, B0_CTST, CS_RST_CLR); > > > > + /* allow writes to PCI config */ > > + sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON); > > + > > /* clear PCI errors, if any */ > > pci_read_config_word(pdev, PCI_STATUS, &status); > > status |= PCI_STATUS_ERROR_BITS; > > > > fixes this regression? > > > > If so, we should revert that change. > > > > > but i noticed another "bug" on 2.6.24-rc7-git with sky2: dmesg shows a > > > lot of lines every 5 seconds: > > > > > > [...] > > > [ 357.400462] sky2 :02:00.0: error interrupt status=0xc000 > > > [ 362.442039] printk: 41 messages suppressed. > > > [ 362.442043] sky2 :02:00.0: error interrupt status=0x8000 > > > [ 367.439151] printk: 18 messages suppressed. > > > [ 367.439156] sky2 :02:00.0: error interrupt status=0x8000 > > > [ 372.436267] printk: 30 messages suppressed. > > > [ 372.436271] sky2 :02:00.0: error interrupt status=0x8000 > > > [ 377.350236] printk: 19 messages suppressed. > > > [...] > > > > > > since i do not notice any errors (yet) i'll wait till next rc, maybe it > > > will be gone then... > > > > That's not good. is this new behaviour? > > > > No, reverting that change will break other systems (including mine). Reverting which change? ac93a3946b676025fa55356180e8321639744b31? Linus has very clearly stated on multiple occasions that patches which fix machine A and break machine B will be reverted. For good reasons. I don't have a copy of those reasons handy, but it should be a well-known thing. If you're really interested we can cc him for a reminder, but the effects of that upon ac93a3946b676025fa55356180e8321639744b31 might be quick. And terminal. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] skge 0000:02:05: read data parity error
On Mon, 14 Jan 2008 20:57:49 +0100 "Oliver Pinter (Pintér Olivér)" <[EMAIL PROTECTED]> wrote: > Hi All! > > It is fully reproductable under 2.6.22.15, 2.6.23.13 (all tainted and > not tainted [4 different kernel] ) and 2 different PC: > > [BUG] skge :02:05: read data parity error > [BUG] skge :02:05: read data parity error > > steps: > 1. login as root > 2. start mc > 3. cd /sys/bus/pci/drivers/skge/:02:05.0 > 4. press F3 (mcview) on resource0 > 5. the system hang up, without panic or bug ... only this message > printed 2x: [BUG] skge :02:05: read data parity error > This is not a bug. The hardware has some debug registers that if accessed cause a read back to the host. Since this can point anywhere, it will cause errors or system hang. The point is don't do it. -- Stephen Hemminger <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why are network counters only updated once a second?
Eric Dumazet wrote: Mark Seger a écrit : I had mentioned this in my previous post but perhaps it might get more attention all by itself. I can't say for sure when this changed, but for the longest time network counters were only updated once every 0.9765 seconds and unless you used a tools like collectl that could monitor at fractional intervals, your traffic was under-reported AND you'd get periodic spikes of double the actual rate. See http://collectl.sourceforge.net/NetworkStats.html for a more complete explanation. Eventually the frequency became better aligned at a 1 second interval because now the number look better, but the problem I see is that when the sampling interval is very close to the monitoring interval you still get periodic incorrect data. Furthermore, you now need to know which way the counters are updated before you pick a sampling interval! But the real point is if anyone ever wants to do finer grained monitoring, say every 1/2 or even tenth of a second, they can't because the counters won't change between samples. Has this ever been discussed before? Yes it was discussed before. Some devices perform counters updates directly at the NIC level, and one in a while a transfert of counters is done to the host. This is supposed to be better, especially on SMP. Maybe you need to setup accounting rules with iptables, so that you can perform counter sampling at whatever rate you want ? Maybe I wasn't clear enough. I'm grabbing the counters from /proc/net/dev and whatever mechanism is being used only ports them with a granularity of about once a second. This means any of the standard tools that use /proc to get their data will all have the same problem. -mark -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [IPV4] fib_trie: size and statistics
Show number of entries in trie, the size field was being set but never used,
but it only counted leaves, not all entries. Refactor the two cases in
fib_triestat_seq_show into a single routine.
Note: the stat structure was being malloc'd but the stack usage isn't so
high (288 bytes) that it is worth the additional complexity.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
Patch against current net-2.6.25
--- a/net/ipv4/fib_trie.c 2008-01-14 10:16:06.0 -0800
+++ b/net/ipv4/fib_trie.c 2008-01-14 10:30:11.0 -0800
@@ -148,10 +148,10 @@ struct trie_stat {
struct trie {
struct node *trie;
+ unsigned int size;
#ifdef CONFIG_IP_FIB_TRIE_STATS
struct trie_use_stats stats;
#endif
- int size;
};
static void put_child(struct trie *t, struct tnode *tn, int i, struct node *n);
@@ -1045,7 +1045,6 @@ static struct list_head *fib_insert_node
insert_leaf_info(&l->list, li);
goto done;
}
- t->size++;
l = leaf_new();
if (!l)
@@ -1258,6 +1257,8 @@ static int fn_trie_insert(struct fib_tab
list_add_tail_rcu(&new_fa->fa_list,
(fa ? &fa->fa_list : fa_head));
+ t->size++;
+
rt_cache_flush(-1);
rtmsg_fib(RTM_NEWROUTE, htonl(key), new_fa, plen, tb->tb_id,
&cfg->fc_nlinfo, 0);
@@ -2128,50 +2129,34 @@ static void trie_show_usage(struct seq_f
}
#endif /* CONFIG_IP_FIB_TRIE_STATS */
+static void fib_trie_show(struct seq_file *seq, const char *name, struct trie
*trie)
+{
+ struct trie_stat stat;
+
+ seq_printf(seq, "%s: %d\n", name, trie->size);
+ trie_collect_stats(trie, &stat);
+ trie_show_stats(seq, &stat);
+#ifdef CONFIG_IP_FIB_TRIE_STATS
+ trie_show_usage(seq, &trie->stats);
+#endif
+}
static int fib_triestat_seq_show(struct seq_file *seq, void *v)
{
struct net *net = (struct net *)seq->private;
- struct trie *trie_local, *trie_main;
- struct trie_stat *stat;
struct fib_table *tb;
- trie_local = NULL;
+ seq_printf(seq,
+ "Basic info: size of leaf: %Zd bytes, size of tnode: %Zd
bytes.\n",
+ sizeof(struct leaf), sizeof(struct tnode));
+
tb = fib_get_table(net, RT_TABLE_LOCAL);
if (tb)
- trie_local = (struct trie *) tb->tb_data;
-
- trie_main = NULL;
+ fib_trie_show(seq, "Local", (struct trie *) tb->tb_data);
+
tb = fib_get_table(net, RT_TABLE_MAIN);
if (tb)
- trie_main = (struct trie *) tb->tb_data;
-
-
- stat = kmalloc(sizeof(*stat), GFP_KERNEL);
- if (!stat)
- return -ENOMEM;
-
- seq_printf(seq, "Basic info: size of leaf: %Zd bytes, size of tnode:
%Zd bytes.\n",
- sizeof(struct leaf), sizeof(struct tnode));
-
- if (trie_local) {
- seq_printf(seq, "Local:\n");
- trie_collect_stats(trie_local, stat);
- trie_show_stats(seq, stat);
-#ifdef CONFIG_IP_FIB_TRIE_STATS
- trie_show_usage(seq, &trie_local->stats);
-#endif
- }
-
- if (trie_main) {
- seq_printf(seq, "Main:\n");
- trie_collect_stats(trie_main, stat);
- trie_show_stats(seq, stat);
-#ifdef CONFIG_IP_FIB_TRIE_STATS
- trie_show_usage(seq, &trie_main->stats);
-#endif
- }
- kfree(stat);
+ fib_trie_show(seq, "Main", (struct trie *) tb->tb_data);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] sky2: wake-on-lan configuration issues
Stephen Hemminger wrote:
Please test this patch against Linus's current (approx 2.6.24-rc7-git5).
Ignore Andrew's premature reversion attempt...
This patch disables config mode access after clearing PCI settings.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.c2008-01-14 09:44:22.0 -0800
+++ b/drivers/net/sky2.c2008-01-14 09:44:51.0 -0800
@@ -621,6 +621,7 @@ static void sky2_phy_power(struct sky2_h
static const u32 phy_power[] = { PCI_Y2_PHY1_POWD, PCI_Y2_PHY2_POWD };
static const u32 coma_mode[] = { PCI_Y2_PHY1_COMA, PCI_Y2_PHY2_COMA };
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
/* Turn on/off phy power saving */
if (onoff)
@@ -632,7 +633,8 @@ static void sky2_phy_power(struct sky2_h
reg1 |= coma_mode[port];
sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
- reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
+ sky2_pci_read32(hw, PCI_DEV_REG1);
udelay(100);
}
@@ -2426,6 +2428,7 @@ static void sky2_hw_intr(struct sky2_hw
if (status & (Y2_IS_MST_ERR | Y2_IS_IRQ_STAT)) {
u16 pci_err;
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
pci_err = sky2_pci_read16(hw, PCI_STATUS);
if (net_ratelimit())
dev_err(&pdev->dev, "PCI hardware error (0x%x)\n",
@@ -2433,12 +2436,14 @@ static void sky2_hw_intr(struct sky2_hw
sky2_pci_write16(hw, PCI_STATUS,
pci_err | PCI_STATUS_ERROR_BITS);
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
}
if (status & Y2_IS_PCI_EXP) {
/* PCI-Express uncorrectable Error occurred */
u32 err;
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
err = sky2_read32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS);
sky2_write32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS,
0xul);
@@ -2446,6 +2451,7 @@ static void sky2_hw_intr(struct sky2_hw
dev_err(&pdev->dev, "PCI Express error (0x%x)\n", err);
sky2_read32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS);
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
}
if (status & Y2_HWE_L1_MASK)
@@ -2811,6 +2817,7 @@ static void sky2_reset(struct sky2_hw *h
}
sky2_power_on(hw);
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
for (i = 0; i < hw->ports; i++) {
sky2_write8(hw, SK_REG(i, GMAC_LINK_CTRL), GMLC_RST_SET);
yes, that did it! just tested it (current linus git tree with patched
sky with above patch), everything is clean now (dmesg output) and wol
works even with the commit ac93a3946b676025fa55356180e8321639744b31
so it the bug is fixed without the need to revert
ac93a3946b676025fa55356180e8321639744b31.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
On Mon, 14 Jan 2008 12:00:51 -0600 Kim Phillips <[EMAIL PROTECTED]> wrote: > On Thu, 10 Jan 2008 21:41:20 -0700 > "Aggrwal Poonam" <[EMAIL PROTECTED]> wrote: > > > Hello All > > > > I am waiting for more feedback on the patches. > > > > If there are no objections please consider them for 2.6.25. > > > if this isn't going to go through Alessandro Rubini/misc drivers, can > it go through the akpm/mm tree? > That would work. But it might be more appropriate to go Kumar->paulus->Linus. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] drivers/misc :UCC based TDM driver for MPC83xx platforms.
On Mon, 10 Dec 2007 17:34:44 +0530 (IST)
Poonam_Aggrwal-b10812 <[EMAIL PROTECTED]> wrote:
> From: Poonam Aggrwal <[EMAIL PROTECTED]>
>
> The UCC TDM driver basically multiplexes and demultiplexes data from
> different channels. It can interface with for example SLIC kind of devices
> to receive TDM data demultiplex it and send to upper applications. At the
> transmit end it receives data for different channels multiplexes it and
> sends them on the TDM channel. It internally uses TSA( Time Slot Assigner)
> which does multiplexing and demultiplexing, UCC to perform SDMA between
> host buffers and the TSA, CMX to connect TSA to UCC.
>
> This driver will run on MPC8323E-RDB platforms.
>
> ...
>
> +#define PREV_PHASE(x) ((x == 0) ? MAX_PHASE : (x - 1))
> +#define NEXT_PHASE(x) (((x + 1) > MAX_PHASE) ? 0 : (x + 1))
These macros can reference their arg more than once and are hence
dangerous. What does PREV_PHASE(foo++) do to foo?
And, in general: do not implement in cpp that which could have been
implemented in C.
> +static struct ucc_tdm_info utdm_primary_info = {
> + .uf_info = {
> + .tsa = 1,
> + .cdp = 1,
> + .cds = 1,
> + .ctsp = 1,
> + .ctss = 1,
> + .revd = 1,
> + .urfs = 0x128,
> + .utfs = 0x128,
> + .utfet = 0,
> + .utftt = 0x128,
> + .ufpt = 256,
> + .ttx_trx = UCC_FAST_GUMR_TRANSPARENT_TTX_TRX_TRANSPARENT,
> + .tenc = UCC_FAST_TX_ENCODING_NRZ,
> + .renc = UCC_FAST_RX_ENCODING_NRZ,
> + .tcrc = UCC_FAST_16_BIT_CRC,
> + .synl = UCC_FAST_SYNC_LEN_NOT_USED,
> + },
> + .ucc_busy = 0,
> +};
> +
> +static struct ucc_tdm_info utdm_info[8];
> +
> +static void dump_siram(struct tdm_ctrl *tdm_c)
> +{
> +#if defined(DEBUG)
Microscopic note: kernel code tends to do
#ifdef FOO
if only one identifier is being tested and
#if defined(FOO) && defined(BAR)
if more than one is being tested.
There is no rational reason for this ;)
> + int i;
> + u16 phy_num_ts;
> +
> + phy_num_ts = tdm_c->physical_num_ts;
> +
> + pr_debug("SI TxRAM dump\n");
> + /* each slot entry in SI RAM is of 2 bytes */
> + for (i = 0; i < phy_num_ts * 2; i++)
> + pr_debug("%x ", in_8(&qe_immr->sir.tx[i]));
> + pr_debug("\nSI RxRAM dump\n");
> + for (i = 0; i < phy_num_ts * 2; i++)
> + pr_debug("%x ", in_8(&qe_immr->sir.rx[i]));
> + pr_debug("\n");
> +#endif
> +}
> +
> +/*
> + * converts u-law compressed samples to linear PCM
> + * If the CONFIG_TDM_LINEAR_PCM flag is not set the
> + * TDM driver receives u-law compressed data from the
> + * SLIC device. This function converts the compressed
> + * data to linear PCM and sends it to upper layers.
> + */
> +static inline int ulaw2int(unsigned char log)
> +{
> + u32 sign, segment, temp, quant;
> + int val;
> +
> + temp = log ^ 0xFF;
> + sign = (temp & 0x80) >> 7;
> + segment = (temp & 0x70) >> 4;
> + quant = temp & 0x0F;
> + quant <<= 1;
> + quant += 33;
> + quant <<= segment;
> + if (sign)
> + val = 33 - quant;
> + else
> + val = quant - 33;
> +
> + val *= 4;
> + return val;
> +}
> +
> +/*
> + * converts linear PCM samples to u-law compressed format.
> + * If the CONFIG_TDM_LINEAR_PCM flag is not set the
> + * TDM driver calls this function to convert the PCM samples
> + * to u-law compressed format before sending them to SLIC
> + * device.
> + */
> +static inline u8 int2ulaw(short linear)
> +{
> + u8 quant, ret;
> + u16 output, absol, temp;
> + u32 i, sign;
> + char segment;
> +
> + ret = 0;
> + if (linear >= 0)
> + linear = (linear >> 2);
> + else
> + linear = (0xc000 | (linear >> 2));
> +
> + absol = abs(linear) + 33;
> + temp = absol;
> + sign = (linear >= 0) ? 1 : 0;
> + for (i = 0; i < 16; i++) {
> + output = temp & 0x8000;
> + if (output)
> + break;
> + temp <<= 1;
> + }
> + segment = 11 - i;
> + quant = (absol >> segment) & 0x0F;
> + segment--;
> + segment <<= 4;
> + output = segment + quant;
> + if (absol > 8191)
> + output = 0x7F;
> + if (sign)
> + ret ^= 0xFF;
> + else
> + ret ^= 0x7F;
> + return ret;
> +}
hrm, how many copies of ulaw/alaw conversion functions do we need in the
tree before someone writes a library function for it?
> + out_be16(&rx_bd->status, bd_status);
> + out_be32(&rx_bd->buf,
> + tdm_c->dma_input_addr + i * SAMPLE_DEPTH * act_num_ts);
> +
> + bd_status = (u16) ((T_R | T_CM | T_W) >> 16);
> + bd_len = SAMPLE_DEPTH * act_num_ts;
> + out_be16(&tx_bd->length, bd_len);
> + out_be16(&tx_bd->status, bd_status);
> + out_be32(&tx_bd->buf,
> + tdm_c->dma_outp
Re: [BUG] skge 0000:02:05: read data parity error
On Mon, Jan 14, 2008 at 12:52:00PM -0800, Stephen Hemminger wrote: > On Mon, 14 Jan 2008 20:57:49 +0100 > "Oliver Pinter (Pintér Olivér)" <[EMAIL PROTECTED]> wrote: > > > Hi All! > > > > It is fully reproductable under 2.6.22.15, 2.6.23.13 (all tainted and > > not tainted [4 different kernel] ) and 2 different PC: > > > > [BUG] skge :02:05: read data parity error > > [BUG] skge :02:05: read data parity error > > > > steps: > > 1. login as root > > 2. start mc > > 3. cd /sys/bus/pci/drivers/skge/:02:05.0 > > 4. press F3 (mcview) on resource0 > > 5. the system hang up, without panic or bug ... only this message > > printed 2x: [BUG] skge :02:05: read data parity error > > This is not a bug. > > The hardware has some debug registers that if accessed cause a read > back to the host. Since this can point anywhere, it will cause errors > or system hang. > > The point is don't do it. Is it really a good idea that _reading_ files under /sys can kill your machine? That sounds like a huge trap for people debugging their machine (or e.g. forgetting to exclude /sys from their backup). cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: occasionally corrupted network stats in /proc/net/dev
Mark Seger a écrit : I had posted the following on linux-net and haven't see any responses possibly because nobody had any or that list is obsolete. I have been told this is the current list for everything networking on linux so I thought I'd try again... I suspect the answer will be that it is what it is, but here's the deal. I have a tool I use for monitoring network traffic among other things - see http://collectl.sourceforge.net/ - and one of its benefits is that you can run it continuously as a daemon (similar to sar) and generate data in a format suitable for plotting. This means that you can automate your entire network monitoring infrastructure at fairly fine granularity, down to second if you like. Actually 1-second level monitoring will provide incorrect data on earlier kernels because the stats aren't updated on 1 second boundaries and you need to monitor at an interval of 0.9765 seconds, but that's a different story which is explained at http://collectl.sourceforge.net/NetworkStats.html But more importantly, I've found that occasionally (not that often) there is bogus data reported from /proc/net/dev. While I don't have a lot of details on this it seems to only show up in 64 bit kernels. Look at the following samples taken at 1 second intervals: eth0:135115809 1024897000 0 0 9 135458926 910340000 0 0 0 eth0:135118023 1024923000 0 0 9 135460952 910363000 0 0 0 eth0:0 884620000 0 0909397 9687563 1049736000 0 0 0 eth0:135121189 1024957000 0 0 9 135464222 910400000 0 0 0 eth0:135129565 1024995000 0 0 9 135473687 910435000 0 0 0 see the middle sample? When I look at the change between samples it generates a really big number since the difference is assumed to be caused a counter wrapping. The problem is it's not always straightforward when there is bad data. For example if the original and bogus values are close enough it's not even clear there is a problem. So the obvious question is, is there any way to prevent the bogus data from getting reported? If not, is there any way to set the values to something to indicate that the correct values can't be determined? Clearly this problem would be visible to any tool that looks at /proc but since many tools are not automated or don't take it to the level I do, nobody probably notices. As for the counter update frequency, even though they now appear to be updated closer to a 1 second boundary it also means tools that can monitor at sub-second intervals will report incorrect data since the counters only change once a second. What is the NIC used for eth0 (and driver name) Which version of linux kernel do you run ? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] s2io LRO bugs
Al,
Thanks for finding this. We have a few patches lined up and will submit
this patch.
Ram
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of Al Viro
> Sent: Sunday, December 23, 2007 10:15 PM
> To: [EMAIL PROTECTED]
> Cc: netdev@vger.kernel.org; [EMAIL PROTECTED]
> Subject: [PATCH] s2io LRO bugs
>
> a) initiate_new_session() sets ->tcp_ack to ntohl(...); everything
>else stores and expects to find there the net-endian value.
> b) check for monotonic timestamps in verify_l3_l4_lro_capable()
>compares the value sitting in TCP option (right there in the
skb->data,
>net-endian 32bit) with the value picked from earlier packet.
>Doing that without ntohl() is an interesting idea and it might even
>work occasionally; unfortunately, it's quite broken.
>
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
> ---
> drivers/net/s2io.c | 20 ++--
> drivers/net/s2io.h |2 +-
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
> index 9d80f1c..aef0875 100644
> --- a/drivers/net/s2io.c
> +++ b/drivers/net/s2io.c
> @@ -7898,7 +7898,7 @@ static void initiate_new_session(struct lro
*lro, u8
> *l2h,
> lro->iph = ip;
> lro->tcph = tcp;
> lro->tcp_next_seq = tcp_pyld_len + ntohl(tcp->seq);
> - lro->tcp_ack = ntohl(tcp->ack_seq);
> + lro->tcp_ack = tcp->ack_seq;
> lro->sg_num = 1;
> lro->total_len = ntohs(ip->tot_len);
> lro->frags_len = 0;
> @@ -7907,10 +7907,10 @@ static void initiate_new_session(struct lro
*lro,
> u8 *l2h,
>* already been done.
>*/
> if (tcp->doff == 8) {
> - u32 *ptr;
> - ptr = (u32 *)(tcp+1);
> + __be32 *ptr;
> + ptr = (__be32 *)(tcp+1);
> lro->saw_ts = 1;
> - lro->cur_tsval = *(ptr+1);
> + lro->cur_tsval = ntohl(*(ptr+1));
> lro->cur_tsecr = *(ptr+2);
> }
> lro->in_use = 1;
> @@ -7936,7 +7936,7 @@ static void update_L3L4_header(struct s2io_nic
*sp,
> struct lro *lro)
>
> /* Update tsecr field if this session has timestamps enabled */
> if (lro->saw_ts) {
> - u32 *ptr = (u32 *)(tcp + 1);
> + __be32 *ptr = (__be32 *)(tcp + 1);
> *(ptr+2) = lro->cur_tsecr;
> }
>
> @@ -7961,10 +7961,10 @@ static void aggregate_new_rx(struct lro *lro,
> struct iphdr *ip,
> lro->window = tcp->window;
>
> if (lro->saw_ts) {
> - u32 *ptr;
> + __be32 *ptr;
> /* Update tsecr and tsval from this packet */
> - ptr = (u32 *) (tcp + 1);
> - lro->cur_tsval = *(ptr + 1);
> + ptr = (__be32 *) (tcp + 1);
> + lro->cur_tsval = ntohl(*(ptr + 1));
> lro->cur_tsecr = *(ptr + 2);
> }
> }
> @@ -8015,11 +8015,11 @@ static int verify_l3_l4_lro_capable(struct lro
> *l_lro, struct iphdr *ip,
>
> /* Ensure timestamp value increases monotonically */
> if (l_lro)
> - if (l_lro->cur_tsval > *((u32 *)(ptr+2)))
> + if (l_lro->cur_tsval > ntohl(*((__be32
*)(ptr+2
> return -1;
>
> /* timestamp echo reply should be non-zero */
> - if (*((u32 *)(ptr+6)) == 0)
> + if (*((__be32 *)(ptr+6)) == 0)
> return -1;
> }
>
> diff --git a/drivers/net/s2io.h b/drivers/net/s2io.h
> index cc1797a..899d60c 100644
> --- a/drivers/net/s2io.h
> +++ b/drivers/net/s2io.h
> @@ -797,7 +797,7 @@ struct lro {
> int in_use;
> __be16 window;
> u32 cur_tsval;
> - u32 cur_tsecr;
> + __be32 cur_tsecr;
> u8 saw_ts;
> };
>
> --
> 1.5.3.GIT
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] skge 0000:02:05: read data parity error
On Mon, Jan 14, 2008 at 10:31:03PM +0100, Oliver Pinter (Pintér Olivér) wrote: > I think, it is a potential security breakpoint, when applications with > root permission its read, then a machine is freezed, or only i thin > it's? When you are root there are infinite ways to kill your machine, so there's nothing security related about this issue. > Thanks, > Oliver cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] skge 0000:02:05: read data parity error
On Mon, Jan 14, 2008 at 10:31:03PM +0100, Oliver Pinter (Pint?r Oliv?r) wrote: > I think, it is a potential security breakpoint, when applications with > root permission its read, then a machine is freezed, or only i thin > it's? I'm sorry, I don't quite understand what you are trying to say here. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] skge 0000:02:05: read data parity error
On 1/14/08, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Mon, Jan 14, 2008 at 10:31:03PM +0100, Oliver Pinter (Pintér Olivér) > wrote: > > I think, it is a potential security breakpoint, when applications with > > root permission its read, then a machine is freezed, or only i thin > > it's? > > When you are root there are infinite ways to kill your machine, so > there's nothing security related about this issue. Yes, i know, but when some application or daemons read some file with running root privileges, then ... thanks, then it is only a "feature" and not bug. > > > Thanks, > > Oliver > > cu > Adrian > > -- > >"Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. >"Only a promise," Lao Er said. >Pearl S. Buck - Dragon Seed > > -- Thanks, Oliver -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
