* Get rid of everything you owe without paying another dime
From: jamie barnes @ 2005-10-06 21:22 UTC (permalink / raw)
To: Phung Green
Cc: owner-lkcd, bowman, xfs-master, outgoing, ralf, netdev,
bugzilla-daemon
Eliminate all you are indebted for with out paying another cent. End the
calls. Bring a stop to the sending of checks! As it turns out most lending
orgizations are doing something illegal. Incredible but right! Visit our web
site for detailed information on the subject our system at N O expense or
requirement. You have naught to lose and heaps to gain.
http://uk.geocities.com/blossom_regan/?re=bVT.Eradicate all that you owe
without sending an other dime
Exhaustive information or to stop receiving or to comprehend postal address
Before the surprised and baffled scientist could collect himself
sufficiently to reply, the boy was soaring far above his head and searching
for a convenient place to alight, that he might investigate the charms of
this famed city of Paris. It was indeed a beautiful place, with many stately
buildings lining the shady boulevards
So thronged were the streets that Rob well knew he would soon be the center
of a curious crowd should he alight upon them
^ permalink raw reply
* [RFC] ipw2200: check version in eeprom correctly
From: Alexey Dobriyan @ 2005-10-06 21:40 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
I'm not 100% sure the fix is right, but the condition looks bogus:
->eeprom is "u8 eeprom[256]".
drivers/net/wireless/ipw2200.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- ./drivers/net/wireless/ipw2200.c
+++ ./drivers/net/wireless/ipw2200.c
@@ -1699,7 +1699,7 @@ static void ipw_eeprom_init_sram(struct
copy. Otherwise let the firmware know to perform the operation
on it's own
*/
- if ((priv->eeprom + EEPROM_VERSION) != 0) {
+ if ((priv->eeprom[EEPROM_VERSION]) != 0) {
IPW_DEBUG_INFO("Writing EEPROM data into SRAM\n");
/* write the eeprom data to sram */
^ permalink raw reply
* [KJ] [PATCH] starfire: free_irq() on error path of netdev_open()
From: Alexey Dobriyan @ 2005-10-06 22:05 UTC (permalink / raw)
To: Ion Badulescu; +Cc: netdev, kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 705 bytes --]
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
drivers/net/starfire.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- ./drivers/net/starfire.c
+++ ./drivers/net/starfire.c
@@ -1091,8 +1091,10 @@ static int netdev_open(struct net_device
rx_ring_size = sizeof(struct starfire_rx_desc) * RX_RING_SIZE;
np->queue_mem_size = tx_done_q_size + rx_done_q_size + tx_ring_size + rx_ring_size;
np->queue_mem = pci_alloc_consistent(np->pci_dev, np->queue_mem_size, &np->queue_mem_dma);
- if (np->queue_mem == 0)
+ if (np->queue_mem == 0) {
+ free_irq(dev->irq, dev);
return -ENOMEM;
+ }
np->tx_done_q = np->queue_mem;
np->tx_done_q_dma = np->queue_mem_dma;
[-- Attachment #2: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Re: [ANNOUNCE] linux-net wiki
From: Greg KH @ 2005-10-07 1:24 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, linux-net, linux-kernel
In-Reply-To: <20051006140007.43262f04@dxpl.pdx.osdl.net>
On Thu, Oct 06, 2005 at 02:00:07PM -0700, Stephen Hemminger wrote:
> There is now a wiki for Linux networking related activities and documentation.
> http://linux-net.osdl.org
> This is an experiment to see if it would be more useful to have
> an online and editable documentation source rather than bits and pieces.
Why not just work with the existing kernelnewbies wiki:
http://wiki.kernelnewbies.org
instead of creating another site?
thanks,
greg k-h
^ permalink raw reply
* Re: [ANNOUNCE] linux-net wiki
From: Ian McDonald @ 2005-10-07 1:34 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Hemminger, netdev, linux-net, linux-kernel
In-Reply-To: <20051007012454.GA9509@kroah.com>
>
> Why not just work with the existing kernelnewbies wiki:
> http://wiki.kernelnewbies.org
> instead of creating another site?
>
Having a quick look around and looking at the name in particular I
think they are different target audiences...
If it was kerneloldies.org it might be different ;-)
Ian
^ permalink raw reply
* Re: [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance
From: Harald Welte @ 2005-10-07 2:38 UTC (permalink / raw)
To: Andi Kleen
Cc: Patrick McHardy, netdev, netfilter-devel, linux-kernel,
Henrik Nordstrom
In-Reply-To: <200510051853.32196.ak@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]
On Wed, Oct 05, 2005 at 06:53:31PM +0200, Andi Kleen wrote:
> On Tuesday 04 October 2005 19:01, Patrick McHardy wrote:
> > Andi Kleen wrote:
> > > In a sense it's even getting worse: For example us losing the CONFIG
> > > option to disable local conntrack (Patrick has disabled it some time ago
> > > without even a comment why he did it) has a really bad impact in some
> > > cases.
> >
> > It was necessary to correctly handle locally generated ICMP errors.
>
> Well you most likely wrecked local performance then when it's enabled.
so you would favour a system that incorrectly deals with ICMP errors but
has higher performance?
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH SECURITY]: orinoco: Information leakage due to incorrect padding
From: Jouni Malinen @ 2005-10-07 3:25 UTC (permalink / raw)
To: Pavel Roskin; +Cc: orinoco-devel, NetDev, Meder Kydyraliev
In-Reply-To: <1128475990.11708.21.camel@dv>
On Tue, Oct 04, 2005 at 09:33:10PM -0400, Pavel Roskin wrote:
> orinoco: Information leakage due to incorrect padding
>
> The orinoco driver can send uninitialized data exposing random pieces of
> the system memory. This happens because data is not padded with zeroes
> when its length needs to be increased.
Issue itself looks valid in the current implementation, but a better fix
would be to just remove the padding.
> - /* Length of the packet body */
> - /* FIXME: what if the skb is smaller than this? */
> - len = max_t(int,skb->len - ETH_HLEN, ETH_ZLEN - ETH_HLEN);
> + /* Check packet length, pad short packets, round up odd length */
> + len = max_t(int, ALIGN(skb->len, 2), ETH_ZLEN);
> + if (skb->len < len) {
> + skb = skb_padto(skb, len);
There is no ETH_ZLEN limit on IEEE 802.11 frames.
--
Jouni Malinen PGP id EFC895FA
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
^ permalink raw reply
* Re: [ANNOUNCE] linux-net wiki
From: Stephen Hemminger @ 2005-10-07 4:45 UTC (permalink / raw)
To: Greg KH; +Cc: netdev, linux-net, linux-kernel
In-Reply-To: <20051007012454.GA9509@kroah.com>
On Thu, 6 Oct 2005 18:24:54 -0700
Greg KH <greg@kroah.com> wrote:
> On Thu, Oct 06, 2005 at 02:00:07PM -0700, Stephen Hemminger wrote:
> > There is now a wiki for Linux networking related activities and documentation.
> > http://linux-net.osdl.org
> > This is an experiment to see if it would be more useful to have
> > an online and editable documentation source rather than bits and pieces.
>
> Why not just work with the existing kernelnewbies wiki:
> http://wiki.kernelnewbies.org
> instead of creating another site?
Mainly because I started it out for my own linux networking projects,
then generalized it. If you look on kernelnewbies you will see that
there was already an MM wiki.
^ permalink raw reply
* Re: [ANNOUNCE] linux-net wiki
From: Diego Calleja @ 2005-10-07 8:15 UTC (permalink / raw)
To: Ian McDonald; +Cc: greg, shemminger, netdev, linux-net, linux-kernel, riel
In-Reply-To: <cbec11ac0510061834j53678e7cq@mail.gmail.com>
El Fri, 7 Oct 2005 14:34:10 +1300,
Ian McDonald <imcdnzl@gmail.com> escribió:
> >
> > Why not just work with the existing kernelnewbies wiki:
> > http://wiki.kernelnewbies.org
> > instead of creating another site?
> >
> Having a quick look around and looking at the name in particular I
> think they are different target audiences...
The fact that it's called "kernelnewbies" doesn't meant it's targetted only
to non-expert people - everybody, including me, you, Linus and all the "core"
kernel hackers are "newbies" WRT to some parts of the kernel. The one thing
that can keep someone being a newbie forever is considering himself an
"expert". In fact you can find some linux kernel "gurus" there...
Also, kernelnewbies is not linux-specific either so there's a chance that even
gurus could learn something interesting (and teach something to others).
Or at least that has always been the intention of the kernelnewbies project.
(That doesn't mean I'm against the linux-net wiki, I just wanted to point out
that kernelnewbies isn't just for "newbies" ;)
^ permalink raw reply
* Re: [PATCH SECURITY]: orinoco: Information leakage due to incorrect padding
From: Pavel Roskin @ 2005-10-07 13:39 UTC (permalink / raw)
To: Jouni Malinen; +Cc: orinoco-devel, NetDev, Meder Kydyraliev
In-Reply-To: <20051007032537.GB3936-mgr6C1c9aYeHXe+LvDLADg@public.gmane.org>
Hi, Jouni!
On Thu, 2005-10-06 at 20:25 -0700, Jouni Malinen wrote:
> On Tue, Oct 04, 2005 at 09:33:10PM -0400, Pavel Roskin wrote:
>
> > orinoco: Information leakage due to incorrect padding
> >
> > The orinoco driver can send uninitialized data exposing random pieces of
> > the system memory. This happens because data is not padded with zeroes
> > when its length needs to be increased.
>
> Issue itself looks valid in the current implementation, but a better fix
> would be to just remove the padding.
Thank you! With you and Jean saying that, I'm pretty much reassured
now :-)
I'll do it in Orinoco CVS soon and then I'll submit the patch.
The patch I posted is actually a simplified version of the patch
actually applied to the orinoco CVS, to make it as safe as possible for
Linux 2.6.14 inclusion.
--
Regards,
Pavel Roskin
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
^ permalink raw reply
* IPW2100 Kconfig is WRONG!
From: Alejandro Bonilla @ 2005-10-07 15:54 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, jketreno
Hi,
AGAIN, the location that the Kconfig of ipw2100 says to put the FW in
2.6.14-rc3-Git is WRONG. It should be /lib/firmware, not /etc/firmware.
I have already sent a patch with this and Jesper Juhl also signed it and sent
one in too. What did I/Jesper did wrong?
.Alejandro
^ permalink raw reply
* Re: [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance
From: Patrick McHardy @ 2005-10-07 17:08 UTC (permalink / raw)
To: Andi Kleen
Cc: Harald Welte, netdev, netfilter-devel, linux-kernel,
Henrik Nordstrom
In-Reply-To: <20051006175956.GI6642@verdi.suse.de>
Andi Kleen wrote:
> On Fri, Oct 07, 2005 at 04:38:02AM +0200, Harald Welte wrote:
>
>>On Wed, Oct 05, 2005 at 06:53:31PM +0200, Andi Kleen wrote:
>>
>>>Well you most likely wrecked local performance then when it's enabled.
There are lots of other hooks and conntrack/NAT already have a
quite large negative influence on performance. Do you have numbers
that show that enabling this actually causes more than a slight
decrease in performance? Besides, most distributors enable all
these options anyway, so it only makes a difference for a small
group of users.
>>so you would favour a system that incorrectly deals with ICMP errors but
>>has higher performance?
>
> I would favour a system where development doesn't lose sight of performance.
I don't think we do.
> Perhaps there would be other ways to fix this problem without impacting
> performance unduly? Can you describe it in detail?
When an ICMP error is send by the firewall itself, the inner
packet needs to be restored to its original state. That means
both DNAT and SNAT which might have been applied need to be
reversed. DNAT is reversed at places where we usually do
SNAT (POST_ROUTING), SNAT is reversed where usually DNAT is
done (PRE_ROUTING/LOCAL_OUT). Since locally generated packets
never go through PRE_ROUTING, it is done in LOCAL_OUT, which
required enabling NAT in LOCAL_OUT unconditionally. It might
be possible to move this to some different hook, I didn't
investigate it.
^ permalink raw reply
* Re: [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance
From: Andi Kleen @ 2005-10-07 17:21 UTC (permalink / raw)
To: Patrick McHardy
Cc: Harald Welte, netdev, netfilter-devel, linux-kernel,
Henrik Nordstrom
In-Reply-To: <4346AB94.4050006@trash.net>
On Friday 07 October 2005 19:08, Patrick McHardy wrote:
> There are lots of other hooks and conntrack/NAT already have a
> quite large negative influence on performance. Do you have numbers
> that show that enabling this actually causes more than a slight
> decrease in performance? Besides, most distributors enable all
> these options anyway, so it only makes a difference for a small
> group of users.
I don't know about other distributions but SUSE at some point
found that some web benchmarks dramatically improved in the default
configuration when local conntrack was off. It was off then since ever.
> > Perhaps there would be other ways to fix this problem without impacting
> > performance unduly? Can you describe it in detail?
>
> When an ICMP error is send by the firewall itself, the inner
> packet needs to be restored to its original state. That means
> both DNAT and SNAT which might have been applied need to be
> reversed. DNAT is reversed at places where we usually do
> SNAT (POST_ROUTING), SNAT is reversed where usually DNAT is
> done (PRE_ROUTING/LOCAL_OUT). Since locally generated packets
> never go through PRE_ROUTING, it is done in LOCAL_OUT, which
> required enabling NAT in LOCAL_OUT unconditionally. It might
> be possible to move this to some different hook, I didn't
> investigate it.
This sounds wrong anyways. You shouldn't be touching conntrack state for ICMPs
generated by routers because they can be temporary errors (e.g. during a
routing flap when the route moves). Only safe way to handle this is to wait
for the timeout which doesn't need local handling. And the firewall cannot be
an endhost here.
-Andi
^ permalink raw reply
* Re: [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance
From: Patrick McHardy @ 2005-10-07 17:50 UTC (permalink / raw)
To: Andi Kleen
Cc: Harald Welte, netdev, netfilter-devel, linux-kernel,
Henrik Nordstrom
In-Reply-To: <200510071921.40343.ak@suse.de>
Andi Kleen wrote:
> On Friday 07 October 2005 19:08, Patrick McHardy wrote:
>
> I don't know about other distributions but SUSE at some point
> found that some web benchmarks dramatically improved in the default
> configuration when local conntrack was off. It was off then since ever.
Interesting ..
>>When an ICMP error is send by the firewall itself, the inner
>>packet needs to be restored to its original state. That means
>>both DNAT and SNAT which might have been applied need to be
>>reversed. DNAT is reversed at places where we usually do
>>SNAT (POST_ROUTING), SNAT is reversed where usually DNAT is
>>done (PRE_ROUTING/LOCAL_OUT). Since locally generated packets
>>never go through PRE_ROUTING, it is done in LOCAL_OUT, which
>>required enabling NAT in LOCAL_OUT unconditionally. It might
>>be possible to move this to some different hook, I didn't
>>investigate it.
>
> This sounds wrong anyways. You shouldn't be touching conntrack state for ICMPs
> generated by routers because they can be temporary errors (e.g. during a
> routing flap when the route moves). Only safe way to handle this is to wait
> for the timeout which doesn't need local handling. And the firewall cannot be
> an endhost here.
You misunderstood me. Its not about conntrack state, its about
the inner packet contained in the ICMP message. If it was
NATed by the box itself before the ICMP message is generated,
it needs to be restored to its original state, otherwise the
receipient will ignore it.
^ permalink raw reply
* [ANNOUNCE] iproute2 (051007)
From: Stephen Hemminger @ 2005-10-07 22:43 UTC (permalink / raw)
To: netdev; +Cc: lartc
Fix one serious bug (in libnetlink), and a couple of other minor
patches.
http://developer.osdl.org/dev/iproute2/download/iproute2-051007.tar.gz
Stephen Hemminger
Reenable ip mroute
Mike Frysinger
Handle pfifo_fast that has no qopt without segfaulting
Mads Martin Joergensen
Trivial netem ccopts
Jerome Borsboom
Fix regression in ip addr (libnetlink) handling
--
Stephen Hemminger <shemminger@osdl.org>
OSDL http://developer.osdl.org/~shemminger
^ permalink raw reply
* [PATCH] ebtables: Port ebt_[u]log.c to nf[netlink]_log
From: Harald Welte @ 2005-10-07 23:49 UTC (permalink / raw)
To: Bart De Schuymer
Cc: Linux Netdev List,
ebtables-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
[-- Attachment #1: Type: text/plain, Size: 9794 bytes --]
Hi Bart!
The patch below is totally untested (though it compiles), and updates
ebtables to resemble the behaviour that we now have in ipv4 (and ipv6):
{ip,ip6,eb}tables just tell the nf_log core that they want to log a
packet, the mechanism (syslog, nfnetlink_log, ...) is actually decided
by nf_log.
By default, everything will behave like before.
Please review, and test that ebt_log and ebt_ulog are still working as
expected. Thanks!
[NETFILTER] ebtables: Port ebt_[u]log.c to nf[netlink]_log
Since we now have a netfilter core logging API, we port the bridging log
and ulog watchers to this new API.
This basically means that if you use the "ebt_log" watcher, it will by
default log to the system console, but enables a userspace logging daemon
binds itself to PF_BRIDGE, and take over all logging.
ebt_ulog also registers itself as logger with nf_log, but any packets
explicitly send to ebt_ulog will always use the ulog mechanism and not
handled via the generic logging handler.
This change resembles the situation that is now present in ipv4.
Signed-off-by: Harald Welte <laforge-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org>
---
commit 0dc2bc0656b4b1c5ba3524dadc8fbf36881903b7
tree 0e43d4f7b10f022ff523ea4751546d76d53c57b7
parent 2e64e94fe8e7e4630c9d9e66c437f3ba81e99f78
author Harald Welte <laforge-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org> Sat, 08 Oct 2005 01:43:49 +0200
committer Harald Welte <laforge-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org> Sat, 08 Oct 2005 01:43:49 +0200
net/bridge/netfilter/Kconfig | 6 +++-
net/bridge/netfilter/ebt_log.c | 61 +++++++++++++++++++++++++++++++++------
net/bridge/netfilter/ebt_ulog.c | 48 +++++++++++++++++++++++++++++--
3 files changed, 102 insertions(+), 13 deletions(-)
diff --git a/net/bridge/netfilter/Kconfig b/net/bridge/netfilter/Kconfig
--- a/net/bridge/netfilter/Kconfig
+++ b/net/bridge/netfilter/Kconfig
@@ -196,9 +196,13 @@ config BRIDGE_EBT_LOG
To compile it as a module, choose M here. If unsure, say N.
config BRIDGE_EBT_ULOG
- tristate "ebt: ulog support"
+ tristate "ebt: ulog support (OBSOLETE)"
depends on BRIDGE_NF_EBTABLES
help
+ This option enables the old bridge-specific "ebt_ulog" implementation
+ which has been obsoleted by the new "nfnetlink_log" code (see
+ CONFIG_NETFILTER_NETLINK_LOG).
+
This option adds the ulog watcher, that you can use in any rule
in any ebtables table. The packet is passed to a userspace
logging daemon using netlink multicast sockets. This differs
diff --git a/net/bridge/netfilter/ebt_log.c b/net/bridge/netfilter/ebt_log.c
--- a/net/bridge/netfilter/ebt_log.c
+++ b/net/bridge/netfilter/ebt_log.c
@@ -3,6 +3,7 @@
*
* Authors:
* Bart De Schuymer <bdschuym-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>
+ * Harald Welte <laforge-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org>
*
* April, 2002
*
@@ -10,6 +11,7 @@
#include <linux/netfilter_bridge/ebtables.h>
#include <linux/netfilter_bridge/ebt_log.h>
+#include <linux/netfilter.h>
#include <linux/module.h>
#include <linux/ip.h>
#include <linux/if_arp.h>
@@ -55,17 +57,19 @@ static void print_MAC(unsigned char *p)
}
#define myNIPQUAD(a) a[0], a[1], a[2], a[3]
-static void ebt_log(const struct sk_buff *skb, unsigned int hooknr,
- const struct net_device *in, const struct net_device *out,
- const void *data, unsigned int datalen)
+static void
+ebt_log_packet(unsigned int pf, unsigned int hooknum,
+ const struct sk_buff *skb, const struct net_device *in,
+ const struct net_device *out, const struct nf_loginfo *loginfo,
+ const char *prefix)
{
- struct ebt_log_info *info = (struct ebt_log_info *)data;
char level_string[4] = "< >";
+ unsigned int bitmask;
- level_string[1] = '0' + info->loglevel;
+ level_string[1] = '0' + loginfo->u.log.level;
spin_lock_bh(&ebt_log_lock);
printk(level_string);
- printk("%s IN=%s OUT=%s ", info->prefix, in ? in->name : "",
+ printk("%s IN=%s OUT=%s ", prefix, in ? in->name : "",
out ? out->name : "");
printk("MAC source = ");
@@ -75,7 +79,12 @@ static void ebt_log(const struct sk_buff
printk("proto = 0x%04x", ntohs(eth_hdr(skb)->h_proto));
- if ((info->bitmask & EBT_LOG_IP) && eth_hdr(skb)->h_proto ==
+ if (loginfo->type == NF_LOG_TYPE_LOG)
+ bitmask = loginfo->u.log.logflags;
+ else
+ bitmask = NF_LOG_MASK;
+
+ if ((bitmask & EBT_LOG_IP) && eth_hdr(skb)->h_proto ==
htons(ETH_P_IP)){
struct iphdr _iph, *ih;
@@ -104,7 +113,7 @@ static void ebt_log(const struct sk_buff
goto out;
}
- if ((info->bitmask & EBT_LOG_ARP) &&
+ if ((bitmask & EBT_LOG_ARP) &&
((eth_hdr(skb)->h_proto == htons(ETH_P_ARP)) ||
(eth_hdr(skb)->h_proto == htons(ETH_P_RARP)))) {
struct arphdr _arph, *ah;
@@ -144,6 +153,21 @@ static void ebt_log(const struct sk_buff
out:
printk("\n");
spin_unlock_bh(&ebt_log_lock);
+
+}
+
+static void ebt_log(const struct sk_buff *skb, unsigned int hooknr,
+ const struct net_device *in, const struct net_device *out,
+ const void *data, unsigned int datalen)
+{
+ struct ebt_log_info *info = (struct ebt_log_info *)data;
+ struct nf_loginfo li;
+
+ li.type = NF_LOG_TYPE_LOG;
+ li.u.log.level = info->loglevel;
+ li.u.log.logflags = info->bitmask;
+
+ nf_log_packet(PF_BRIDGE, hooknr, skb, in, out, &li, info->prefix);
}
static struct ebt_watcher log =
@@ -154,13 +178,32 @@ static struct ebt_watcher log =
.me = THIS_MODULE,
};
+static struct nf_logger ebt_log_logger = {
+ .name = "ebt_log",
+ .logfn = &ebt_log_packet,
+ .me = THIS_MODULE,
+};
+
static int __init init(void)
{
- return ebt_register_watcher(&log);
+ int ret;
+
+ ret = ebt_register_watcher(&log);
+ if (ret < 0)
+ return ret;
+ if (nf_log_register(PF_BRIDGE, &ebt_log_logger) < 0) {
+ printk(KERN_WARNING "ebt_log: not logging via system console "
+ "since somebody else already registered for PF_INET\n");
+ /* wecannot make module load fail here, since otherwise
+ * ebtables userspace would abort */
+ }
+
+ return 0;
}
static void __exit fini(void)
{
+ nf_log_unregister_logger(&ebt_log_logger);
ebt_unregister_watcher(&log);
}
diff --git a/net/bridge/netfilter/ebt_ulog.c b/net/bridge/netfilter/ebt_ulog.c
--- a/net/bridge/netfilter/ebt_ulog.c
+++ b/net/bridge/netfilter/ebt_ulog.c
@@ -3,6 +3,7 @@
*
* Authors:
* Bart De Schuymer <bdschuym-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>
+ * Harald Welte <laforge-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org>
*
* November, 2004
*
@@ -115,14 +116,13 @@ static struct sk_buff *ulog_alloc_skb(un
return skb;
}
-static void ebt_ulog(const struct sk_buff *skb, unsigned int hooknr,
+static void ebt_ulog_packet(unsigned int hooknr, const struct sk_buff *skb,
const struct net_device *in, const struct net_device *out,
- const void *data, unsigned int datalen)
+ const struct ebt_ulog_info *uloginfo, const char *prefix)
{
ebt_ulog_packet_msg_t *pm;
size_t size, copy_len;
struct nlmsghdr *nlh;
- struct ebt_ulog_info *uloginfo = (struct ebt_ulog_info *)data;
unsigned int group = uloginfo->nlgroup;
ebt_ulog_buff_t *ub = &ulog_buffers[group];
spinlock_t *lock = &ub->lock;
@@ -216,6 +216,39 @@ alloc_failure:
goto unlock;
}
+/* this function is registered with the netfilter core */
+static void ebt_log_packet(unsigned int pf, unsigned int hooknum,
+ const struct sk_buff *skb, const struct net_device *in,
+ const struct net_device *out, const struct nf_loginfo *li,
+ const char *prefix)
+{
+ struct ebt_ulog_info loginfo;
+
+ if (!li || li->type != NF_LOG_TYPE_ULOG) {
+ loginfo.nlgroup = EBT_ULOG_DEFAULT_NLGROUP;
+ loginfo.cprange = 0;
+ loginfo.qthreshold = EBT_ULOG_DEFAULT_QTHRESHOLD;
+ loginfo.prefix[0] = '\0';
+ } else {
+ loginfo.nlgroup = li->u.ulog.group;
+ loginfo.cprange = li->u.ulog.copy_len;
+ loginfo.qthreshold = li->u.ulog.qthreshold;
+ strlcpy(loginfo.prefix, prefix, sizeof(loginfo.prefix));
+ }
+
+ ebt_ulog_packet(hooknum, skb, in, out, &loginfo, prefix);
+}
+
+static void ebt_ulog(const struct sk_buff *skb, unsigned int hooknr,
+ const struct net_device *in, const struct net_device *out,
+ const void *data, unsigned int datalen)
+{
+ struct ebt_ulog_info *uloginfo = (struct ebt_ulog_info *)data;
+
+ ebt_ulog_packet(hooknr, skb, in, out, uloginfo, NULL);
+}
+
+
static int ebt_ulog_check(const char *tablename, unsigned int hookmask,
const struct ebt_entry *e, void *data, unsigned int datalen)
{
@@ -240,6 +273,12 @@ static struct ebt_watcher ulog = {
.me = THIS_MODULE,
};
+static struct nf_logger ebt_ulog_logger = {
+ .name = EBT_ULOG_WATCHER,
+ .logfn = &ebt_log_packet,
+ .me = THIS_MODULE,
+};
+
static int __init init(void)
{
int i, ret = 0;
@@ -265,6 +304,8 @@ static int __init init(void)
else if ((ret = ebt_register_watcher(&ulog)))
sock_release(ebtulognl->sk_socket);
+ nf_log_register(PF_BRIDGE, &ebt_ulog_logger);
+
return ret;
}
@@ -273,6 +314,7 @@ static void __exit fini(void)
ebt_ulog_buff_t *ub;
int i;
+ nf_log_unregister_logger(&ebt_ulog_logger);
ebt_unregister_watcher(&ulog);
for (i = 0; i < EBT_ULOG_MAXNLGROUPS; i++) {
ub = &ulog_buffers[i];
--
- Harald Welte <laforge-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [patch 2/7] orinoco: Information leakage due to incorrect padding
From: Greg KH @ 2005-10-07 23:54 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Chuck Wolber, torvalds, akpm, alan, meder, proski, orinoco-devel,
netdev
In-Reply-To: <20051007235353.GA23111@kroah.com>
[-- Attachment #1: orinoco-info-leak.patch --]
[-- Type: text/plain, Size: 1460 bytes --]
From: Pavel Roskin <proski@gnu.org>
The orinoco driver can send uninitialized data exposing random pieces of
the system memory. This happens because data is not padded with zeroes
when its length needs to be increased.
Reported by Meder Kydyraliev <meder@o0o.nu>
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/net/wireless/orinoco.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
--- linux-2.6.13.y.orig/drivers/net/wireless/orinoco.c
+++ linux-2.6.13.y/drivers/net/wireless/orinoco.c
@@ -502,9 +502,14 @@ static int orinoco_xmit(struct sk_buff *
return 0;
}
- /* Length of the packet body */
- /* FIXME: what if the skb is smaller than this? */
- len = max_t(int,skb->len - ETH_HLEN, ETH_ZLEN - ETH_HLEN);
+ /* Check packet length, pad short packets, round up odd length */
+ len = max_t(int, ALIGN(skb->len, 2), ETH_ZLEN);
+ if (skb->len < len) {
+ skb = skb_padto(skb, len);
+ if (skb == NULL)
+ goto fail;
+ }
+ len -= ETH_HLEN;
eh = (struct ethhdr *)skb->data;
@@ -556,8 +561,7 @@ static int orinoco_xmit(struct sk_buff *
p = skb->data;
}
- /* Round up for odd length packets */
- err = hermes_bap_pwrite(hw, USER_BAP, p, ALIGN(data_len, 2),
+ err = hermes_bap_pwrite(hw, USER_BAP, p, data_len,
txfid, data_off);
if (err) {
printk(KERN_ERR "%s: Error %d writing packet to BAP\n",
--
^ permalink raw reply
* Re: Timeline of IPoIB performance
From: Matt Leininger @ 2005-10-08 2:25 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev, openib-general
In-Reply-To: <52br20lsei.fsf@cisco.com>
I'm adding netdev to this thread to see if they can help.
I'm seeing an IPoIB (IP over InfiniBand) netperf performance drop off,
of up to 90 MB/s, when using kernels newer than 2.6.11. This doesn't
appear to be an OpenIB IPoIB issue since the older in-kernel IB for
2.6.11 and a recent svn3687 snapshot both have the same performance (464
MB/s) with 2.6.11. I used the same kernel config file as a starting
point for each of these kernel builds. Have there been any changes in
Linux that would explain these results?
Here is the hardware setup and netperf results using 'netperf -f -M -c
-C -H IPoIB_ADDRESS
All benchmarks are with RHEL4 x86_64 with HCA FW v4.7.0
dual EM64T 3.2 GHz PCIe IB HCA (memfull)
Kernel OpenIB msi_x netperf (MB/s)
2.6.14-rc3 in-kernel 1 374
2.6.13.2 svn3627 1 386
2.6.13.2 in-kernel 1 394
2.6.12.5-lustre in-kernel 1 399
2.6.12.5 in-kernel 1 402
2.6.12 in-kernel 1 406
2.6.12-rc6 in-kernel 1 407
2.6.12-rc5 in-kernel 1 405 <<<<<
2.6.12-rc4 in-kernel 1 470 <<<<<
2.6.12-rc3 in-kernel 1 466
2.6.12-rc2 in-kernel 1 469
2.6.12-rc1 in-kernel 1 466
2.6.11 in-kernel 1 464
2.6.11 svn3687 1 464
2.6.9-11.ELsmp svn3513 1 425 (Woody's results, 3.6Ghz EM64T)
Thanks,
- Matt
^ permalink raw reply
* pcnet32 does not use the PROM address on powerpc
From: Olaf Hering @ 2005-10-08 10:47 UTC (permalink / raw)
To: netdev, linuxppc64-dev
Does anyone remember why ppc is handled special in pcnet32_probe1()?
It as added to Linus tree around 2.6.14, I dont find relevant patches in
our bugzilla. It was likely added during early ppc64 bringup.
google doesnt know the patch submitter, perhaps jgarzik has some old
records from around 2000/2001?
I have a 44p 270, which gets all 0xFF as MAC address if I power if off
and on again. Further reboots do not fix it.
But it does get the correct one if I boot into SMS and do a netboot,
further reboots will always get the correct MAC address
I think these 0xFF happen also on other systems, I have seen them on B50
as well. We should just remove the #ifdef.
....
if (memcmp(promaddr, dev->dev_addr, 6)
|| !is_valid_ether_addr(dev->dev_addr)) {
#ifndef __powerpc__
if (is_valid_ether_addr(promaddr)) {
#else
if (!is_valid_ether_addr(dev->dev_addr)
&& is_valid_ether_addr(promaddr)) {
#endif
if (pcnet32_debug & NETIF_MSG_PROBE) {
printk(" warning: CSR address invalid,\n");
printk(KERN_INFO " using instead PROM address of");
}
memcpy(dev->dev_addr, promaddr, 6);
}
}
....
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: pcnet32 does not use the PROM address on powerpc
From: Olaf Hering @ 2005-10-08 12:03 UTC (permalink / raw)
To: netdev, linuxppc64-dev
In-Reply-To: <20051008104725.GA10248@suse.de>
On Sat, Oct 08, Olaf Hering wrote:
> I have a 44p 270, which gets all 0xFF as MAC address if I power if off
> and on again. Further reboots do not fix it.
> But it does get the correct one if I boot into SMS and do a netboot,
> further reboots will always get the correct MAC address
The CSR will get the correct value after the first ifup:
(none):/# modprobe -v pcnet32
insmod /lib/modules/2.6.13.3-20051007_rtas-ppc64/kernel/drivers/net/mii.ko
insmod /lib/modules/2.6.13.3-20051007_rtas-ppc64/kernel/drivers/net/pcnet32.ko
(none):/# ip link set eth0 up
(none):/# rmmod pcnet32
(none):/# modprobe -v pcnet32
insmod /lib/modules/2.6.13.3-20051007_rtas-ppc64/kernel/drivers/net/mii.ko
insmod /lib/modules/2.6.13.3-20051007_rtas-ppc64/kernel/drivers/net/pcnet32.ko
(none):/# dmesg | tail -n 15
pcnet32.c:v1.30j 29.04.2005 tsbogend@alpha.franken.de
PCI: Enabling device: (0000:00:10.0), cmd 143
pcnet32: PCnet/FAST 79C971 at 0xfff400, prom 0004ace4a6d7 csr ffffffffffff, warning: CSR address invalid,
using instead PROM address of 00 04 ac e4 a6 d7
tx_start_pt(0x0c00):~220 bytes, BCR18(68e1):BurstWrEn BurstRdEn DWordIO NoUFlow
SRAMSIZE=0x7f00, SRAM_BND=0x4000, assigned IRQ 18.
eth0: registered as PCnet/FAST 79C971
pcnet32: 1 cards_found.
eth0: link up, 100Mbps, half-duplex, lpa 0x40A1
pcnet32.c:v1.30j 29.04.2005 tsbogend@alpha.franken.de
pcnet32: PCnet/FAST 79C971 at 0xfff400, prom 0004ace4a6d7 csr 0004ace4a6d7, 00 04 ac e4 a6 d7
tx_start_pt(0x0c00):~220 bytes, BCR18(68e1):BurstWrEn BurstRdEn DWordIO NoUFlow
SRAMSIZE=0x7f00, SRAM_BND=0x4000, assigned IRQ 18.
eth0: registered as PCnet/FAST 79C971
pcnet32: 1 cards_found.
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: [PATCH] sis900: come alive after temporary memory shortage
From: Vasily Averin @ 2005-10-08 13:09 UTC (permalink / raw)
To: Daniele Venzano, Andrew Morton; +Cc: Jeff Garzik, NetDev, Stanislav Protassov
In-Reply-To: <20051006104004.GA2124@renditai.milesteg.arr>
[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]
Daniele Venzano wrote:
> This patch is good and fixes some corner cases. Please consider for
> inclusion.
Daniele,
sorry, but unfortunately our patch was wrong.
> + int rx_work_limit =
> + (sis_priv->dirty_rx - sis_priv->cur_rx) % NUM_RX_DESC;
when dirty_rx = cur_rx it computes limit=0, but should be NUM_RX_DESC
Also I've noticed that 'if (sis_priv->rx_skbuff[entry] == NULL)' statement
inside the while loop is really impossible now. Therefore I've increased message
loglevel up to KERN_WARNING and added some useful debug.
Daniele, could you please check our new patch carefully?
Andrew, could you please drop our old patch and replace it by the new one?
Thank you,
Vasily Averin, SWsoft Linux kernel team
Patch solves following problems:
1) Forgotten counter incrementation in sis900_rx() in case
it doesn't get memory for skb, that leads to whole interface failure.
Problem is accompanied with messages:
eth0: Memory squeeze,deferring packet.
eth0: NULL pointer encountered in Rx ring, skipping
2) If counter cur_rx overflows and there'll be temporary memory problems
buffer can't be recreated later, when memory IS available.
3) Limit the work in handler to prevent the endless packets processing if
new packets are generated faster then handled.
Signed-off-by: Konstantin Khorenko <khorenko@sw.ru>
Signed-off-by: Vasily Averin <vvs@sw.ru>
[-- Attachment #2: diff-drv-sis900-20051008 --]
[-- Type: text/plain, Size: 1995 bytes --]
--- a/drivers/net/sis900.c 2005-10-08 12:22:53.000000000 +0400
+++ b/drivers/net/sis900.c 2005-10-08 15:12:29.000000000 +0400
@@ -1696,15 +1696,20 @@ static int sis900_rx(struct net_device *
long ioaddr = net_dev->base_addr;
unsigned int entry = sis_priv->cur_rx % NUM_RX_DESC;
u32 rx_status = sis_priv->rx_ring[entry].cmdsts;
+ int rx_work_limit;
if (netif_msg_rx_status(sis_priv))
printk(KERN_DEBUG "sis900_rx, cur_rx:%4.4d, dirty_rx:%4.4d "
"status:0x%8.8x\n",
sis_priv->cur_rx, sis_priv->dirty_rx, rx_status);
+ rx_work_limit = sis_priv->dirty_rx + NUM_RX_DESC - sis_priv->cur_rx;
while (rx_status & OWN) {
unsigned int rx_size;
+ if (--rx_work_limit < 0)
+ break;
+
rx_size = (rx_status & DSIZE) - CRC_SIZE;
if (rx_status & (ABORT|OVERRUN|TOOLONG|RUNT|RXISERR|CRCERR|FAERR)) {
@@ -1732,9 +1737,11 @@ static int sis900_rx(struct net_device *
we are working on NULL sk_buff :-( */
if (sis_priv->rx_skbuff[entry] == NULL) {
if (netif_msg_rx_err(sis_priv))
- printk(KERN_INFO "%s: NULL pointer "
- "encountered in Rx ring, skipping\n",
- net_dev->name);
+ printk(KERN_WARNING "%s: NULL pointer "
+ "encountered in Rx ring\n"
+ "cur_rx:%4.4d, dirty_rx:%4.4d\n",
+ net_dev->name, sis_priv->cur_rx,
+ sis_priv->dirty_rx);
break;
}
@@ -1770,6 +1777,7 @@ static int sis900_rx(struct net_device *
sis_priv->rx_ring[entry].cmdsts = 0;
sis_priv->rx_ring[entry].bufptr = 0;
sis_priv->stats.rx_dropped++;
+ sis_priv->cur_rx++;
break;
}
skb->dev = net_dev;
@@ -1787,7 +1795,7 @@ static int sis900_rx(struct net_device *
/* refill the Rx buffer, what if the rate of refilling is slower
* than consuming ?? */
- for (;sis_priv->cur_rx - sis_priv->dirty_rx > 0; sis_priv->dirty_rx++) {
+ for (; sis_priv->cur_rx != sis_priv->dirty_rx; sis_priv->dirty_rx++) {
struct sk_buff *skb;
entry = sis_priv->dirty_rx % NUM_RX_DESC;
^ permalink raw reply
* Re: Is this skb recycle buffer helpful to improve Linux network stack performance?
From: LeoY @ 2005-10-08 21:59 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <43483E57.1040205@cosmosbay.com>
Here is the modifications I made:
//skbuff.h
//I added the folloing definitions
#define MAX_POOL_SIZE 4096
unsigned char *skbuff_data_pool[MAX_POOL_SIZE];
int skbPoolHead, skbPoolTail;
//skb_init()
//I add the following codes:
for(i=0;i<MAX_POOL_SIZE;i++)
skbuff_data_pool[i] = NULL;
skbPoolHead = skbPoolTail = 0;
//alloc_skb()
//I made the following changes
if (skbuff_data_pool[skbPoolHead])
{
data = skbuff_data_pool[skbPoolHead];
skbuff_data_pool[skbPoolHead] = NULL;
if (++skbPoolHead == MAX_POOL_SIZE)
skbPoolHead = 0;
}
else{ //Original path
size = SKB_DATA_ALIGN(size);
data = kmalloc(size + sizeof(struct skb_shared_info), gfp_mask);
}
//skb_release_data()
//I made the following changes:
if ((skbPoolHead == skbPoolTail) && (skbuff_data_pool[skbPoolHead] !=
NULL))
//Original path
kfree(skb->head);
else{
if (skbuff_data_pool[skbPoolTail])
panic("Tail pointer must be null");
skbuff_data_pool[skbPoolTail] = skb->head;
if (++skbPoolTail == MAX_POOL_SIZE)
skbPoolTail = 0;
}
----- Original Message -----
From: "Eric Dumazet" <dada1@cosmosbay.com>
To: "LeoY" <multisyncfe991@hotmail.com>
Cc: <netdev@vger.kernel.org>
Sent: Saturday, October 08, 2005 2:47 PM
Subject: Re: Is this skb recycle buffer helpful to improve Linux network
stack performance?
> LeoY a écrit :
>> Hi,
>>
>> Motivation: we noticed alloc_skb()/kfree() used lots of clock ticks when
>> handling heavy network traffic. As Linux kernel always need to call
>> kmalloc()/kfree() to allocate and deallocate a skb DATA buffer(not
>> sk_buff)
>> for each incoming/outgoing packet, we try to reduce the frequence of
>> calling
>> these memory functions.
>>
>> I wangt to set up a ring buffer in Linux kernel(skbuff.c) and recycle
>> those
>> skb data buffers. The basic idea is as follows:
>> 1. Create a ring buffer. This ring buffer has a head pointer which points
>> to
>> the virtual address of the data buffer to be reused; It also has a tail
>> pointer, which can be used to store the virutal address of skb data
>> buffer
>> for those transmitted packets.
>> 2. If the ring buffer is full, just use normal kmalloc()/kfree()
>> operation
>> to manager those skb data buffers instead of recycling them.
>> 3. if any DATA buffer is available, Instead of calling kmalloc(), assign
>> a
>> skb data buffer directly from ring buffer to the incoming packets.
>> 4. If ring buffer still has space, Instead of calling kfree(), store the
>> skb
>> data buffer into the ring buffer.
>> 5. if the head and tail pointer overlap and head pointer is not empty,
>> just
>> stop accpeting more DATA buffer until some DATA buffer is used for the
>> incoming packets.
>>
>> I tested my method on the latest Linux kernel 2.6.13.3, it works with the
>> normal traffic; However, the Linux kernel crashed under the heavy network
>> traffic.
>>
>> Any idea to make this ring bufer work under the heavy network traffic?
>
> Your idea seems interesting, but you forgot to post a link to the code you
> wrote. How do you want us to help you ?
>
> Eric
>
^ permalink raw reply
* Re: Is this skb recycle buffer helpful to improve Linux network stack performance?
From: Eric Dumazet @ 2005-10-08 22:09 UTC (permalink / raw)
To: LeoY; +Cc: linux-kernel, netdev
In-Reply-To: <BAY108-DAV140650CDA8608152927C4E93870@phx.gbl>
LeoY a écrit :
> Here is the modifications I made:
> //skbuff.h
> //I added the folloing definitions
> #define MAX_POOL_SIZE 4096
> unsigned char *skbuff_data_pool[MAX_POOL_SIZE];
> int skbPoolHead, skbPoolTail;
>
>
> //skb_init()
> //I add the following codes:
> for(i=0;i<MAX_POOL_SIZE;i++)
> skbuff_data_pool[i] = NULL;
> skbPoolHead = skbPoolTail = 0;
>
>
> //alloc_skb()
> //I made the following changes
> if (skbuff_data_pool[skbPoolHead])
> {
> data = skbuff_data_pool[skbPoolHead];
> skbuff_data_pool[skbPoolHead] = NULL;
> if (++skbPoolHead == MAX_POOL_SIZE)
> skbPoolHead = 0;
> }
> else{ //Original path
> size = SKB_DATA_ALIGN(size);
> data = kmalloc(size + sizeof(struct skb_shared_info), gfp_mask);
> }
>
> //skb_release_data()
> //I made the following changes:
> if ((skbPoolHead == skbPoolTail) && (skbuff_data_pool[skbPoolHead] !=
> NULL))
> //Original path
> kfree(skb->head);
> else{
> if (skbuff_data_pool[skbPoolTail])
> panic("Tail pointer must be null");
>
> skbuff_data_pool[skbPoolTail] = skb->head;
> if (++skbPoolTail == MAX_POOL_SIZE)
> skbPoolTail = 0;
> }
>
Hum... Lot of problems I think
Are you aware that skb_alloc() / skb_free() can handle data buffers of
different sizes ?
So if you kmalloc() a small buffer, and store it later in your ring buffer,
you should not give it back to a caller that need a biger buffer.
If you want your 'ring buffer'to work, I suspect you should ignore the 'size'
and let it be the max possible size handled in your machine.
Then, dont forget about SMP and IRQs : I dont see in your code how you protect
against concurrent processors accessing your ring buffers, and how you protect
against IRQ (since a nic handler can runs on IRQ or softirq context)
kmalloc()/kfree() are SMP safe.
> ----- Original Message ----- From: "Eric Dumazet" <dada1@cosmosbay.com>
> To: "LeoY" <multisyncfe991@hotmail.com>
> Cc: <netdev@vger.kernel.org>
> Sent: Saturday, October 08, 2005 2:47 PM
> Subject: Re: Is this skb recycle buffer helpful to improve Linux network
> stack performance?
>
>
>> LeoY a écrit :
>>
>>> Hi,
>>>
>>> Motivation: we noticed alloc_skb()/kfree() used lots of clock ticks when
>>> handling heavy network traffic. As Linux kernel always need to call
>>> kmalloc()/kfree() to allocate and deallocate a skb DATA buffer(not
>>> sk_buff)
>>> for each incoming/outgoing packet, we try to reduce the frequence of
>>> calling
>>> these memory functions.
>>>
>>> I wangt to set up a ring buffer in Linux kernel(skbuff.c) and recycle
>>> those
>>> skb data buffers. The basic idea is as follows:
>>> 1. Create a ring buffer. This ring buffer has a head pointer which
>>> points to
>>> the virtual address of the data buffer to be reused; It also has a tail
>>> pointer, which can be used to store the virutal address of skb data
>>> buffer
>>> for those transmitted packets.
>>> 2. If the ring buffer is full, just use normal kmalloc()/kfree()
>>> operation
>>> to manager those skb data buffers instead of recycling them.
>>> 3. if any DATA buffer is available, Instead of calling kmalloc(),
>>> assign a
>>> skb data buffer directly from ring buffer to the incoming packets.
>>> 4. If ring buffer still has space, Instead of calling kfree(), store
>>> the skb
>>> data buffer into the ring buffer.
>>> 5. if the head and tail pointer overlap and head pointer is not
>>> empty, just
>>> stop accpeting more DATA buffer until some DATA buffer is used for the
>>> incoming packets.
>>>
>>> I tested my method on the latest Linux kernel 2.6.13.3, it works with
>>> the
>>> normal traffic; However, the Linux kernel crashed under the heavy
>>> network
>>> traffic.
>>>
>>> Any idea to make this ring bufer work under the heavy network traffic?
>>
>>
>> Your idea seems interesting, but you forgot to post a link to the code
>> you wrote. How do you want us to help you ?
>>
>> Eric
>>
>
^ permalink raw reply
* Re: Is this skb recycle buffer helpful to improve Linux network stack performance?
From: LeoY @ 2005-10-08 22:14 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-kernel
In-Reply-To: <434843B5.3020306@cosmosbay.com>
Hi Eric,
Thanks for your reply.
1. For the packet size, this idea is targeting some specific network card
driver and we assume all the packet size will not exceed 2KB.
2. Currently only Uni-Processor is considered(Hyper-threading is also
disabled), I will add spin lock part once it works on the UP.
Leo
----- Original Message -----
From: "Eric Dumazet" <dada1@cosmosbay.com>
To: "LeoY" <multisyncfe991@hotmail.com>
Cc: <linux-kernel@vger.kernel.org>; <netdev@vger.kernel.org>
Sent: Saturday, October 08, 2005 3:09 PM
Subject: Re: Is this skb recycle buffer helpful to improve Linux network
stack performance?
> LeoY a écrit :
>> Here is the modifications I made:
>> //skbuff.h
>> //I added the folloing definitions
>> #define MAX_POOL_SIZE 4096
>> unsigned char *skbuff_data_pool[MAX_POOL_SIZE];
>> int skbPoolHead, skbPoolTail;
>>
>>
>> //skb_init()
>> //I add the following codes:
>> for(i=0;i<MAX_POOL_SIZE;i++)
>> skbuff_data_pool[i] = NULL;
>> skbPoolHead = skbPoolTail = 0;
>>
>>
>> //alloc_skb()
>> //I made the following changes
>> if (skbuff_data_pool[skbPoolHead])
>> {
>> data = skbuff_data_pool[skbPoolHead];
>> skbuff_data_pool[skbPoolHead] = NULL;
>> if (++skbPoolHead == MAX_POOL_SIZE)
>> skbPoolHead = 0;
>> }
>> else{ //Original path
>> size = SKB_DATA_ALIGN(size);
>> data = kmalloc(size + sizeof(struct skb_shared_info), gfp_mask);
>> }
>>
>> //skb_release_data()
>> //I made the following changes:
>> if ((skbPoolHead == skbPoolTail) && (skbuff_data_pool[skbPoolHead] !=
>> NULL))
>> //Original path
>> kfree(skb->head);
>> else{
>> if (skbuff_data_pool[skbPoolTail])
>> panic("Tail pointer must be null");
>>
>> skbuff_data_pool[skbPoolTail] = skb->head;
>> if (++skbPoolTail == MAX_POOL_SIZE)
>> skbPoolTail = 0;
>> }
>>
>
> Hum... Lot of problems I think
>
> Are you aware that skb_alloc() / skb_free() can handle data buffers of
> different sizes ?
>
> So if you kmalloc() a small buffer, and store it later in your ring
> buffer, you should not give it back to a caller that need a biger buffer.
>
> If you want your 'ring buffer'to work, I suspect you should ignore the
> 'size' and let it be the max possible size handled in your machine.
>
> Then, dont forget about SMP and IRQs : I dont see in your code how you
> protect against concurrent processors accessing your ring buffers, and how
> you protect against IRQ (since a nic handler can runs on IRQ or softirq
> context)
>
> kmalloc()/kfree() are SMP safe.
>
>> ----- Original Message ----- From: "Eric Dumazet" <dada1@cosmosbay.com>
>> To: "LeoY" <multisyncfe991@hotmail.com>
>> Cc: <netdev@vger.kernel.org>
>> Sent: Saturday, October 08, 2005 2:47 PM
>> Subject: Re: Is this skb recycle buffer helpful to improve Linux network
>> stack performance?
>>
>>
>>> LeoY a écrit :
>>>
>>>> Hi,
>>>>
>>>> Motivation: we noticed alloc_skb()/kfree() used lots of clock ticks
>>>> when
>>>> handling heavy network traffic. As Linux kernel always need to call
>>>> kmalloc()/kfree() to allocate and deallocate a skb DATA buffer(not
>>>> sk_buff)
>>>> for each incoming/outgoing packet, we try to reduce the frequence of
>>>> calling
>>>> these memory functions.
>>>>
>>>> I wangt to set up a ring buffer in Linux kernel(skbuff.c) and recycle
>>>> those
>>>> skb data buffers. The basic idea is as follows:
>>>> 1. Create a ring buffer. This ring buffer has a head pointer which
>>>> points to
>>>> the virtual address of the data buffer to be reused; It also has a tail
>>>> pointer, which can be used to store the virutal address of skb data
>>>> buffer
>>>> for those transmitted packets.
>>>> 2. If the ring buffer is full, just use normal kmalloc()/kfree()
>>>> operation
>>>> to manager those skb data buffers instead of recycling them.
>>>> 3. if any DATA buffer is available, Instead of calling kmalloc(),
>>>> assign a
>>>> skb data buffer directly from ring buffer to the incoming packets.
>>>> 4. If ring buffer still has space, Instead of calling kfree(), store
>>>> the skb
>>>> data buffer into the ring buffer.
>>>> 5. if the head and tail pointer overlap and head pointer is not empty,
>>>> just
>>>> stop accpeting more DATA buffer until some DATA buffer is used for the
>>>> incoming packets.
>>>>
>>>> I tested my method on the latest Linux kernel 2.6.13.3, it works with
>>>> the
>>>> normal traffic; However, the Linux kernel crashed under the heavy
>>>> network
>>>> traffic.
>>>>
>>>> Any idea to make this ring bufer work under the heavy network traffic?
>>>
>>>
>>> Your idea seems interesting, but you forgot to post a link to the code
>>> you wrote. How do you want us to help you ?
>>>
>>> Eric
>>>
>
>>
>
>
^ permalink raw reply
* Re: Is this skb recycle buffer helpful to improve Linux network stack performance?
From: Eric Dumazet @ 2005-10-08 22:22 UTC (permalink / raw)
To: LeoY; +Cc: netdev, linux-kernel
In-Reply-To: <BAY108-DAV4008FD962D8FEC0497CC193870@phx.gbl>
LeoY a écrit :
> Hi Eric,
>
> Thanks for your reply.
> 1. For the packet size, this idea is targeting some specific network
> card driver and we assume all the packet size will not exceed 2KB.
> 2. Currently only Uni-Processor is considered(Hyper-threading is also
> disabled), I will add spin lock part once it works on the UP.
>
1) Even on Uni-Processor, you still need to protect against IRQS
2) The big cost of kmalloc()/kfree() come from the
local_irq_save(flags)/local_irq_restore(flags)
Once you add them in your code, you will discover you gain nothing compared to
kmalloc()/kfree() that already use a 'ring buffer' : More over, the slab
implementation is designed to have separate 'ring buffer' (one for each cpu),
so it is probably better than a 'central ring buffer'
Eric
^ 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