* Re: [RFC] ip / ifconfig redesign
From: Ben Greear @ 2005-12-05 18:00 UTC (permalink / raw)
To: Marc Singer; +Cc: Al Boldi, netdev, linux-net
In-Reply-To: <20051205174010.GA14101@buici.com>
Marc Singer wrote:
> On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote:
>
>>On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote:
>>
>>>Al Boldi wrote:
>>>
>>>
>>>>Here specifically, ip/ifconfig is implemented upside-down requiring a
>>>>link/dev to exist for an address to be defined, in effect containing layer
>>>>3 inside layer 2, when an address should be allowed to be defined w/o a
>>>>link/dev much like an app is allowed to be defined w/o an address.
>>>
>>>[Removed lkml from CC list]
>>>
>>>You can add multiple virtual IP addresses to physical interfaces. It
>>>makes no sense to have an IP without any association to an interface
>>>in my opinion. Often, when you have multiple interfaces, you most
>>>definately
>>>want different IPs associated specifically with particular interfaces.
>>>Think about redundant paths, routers, firewalls, and such.
>>
>>The association between IP addresses and links is already a bit murky.
>>Reference the arp_announce sysctl for what I mean. I recall Dave M.
>>emphasizing on at least one occassion that IP addresses belong to
>>the _box_, not to the link.
>>
>>I think Al B.'s idea merits some consideration. I definitely think
>>we blur the distinctions between L2 and L3 a bit too much in places.
>>
>>Of course, patches would be helpful...
>
>
> Precisely the case. It should be the case that a box response to an
> arp on *any* interface for *any* IP address known to the box.
I certainly don't mind if this is a configurable, or even default
behaviour, but we also need the ability to only respond to particular
arps on particular interfaces, based on the IP addresses assigned
to those interfaces. I am able to get this particular arp binding working
today, so I'm not suggesting changes, just mentioning that there are other
configurations than what you mention that are useful to people.
> As for changing the behavior, I haven't seen a compelling reason to
> change it. IMHO, without a motivating case, we would be mucking about
> without a clear goal.
Agreed.
Thanks,
Ben
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Jiri Benc @ 2005-12-05 18:00 UTC (permalink / raw)
To: mbuesch; +Cc: linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <E1Eiyw4-0003Ab-FW@www1.emo.freenet-rz.de>
On Sun, 04 Dec 2005 19:50:08 +0100, mbuesch@freenet.de wrote:
> The team is in the progress of writing a SoftwareMAC layer,
> which is needed for the bcm device. The SoftMAC is still very
> incomplete. So do not expect to do any fancy stuff like WPA
> or something line that with it.
Why yet another attempt to write 802.11 stack? Sure, the one currently
in the kernel is unusable and everybody knows about it. But why not to
improve code opensourced by Devicescape some time ago instead of
inventing the wheel again and again? Yes, I know that code is not
perfect and needs a lot of work, but it is the best piece of code we
have available now. And it _does_ support WPA and such - in fact, it is
nearly complete.
Please take a look at http://kernel.org/pub/linux/kernel/people/jbenc/
Thanks,
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Jeroen Massar @ 2005-12-05 17:59 UTC (permalink / raw)
To: Marc Singer; +Cc: Ben Greear, Al Boldi, netdev, linux-net
In-Reply-To: <20051205174010.GA14101@buici.com>
[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]
Marc Singer wrote:
> On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote:
>> On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote:
<SNIP>
>> The association between IP addresses and links is already a bit murky.
>> Reference the arp_announce sysctl for what I mean. I recall Dave M.
>> emphasizing on at least one occassion that IP addresses belong to
>> the _box_, not to the link.
>
> Precisely the case. It should be the case that a box response to an
> arp on *any* interface for *any* IP address known to the box.
Thus you have the following nice setup:
10.100.10.0/24 = 10Gbit streaming network
10.100.20.0/24 = 10mbit admin network
10.100.10.1 on eth0
10.100.20.1 on eth2
Then some idiot misconfigures his client box, putting 10.100.10.42/24 on
the NIC that is supposed to be in the admin network only.
Suddenly your 10mbit link is full because the arp's get answered on this
link.
I wonder how many RFC's it violates. An interface must only answer ARP's
on the interface that it is configured on, not anything else.
There is a low level of brokeness here already. When you have:
eth0 = 10.100.10.1/24
eth1 = 192.168.1.1/24
default route towards 192.168.1.250, forwarding enabled.
SMTP on 192.168.1.1.
Now when a client from 10.100.10.5 contacts 192.168.1.1, the FORWARD
chain of iptables is skipped. The packet directly comes into INPUT.
Blocking based on the decision that it is actually being forwarded is
impossible because of this, unless you do -i eth0 -d 192.168.1.1.
Combine this with the above and you can suddenly access internal IP's
when the firewall is configured correctly to block FORWARD's from the
eth1 interface and you have an internal service on 10.100.10.1. You only
have to find a way to be local on the external interface so that you can
do arp's for internal IP's. It will be loved by pesky ISP's who limit
people and disallow them to do NAT of course.
Greets,
Jeroen
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 238 bytes --]
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Marc Singer @ 2005-12-05 17:40 UTC (permalink / raw)
To: Ben Greear, Al Boldi, netdev, linux-net
In-Reply-To: <20051205140057.GC24764@tuxdriver.com>
On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote:
> On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote:
> > Al Boldi wrote:
> >
> > >Here specifically, ip/ifconfig is implemented upside-down requiring a
> > >link/dev to exist for an address to be defined, in effect containing layer
> > >3 inside layer 2, when an address should be allowed to be defined w/o a
> > >link/dev much like an app is allowed to be defined w/o an address.
> >
> > [Removed lkml from CC list]
> >
> > You can add multiple virtual IP addresses to physical interfaces. It
> > makes no sense to have an IP without any association to an interface
> > in my opinion. Often, when you have multiple interfaces, you most
> > definately
> > want different IPs associated specifically with particular interfaces.
> > Think about redundant paths, routers, firewalls, and such.
>
> The association between IP addresses and links is already a bit murky.
> Reference the arp_announce sysctl for what I mean. I recall Dave M.
> emphasizing on at least one occassion that IP addresses belong to
> the _box_, not to the link.
>
> I think Al B.'s idea merits some consideration. I definitely think
> we blur the distinctions between L2 and L3 a bit too much in places.
>
> Of course, patches would be helpful...
Precisely the case. It should be the case that a box response to an
arp on *any* interface for *any* IP address known to the box.
As for changing the behavior, I haven't seen a compelling reason to
change it. IMHO, without a motivating case, we would be mucking about
without a clear goal.
^ permalink raw reply
* ¿À´Ãµµ Æí¾ÈÇϼ¼¿ä?
From: ¹æ ¼±Èñ @ 2005-12-05 16:39 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: multipart/alternative, Size: 2901 bytes --]
^ permalink raw reply
* Bug#341392: (fwd) Bug#341392: linux-2.6: kernel BUG at mm/slab.c:1807!
From: maximilian attems @ 2005-12-05 14:57 UTC (permalink / raw)
To: netdev; +Cc: 341392, Frans Pop
please take a look at belows BUG_ON()
at a quick glance didn't find a patch for that in git-commits-list.
belows kernel has all fixes from the latest 2.6.14.3 stable.
----- Forwarded message from Frans Pop <aragorn@tiscali.nl> -----
Subject: Bug#341392: linux-2.6: kernel BUG at mm/slab.c:1807!
Date: Wed, 30 Nov 2005 13:14:02 +0100
From: Frans Pop <aragorn@tiscali.nl>
To: submit@bugs.debian.org
Package: linux-2.6
Version: 2.6.14-4
Severity: serious
The following error happens on Debian Installer boot in vmware (386 kernel).
This problem was not present in -3.
The system does come up after the error, but it looks so basic (memory
management AFAICT) that I've set RC severity anyway.
Feel free to adjust if you disagree.
Cheers,
FJP
ACPI: Processor [CPU0] (supports 8 throttling states)
kmem_cache_create: duplicate cache UNIX
------------[ cut here ]------------
kernel BUG at mm/slab.c:1807!
invalid operand: 0000 [#1]
Modules linked in: unix thermal processor fan pcnet32 mii uhci_hcd usbcore
CPU: 0
EIP: 0060:[<c013c552>] Not tainted VLI
EFLAGS: 00010202 (2.6.14-2-386)
EIP is at kmem_cache_create+0x4ea/0x64c
eax: 0000002b ebx: c9c26b4c ecx: c02f8080 edx: 0000206b
esi: c0303829 edi: ca86fde9 ebp: c9c26980 esp: c988ff38
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 1605, threadinfo=c988e000 task=c98c8a70)
Stack: c02ba8f8 ca86fde4 0000000a c9a957a0 c9c2699c ffffff80 00000080 c0000000
00000080 ca870080 ca86fd60 0804e154 ca86fde4 c02410d2 ca86fde4 0000015c
00000000 00002000 00000000 00000000 ca804000 ca870080 0804e190 0804e154
Call Trace:
[<c02410d2>] proto_register+0x56/0x1b4
[<ca804000>] af_unix_init+0x0/0x5f [unix]
[<ca80400d>] af_unix_init+0xd/0x5f [unix]
[<c012e8a1>] sys_init_module+0x99/0x16c
[<c01030dd>] syscall_call+0x7/0xb
Code: c9 fc ff ff 55 e8 0f 0e 00 00 59 e9 a9 fd ff ff 90 ff 74 24 30 68 f8 a8 2b c0 e8 6e b3
fd ff ff 05 4c 16 39 c0 0f 8e cb 15 00 00 <0f> 0b 0f 07 0d a0 2b c0 58 5a e9 d7 fd ff ff b8
00 e0 ff ff 21
<6>usbcore: registered new driver usbkbd
drivers/usb/input/usbkbd.c: :USB HID Boot Protocol keyboard driver
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
----- End forwarded message -----
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Jeroen Massar @ 2005-12-05 14:20 UTC (permalink / raw)
To: Ben Greear, Al Boldi, netdev, linux-net
In-Reply-To: <20051205140057.GC24764@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 434 bytes --]
John W. Linville wrote:
<SNIP>
> Of course, patches would be helpful...
/sbin/ipadd <address>
#!/bin/sh
ip addr add $1 dev lo
/sbin/ipdel <address>
#!/bin/sh
ip addr del $1 dev lo
/sbin/ipactivate <address> <device>
#!/bin/sh
ip addr add $1 dev $2
/sbin/ipdeactivate <address> <device>
#!/bin/sh
ip addr del $1 dev $2
There are your 'patches'. Add -6's to places for IPv6 versions.
Greets,
Jeroen
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 238 bytes --]
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: John W. Linville @ 2005-12-05 14:01 UTC (permalink / raw)
To: Ben Greear; +Cc: Al Boldi, netdev, linux-net
In-Reply-To: <4391E4FC.1040200@candelatech.com>
On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote:
> Al Boldi wrote:
>
> >Here specifically, ip/ifconfig is implemented upside-down requiring a
> >link/dev to exist for an address to be defined, in effect containing layer
> >3 inside layer 2, when an address should be allowed to be defined w/o a
> >link/dev much like an app is allowed to be defined w/o an address.
>
> [Removed lkml from CC list]
>
> You can add multiple virtual IP addresses to physical interfaces. It
> makes no sense to have an IP without any association to an interface
> in my opinion. Often, when you have multiple interfaces, you most
> definately
> want different IPs associated specifically with particular interfaces.
> Think about redundant paths, routers, firewalls, and such.
The association between IP addresses and links is already a bit murky.
Reference the arp_announce sysctl for what I mean. I recall Dave M.
emphasizing on at least one occassion that IP addresses belong to
the _box_, not to the link.
I think Al B.'s idea merits some consideration. I definitely think
we blur the distinctions between L2 and L3 a bit too much in places.
Of course, patches would be helpful...
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Highly Recommended Cailis fuDkW
From: Evangelina Vasquez @ 2005-12-05 13:46 UTC (permalink / raw)
To: murray
"Ci-ialis Softabs" is better than Pfizer Viiagrra
and normal Ci-ialis because:
- Guaaraantees 36 hours lasting
- Safe to take, no side effects at all
- Boost and increase se-xual performance
- Haarder e-rectiions and quick recharge
- Proven and certified by experts and doctors
- only $3.99 per tabs
Cllick heree:
http://uk.geocities.com/Dominga95177Sylas3105/
roovvQ
^ permalink raw reply
* ¢³øL¦
From: mahomaho094dsh @ 2005-12-05 12:39 UTC (permalink / raw)
To: netdev
j4mC34LcgrWCxIFCgXmDWoOMg3WJ74FGkeOVXCCL4I/pkF6LfIF6gsaQXIK1gtyCt4FCDQqC
sYLMg1SDQ4NngsmPb46RgrWCxIKigumCzILFk8GVyoLJi5aJwoLwkriCq4FBleWPV4K1gtyC
t4FCDQqKhJDYgsGCvYzwjduC8IuBgt+C6ZROjvsxNTAwlpyIyI/jgsyPl5CrgsaCzIt0g1SD
fIGbg2eM8I3bgvCCtYLEgt2C3IK5gvGCqYFIDQqBnZP8ie+L4IFFie+U75OZgreC14LEj5eQ
q5WJklOBQZJqkKuCzYLcgsGCvYKtl7+L4IKqinyCqYLogtyCuYLxgUINCoGdjI4xgWAyifEo
j5eQq4LJguaC6YFBlpSCzZhigrWNh4KigsUpDQqBnYqEkNiCwYK9itaMV4FBjIuNpZFPkvGB
QYNyg1eDbINYg3CBW4Nng2mBW4FBj5eQq4LMltqTSYLgl2yBWILFgrcNCmh0dHA6Ly93d3cu
NTUxNWQuY29tL35mYzUwMTIvDQqXVJWfgsiPl5Crie+I9YLNk/yJ74vggUWJ75TvgvCVpYLB
gsSTb5hegrWCxIKigtyCt4FCDQqX4oLigqmCtYFBg1SDToOJgsyPl5Crgs2I6pBsguCCooLc
grmC8YLMgsWCsojAkFOCrYK+grOCooFCDQoNCi0tDQqUepBNjtKBRoz8iOSQXpS/DQoxMDIt
MDA3NQ0Kk4yLnpNzkOeR45Nji+aOT5TUkqw2lNSSbg0KlHqQTYuRlNuCzJX7gs2CsYK/gueC
yYKymEGXjYm6grOCooFCDQptYWhvbWFobzA5NGRzaEB5YWhvby5jb20NCg==
^ permalink raw reply
* antic Get promoted with one of our special accessories. stockroom
From: Merav @ 2005-12-05 10:33 UTC (permalink / raw)
To: Leon Malit; +Cc: lockmeter, netdev, knight, glover, andrews, ver, ralf, bates
Do you recall how you said you wanted a new timepiece?
Well, I fell upon an internet address that has hundreds of fantastic ones
and I honestly think you should stop by.
I'm tired of seeing your look of sorrow whenever we go to the mall and you
can't afford luxury things.
You definitely deserve something well-made and these classic pieces are
really feasible.
The shop is convenient, with a rapid dispatchment and cyber order locating
tool.
fj http://au.geocities.com/amedwreathegoodau
I can just picture the overjoyed look on your face when you pick up your
delivery.
These words, in plain English, conveyed an injunction to ring the bell. It
was answered by another Jew: puppyer than Fagin, but nearly as vile and
repulsive in appearance.
ewass eheathers exyugoslav HZ02 easma riff-format
`If she goes I shan't; and if I don't, Laurie won't like it; and it will be
very rude, after he invited only us, to go and drag in Amy. I should think
she'd hate to poke herself where she isn't wanted,' said Jo, crossly, for
she disliked the trouble of overseeing a fidgety child, when she wanted to
enjoy herself. Her tone and manner angered Amy, who began to put her boots
on, saying, in her most aggravating way, `I shall go; Meg says I may; and if
I pay for myself, Laurie hasn't anything to do with it.'
`You can't sit with us, for our seats are reserved, and you mustn't sit
alone; so Laurie will give you his place, and that will spoil our pleasure;
or he'll get another seat for you, and that isn't proper, when you weren't
asked. You shan't stir a step; so you may just stay where you are,' scolded
Jo, crosser than ever, having just pricked her finger in her hurry.
^ permalink raw reply
* (no subject)
From: polpolkim6677 @ 2005-12-05 4:32 UTC (permalink / raw)
^ permalink raw reply
* Re: [RFC: -mm patch] drivers/net/wireless/hostap/hostap_main.c shouldn't #include C files
From: Jouni Malinen @ 2005-12-05 2:14 UTC (permalink / raw)
To: Adrian Bunk; +Cc: netdev, hostap, linux-kernel
In-Reply-To: <20051203122309.GD31395@stusta.de>
On Sat, Dec 03, 2005 at 01:23:09PM +0100, Adrian Bunk wrote:
> This patch contains an attempt to properly build hostap.o without
> #incude'ing C files.
Looks good. However, I did not test this now since this did not apply to
netdev-2.6 (it does not have hostap_main.c). Did the hostap.c to
hostap_main.c rename go only to -mm? I would prefer to do this kind of
changes in a single place and I thought netdev-2.6 would be that. I'm
not following -mm tree at all and it would be easier to go through
patches if they are against netdev-2.6 upstream branch.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: Linux 2.6.15-rc5: sk98lin broken
From: Johannes Stezenbach @ 2005-12-04 23:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, shemminger, netdev
In-Reply-To: <Pine.LNX.4.64.0512032155290.3099@g5.osdl.org>
On Sat, Dec 03, 2005, Linus Torvalds wrote:
> shemminger@osdl.org:
> sk98lin: fix checksumming code
> sk98lin: add permanent address support
> sk98lin: avoid message confusion with skge
I have an Asus P4P800 "Deluxe" with 3c940 LOM.
If I ping the box I get the following:
Dec 4 22:57:02 abc kernel: [<c0103c00>] dump_stack+0x17/0x19
Dec 4 22:57:02 abc kernel: [<c03b99e9>] netdev_rx_csum_fault+0x27/0x2d
Dec 4 22:57:02 abc kernel: [<c03b75a9>] __skb_checksum_complete+0x5a/0x60
Dec 4 22:57:02 abc kernel: [<c0404c51>] icmp_error+0xbd/0x193
Dec 4 22:57:02 abc kernel: [<c0402291>] ip_conntrack_in+0x67/0x279
Dec 4 22:57:02 abc kernel: [<c03c8cbf>] nf_iterate+0x59/0x7d
Dec 4 22:57:02 abc kernel: [<c03c8d3a>] nf_hook_slow+0x57/0x106
Dec 4 22:57:02 abc kernel: [<c03d1074>] ip_rcv+0x1af/0x580
Dec 4 22:57:02 abc kernel: [<c03ba1ed>] netif_receive_skb+0x15a/0x1ef
Dec 4 22:57:02 abc kernel: [<c03ba301>] process_backlog+0x7f/0x10d
Dec 4 22:57:02 abc kernel: [<c03ba40c>] net_rx_action+0x7d/0x110
Dec 4 22:57:02 abc kernel: [<c01250a2>] __do_softirq+0x72/0xe1
Dec 4 22:57:02 abc kernel: [<c0104ed7>] do_softirq+0x5d/0x61
Dec 4 22:57:02 abc kernel: =======================
Dec 4 22:57:02 abc kernel: [<c01251fa>] irq_exit+0x48/0x4a
Dec 4 22:57:02 abc kernel: [<c0104d9d>] do_IRQ+0x5d/0x8f
Dec 4 22:57:02 abc kernel: [<c010372e>] common_interrupt+0x1a/0x20
Dec 4 22:57:02 abc kernel: [<c0100d51>] cpu_idle+0x49/0xa0
Dec 4 22:57:02 abc kernel: [<c01002d7>] rest_init+0x37/0x39
Dec 4 22:57:02 abc kernel: [<c057f8cf>] start_kernel+0x164/0x177
Dec 4 22:57:02 abc kernel: [<c0100210>] 0xc0100210
(once for each ICMP packet)
2.6.15-rc2 works fine.
Johannes
^ permalink raw reply
* Re: [PATCH 06/13]: [IPV4/6]: Netfilter IPsec input hooks
From: Patrick McHardy @ 2005-12-04 22:49 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <20051204221002.GA17056@gondor.apana.org.au>
Herbert Xu wrote:
> On Sun, Dec 04, 2005 at 11:06:02PM +0100, Patrick McHardy wrote:
>
> If there is a DNAT in the way, this will jump to the very start of
> the stack. So if we have a hostile IPsec peer, and the DNAT rules
> are such that this can occur, then we could be in trouble (especially
> because policy/selector verification does not occur until all IPsec
> has been done so we can't check inner address validitiy at this point).
We could return NET_XMIT_BYPASS from ip_xfrm_transport_hook(), although
it looks a bit ugly to use NET_XMIT* on the input path.
^ permalink raw reply
* [PATCH] natsemi: NAPI support
From: Mark Brown @ 2005-12-04 22:47 UTC (permalink / raw)
To: Jeff Garzik, Tim Hockin; +Cc: Harald Welte, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 8906 bytes --]
This patch against 2.6.14 converts the natsemi driver to use NAPI. It
was originally based on one written by Harald Welte, though it has since
been modified quite a bit, most extensively in order to remove the
ability to disable NAPI since none of the other drivers seem to provide
that functionality any more.
Signed-off-by: Mark Brown <broonie@sirena.org.uk>
--- linux-2.6.14/drivers/net/natsemi.c.orig 2005-11-29 19:29:12.000000000 +0000
+++ linux/drivers/net/natsemi.c 2005-12-04 22:13:33.000000000 +0000
@@ -3,6 +3,7 @@
Written/copyright 1999-2001 by Donald Becker.
Portions copyright (c) 2001,2002 Sun Microsystems (thockin@sun.com)
Portions copyright 2001,2002 Manfred Spraul (manfred@colorfullife.com)
+ Portions copyright 2004 Harald Welte <laforge@gnumonks.org>
This software may be used and distributed according to the terms of
the GNU General Public License (GPL), incorporated herein by reference.
@@ -136,7 +137,6 @@
TODO:
* big endian support with CFG:BEM instead of cpu_to_le32
* support for an external PHY
- * NAPI
*/
#include <linux/config.h>
@@ -160,6 +160,7 @@
#include <linux/mii.h>
#include <linux/crc32.h>
#include <linux/bitops.h>
+#include <linux/prefetch.h>
#include <asm/processor.h> /* Processor type for cache alignment. */
#include <asm/io.h>
#include <asm/irq.h>
@@ -183,8 +184,6 @@
NETIF_MSG_TX_ERR)
static int debug = -1;
-/* Maximum events (Rx packets, etc.) to handle at each interrupt. */
-static int max_interrupt_work = 20;
static int mtu;
/* Maximum number of multicast addresses to filter (vs. rx-all-multicast).
@@ -251,14 +250,11 @@
MODULE_DESCRIPTION("National Semiconductor DP8381x series PCI Ethernet driver");
MODULE_LICENSE("GPL");
-module_param(max_interrupt_work, int, 0);
module_param(mtu, int, 0);
module_param(debug, int, 0);
module_param(rx_copybreak, int, 0);
module_param_array(options, int, NULL, 0);
module_param_array(full_duplex, int, NULL, 0);
-MODULE_PARM_DESC(max_interrupt_work,
- "DP8381x maximum events handled per interrupt");
MODULE_PARM_DESC(mtu, "DP8381x MTU (all boards)");
MODULE_PARM_DESC(debug, "DP8381x default debug level");
MODULE_PARM_DESC(rx_copybreak,
@@ -691,6 +687,8 @@
/* Based on MTU+slack. */
unsigned int rx_buf_sz;
int oom;
+ /* Interrupt status */
+ u32 intr_status;
/* Do not touch the nic registers */
int hands_off;
/* external phy that is used: only valid if dev->if_port != PORT_TP */
@@ -748,7 +746,8 @@
static int start_tx(struct sk_buff *skb, struct net_device *dev);
static irqreturn_t intr_handler(int irq, void *dev_instance, struct pt_regs *regs);
static void netdev_error(struct net_device *dev, int intr_status);
-static void netdev_rx(struct net_device *dev);
+static int natsemi_poll(struct net_device *dev, int *budget);
+static void netdev_rx(struct net_device *dev, int *work_done, int work_to_do);
static void netdev_tx_done(struct net_device *dev);
static int natsemi_change_mtu(struct net_device *dev, int new_mtu);
#ifdef CONFIG_NET_POLL_CONTROLLER
@@ -776,6 +775,18 @@
return (void __iomem *) dev->base_addr;
}
+static inline void natsemi_irq_enable(struct net_device *dev)
+{
+ writel(1, ns_ioaddr(dev) + IntrEnable);
+ readl(ns_ioaddr(dev) + IntrEnable);
+}
+
+static inline void natsemi_irq_disable(struct net_device *dev)
+{
+ writel(0, ns_ioaddr(dev) + IntrEnable);
+ readl(ns_ioaddr(dev) + IntrEnable);
+}
+
static void move_int_phy(struct net_device *dev, int addr)
{
struct netdev_private *np = netdev_priv(dev);
@@ -879,6 +890,7 @@
spin_lock_init(&np->lock);
np->msg_enable = (debug >= 0) ? (1<<debug)-1 : NATSEMI_DEF_MSG;
np->hands_off = 0;
+ np->intr_status = 0;
/* Initial port:
* - If the nic was configured to use an external phy and if find_mii
@@ -932,6 +944,9 @@
dev->do_ioctl = &netdev_ioctl;
dev->tx_timeout = &tx_timeout;
dev->watchdog_timeo = TX_TIMEOUT;
+ dev->poll = natsemi_poll;
+ dev->weight = 64;
+
#ifdef CONFIG_NET_POLL_CONTROLLER
dev->poll_controller = &natsemi_poll_controller;
#endif
@@ -2158,68 +2173,93 @@
}
}
-/* The interrupt handler does all of the Rx thread work and cleans up
- after the Tx thread. */
+/* The interrupt handler doesn't actually handle interrupts itself, it
+ * schedules a NAPI poll if there is anything to do. */
static irqreturn_t intr_handler(int irq, void *dev_instance, struct pt_regs *rgs)
{
struct net_device *dev = dev_instance;
struct netdev_private *np = netdev_priv(dev);
void __iomem * ioaddr = ns_ioaddr(dev);
- int boguscnt = max_interrupt_work;
- unsigned int handled = 0;
if (np->hands_off)
return IRQ_NONE;
- do {
- /* Reading automatically acknowledges all int sources. */
- u32 intr_status = readl(ioaddr + IntrStatus);
+
+ /* Reading automatically acknowledges. */
+ np->intr_status = readl(ioaddr + IntrStatus);
- if (netif_msg_intr(np))
- printk(KERN_DEBUG
- "%s: Interrupt, status %#08x, mask %#08x.\n",
- dev->name, intr_status,
- readl(ioaddr + IntrMask));
+ if (netif_msg_intr(np))
+ printk(KERN_DEBUG
+ "%s: Interrupt, status %#08x, mask %#08x.\n",
+ dev->name, np->intr_status,
+ readl(ioaddr + IntrMask));
- if (intr_status == 0)
- break;
- handled = 1;
+ if (!np->intr_status)
+ return IRQ_NONE;
- if (intr_status &
- (IntrRxDone | IntrRxIntr | RxStatusFIFOOver |
- IntrRxErr | IntrRxOverrun)) {
- netdev_rx(dev);
- }
+ prefetch(&np->rx_skbuff[np->cur_rx % RX_RING_SIZE]);
+
+ if (netif_rx_schedule_prep(dev)) {
+ /* Disable interrupts and register for poll */
+ natsemi_irq_disable(dev);
+ __netif_rx_schedule(dev);
+ }
+ return IRQ_HANDLED;
+}
+
+/* This is the NAPI poll routine. As well as the standard RX handling
+ * it also handles all other interrupts that the chip might raise.
+ */
+static int natsemi_poll(struct net_device *dev, int *budget)
+{
+ struct netdev_private *np = netdev_priv(dev);
+ void __iomem * ioaddr = ns_ioaddr(dev);
- if (intr_status &
- (IntrTxDone | IntrTxIntr | IntrTxIdle | IntrTxErr)) {
+ int work_to_do = min(*budget, dev->quota);
+ int work_done = 0;
+
+ spin_lock_irq(&np->lock);
+ if (np->hands_off) {
+ spin_unlock_irq(&np->lock);
+ return 0;
+ }
+ spin_unlock_irq(&np->lock);
+
+ do {
+ if (np->intr_status &
+ (IntrTxDone | IntrTxIntr | IntrTxIdle | IntrTxErr)) {
spin_lock(&np->lock);
netdev_tx_done(dev);
spin_unlock(&np->lock);
}
-
+
/* Abnormal error summary/uncommon events handlers. */
- if (intr_status & IntrAbnormalSummary)
- netdev_error(dev, intr_status);
-
- if (--boguscnt < 0) {
- if (netif_msg_intr(np))
- printk(KERN_WARNING
- "%s: Too much work at interrupt, "
- "status=%#08x.\n",
- dev->name, intr_status);
- break;
+ if (np->intr_status & IntrAbnormalSummary)
+ netdev_error(dev, np->intr_status);
+
+ if (np->intr_status &
+ (IntrRxDone | IntrRxIntr | RxStatusFIFOOver |
+ IntrRxErr | IntrRxOverrun)) {
+ netdev_rx(dev, &work_done, work_to_do);
}
- } while (1);
+
+ *budget -= work_done;
+ dev->quota -= work_done;
- if (netif_msg_intr(np))
- printk(KERN_DEBUG "%s: exiting interrupt.\n", dev->name);
+ if (work_done >= work_to_do)
+ return 1;
- return IRQ_RETVAL(handled);
+ np->intr_status = readl(ioaddr + IntrStatus);
+ } while (np->intr_status);
+
+ netif_rx_complete(dev);
+ natsemi_irq_enable(dev);
+
+ return 0;
}
/* This routine is logically part of the interrupt handler, but separated
for clarity and better register allocation. */
-static void netdev_rx(struct net_device *dev)
+static void netdev_rx(struct net_device *dev, int *work_done, int work_to_do)
{
struct netdev_private *np = netdev_priv(dev);
int entry = np->cur_rx % RX_RING_SIZE;
@@ -2237,6 +2277,12 @@
entry, desc_status);
if (--boguscnt < 0)
break;
+
+ if (*work_done >= work_to_do)
+ break;
+
+ (*work_done)++;
+
pkt_len = (desc_status & DescSizeMask) - 4;
if ((desc_status&(DescMore|DescPktOK|DescRxLong)) != DescPktOK){
if (desc_status & DescMore) {
@@ -2293,7 +2339,7 @@
np->rx_skbuff[entry] = NULL;
}
skb->protocol = eth_type_trans(skb, dev);
- netif_rx(skb);
+ netif_receive_skb(skb);
dev->last_rx = jiffies;
np->stats.rx_packets++;
np->stats.rx_bytes += pkt_len;
@@ -3175,6 +3221,8 @@
disable_irq(dev->irq);
spin_lock_irq(&np->lock);
+ netif_poll_disable(dev);
+
writel(0, ioaddr + IntrEnable);
np->hands_off = 1;
natsemi_stop_rxtx(dev);
@@ -3235,6 +3283,7 @@
mod_timer(&np->timer, jiffies + 1*HZ);
}
netif_device_attach(dev);
+ netif_poll_enable(dev);
out:
rtnl_unlock();
return 0;
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* Re: [PATCH 05/13]: [IPV4/6]: Netfilter IPsec output hooks
From: Herbert Xu @ 2005-12-04 22:15 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <43936905.2000700@trash.net>
On Sun, Dec 04, 2005 at 11:09:09PM +0100, Patrick McHardy wrote:
>
> Thanks, I've added the correct patch now :) Unless I missed something,
> it was still missing a call to dst_output after the last transform
> in xfrm4_output_finish, unless we keep the loop in dst_output.
Good catch. The lines
err = 0;
if (!skb->dst->xfrm)
break;
should read
if (!skb->dst->xfrm)
return dst_output(skb);
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 06/13]: [IPV4/6]: Netfilter IPsec input hooks
From: Herbert Xu @ 2005-12-04 22:10 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <4393684A.8030208@trash.net>
On Sun, Dec 04, 2005 at 11:06:02PM +0100, Patrick McHardy wrote:
>
> >I'm worried about this bit. This looks like it'll go back to the top
> >of the IP stack with the existing call chain. So could grow as the
> >number of transforms increase.
>
> Its not so bad. It adds ip_xfrm_transport_hook and
> ip_local_deliver_finish to the call stack, but since two subsequent
> transport mode SAs are always processed at once it can't take this
> path again without calling netif_rx in between.
If there is a DNAT in the way, this will jump to the very start of
the stack. So if we have a hostile IPsec peer, and the DNAT rules
are such that this can occur, then we could be in trouble (especially
because policy/selector verification does not occur until all IPsec
has been done so we can't check inner address validitiy at this point).
> Besides the double counting, packets also appear on the packet sockets
> after transport mode decapsulation with the original approach. For
> IPv6 there's also the double-parsing of extension header issue.
Having the packets appear twice on AF_PACKET is probably desirable :)
I'll need to think about the double-parsing though.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 05/13]: [IPV4/6]: Netfilter IPsec output hooks
From: Patrick McHardy @ 2005-12-04 22:09 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <20051128045611.GA9571@gondor.apana.org.au>
Herbert Xu wrote:
>>before tunnel mode transforms and added a missing dst_output call
>>for the final packet.
>
> This shouldn't be necessary if you apply it on top of my previous
> patch which made xfrm[46]_output process the first SA and all subsequent
> transport mode SAs. I've included that patch here again.
Thanks, I've added the correct patch now :) Unless I missed something,
it was still missing a call to dst_output after the last transform
in xfrm4_output_finish, unless we keep the loop in dst_output.
^ permalink raw reply
* Re: [PATCH 06/13]: [IPV4/6]: Netfilter IPsec input hooks
From: Patrick McHardy @ 2005-12-04 22:06 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <20051201012711.GA2527@gondor.apana.org.au>
Herbert Xu wrote:
> On Sun, Nov 20, 2005 at 04:31:36PM +0000, Patrick McHardy wrote:
>
>>@@ -145,7 +149,17 @@ int xfrm4_rcv_encap(struct sk_buff *skb,
>> netif_rx(skb);
>> return 0;
>> } else {
>>+#ifdef CONFIG_NETFILTER
>>+ __skb_push(skb, skb->data - skb->nh.raw);
>>+ skb->nh.iph->tot_len = htons(skb->len);
>>+ ip_send_check(skb->nh.iph);
>>+
>>+ NF_HOOK(PF_INET, NF_IP_PRE_ROUTING, skb, skb->dev, NULL,
>>+ ip_xfrm_transport_hook);
>>+ return 0;
>>+#else
>> return -skb->nh.iph->protocol;
>>+#endif
>
>
> I'm worried about this bit. This looks like it'll go back to the top
> of the IP stack with the existing call chain. So could grow as the
> number of transforms increase.
Its not so bad. It adds ip_xfrm_transport_hook and
ip_local_deliver_finish to the call stack, but since two subsequent
transport mode SAs are always processed at once it can't take this
path again without calling netif_rx in between.
> Perhaps we need to play a dst_input/netif_rx trick here.
>
> Actually, was there a problem with your original netif_rx approach
> apart from the issue with double counting?
Besides the double counting, packets also appear on the packet sockets
after transport mode decapsulation with the original approach. For
IPv6 there's also the double-parsing of extension header issue.
^ permalink raw reply
* smtp mail failed
From: hostmaster @ 2005-12-04 20:59 UTC (permalink / raw)
To: priv-mail
[-- Attachment #1: Type: text/plain, Size: 241 bytes --]
This is an automatically generated Delivery Status Notification.
SMTP_Error []
I'm afraid I wasn't able to deliver your message.
This is a permanent error; I've given up. Sorry it didn't work out.
The full mail-text and header is attached!
[-- Attachment #2: mail.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: [-mm patch] remove code for WIRELESS_EXT < 18
From: Adrian Bunk @ 2005-12-04 19:52 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel
In-Reply-To: <4393447E.3020003@pobox.com>
On Sun, Dec 04, 2005 at 02:33:18PM -0500, Jeff Garzik wrote:
> Adrian Bunk wrote:
> >WIRELESS_EXT < 18 will never be true in the kernel.
> >
> >
> >Signed-off-by: Adrian Bunk <bunk@stusta.de>
> >
> >---
> >
> > drivers/net/wireless/ipw2100.c | 434 ----------------------
> > drivers/net/wireless/tiacx/acx_struct.h | 5
> > drivers/net/wireless/tiacx/common.c | 4
> > drivers/net/wireless/tiacx/conv.c | 2
> > drivers/net/wireless/tiacx/ioctl.c | 441 -----------------------
> > drivers/net/wireless/tiacx/pci.c | 8
> > drivers/net/wireless/tiacx/usb.c | 6
> > drivers/net/wireless/tiacx/wlan.c | 2
> > drivers/net/wireless/tiacx/wlan_compat.h | 9
> > 9 files changed, 1 insertion(+), 910 deletions(-)
>
> NAK, patches non-existent files.
>
> [jgarzik@pretzel linux-2.6]$ ls drivers/net/wireless/tiacx
> ls: drivers/net/wireless/tiacx: No such file or directory
As the subject says, it's against -mm.
How should I resend it?
One patch against ipw2100.c and one patch for the tiacx stuff?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [-mm patch] remove code for WIRELESS_EXT < 18
From: Jeff Garzik @ 2005-12-04 19:33 UTC (permalink / raw)
To: Adrian Bunk; +Cc: netdev, linux-kernel
In-Reply-To: <20051203122720.GF31395@stusta.de>
Adrian Bunk wrote:
> WIRELESS_EXT < 18 will never be true in the kernel.
>
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> ---
>
> drivers/net/wireless/ipw2100.c | 434 ----------------------
> drivers/net/wireless/tiacx/acx_struct.h | 5
> drivers/net/wireless/tiacx/common.c | 4
> drivers/net/wireless/tiacx/conv.c | 2
> drivers/net/wireless/tiacx/ioctl.c | 441 -----------------------
> drivers/net/wireless/tiacx/pci.c | 8
> drivers/net/wireless/tiacx/usb.c | 6
> drivers/net/wireless/tiacx/wlan.c | 2
> drivers/net/wireless/tiacx/wlan_compat.h | 9
> 9 files changed, 1 insertion(+), 910 deletions(-)
NAK, patches non-existent files.
[jgarzik@pretzel linux-2.6]$ ls drivers/net/wireless/tiacx
ls: drivers/net/wireless/tiacx: No such file or directory
^ permalink raw reply
* ¿À´Ãµµ Æí¾ÈÇϼ¼¿ä?
From: ¹æ ¿µÁ¦ @ 2005-12-04 13:50 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: multipart/alternative, Size: 2259 bytes --]
^ permalink raw reply
* ¿À´Ãµµ Æí¾ÈÇϼ¼¿ä?
From: ÇÇ »ó±¹ @ 2005-12-03 23:47 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: multipart/alternative, Size: 2258 bytes --]
^ 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