* Re: [PATCH V3 8/8] net: backlog functions rename
From: Eric Dumazet @ 2010-03-05 6:32 UTC (permalink / raw)
To: Zhu Yi; +Cc: davem, netdev
In-Reply-To: <1267761707-15605-8-git-send-email-yi.zhu@intel.com>
Le vendredi 05 mars 2010 à 12:01 +0800, Zhu Yi a écrit :
> sk_add_backlog -> __sk_add_backlog
> sk_add_backlog_limited -> sk_add_backlog
>
> Signed-off-by: Zhu Yi <yi.zhu@intel.com>
> ---
> include/net/sock.h | 6 +++---
> net/core/sock.c | 2 +-
> net/dccp/minisocks.c | 2 +-
> net/ipv4/tcp_ipv4.c | 2 +-
> net/ipv4/tcp_minisocks.c | 2 +-
> net/ipv4/udp.c | 2 +-
> net/ipv6/tcp_ipv6.c | 2 +-
> net/ipv6/udp.c | 4 ++--
> net/llc/llc_c_ac.c | 2 +-
> net/llc/llc_conn.c | 2 +-
> net/sctp/input.c | 4 ++--
> net/tipc/socket.c | 2 +-
> net/x25/x25_dev.c | 2 +-
> 13 files changed, 17 insertions(+), 17 deletions(-)
>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: KS8695: possible NAPI issue
From: figo zhang @ 2010-03-05 6:54 UTC (permalink / raw)
To: Yegor Yefremov; +Cc: Dick Hollenbeck, netdev, zealcook
In-Reply-To: <f69abfc31003040210i7e8a136am4b4a97306ba770cf@mail.gmail.com>
2010/3/4 Yegor Yefremov <yegorslists@googlemail.com>:
>>>> I'm using 2.6.33 kernel and I noticed such a strange behavior:
>>>>
>>>> after system start I transfer one file via netcat from my development
>>>> host, after this transfer the network is not functioning i.e. no pings
>>>> possible etc.
>>>>
>>>> To narrow down the problem I checked out this commit
>>>>
>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=451f14439847db302e5104c44458b2dbb4b1829d.
>>>> Till here the network driver is functioning as intended, but after
>>>> NAPI introduction I have this issue. With latest git-pull of "Linus'
>>>> kernel tree" I can't even ping right after the systems start.
>>>>
>>>> Any Ideas? What am I missing?
>>>>
>>>
>>> No idea, although I am using the same ARM chip, my kernel is at 2.6.30.5,
>>> and except for this occasional loss of connection I get, the ethernet driver
>>> seems to work better than what you are reporting.
>>
>> from linux-2.6.32, this ethernet driver have add NAPI support, would
>> you like to
>> try using this version?
>
> Figo, I just looked at the 2.6.32 kernel and found out that it
> doesn't' contain NAPI support (see the history
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=history;f=drivers/net/arm/ks8695net.c;h=2a7b7745cc55b54cefada690b0ea47865b54b6b9;hb=HEAD).
> So 2.6.33 is the first stable kernel to support NAPI.
>
> I made some further tests but I can't find the reason for network
> failures: the interrupts are coming and the packets will be received
> and sent so that rx/tx counters would be increased, but none of them
> seem to reach the IP stack. I don't know where and why the things get
> desynchronized.
>
> Could you try the 2.6.33 or Linus tree? Thank you in advance.
yes, i have test it on linux-2.6.33, it is work well.
^ permalink raw reply
* [PATCH V2 0/3] recursive printk, make functions from logging macros
From: Joe Perches @ 2010-03-05 6:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, Greg Kroah-Hartman, linux-kernel, netdev
dev_<level> macros use a lot of repetitive string space and arguments
pr_<level> macros use repetitive unnecessary KERN_<level> strings
Eliminate the string prefixes and function arguments from all the macro uses
and consolidate them in functions.
This patchset saves about 60K of text in an x86 defconfig.
This implementation adds the ability to use a struct va_format to
emit a format string along with va_list arguments.
This %pV implementation should not be used without a wrapper that
does printf argument verification like the dev_<level> functions.
Inspired a bit by Nick Andrew's patches and Linus' comments in December 2008
http://lkml.org/lkml/2008/12/6/15
http://lkml.org/lkml/2008/12/6/101
Joe Perches (3):
vsprintf: Recursive vsnprintf: Add "%pV", struct va_format
device.h drivers/base/core.c Convert dev_<level> macros to functions
kernel.h kernel/printk.c: Convert pr_<level> macros to functions
drivers/base/core.c | 56 +++++++++++++++++++++++++
include/linux/device.h | 105 ++++++++++++++++++++++++++++++++++++------------
include/linux/kernel.h | 75 +++++++++++++++++++++++++++-------
kernel/printk.c | 26 ++++++++++++
lib/vsprintf.c | 9 ++++
5 files changed, 229 insertions(+), 42 deletions(-)
^ permalink raw reply
* [PATCH 2/3] device.h drivers/base/core.c Convert dev_<level> macros to functions
From: Joe Perches @ 2010-03-05 6:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, Greg Kroah-Hartman, linux-kernel, netdev
In-Reply-To: <cover.1267771398.git.joe@perches.com>
Save ~60k in a defconfig
Use %pV and struct va_format
Format arguments are verified before printk
There are existing "struct dev_info" declarations as well as local variables
named dev_info so the dev_info macro to function conversion is instead
called _dev_info and a macro is used to call _dev_info
Perhaps over time the struct and local uses of dev_info should be renamed.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/base/core.c | 56 +++++++++++++++++++++++++
include/linux/device.h | 105 ++++++++++++++++++++++++++++++++++++------------
2 files changed, 135 insertions(+), 26 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 2820257..19de3ab 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1745,3 +1745,59 @@ void device_shutdown(void)
}
async_synchronize_full();
}
+
+/*
+ * Device logging functions
+ */
+
+#ifdef CONFIG_PRINTK
+
+static int __dev_printk(const char *level, const struct device *dev,
+ const char *fmt, va_list args)
+{
+ struct va_format vaf;
+
+ vaf.fmt = fmt;
+ vaf.va = &args;
+ return printk("%s%s %s: %pV",
+ level, dev_driver_string(dev), dev_name(dev), &vaf);
+}
+
+int dev_printk(const char *level, const struct device *dev,
+ const char *fmt, ...)
+{
+ int r;
+ va_list args;
+
+ va_start(args, fmt);
+ r = __dev_printk(level, dev, fmt, args);
+ va_end(args);
+
+ return r;
+}
+EXPORT_SYMBOL(dev_printk);
+
+#define declare_dev_level(function, level) \
+int function(const struct device *dev, const char *fmt, ...) \
+{ \
+ int r; \
+ va_list args; \
+ \
+ va_start(args, fmt); \
+ r = __dev_printk(level, dev, fmt, args); \
+ va_end(args); \
+ \
+ return r; \
+} \
+EXPORT_SYMBOL(function)
+
+declare_dev_level(dev_emerg, KERN_EMERG);
+declare_dev_level(dev_alert, KERN_ALERT);
+declare_dev_level(dev_crit, KERN_CRIT);
+declare_dev_level(dev_err, KERN_ERR);
+declare_dev_level(dev_warn, KERN_WARNING);
+declare_dev_level(dev_notice, KERN_NOTICE);
+declare_dev_level(_dev_info, KERN_INFO);
+/* Not dev_info because it conflicts with with existing "struct dev_info" */
+
+#endif
diff --git a/include/linux/device.h b/include/linux/device.h
index b30527d..5948c07 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -590,43 +590,96 @@ extern void sysdev_shutdown(void);
/* debugging and troubleshooting/diagnostic helpers. */
extern const char *dev_driver_string(const struct device *dev);
-#define dev_printk(level, dev, format, arg...) \
- printk(level "%s %s: " format , dev_driver_string(dev) , \
- dev_name(dev) , ## arg)
-
-#define dev_emerg(dev, format, arg...) \
- dev_printk(KERN_EMERG , dev , format , ## arg)
-#define dev_alert(dev, format, arg...) \
- dev_printk(KERN_ALERT , dev , format , ## arg)
-#define dev_crit(dev, format, arg...) \
- dev_printk(KERN_CRIT , dev , format , ## arg)
-#define dev_err(dev, format, arg...) \
- dev_printk(KERN_ERR , dev , format , ## arg)
-#define dev_warn(dev, format, arg...) \
- dev_printk(KERN_WARNING , dev , format , ## arg)
-#define dev_notice(dev, format, arg...) \
- dev_printk(KERN_NOTICE , dev , format , ## arg)
-#define dev_info(dev, format, arg...) \
- dev_printk(KERN_INFO , dev , format , ## arg)
+
+#ifdef CONFIG_PRINTK
+
+extern int dev_printk(const char *level, const struct device *dev,
+ const char *fmt, ...)
+ __attribute__ ((format (printf, 3, 4)));
+extern int dev_emerg(const struct device *dev, const char *fmt, ...)
+ __attribute__ ((format (printf, 2, 3)));
+extern int dev_alert(const struct device *dev, const char *fmt, ...)
+ __attribute__ ((format (printf, 2, 3)));
+extern int dev_crit(const struct device *dev, const char *fmt, ...)
+ __attribute__ ((format (printf, 2, 3)));
+extern int dev_err(const struct device *dev, const char *fmt, ...)
+ __attribute__ ((format (printf, 2, 3)));
+extern int dev_warn(const struct device *dev, const char *fmt, ...)
+ __attribute__ ((format (printf, 2, 3)));
+extern int dev_notice(const struct device *dev, const char *fmt, ...)
+ __attribute__ ((format (printf, 2, 3)));
+extern int _dev_info(const struct device *dev, const char *fmt, ...)
+ __attribute__ ((format (printf, 2, 3)));
+
+#else
+
+static inline int dev_printk(const char *level, const struct device *dev,
+ const char *fmt, ...)
+ __attribute__ ((format (printf, 3, 4)));
+static inline int dev_printk(const char *level, const struct device *dev,
+ const char *fmt, ...)
+ { return 0; }
+
+static inline int dev_emerg(const struct device *dev, const char *s, ...)
+ __attribute__ ((format (printf, 2, 3)));
+static inline int dev_emerg(const struct device *dev, const char *s, ...)
+ { return 0; }
+static inline int dev_crit(const struct device *dev, const char *s, ...)
+ __attribute__ ((format (printf, 2, 3)));
+static inline int dev_crit(const struct device *dev, const char *s, ...)
+ { return 0; }
+static inline int dev_alert(const struct device *dev, const char *s, ...)
+ __attribute__ ((format (printf, 2, 3)));
+static inline int dev_alert(const struct device *dev, const char *s, ...)
+ { return 0; }
+static inline int dev_err(const struct device *dev, const char *s, ...)
+ __attribute__ ((format (printf, 2, 3)));
+static inline int dev_err(const struct device *dev, const char *s, ...)
+ { return 0; }
+static inline int dev_warn(const struct device *dev, const char *s, ...)
+ __attribute__ ((format (printf, 2, 3)));
+static inline int dev_warn(const struct device *dev, const char *s, ...)
+ { return 0; }
+static inline int dev_notice(const struct device *dev, const char *s, ...)
+ __attribute__ ((format (printf, 2, 3)));
+static inline int dev_notice(const struct device *dev, const char *s, ...)
+ { return 0; }
+static inline int _dev_info(const struct device *dev, const char *s, ...)
+ __attribute__ ((format (printf, 2, 3)));
+static inline int _dev_info(const struct device *dev, const char *s, ...)
+ { return 0; }
+
+#endif
+
+#define dev_info(dev, fmt, arg...) _dev_info(dev, fmt, ##arg)
+/* workaround for existing struct dev_info and variable dev_info uses */
#if defined(DEBUG)
#define dev_dbg(dev, format, arg...) \
- dev_printk(KERN_DEBUG , dev , format , ## arg)
+ dev_printk(KERN_DEBUG, dev, format, ##arg)
#elif defined(CONFIG_DYNAMIC_DEBUG)
-#define dev_dbg(dev, format, ...) do { \
+#define dev_dbg(dev, format, ...) \
+do { \
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
- } while (0)
+} while (0)
#else
-#define dev_dbg(dev, format, arg...) \
- ({ if (0) dev_printk(KERN_DEBUG, dev, format, ##arg); 0; })
+#define dev_dbg(dev, format, arg...) \
+({ \
+ if (0) \
+ dev_printk(KERN_DEBUG, dev, format, ##arg); \
+ 0; \
+})
#endif
#ifdef VERBOSE_DEBUG
#define dev_vdbg dev_dbg
#else
-
-#define dev_vdbg(dev, format, arg...) \
- ({ if (0) dev_printk(KERN_DEBUG, dev, format, ##arg); 0; })
+#define dev_vdbg(dev, format, arg...) \
+({ \
+ if (0) \
+ dev_printk(KERN_DEBUG, dev, format, ##arg); \
+ 0; \
+})
#endif
/*
--
1.7.0.14.g7e948
^ permalink raw reply related
* Re: [PATCH 2/3] device.h drivers/base/core.c Convert dev_<level> macros to functions
From: Andrew Morton @ 2010-03-05 7:10 UTC (permalink / raw)
To: Joe Perches; +Cc: Linus Torvalds, Greg Kroah-Hartman, linux-kernel, netdev
In-Reply-To: <e18f5d8b8a0857a07918107f464a653234a47564.1267771398.git.joe@perches.com>
On Thu, 4 Mar 2010 22:56:53 -0800 Joe Perches <joe@perches.com> wrote:
> Perhaps over time the struct and local uses of dev_info should be renamed.
aww, c'mon.
y:/usr/src/linux-2.6.33> grep -r '\*dev_info;' . | wc -l
30
Half an hour, tops.
^ permalink raw reply
* Re: [PATCH 2/3] device.h drivers/base/core.c Convert dev_<level> macros to functions
From: Joe Perches @ 2010-03-05 7:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, Greg Kroah-Hartman, linux-kernel, netdev
In-Reply-To: <20100304231047.4d76e0ef.akpm@linux-foundation.org>
On Thu, 2010-03-04 at 23:10 -0800, Andrew Morton wrote:
> On Thu, 4 Mar 2010 22:56:53 -0800 Joe Perches <joe@perches.com> wrote:
> > Perhaps over time the struct and local uses of dev_info should be renamed.
> aww, c'mon.
> y:/usr/src/linux-2.6.33> grep -r '\*dev_info;' . | wc -l
> 30
No doubt I could submit all the required changes in
an hour or so, but some of the maintainers seem
less than open to what they consider "churn".
$ grep -rP --include=*.[ch] -l "dev_info\b\s*[^\(]" *
arch/powerpc/platforms/iseries/dt.c
drivers/usb/host/xhci-dbg.c
drivers/usb/host/xhci.h
drivers/usb/wusbcore/wusbhc.h
drivers/scsi/scsi_devinfo.c
drivers/staging/comedi/drivers/das08_cs.c
drivers/staging/comedi/drivers/ni_daq_dio24.c
drivers/staging/comedi/drivers/quatech_daqp_cs.c
drivers/staging/comedi/drivers/ni_daq_700.c
drivers/staging/comedi/drivers/ni_labpc_cs.c
drivers/staging/comedi/drivers/cb_das16_cs.c
drivers/staging/udlfb/udlfb.c
drivers/media/video/sh_mobile_ceu_camera.c
drivers/md/linear.h
drivers/net/ksz884x.c
drivers/net/bnx2x_link.c
drivers/net/wireless/wl3501_cs.c
drivers/net/cnic.c
drivers/net/bnx2x_main.c
include/linux/sfi.h
include/net/bluetooth/rfcomm.h
^ permalink raw reply
* Re: [PATCH 2/3] device.h drivers/base/core.c Convert dev_<level> macros to functions
From: Andrew Morton @ 2010-03-05 7:29 UTC (permalink / raw)
To: Joe Perches; +Cc: Linus Torvalds, Greg Kroah-Hartman, linux-kernel, netdev
In-Reply-To: <1267773815.2136.10.camel@Joe-Laptop.home>
On Thu, 04 Mar 2010 23:23:35 -0800 Joe Perches <joe@perches.com> wrote:
> On Thu, 2010-03-04 at 23:10 -0800, Andrew Morton wrote:
> > On Thu, 4 Mar 2010 22:56:53 -0800 Joe Perches <joe@perches.com> wrote:
> > > Perhaps over time the struct and local uses of dev_info should be renamed.
> > aww, c'mon.
> > y:/usr/src/linux-2.6.33> grep -r '\*dev_info;' . | wc -l
> > 30
>
> No doubt I could submit all the required changes in
> an hour or so, but some of the maintainers seem
> less than open to what they consider "churn".
Well, that has to be one of the worst possible reasons?
> $ grep -rP --include=*.[ch] -l "dev_info\b\s*[^\(]" *
> arch/powerpc/platforms/iseries/dt.c
> drivers/usb/host/xhci-dbg.c
> drivers/usb/host/xhci.h
> drivers/usb/wusbcore/wusbhc.h
> drivers/scsi/scsi_devinfo.c
> drivers/staging/comedi/drivers/das08_cs.c
> drivers/staging/comedi/drivers/ni_daq_dio24.c
> drivers/staging/comedi/drivers/quatech_daqp_cs.c
> drivers/staging/comedi/drivers/ni_daq_700.c
> drivers/staging/comedi/drivers/ni_labpc_cs.c
> drivers/staging/comedi/drivers/cb_das16_cs.c
> drivers/staging/udlfb/udlfb.c
> drivers/media/video/sh_mobile_ceu_camera.c
> drivers/md/linear.h
> drivers/net/ksz884x.c
> drivers/net/bnx2x_link.c
> drivers/net/wireless/wl3501_cs.c
> drivers/net/cnic.c
> drivers/net/bnx2x_main.c
> include/linux/sfi.h
> include/net/bluetooth/rfcomm.h
Send 'em over, please. I'll merge any stragglers directly.
^ permalink raw reply
* Re: KS8695: possible NAPI issue
From: Yegor Yefremov @ 2010-03-05 10:06 UTC (permalink / raw)
To: figo zhang; +Cc: Dick Hollenbeck, netdev, zealcook
In-Reply-To: <c6ed1ac51003042254g27f65f9dhd9bd731e05a9518@mail.gmail.com>
On Fri, Mar 5, 2010 at 7:54 AM, figo zhang <figo1802@gmail.com> wrote:
> 2010/3/4 Yegor Yefremov <yegorslists@googlemail.com>:
>>>>> I'm using 2.6.33 kernel and I noticed such a strange behavior:
>>>>>
>>>>> after system start I transfer one file via netcat from my development
>>>>> host, after this transfer the network is not functioning i.e. no pings
>>>>> possible etc.
>>>>>
>>>>> To narrow down the problem I checked out this commit
>>>>>
>>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=451f14439847db302e5104c44458b2dbb4b1829d.
>>>>> Till here the network driver is functioning as intended, but after
>>>>> NAPI introduction I have this issue. With latest git-pull of "Linus'
>>>>> kernel tree" I can't even ping right after the systems start.
>>>>>
>>>>> Any Ideas? What am I missing?
>>>>>
>>>>
>>>> No idea, although I am using the same ARM chip, my kernel is at 2.6.30.5,
>>>> and except for this occasional loss of connection I get, the ethernet driver
>>>> seems to work better than what you are reporting.
>>>
>>> from linux-2.6.32, this ethernet driver have add NAPI support, would
>>> you like to
>>> try using this version?
>>
>> Figo, I just looked at the 2.6.32 kernel and found out that it
>> doesn't' contain NAPI support (see the history
>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=history;f=drivers/net/arm/ks8695net.c;h=2a7b7745cc55b54cefada690b0ea47865b54b6b9;hb=HEAD).
>> So 2.6.33 is the first stable kernel to support NAPI.
>>
>> I made some further tests but I can't find the reason for network
>> failures: the interrupts are coming and the packets will be received
>> and sent so that rx/tx counters would be increased, but none of them
>> seem to reach the IP stack. I don't know where and why the things get
>> desynchronized.
>>
>> Could you try the 2.6.33 or Linus tree? Thank you in advance.
>
> yes, i have test it on linux-2.6.33, it is work well.
Thanks for testing. What kind of tests have you made? And with what data amount?
My tests look like following:
1. system start
2. ping one host: O.K.
3. nc -l -p 5000 > /var/test (about 1Mb): O.K.
4. ping the same host: failed
and even if the fourth test succeeds, if I then send a file from other
host the next ping or any other communication fails. I just tried to
make some SSH sessions. It goes without a problem till I issue a ping
after that.
If I test the system with nuttcp I have no problem.
Do you have any idea how to debug this? If I remove the NAPI support I
have no problem with the same kernel and environment. I'd really like
to get the whole stuff working.
Regards,
Yegor
^ permalink raw reply
* RE: [PATCH V3 5/8] sctp: use limited socket backlog
From: Zhu, Yi @ 2010-03-05 11:05 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem@davemloft.net, netdev@vger.kernel.org, Vlad Yasevich,
Sridhar Samudrala
In-Reply-To: <1267770483.2867.6.camel@edumazet-laptop>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> As advertized by comment, we should hold the association *before*
> accessing backlog queue.
> If order is not important, comment should be relaxed somehow ?
I don't see how the order is important here. We are under sock_lock
here thus nobody will race with us. IMHO, the comment talks about
if a packet is queued into the backlog, we need to increase the assoc/ep
reference count. Otherwise the assoc/ep might be disappeared when
we are about to process it (by sctp_backlog_rcv) sometime later.
Thanks,
-yi
^ permalink raw reply
* Re: [PATCH kernel 2.6.32-rc5] pcnet_cs: add cis of PreMax PE-200 ethernet pcmcia card
From: Ken Kawasaki @ 2010-03-05 11:21 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, David Woodhouse
In-Reply-To: <1267747341.2819.177.camel@localhost>
Hi,
> The CIS files under firmware/ are, according to firmware/WHENCE,
> 'developed by the pcmcia-cs project'. So I had a look at what's left of
> the pcmcia-cs project and its last release, and found that it includes:
>
> - the tool 'pack_cis' which compiles a text version of CIS to the
> standard binary format
> - text versions of most of the CIS files
>
> Since the text versions contain comments which are excluded from the
> binary format, I believe they should be considered the 'preferred form
> for modification' and included in the linux-2.6 and linux-firmware trees
> along with the binaries.
>
Actually, it is better to build CIS by "pack_cis /lib/firmware/cis/src/xxx.cis"
instead of "IHEX /lib/firmware/cis/xxx.cis".
In that case, the "pack_cis" tool should be included in the kernel-tree.
Ken.
^ permalink raw reply
* Re:[PATCH kernel 2.6.32-rc5] pcnet_cs: add cis of PreMax PE-200 ethernet pcmcia card
From: Ken Kawasaki @ 2010-03-05 12:01 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, David Woodhouse
In-Reply-To: <20100305202153.fb39cd64.ken_kawasaki@spring.nifty.jp>
Hi,
> The CIS files under firmware/ are, according to firmware/WHENCE,
> 'developed by the pcmcia-cs project'. So I had a look at what's left of
> the pcmcia-cs project and its last release, and found that it includes:
>
> - the tool 'pack_cis' which compiles a text version of CIS to the
> standard binary format
> - text versions of most of the CIS files
>
> Since the text versions contain comments which are excluded from the
> binary format, I believe they should be considered the 'preferred form
> for modification' and included in the linux-2.6 and linux-firmware trees
> along with the binaries.
>
Actually, it is better to build CIS by "pack_cis firmware/cis/src/xxx.cis"
instead of "IHEX firmware/cis/xxx.cis".
In that case, the "pack_cis" tool should be included in the kernel-tree.
Ken.
^ permalink raw reply
* [PATCH] e1000e: fix packet corruption and tx hang during NFSv2
From: Jeff Kirsher @ 2010-03-05 12:21 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, nhorman, Jesse Brandeburg, Jeff Kirsher
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
when receiving a particular type of NFS v2 UDP traffic, the hardware could
DMA some bad data and then hang, possibly corrupting memory.
Disable the NFS parsing in this hardware, verified to fix the bug.
Originally reported and reproduced by RedHat's Neil Horman
CC: nhorman@tuxdriver.com
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/defines.h | 2 ++
drivers/net/e1000e/ich8lan.c | 10 ++++++++++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000e/defines.h b/drivers/net/e1000e/defines.h
index db05ec3..e301e26 100644
--- a/drivers/net/e1000e/defines.h
+++ b/drivers/net/e1000e/defines.h
@@ -320,6 +320,8 @@
#define E1000_RXCSUM_IPPCSE 0x00001000 /* IP payload checksum enable */
/* Header split receive */
+#define E1000_RFCTL_NFSW_DIS 0x00000040
+#define E1000_RFCTL_NFSR_DIS 0x00000080
#define E1000_RFCTL_ACK_DIS 0x00001000
#define E1000_RFCTL_EXTEN 0x00008000
#define E1000_RFCTL_IPV6_EX_DIS 0x00010000
diff --git a/drivers/net/e1000e/ich8lan.c b/drivers/net/e1000e/ich8lan.c
index 54d03a0..8b5e157 100644
--- a/drivers/net/e1000e/ich8lan.c
+++ b/drivers/net/e1000e/ich8lan.c
@@ -2740,6 +2740,16 @@ static void e1000_initialize_hw_bits_ich8lan(struct e1000_hw *hw)
reg &= ~(1 << 31);
ew32(STATUS, reg);
}
+
+ /*
+ * work-around descriptor data corruption issue during nfs v2 udp
+ * traffic, just disable the nfs filtering capability
+ */
+ reg = er32(RFCTL);
+ reg |= (E1000_RFCTL_NFSW_DIS | E1000_RFCTL_NFSR_DIS);
+ ew32(RFCTL, reg);
+
+ return;
}
/**
^ permalink raw reply related
* radvd 1.6 released
From: Pekka Savola @ 2010-03-05 12:28 UTC (permalink / raw)
To: netdev, radvd-announce-l
Hello,
A new version of radvd has been released. This contains a couple of
bug fixes and some new functionality. Thanks to everyone who
contributed patches (below).
* Decrease MSG_SIZE from 4096 to about 1500B. Send buffer uses a
smaller size in order to avoid sending out fragmented packets, yet
being able to receive full-size frames.
* Keep track of buffer size and exit if the number of
prefixes/routes/etc. would grow too much. Prevent a memory corruption
due to wrong memset. Patches from Jan Gorig, Red Hat bug #554125.
* On BSD use getifaddrs() also in setup_deviceinfo(), fixes a
multiple interfaces problem on NetBSD 5 due to change in data
structures. Patch from Michael Stapelberg.
* Allow radvd.conf prefix, clients, route, and RDNSS options to be
in any order. Patch from Michael Stapelberg.
Get it at: http://www.litech.org/radvd/
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
^ permalink raw reply
* Re: Re:[PATCH kernel 2.6.32-rc5] pcnet_cs: add cis of PreMax PE-200 ethernet pcmcia card
From: Ben Hutchings @ 2010-03-05 12:46 UTC (permalink / raw)
To: Ken Kawasaki; +Cc: netdev, David Woodhouse
In-Reply-To: <20100305210151.b27ce31a.ken_kawasaki@spring.nifty.jp>
[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]
On Fri, 2010-03-05 at 21:01 +0900, Ken Kawasaki wrote:
> Hi,
>
> > The CIS files under firmware/ are, according to firmware/WHENCE,
> > 'developed by the pcmcia-cs project'. So I had a look at what's left of
> > the pcmcia-cs project and its last release, and found that it includes:
> >
> > - the tool 'pack_cis' which compiles a text version of CIS to the
> > standard binary format
> > - text versions of most of the CIS files
> >
> > Since the text versions contain comments which are excluded from the
> > binary format, I believe they should be considered the 'preferred form
> > for modification' and included in the linux-2.6 and linux-firmware trees
> > along with the binaries.
> >
>
> Actually, it is better to build CIS by "pack_cis firmware/cis/src/xxx.cis"
> instead of "IHEX firmware/cis/xxx.cis".
>
> In that case, the "pack_cis" tool should be included in the kernel-tree.
We don't include other firmware-building tools in the tree, even where
they are free software. Why this one?
Ben.
--
Ben Hutchings
Q. Which is the greater problem in the world today, ignorance or apathy?
A. I don't know and I couldn't care less.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH] Fix netdev_printk null dereference
From: Steve Glendinning @ 2010-03-05 12:47 UTC (permalink / raw)
To: netdev
This patch fixes a reproducible null dereference in smsc95xx (and I
suspect others) when the device is removed during a control register
access. This can be reproduced by rapidly plugging and unplugging
the device during its initialisation.
Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
---
include/linux/netdevice.h | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index c79a88b..250dbc0 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2132,9 +2132,10 @@ static inline const char *netdev_name(const struct net_device *dev)
}
#define netdev_printk(level, netdev, format, args...) \
- dev_printk(level, (netdev)->dev.parent, \
+ ({ if ((netdev)->dev.parent) \
+ dev_printk(level, (netdev)->dev.parent, \
"%s: " format, \
- netdev_name(netdev), ##args)
+ netdev_name(netdev), ##args); })
#define netdev_emerg(dev, format, args...) \
netdev_printk(KERN_EMERG, dev, format, ##args)
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH V3 4/8] llc: use limited socket backlog
From: Arnaldo Carvalho de Melo @ 2010-03-05 13:00 UTC (permalink / raw)
To: Zhu Yi; +Cc: davem, netdev
In-Reply-To: <1267761707-15605-4-git-send-email-yi.zhu@intel.com>
Em Fri, Mar 05, 2010 at 12:01:43PM +0800, Zhu Yi escreveu:
> Make llc adapt to the limited socket backlog change.
>
> Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
> Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
^ permalink raw reply
* Re: [PATCH] e1000e: fix packet corruption and tx hang during NFSv2
From: Neil Horman @ 2010-03-05 13:18 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, Jesse Brandeburg
In-Reply-To: <20100305122131.8250.21132.stgit@localhost.localdomain>
On Fri, Mar 05, 2010 at 04:21:44AM -0800, Jeff Kirsher wrote:
> From: Jesse Brandeburg <jesse.brandeburg@intel.com>
>
> when receiving a particular type of NFS v2 UDP traffic, the hardware could
> DMA some bad data and then hang, possibly corrupting memory.
>
> Disable the NFS parsing in this hardware, verified to fix the bug.
>
> Originally reported and reproduced by RedHat's Neil Horman
> CC: nhorman@tuxdriver.com
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* RE: [PATCH V3 5/8] sctp: use limited socket backlog
From: Eric Dumazet @ 2010-03-05 13:24 UTC (permalink / raw)
To: Zhu, Yi
Cc: davem@davemloft.net, netdev@vger.kernel.org, Vlad Yasevich,
Sridhar Samudrala
In-Reply-To: <DA586906BA1FFC4384FCFD6429ECE860A4604767@shzsmsx502.ccr.corp.intel.com>
Le vendredi 05 mars 2010 à 19:05 +0800, Zhu, Yi a écrit :
> I don't see how the order is important here. We are under sock_lock
> here thus nobody will race with us. IMHO, the comment talks about
> if a packet is queued into the backlog, we need to increase the assoc/ep
> reference count. Otherwise the assoc/ep might be disappeared when
> we are about to process it (by sctp_backlog_rcv) sometime later.
>
OK then.
Its strange this protocol has to increase a refcount for each queued
frame in its backlog, but this is unrelated to your changes anyway.
^ permalink raw reply
* Re: [PATCH V3 1/8] net: add limit for socket backlog
From: Arnaldo Carvalho de Melo @ 2010-03-05 13:00 UTC (permalink / raw)
To: Zhu Yi
Cc: davem, netdev, Pekka Savola (ipv6), Patrick McHardy,
Vlad Yasevich, Sridhar Samudrala, Jon Maloy, Allan Stephens,
Andrew Hendry, Eric Dumazet
In-Reply-To: <1267761707-15605-1-git-send-email-yi.zhu@intel.com>
Em Fri, Mar 05, 2010 at 12:01:40PM +0800, Zhu Yi escreveu:
> We got system OOM while running some UDP netperf testing on the loopback
> device. The case is multiple senders sent stream UDP packets to a single
> receiver via loopback on local host. Of course, the receiver is not able
> to handle all the packets in time. But we surprisingly found that these
> packets were not discarded due to the receiver's sk->sk_rcvbuf limit.
> Instead, they are kept queuing to sk->sk_backlog and finally ate up all
> the memory. We believe this is a secure hole that a none privileged user
> can crash the system.
>
> The root cause for this problem is, when the receiver is doing
> __release_sock() (i.e. after userspace recv, kernel udp_recvmsg ->
> skb_free_datagram_locked -> release_sock), it moves skbs from backlog to
> sk_receive_queue with the softirq enabled. In the above case, multiple
> busy senders will almost make it an endless loop. The skbs in the
> backlog end up eat all the system memory.
>
> The issue is not only for UDP. Any protocols using socket backlog is
> potentially affected. The patch adds limit for socket backlog so that
> the backlog size cannot be expanded endlessly.
>From visual inspection (no testing):
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
- Arnaldo
^ permalink raw reply
* Re: [PATCH V3 5/8] sctp: use limited socket backlog
From: Vlad Yasevich @ 2010-03-05 13:30 UTC (permalink / raw)
To: Zhu, Yi
Cc: Eric Dumazet, davem@davemloft.net, netdev@vger.kernel.org,
Sridhar Samudrala
In-Reply-To: <DA586906BA1FFC4384FCFD6429ECE860A4604767@shzsmsx502.ccr.corp.intel.com>
Zhu, Yi wrote:
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> As advertized by comment, we should hold the association *before*
>> accessing backlog queue.
>
>> If order is not important, comment should be relaxed somehow ?
>
> I don't see how the order is important here. We are under sock_lock
> here thus nobody will race with us. IMHO, the comment talks about
> if a packet is queued into the backlog, we need to increase the assoc/ep
> reference count. Otherwise the assoc/ep might be disappeared when
> we are about to process it (by sctp_backlog_rcv) sometime later.
>
> Thanks,
> -yi
Yes, that's correct. The order is not really important since we
are under lock and are actually already holding a ref. However
the ref will be dropped once we exit the function, so the function
takes an additional ref that is held while the packet is backloged.
You could get rid of the extra nesting though by returning early
if backlog failed.
-vlad
^ permalink raw reply
* Re: KS8695: possible NAPI issue
From: Figo.zhang @ 2010-03-05 13:52 UTC (permalink / raw)
To: Yegor Yefremov; +Cc: Dick Hollenbeck, netdev, zealcook
In-Reply-To: <f69abfc31003050206h4f9ffe65s2b90e6acea014ec2@mail.gmail.com>
>
> and even if the fourth test succeeds, if I then send a file from other
> host the next ping or any other communication fails. I just tried to
> make some SSH sessions. It goes without a problem till I issue a ping
> after that.
>
> If I test the system with nuttcp I have no problem.
the network driver seems work well for system. the "netcat" application
is build in busybox? you can check busybox configure.
>
> Do you have any idea how to debug this? If I remove the NAPI support I
> have no problem with the same kernel and environment. I'd really like
> to get the whole stuff working.
>
> Regards,
> Yegor
^ permalink raw reply
* Re: KS8695: possible NAPI issue
From: Figo.zhang @ 2010-03-05 14:07 UTC (permalink / raw)
To: Yegor Yefremov; +Cc: Dick Hollenbeck, netdev, zealcook
In-Reply-To: <f69abfc31003050206h4f9ffe65s2b90e6acea014ec2@mail.gmail.com>
>
> My tests look like following:
>
> 1. system start
> 2. ping one host: O.K.
> 3. nc -l -p 5000 > /var/test (about 1Mb): O.K.
> 4. ping the same host: failed
1. type "arp" command, see the arp is exit or expire?
2. at this point, see is it still have RX interrpt and receive packet in
ks8695_rx()? (in some watchpoint add printk).
>
> and even if the fourth test succeeds, if I then send a file from other
> host the next ping or any other communication fails. I just tried to
> make some SSH sessions. It goes without a problem till I issue a ping
> after that.
>
> If I test the system with nuttcp I have no problem.
>
> Do you have any idea how to debug this? If I remove the NAPI support I
> have no problem with the same kernel and environment. I'd really like
> to get the whole stuff working.
>
> Regards,
> Yegor
^ permalink raw reply
* Re: [PATCH] s2io: fixing DBG_PRINT() macro
From: Breno Leitao @ 2010-03-05 14:21 UTC (permalink / raw)
To: David Miller; +Cc: sreenivasa.honnur, joe, netdev
In-Reply-To: <1267623697-14781-1-git-send-email-leitao@linux.vnet.ibm.com>
David,
Due my mistake I didn't send this patch to Sreenivasa. After
sending this patch to netdev, I forward to him, and
he acked it privately.
Sorry for the confusion.
Thanks,
Breno
leitao@linux.vnet.ibm.com wrote:
> Patch 9e39f7c5b311a306977c5471f9e2ce4c456aa038 changed the
> DBG_PRINT() macro and the if clause was changed. It means
> that currently all the DBG_PRINT are being printed, flooding
> the kernel log buffer with thinkgs like:
>
> s2io: eth6: Next block at: c0000000b9c90000
> s2io: eth6: In Neterion Tx routine
>
> This patch just fixes the if clause condition.
>
> Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
> ---
> drivers/net/s2io.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/s2io.h b/drivers/net/s2io.h
> index 47c36e0..3b6f45d 100644
> --- a/drivers/net/s2io.h
> +++ b/drivers/net/s2io.h
> @@ -65,7 +65,7 @@ static int debug_level = ERR_DBG;
>
> /* DEBUG message print. */
> #define DBG_PRINT(dbg_level, fmt, args...) do { \
> - if (dbg_level >= debug_level) \
> + if (dbg_level <= debug_level) \
> pr_info(fmt, ##args); \
> } while (0)
>
^ permalink raw reply
* Re: [PATCH] Fix netdev_printk null dereference
From: David Miller @ 2010-03-05 14:39 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev
In-Reply-To: <1267793225-426-1-git-send-email-steve.glendinning@smsc.com>
From: Steve Glendinning <steve.glendinning@smsc.com>
Date: Fri, 5 Mar 2010 12:47:05 +0000
> This patch fixes a reproducible null dereference in smsc95xx (and I
> suspect others) when the device is removed during a control register
> access. This can be reproduced by rapidly plugging and unplugging
> the device during its initialisation.
>
> Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
The parent shouldn't become NULL until the device is totally quiesced
and is no longer accesses.
Maybe you can instead fix the smsc95xx driver to abide by this rule
instead of adding a conditional check to thousands of other drivers in
the tree that do not need this?
I really have no intention of adding your change, please fix this
properly, thanks.
^ permalink raw reply
* Re: [PATCH] Fix netdev_printk null dereference
From: Joe Perches @ 2010-03-05 14:50 UTC (permalink / raw)
To: David Miller; +Cc: steve.glendinning, netdev
In-Reply-To: <20100305.063909.26489418.davem@davemloft.net>
On Fri, 2010-03-05 at 06:39 -0800, David Miller wrote:
> From: Steve Glendinning <steve.glendinning@smsc.com>
> Date: Fri, 5 Mar 2010 12:47:05 +0000
>
> > This patch fixes a reproducible null dereference in smsc95xx (and I
> > suspect others) when the device is removed during a control register
> > access. This can be reproduced by rapidly plugging and unplugging
> > the device during its initialisation.
> >
> > Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
>
> The parent shouldn't become NULL until the device is totally quiesced
> and is no longer accesses.
>
> Maybe you can instead fix the smsc95xx driver to abide by this rule
> instead of adding a conditional check to thousands of other drivers in
> the tree that do not need this?
>
> I really have no intention of adding your change, please fix this
> properly, thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Perhaps something like this is appropriate in the mean time:
const char *get_netdev_parent_name(const struct net_device *dev)
{
if (!dev->dev.parent)
return "Unparented net_device, please report this";
return netdev->dev.parent;
}
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox