* [PATCH] Documentation/networking/README.ipw2200
From: Alejandro Bonilla @ 2005-10-10 17:18 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, jketreno, jgarzik
Hi,
This patch is different from the previous one. This is for IPW2200. ;-)
It updates the information/README to match the Kconfig info of the IPW2200.
Please apply to have a better documented 2.6.14
I dunno if this is either handled by Netdev or LKML because is about
Documentation/
Thanks,
.Alejandro
Signed-off-by: Alejandro Bonilla <abonilla@linuxwireless.org>
diff --git a/Documentation/networking/README.ipw2200
b/Documentation/networking/README.ipw2200
--- a/Documentation/networking/README.ipw2200
+++ b/Documentation/networking/README.ipw2200
@@ -1,5 +1,5 @@
-Intel(R) PRO/Wireless 2915ABG Driver for Linux in support of:
+Intel(R) PRO/Wireless 2200BG Driver for Linux in support of:
Intel(R) PRO/Wireless 2200BG Network Connection
Intel(R) PRO/Wireless 2915ABG Network Connection
@@ -27,7 +27,8 @@ Index
1.4. Sysfs Helper Files
2. About the Version Numbers
3. Support
-4. License
+4. Firmware
+5. License
1. Introduction
@@ -272,7 +273,24 @@ For general information and support, go
http://ipw2200.sf.net/
-4. License
+4. Firmware
+-----------------------------------------------
+
+As the firmware is licensed under a restricted use license, it can not be
+included within the kernel sources. To enable the IPW2200 you will need a
+firmware image to load into the wireless NIC's processors.
+
+You can obtain these images from <http://ipw2200.sf.net/firmware.php>.
+
+The firmware package should be extracted where your hotplug firmware agent
+is looking:
+
+% grep FIRMWARE /etc/hotplug/firmware.agent
+
+The most common path is /lib/firmware but the firmware.agent will tell.
+
+
+5. License
-----------------------------------------------
Copyright(c) 2003 - 2005 Intel Corporation. All rights reserved.
^ permalink raw reply
* [PATCH] Documentation/networking/README.ipw2100
From: Alejandro Bonilla @ 2005-10-10 17:05 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, jketreno, jgarzik
Hi,
This updates the Documentation so that IPW2100 can be well documented for
2.6.14, the Kconfig points to this file but there is no information about the
firmware.
Please apply.
Signed-off-by: Alejandro Bonilla <abonilla@linuxwireless.org>
diff --git a/Documentation/networking/README.ipw2100
b/Documentation/networking/README.ipw2100
--- a/Documentation/networking/README.ipw2100
+++ b/Documentation/networking/README.ipw2100
@@ -143,7 +143,12 @@ firmware image to load into the wireless
You can obtain these images from <http://ipw2100.sf.net/firmware.php>.
-See INSTALL for instructions on installing the firmware.
+The firmware package should be extracted where your hotplug firmware agent
+is looking:
+
+% grep FIRMWARE /etc/hotplug/firmware.agent
+
+The most common path is /lib/firmware but the firmware.agent will tell.
===========================
^ permalink raw reply
* Re: [ANNOUNCE] iproute2 version (050929)
From: Stephen Hemminger @ 2005-10-10 14:40 UTC (permalink / raw)
To: Krzysztof Oledzki; +Cc: netdev, lartc
In-Reply-To: <Pine.LNX.4.62.0510101232310.1343@bizon.gios.gov.pl>
On Mon, 10 Oct 2005 12:34:51 +0200 (CEST)
Krzysztof Oledzki <olel@ans.pl> wrote:
>
>
> On Wed, 5 Oct 2005, Stephen Hemminger wrote:
>
> > On Sat, 1 Oct 2005 23:34:25 +0200 (CEST)
> > Krzysztof Oledzki <olel@ans.pl> wrote:
> >
> >>
> >>
> >> On Fri, 30 Sep 2005, Stephen Hemminger wrote:
> >>
> >>> There is an new minor update to iproute2 utilities available:
> >>> http://developer.osdl.org/dev/iproute2/download/iproute2-050929.tar.gz
> >>
> >>
> >> It hangs on "ip rule flush". Tested on 2.6.13.2.
> >>
> >>
> >> Best regards,
> >>
> >>
> >> Krzysztof Olędzki
> >
> > Fixed by this patch (in next release)
>
> Not sure... Just checked iproute2-ss051007 and it still hangs on "ip rule
> flush" with ~100% cpu load.
>
Are you running as root? If not it will loop forever.
^ permalink raw reply
* [PATCH] pcnet32 does not use the PROM address on powerpc
From: Olaf Hering @ 2005-10-10 14:23 UTC (permalink / raw)
To: netdev, linuxppc64-dev
In-Reply-To: <20051008120316.GA12122@suse.de>
On Sat, Oct 08, Olaf Hering wrote:
> 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 contains garbage after a coldboot on RS/6000.
One some systems (like my 44p 270) the MAC address is all FF,
on others (like my B50) it is ff:ff:ff:fd:ff:6b.
It can eventually be fixed by loading pcnet32, set the interface
into the UP state, rmmod pcnet32 and load it again. But this worked
only on the 270.
Only netbooting after a cold start provides the correct MAC address
via prom and CSR. This makes it very unreliable.
I dont know why the MAC is stored in two different places. Remove
the special case for powerpc, which was added in early 2.4 development.
Signed-off-by: Olaf Hering <olh@suse.de>
drivers/net/pcnet32.c | 5 -----
1 files changed, 5 deletions(-)
Index: linux-2.6.14-rc3/drivers/net/pcnet32.c
===================================================================
--- linux-2.6.14-rc3.orig/drivers/net/pcnet32.c
+++ linux-2.6.14-rc3/drivers/net/pcnet32.c
@@ -1172,12 +1172,7 @@ pcnet32_probe1(unsigned long ioaddr, int
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");
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: 32 bit (socket layer) ioctl emulation for 64 bit kernels- Question regarding...
From: Arnd Bergmann @ 2005-10-10 11:48 UTC (permalink / raw)
To: spereira; +Cc: linux-kernel, netdev
In-Reply-To: <3ad486780510092121h78a522cat11f33581dfc670dc@mail.gmail.com>
On Maandag 10 Oktober 2005 06:21, spereira wrote:
>
> Is there currently an alternative to register_ioctl32_conversion that
> would help achive 32 bit ioctl emulation at the socket layer?
> Any suggestions/advice whould be much appreciated.
The correct solution would be to add the missing functionality to
net/socket.c and move over the implementation of SIOC* from
fs/compat_ioctl.c. Getting the code path right is a little tricky,
but I think a patch to fix this up would be appreciated.
As a start, you could define a compat_sock_ioctl along the
lines of compat_blkdev_ioctl and add your own handlers to the
x25_proto_ops, but IMHO it would makes sense to get rid of stuff
like dev_ifsioc from fs/compat_ioctl.c at the same time by
introducing a new compat_dev_ioctl called from compat_sock_ioctl.
Arnd <><
^ permalink raw reply
* Re: [PATCH] sis900: come alive after temporary memory shortage
From: Daniele Venzano @ 2005-10-10 8:37 UTC (permalink / raw)
To: Vasily Averin; +Cc: Andrew Morton, Jeff Garzik, NetDev, Stanislav Protassov
In-Reply-To: <4347C50A.9010501@sw.ru>
On Sat, Oct 08, 2005 at 05:09:30PM +0400, Vasily Averin wrote:
> Daniele, could you please check our new patch carefully?
This time I tested it as thoroughly as possible. It kept working during
all the time the memory was filling up, until the OOM killer woke up
from his dark pit. After OOM frenzy, the driver was still alive and
kicking.
> Andrew, could you please drop our old patch and replace it by the new one?
Yes, this one is better, thanks.
> 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>
Signed-off-by: Daniele Venzano <venza@brownhat.org>
--- 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
* friable No delay dispatch! Accept your antibiotics quicker. synthesis
From: ambrose cravens @ 2005-10-10 4:54 UTC (permalink / raw)
To: Dean Puller, owner-linux-xfs, gomez, blair, devfs, craig, leonard,
ogl-sample, netdev
Constraint to acquire meddicaation, acquisite those all here.
Heal your annxiety by taking our effective meddicaation.
Wholly Tracked Packages will arrive to you within 40hrs.
Treat your syndrome at much economical tags.
Free meddicaal details with our accredited doctor.
3 wordings for you! You are surprising. Howard K --NJ.
http://uk.geocities.com/snazzysmashingb/?exfo
"You used to teach girls," she said, "If you could only have taught me, I
could have learnt from you. I am so very miserable, and I like you so much."
bluethner dsavage cmdi sz04 esingers felip
"Is it you, indeed, Professor Wilson? I was afraid that you might get here
before I did. I was detained at a concert, and Bartley telephoned that he
would be late. Thomas will show you your room. Had you rather have your tea
brought to you there, or will you have it down here with me, while we wait
for Bartley?"
Wilson was pleased to find that he had been the cause of her rapid walk,
and with her he was even more vastly pleased than before. He followed her
through the drawing-room into the library, where the wide back windows
looked out upon the garden and the sunset and a fine stretch of
silver-colored river. A harp-shaped elm stood stripped against the
pale-colored evening sky, with ragged last year's birds' nests in its forks,
and through the bare branches the evening star quivered in the misty air.
The long brown room breathed the peace of a rich and amply guarded quiet.
Tea was brought in immediately and placed in front of the wood fire. Mrs.
Alexander sat down in a high-backed chair and began to pour it, while Wilson
sank into a low seat opposite her and took his cup with a great sense of
ease and harmony and comfort.
^ permalink raw reply
* [RTI #2053] AutoReply: exception
From: RTI support via RT @ 2005-10-09 4:01 UTC (permalink / raw)
To: netdev
In-Reply-To: <200510090402.j99422SP016667@bigbend.rti.com>
Greetings!
This message has been automatically generated in response to the
creation of a trouble ticket regarding:
"exception",
a summary of which appears below.
There is no need to reply to this message right now. Your ticket has been
assigned an ID of [RTI #2053].
Please include the string:
[RTI #2053]
in the subject line of all future correspondence about this issue. To do so,
you may reply to this message.
Thank you,
Real-Time Innovations support team
<support@rti.com>
-------------------------------------------------------------------------
take it easy!
^ 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
* 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: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 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: [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: 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
* 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: 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
* [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
* [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
* [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
* 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
* 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: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
* 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 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
* 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
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