* Re: [PATCH 0/6] forcedeth interrupt and task overhaul, v2
From: Jeff Garzik @ 2007-10-17 5:59 UTC (permalink / raw)
To: netdev, LKML; +Cc: Manfred Spraul, Ingo Molnar, Ayaz Abdulla
In-Reply-To: <20071017055251.GA19972@havoc.gtf.org>
Jeff Garzik wrote:
> These six changes can be found in the 'fe' branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
Note the change from the previous 'fe-lock' branch, which is now left
as-is on kernel.org, but not being updated.
^ permalink raw reply
* Sven Lukas is out of the office.
From: Sven Lukas @ 2007-10-17 6:18 UTC (permalink / raw)
To: netdev
I will be out of the office starting 10/16/2007 and will not return until
10/22/2007.
For topics regarding Malta or Elba driver release please contact Christian
Rund and Gunner von Boehn. For network relates issues please contact Adrian
Reber. Please contact Christopher Oelsner for all other topics.
For topics regarding Broadcom NIC please contact Tim Wensky.
For topics regarding SLOF driver releases for Malta please contact Thomas
Huth.
For all other issues please contact Christopher Oelsner, Stefan Koch4 or
Hartmut Penner.
^ permalink raw reply
* Re: [patch] ipv6.7: IPV6_ROUTER_ALERT sockopt correction
From: Pekka Savola @ 2007-10-17 6:19 UTC (permalink / raw)
To: Andrew McDonald; +Cc: netdev
In-Reply-To: <20071016201550.GC28453@mcdonald.org.uk>
On Tue, 16 Oct 2007, Andrew McDonald wrote:
> For why you don't want to packets to be forwarded, consider a simple
> example that applies to something like RSVP:
> - packet hits router, identified as potentially interesting from router
> alert option
> - packet passed to user space, confirmed as really interesting and
> processed
> - create new packet (based on the one that came in and the RSVP
> processing you've done) and send it out
>
> You don't want the original packet you received to be forwarded, only
> your new packet.
Router alert option on a hop-by-hop header means that every router on
the path should process the option.
You did not mention the rationale why the it would be reasonable for a
packet that would otherwise be forwarded by the Linux router and
expected to be processed by every router on the path to be re-created
at every step, and every user-space application have to do that.
In the specific case of RSVP packets, AFAIK (e.g., Path and PathTear
messages), the content of the RSVP packet is expected to be the
same at every hop.
Your argument might make sense in the case where the payload of the
packet carrying router-alert option is expected to change at every
hop. I believe that's not the intent of any router alert options that
I'm aware of.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
^ permalink raw reply
* BUG: unable to handle kernel NULL pointer dereference at virtual address 000000b0
From: Krzysztof Oledzki @ 2007-10-17 6:40 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1836 bytes --]
Hello,
Today I found in my logs:
BUG: unable to handle kernel NULL pointer dereference at virtual address 000000b0
printing eip:
78395f65
*pde = 00000000
Oops: 0000 [#1]
PREEMPT SMP
CPU: 0
EIP: 0060:[<78395f65>] Not tainted VLI
EFLAGS: 00210286 (2.6.22.9 #1)
EIP is at __ip_route_output_key+0x412/0x722
eax: 80000000 ebx: 00000000 ecx: 5dd2b1c3 edx: 00000000
esi: 00000000 edi: d44c7e30 ebp: ec8c4980 esp: d44c7ddc
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process smtpd (pid: 12479, ti=d44c6000 task=9e759510 task.ti=d44c6000)
Stack: d44c7e7c d44c7e7c d44c7eb8 00000000 d44c7e7c 00000000 00000000 00000005
00000000 ffffffff 5dd2b1c3 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00030000 00000000 d44c7e7c
Call Trace:
[<78396280>] ip_route_output_flow+0xb/0x3e
[<783b2b29>] ip4_datagram_connect+0x1c9/0x308
[<783ba70a>] inet_dgram_connect+0x45/0x4e
[<7837135e>] sys_connect+0x72/0x9c
[<78371607>] sock_map_fd+0x41/0x4a
[<7840d1b1>] _spin_lock+0x33/0x3e
[<7840d623>] _spin_unlock+0x25/0x3b
[<78371607>] sock_map_fd+0x41/0x4a
[<78372792>] sys_socketcall+0x8f/0x242
[<7813e99c>] trace_hardirqs_on+0x122/0x14c
[<78103dc6>] sysenter_past_esp+0x8f/0x99
[<78103d96>] sysenter_past_esp+0x5f/0x99
=======================
Code: fa e0 00 00 00 75 07 c6 44 24 56 05 eb 14 81 fa f0 00 00 00 0f 84 e1 02 00 00 84 c0 0f 84 d9 02 00 00 8b 44 24 0c 0d 00 00 00 80 <f6> 86 b0 00 00 00 08 0f 44 44 24 0c 89 44 24 0c b8 01 00 00 00
EIP: [<78395f65>] __ip_route_output_key+0x412/0x722 SS:ESP 0068:d44c7ddc
Shortly before it there was:
Oct 17 07:17:55 cougar postfix/master[3400]: warning: process /usr/lib/postfix/smtpd pid 12479 killed by signal 11
Best regards,
Krzysztof Olędzki
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at virtual address 000000b0
From: Eric Dumazet @ 2007-10-17 6:57 UTC (permalink / raw)
To: Krzysztof Oledzki; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0710170833071.21430@bizon.gios.gov.pl>
Krzysztof Oledzki a écrit :
> Hello,
>
> Today I found in my logs:
>
> BUG: unable to handle kernel NULL pointer dereference at virtual address
> 000000b0
> printing eip:
> 78395f65
> *pde = 00000000
> Oops: 0000 [#1]
> PREEMPT SMP
> CPU: 0
> EIP: 0060:[<78395f65>] Not tainted VLI
> EFLAGS: 00210286 (2.6.22.9 #1)
> EIP is at __ip_route_output_key+0x412/0x722
> eax: 80000000 ebx: 00000000 ecx: 5dd2b1c3 edx: 00000000
> esi: 00000000 edi: d44c7e30 ebp: ec8c4980 esp: d44c7ddc
> ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
> Process smtpd (pid: 12479, ti=d44c6000 task=9e759510 task.ti=d44c6000)
> Stack: d44c7e7c d44c7e7c d44c7eb8 00000000 d44c7e7c 00000000 00000000
> 00000005
> 00000000 ffffffff 5dd2b1c3 00000000 00000000 00000000 00000000
> 00000000
> 00000000 00000000 00000000 00000000 00000000 00030000 00000000
> d44c7e7c
> Call Trace:
> [<78396280>] ip_route_output_flow+0xb/0x3e
> [<783b2b29>] ip4_datagram_connect+0x1c9/0x308
> [<783ba70a>] inet_dgram_connect+0x45/0x4e
> [<7837135e>] sys_connect+0x72/0x9c
> [<78371607>] sock_map_fd+0x41/0x4a
> [<7840d1b1>] _spin_lock+0x33/0x3e
> [<7840d623>] _spin_unlock+0x25/0x3b
> [<78371607>] sock_map_fd+0x41/0x4a
> [<78372792>] sys_socketcall+0x8f/0x242
> [<7813e99c>] trace_hardirqs_on+0x122/0x14c
> [<78103dc6>] sysenter_past_esp+0x8f/0x99
> [<78103d96>] sysenter_past_esp+0x5f/0x99
> =======================
> Code: fa e0 00 00 00 75 07 c6 44 24 56 05 eb 14 81 fa f0 00 00 00 0f 84
> e1 02 00 00 84 c0 0f 84 d9 02 00 00 8b 44 24 0c 0d 00 00 00 80 <f6> 86
> b0 00 00 00 08 0f 44 44 24 0c 89 44 24 0c b8 01 00 00 00
> EIP: [<78395f65>] __ip_route_output_key+0x412/0x722 SS:ESP 0068:d44c7ddc
>
> Shortly before it there was:
> Oct 17 07:17:55 cougar postfix/master[3400]: warning: process
> /usr/lib/postfix/smtpd pid 12479 killed by signal 11
>
> Best regards,
>
>
> Krzysztof Olędzki
Hello Krzysztof
Could you give us some details about this ? kernel version at least.
(you could for example take a look at REPORTING-BUGS, or run
scripts/ver_linux)
Thanks
^ permalink raw reply
* [PATCH] ip_gre: sendto/recvfrom NBMA address
From: Timo Teräs @ 2007-10-17 8:00 UTC (permalink / raw)
To: davem, netdev; +Cc: kuznet, linux-kernel
When GRE tunnel is in NBMA mode, this patch allows an application to use
a PF_PACKET socket to:
- send a packet to specific NBMA address with sendto()
- use recvfrom() to receive packet and check which NBMA address it came from
Signed-off-by: Timo Teras <timo.teras@iki.fi>
---
This is useful for implementing NHRP over NBMA GRE tunnels.
Sent earlier to netdev list only. Resending to wider audience with
a style issue fixed.
net/ipv4/ip_gre.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index f151900..b1e3816 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1033,7 +1033,6 @@ static int ipgre_tunnel_change_mtu(struct net_device *dev, int new_mtu)
return 0;
}
-#ifdef CONFIG_NET_IPGRE_BROADCAST
/* Nice toy. Unfortunately, useless in real life :-)
It allows to construct virtual multiprotocol broadcast "LAN"
over the Internet, provided multicast routing is tuned.
@@ -1092,10 +1091,19 @@ static int ipgre_header(struct sk_buff *skb, struct net_device *dev,
return -t->hlen;
}
+static int ipgre_header_parse(const struct sk_buff *skb, unsigned char *haddr)
+{
+ struct iphdr *iph = (struct iphdr *) skb_mac_header(skb);
+ memcpy(haddr, &iph->saddr, 4);
+ return 4;
+}
+
static const struct header_ops ipgre_header_ops = {
.create = ipgre_header,
+ .parse = ipgre_header_parse,
};
+#ifdef CONFIG_NET_IPGRE_BROADCAST
static int ipgre_open(struct net_device *dev)
{
struct ip_tunnel *t = netdev_priv(dev);
@@ -1197,6 +1205,8 @@ static int ipgre_tunnel_init(struct net_device *dev)
dev->stop = ipgre_close;
}
#endif
+ } else {
+ dev->header_ops = &ipgre_header_ops;
}
if (!tdev && tunnel->parms.link)
^ permalink raw reply related
* Re: BUG: unable to handle kernel NULL pointer dereference at virtual address 000000b0
From: Krzysztof Oledzki @ 2007-10-17 8:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <4715B26E.20302@cosmosbay.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2969 bytes --]
On Wed, 17 Oct 2007, Eric Dumazet wrote:
> Krzysztof Oledzki a écrit :
>> Hello,
>>
>> Today I found in my logs:
>>
>> BUG: unable to handle kernel NULL pointer dereference at virtual address
>> 000000b0
>> printing eip:
>> 78395f65
>> *pde = 00000000
>> Oops: 0000 [#1]
>> PREEMPT SMP
>> CPU: 0
>> EIP: 0060:[<78395f65>] Not tainted VLI
>> EFLAGS: 00210286 (2.6.22.9 #1)
>> EIP is at __ip_route_output_key+0x412/0x722
>> eax: 80000000 ebx: 00000000 ecx: 5dd2b1c3 edx: 00000000
>> esi: 00000000 edi: d44c7e30 ebp: ec8c4980 esp: d44c7ddc
>> ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
>> Process smtpd (pid: 12479, ti=d44c6000 task=9e759510 task.ti=d44c6000)
>> Stack: d44c7e7c d44c7e7c d44c7eb8 00000000 d44c7e7c 00000000 00000000
>> 00000005
>> 00000000 ffffffff 5dd2b1c3 00000000 00000000 00000000 00000000
>> 00000000
>> 00000000 00000000 00000000 00000000 00000000 00030000 00000000
>> d44c7e7c
>> Call Trace:
>> [<78396280>] ip_route_output_flow+0xb/0x3e
>> [<783b2b29>] ip4_datagram_connect+0x1c9/0x308
>> [<783ba70a>] inet_dgram_connect+0x45/0x4e
>> [<7837135e>] sys_connect+0x72/0x9c
>> [<78371607>] sock_map_fd+0x41/0x4a
>> [<7840d1b1>] _spin_lock+0x33/0x3e
>> [<7840d623>] _spin_unlock+0x25/0x3b
>> [<78371607>] sock_map_fd+0x41/0x4a
>> [<78372792>] sys_socketcall+0x8f/0x242
>> [<7813e99c>] trace_hardirqs_on+0x122/0x14c
>> [<78103dc6>] sysenter_past_esp+0x8f/0x99
>> [<78103d96>] sysenter_past_esp+0x5f/0x99
>> =======================
>> Code: fa e0 00 00 00 75 07 c6 44 24 56 05 eb 14 81 fa f0 00 00 00 0f 84 e1
>> 02 00 00 84 c0 0f 84 d9 02 00 00 8b 44 24 0c 0d 00 00 00 80 <f6> 86 b0 00
>> 00 00 08 0f 44 44 24 0c 89 44 24 0c b8 01 00 00 00
>> EIP: [<78395f65>] __ip_route_output_key+0x412/0x722 SS:ESP 0068:d44c7ddc
>>
>> Shortly before it there was:
>> Oct 17 07:17:55 cougar postfix/master[3400]: warning: process
>> /usr/lib/postfix/smtpd pid 12479 killed by signal 11
>>
>> Best regards,
>>
>>
>> Krzysztof Olędzki
>
> Hello Krzysztof
>
> Could you give us some details about this ? kernel version at least.
Yes, I was little to hurry sending this bug report. Anyway, it is 2.6.22.9
like mentioned in the oops: EFLAGS: 00210286 (2.6.22.9 #1)
> (you could for example take a look at REPORTING-BUGS, or run
> scripts/ver_linux)
Linux cougar 2.6.22.9 #1 SMP PREEMPT Wed Oct 3 10:24:19 CEST 2007 i686 Intel(R) Pentium(R) D CPU 3.20GHz GenuineIntel GNU/Linux
Gnu C 4.1.2
Gnu make 3.81
binutils 2.17
util-linux 2.12r
mount 2.12r
module-init-tools 3.2.2
e2fsprogs 1.40.2
Linux C Library > libc.2.5
Dynamic linker (ldd) 2.5
Procps 3.2.7
Net-tools 1.60
Kbd 1.12
Sh-utils 6.9
Best regards,
Krzysztof OLędzki
^ permalink raw reply
* Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
From: Jarek Poplawski @ 2007-10-17 8:58 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Andy Fleming, Andrew Morton, Jeff Garzik, netdev, linux-kernel
In-Reply-To: <Pine.LNX.4.64N.0710161759050.22596@blysk.ds.pg.gda.pl>
On Tue, Oct 16, 2007 at 06:19:32PM +0100, Maciej W. Rozycki wrote:
...
> Well, enable_irq() and disable_irq() themselves are nesting, so they are
> not a problem. OTOH, free_irq() does not seem to maintain the depth count
> correctly, which looks like a bug to me and which could trigger regardless
> of whether flush_scheduled_work() or cancel_work_sync() was called.
I'm not sure free_irq() should maintain the depth count - rather warn
on not zero. But, IMHO, any activity on freed irq seems suspicious to
me (and doesn't look like very common), even if it's safe with current
implementation.
> The reason is CONFIG_DEBUG_SHIRQ which makes a simulated interrupt event
> be sent at the end of free_irq(). It looks like a problem that is
> complementary to one I signalled here:
>
> http://lkml.org/lkml/2007/9/12/82
>
> with respect to request_irq(), where, similarly, such an interrupt event
> is sent at the beginning. It looks like nobody was concerned back then,
> but perhaps it is time to do a better investigation now and propose a
> solution.
Yes, these DEBUG_SHIRQ checks are suspicious to me too, but they seem
to be reasonable only in the case of possible resent irqs (so not for
all irqs). On the other hand, it seems, proper irq handler with proper
hardware shouldn't have any problems with such a check.
> I'll think about it and thanks for your inquisitiveness that has led to
> these conclusions.
Btw., since, because of this patch, I've had a one more look at phy.c
and there are a few more doubts, so this time I'll try to bother you
for real:
1) phy_change() checks PHY_HALTED flag without lock; I think it's
racy: eg. if it's done during phy_stop() it can check just before
the flag is set and reenable interrupts just after phy_stop() ends.
2) phy_change() doesn't reenable irq line after it sees returns
with errors; IMHO it should at least write some warning, but maybe
try some safety plan, so enable_irq() and try to disable interrupts
and free_irq() on the next call (if it happens). (But, I can be very
wrong with this - maybe it's OK and official way.)
3) phy_interrupt() checks PHY_HALTED flag without lock too, but I'm
not sure now if it could be dangerous after fixing #1; on the other
hand even if we know it's not our regular interrupt, with current
DEBUG_SHIRQ it could be easier to call schedule_work() anyway since
we are sure it's before/in free_irq() yet.
4) phy_interrupt() should check return value from schedule_work() and
enable irq on 0.
5) phy_stop_interrupts(): maybe I miss something, but it seems
phy_stop() is required before this, so maybe there should be a
comment on this?
6) phy_stop_interrupts(): if I'm not wrong with #3 calling
phy_disable_interrupts() looks like we are not sure this phy_stop()
really works; than maybe a WARN_ON?
7) phy_stop_interrupts(): after above mentioned changes in
phy_interrupt(), and phy_changes() (always enable_irq()) I can't see
any reason why there should be more than one skipped enable_irq(),
so checking return from cancel_work_sync() shouldn't be enough
instead of this atomic counter.
8) phy_stop_interrupts(): I'm not sure this additional call from
DEBUG_SHIRQ should be so dangerous, eg.:
/*
* status == PHY_HALTED &&
* interrupts are stopped after phy_stop()
*/
if (cancel_work_sync(...))
enable_irq();
free_irq(...);
/*
* possible schedule_work() from DEBUG_SHIRQ only,
* but proper check for PHY_HALTED is done;
* so, let's flush after this too:
*/
cancel_work_sync();
Of course, I don't know phy.c enough, so most of this can be terribly
wrong, then feel free to forget about this - I don't expect you should
waste any time for explaining me these things - after all they are
doubts only.
Regards,
Jarek P.
^ permalink raw reply
* [PATCH] [net] gianfar: remove orphan struct.
From: Sebastian Siewior @ 2007-10-17 8:52 UTC (permalink / raw)
To: jeff; +Cc: netdev, Li Yang
struct net_device_stats is no longer used in driver's private
struct but in struct net_device.
Cc: Li Yang <leoli@freescale.com>
Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de>
---
drivers/net/gianfar.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index c16cc8b..46cd773 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -749,7 +749,6 @@ struct gfar_private {
uint32_t msg_enable;
/* Network Statistics */
- struct net_device_stats stats;
struct gfar_extra_stats extra_stats;
};
--
1.5.2.2
^ permalink raw reply related
* [PATCH] Fix ethernet multicast for ucc_geth.
From: Joakim Tjernlund @ 2007-10-17 9:05 UTC (permalink / raw)
To: Netdev, Li Yang-r58472
>From 5761a9e5924b34615c748fba2dcb977ed04c1243 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Wed, 17 Oct 2007 11:01:44 +0200
Subject: [PATCH] Fix ethernet multicast for ucc_geth.
hw_add_addr_in_hash() already swaps byte
order, don't do it in ucc_geth_set_multi() too.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
drivers/net/ucc_geth.c | 15 ++-------------
1 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 61f5cce..f649b1e 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2214,9 +2214,7 @@ static void ucc_geth_set_multi(struct net_device *dev)
struct dev_mc_list *dmi;
struct ucc_fast *uf_regs;
struct ucc_geth_82xx_address_filtering_pram *p_82xx_addr_filt;
- u8 tempaddr[6];
- u8 *mcptr, *tdptr;
- int i, j;
+ int i;
ugeth = netdev_priv(dev);
@@ -2255,19 +2253,10 @@ static void ucc_geth_set_multi(struct net_device *dev)
if (!(dmi->dmi_addr[0] & 1))
continue;
- /* The address in dmi_addr is LSB first,
- * and taddr is MSB first. We have to
- * copy bytes MSB first from dmi_addr.
- */
- mcptr = (u8 *) dmi->dmi_addr + 5;
- tdptr = (u8 *) tempaddr;
- for (j = 0; j < 6; j++)
- *tdptr++ = *mcptr--;
-
/* Ask CPM to run CRC and set bit in
* filter mask.
*/
- hw_add_addr_in_hash(ugeth, tempaddr);
+ hw_add_addr_in_hash(ugeth, dmi->dmi_addr);
}
}
}
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
From: Jarek Poplawski @ 2007-10-17 9:09 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Andy Fleming, Andrew Morton, Jeff Garzik, netdev, linux-kernel
In-Reply-To: <20071017085809.GA1658@ff.dom.local>
On Wed, Oct 17, 2007 at 10:58:09AM +0200, Jarek Poplawski wrote:
...
> 5) phy_stop_interrupts(): maybe I miss something, but it seems
> phy_stop() is required before this, so maybe there should be a
> comment on this?
>
> 6) phy_stop_interrupts(): if I'm not wrong with #3 calling
Should be:
6) phy_stop_interrupts(): if I'm not wrong with #5 calling
Jarek P.
^ permalink raw reply
* Re: [PATCH 2/2] Interface group match - netfilter part
From: Laszlo Attila Toth @ 2007-10-17 9:08 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, netfilter-devel
In-Reply-To: <47147692.8070709@trash.net>
Patrick McHardy írta:
> Laszlo Attila Toth wrote:
>> +static int match(const struct sk_buff *skb,
>> + const struct net_device *in,
>> + const struct net_device *out,
>> + const struct xt_match *match,
>> + const void *matchinfo,
>> + int offset,
>> + unsigned int protoff,
>> + int *hotdrop)
>> +{
>> + const struct xt_ifgroup_info *info = matchinfo;
>> +
>> + return ((in->ifgroup & info->mask) == info->group) ^ info->invert;
>
> The input interface is only valid in PREROUTING, INPUT and FORWARD.
> Why don't you support output-interface matching?
>
The new version supports output-interface, currently I'm rewriting
iptables part. But I'm not sure what to do with the forward chain
because both input and output interface are valid here. My idea is that
the ifgroup_match function checks ifgroup values of both input and
output interfaces if they are set. An example:
iptables -A FORWARD -m ifgroup --in-ifgroup 4 --out-ifgroup 5/0x0f -j ACCEPT
The packet's input interface must be in group 4 and output interface
must be in group 5 but only lower 4 bits are checked. If one of these
assumptions fails the match fails.
Is it ok, or only one of them should be checked as in xt_policy: if
input side matches, other one is not checked?
--
Attila
^ permalink raw reply
* Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
From: Benjamin Herrenschmidt @ 2007-10-17 9:08 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Maciej W. Rozycki, Andy Fleming, Andrew Morton, Jeff Garzik,
netdev, linux-kernel
In-Reply-To: <20071017085809.GA1658@ff.dom.local>
> Btw., since, because of this patch, I've had a one more look at phy.c
> and there are a few more doubts, so this time I'll try to bother you
> for real:
.../...
While there... is somebody interested in making the whole PHY lib
operate a task level and use mutexes instead of spinlock ? I need that
for drivers like EMAC (who use their own PHY layer for now), and I might
even give a go at adapting phylib myself, but I'd like to take the
temperature about it first.
Basically, there is nothing in phylib that is performance critical or
such that requires it to run at irq time and/or use locks. On the other
hand, it complicates things in various areas. The most obvious one being
that it prevents the network driver mii access callbacks from sleeping
which can be annoying as MDIO can be slow, and some drivers have fancy
muxes in there that are better off mutexed than spinlocked.
Ben.
^ permalink raw reply
* Re: [PATCH 2/2] Interface group match - netfilter part
From: Patrick McHardy @ 2007-10-17 9:11 UTC (permalink / raw)
To: panther; +Cc: netdev, netfilter-devel
In-Reply-To: <4715D117.3080405@balabit.hu>
Laszlo Attila Toth wrote:
> Patrick McHardy írta:
>
>> The input interface is only valid in PREROUTING, INPUT and FORWARD.
>> Why don't you support output-interface matching?
>>
>
> The new version supports output-interface, currently I'm rewriting
> iptables part. But I'm not sure what to do with the forward chain
> because both input and output interface are valid here. My idea is that
> the ifgroup_match function checks ifgroup values of both input and
> output interfaces if they are set. An example:
>
> iptables -A FORWARD -m ifgroup --in-ifgroup 4 --out-ifgroup 5/0x0f -j
> ACCEPT
>
> The packet's input interface must be in group 4 and output interface
> must be in group 5 but only lower 4 bits are checked. If one of these
> assumptions fails the match fails.
>
> Is it ok, or only one of them should be checked as in xt_policy: if
> input side matches, other one is not checked?
xt_policy is a special case because the policy structure is so
large I decided the user should better use the match twice if
he really needs it (its also a quite uncommon use). For the
ifgroup match I think it should behave exactly as the -i and -o
matches: allow matching both in FORWARD, input device in
PREROUTING and INPUT and output device in OUTPUT and POSTROUTING.
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Difference between device statistics from ifconfig and ip -s l l
From: Milan Kocian @ 2007-10-17 9:27 UTC (permalink / raw)
To: netdev
hello,
see dropped packets, please:
sit:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:04:23:D6:D5:DE
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:522284892 errors:0 dropped:16800 overruns:0 frame:0
TX packets:506064445 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1405350664 (1.3 GiB) TX bytes:4082649020 (3.8 GiB)
Base address:0xac00 Memory:ff6e0000-ff700000
see via ip l l (here are no dropped packets):
sit:~# ip -s l l dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc htb qlen 1000
link/ether 00:04:23:d6:d5:de brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
2494988681 523755694 0 0 0 57458
TX: bytes packets errors dropped carrier collsns
453184821 507470461 0 0 0 0
but see more detailed stats (dropped packet are as missed in RX errors ?!):
sit:~# ip -s -s l l dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc htb qlen 1000
link/ether 00:04:23:d6:d5:de brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
2752159866 524110163 0 0 0 57485
RX errors: length crc frame fifo missed
0 0 0 0 16800
TX: bytes packets errors dropped carrier collsns
607359337 507807361 0 0 0 0
TX errors: aborted fifo window heartbeat
0 0 0 0
Is this bug or feature ? From my point of view is somewhere lost any sum.
Or is it driver dependent? Kernel 2.6.23.1 (in 2.6.20.20 is the same behavior),
driver e1000. iproute2-ss070313; net-tools 1.60, ifconfig 1.42 (2001-04-13)
Regards,
--
Milan Kocian
^ permalink raw reply
* Re: Difference between device statistics from ifconfig and ip -s l l
From: Patrick McHardy @ 2007-10-17 9:36 UTC (permalink / raw)
To: Milan Kocian; +Cc: netdev
In-Reply-To: <20071017092659.GA16356@wq.cz>
Milan Kocian wrote:
> hello,
>
> see dropped packets, please:
>
> sit:~# ifconfig eth0
> eth0 Link encap:Ethernet HWaddr 00:04:23:D6:D5:DE
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:522284892 errors:0 dropped:16800 overruns:0 frame:0
> TX packets:506064445 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:1405350664 (1.3 GiB) TX bytes:4082649020 (3.8 GiB)
> Base address:0xac00 Memory:ff6e0000-ff700000
>
> see via ip l l (here are no dropped packets):
>
> sit:~# ip -s l l dev eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc htb qlen 1000
> link/ether 00:04:23:d6:d5:de brd ff:ff:ff:ff:ff:ff
> RX: bytes packets errors dropped overrun mcast
> 2494988681 523755694 0 0 0 57458
> TX: bytes packets errors dropped carrier collsns
> 453184821 507470461 0 0 0 0
>
> but see more detailed stats (dropped packet are as missed in RX errors ?!):
>
> sit:~# ip -s -s l l dev eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc htb qlen 1000
> link/ether 00:04:23:d6:d5:de brd ff:ff:ff:ff:ff:ff
> RX: bytes packets errors dropped overrun mcast
> 2752159866 524110163 0 0 0 57485
> RX errors: length crc frame fifo missed
> 0 0 0 0 16800
> TX: bytes packets errors dropped carrier collsns
> 607359337 507807361 0 0 0 0
> TX errors: aborted fifo window heartbeat
> 0 0 0 0
>
> Is this bug or feature ? From my point of view is somewhere lost any sum.
> Or is it driver dependent? Kernel 2.6.23.1 (in 2.6.20.20 is the same behavior),
> driver e1000. iproute2-ss070313; net-tools 1.60, ifconfig 1.42 (2001-04-13)
ifconfig gets its data from /proc/net/dev, which adds up rx_errors
and rx_missed.
^ permalink raw reply
* [PATCH 0/4] Fix race between sk_filter reassign and sk_clone()
From: Pavel Emelyanov @ 2007-10-17 9:45 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
The race can result in that some sock will get an sk_filter
pointer set to kfree-d memory. Look
CPU1: CPU2:
sk_clone(): sk_attach_filter():
new_sk = sk_alloc(...);
sock_copy(new_sk, sk);
/* copies the filter ptr */
...
filter = new_sk->sk_filter;
if (filter)
old_fp = sk->sk_filter;
...
sk_filter_release(old_fp);
if (atomic_dec_and_test(&old_fp->refcnt))
atomic_inc(&filter->refcnt);
/* true */
call_rcu(&fp->rcu, kfree);
that's it - after a quiescent state pass the new_sk will have
a pointer on kfree-d filter.
The same problem exists for detaching filter (SO_DETACH_FILTER).
The proposed fix consists of 3 preparation patches and the fix itself.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
^ permalink raw reply
* [PATCH 1/4] Introduce the sk_detach_filter() call
From: Pavel Emelyanov @ 2007-10-17 9:47 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
In-Reply-To: <4715D9D2.8070102@openvz.org>
Filter is attached in a separate function, so do the
same for filter detaching.
This also removes one variable sock_setsockopt().
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 91b2e3b..ddfa037 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -146,6 +146,7 @@ struct sock;
extern unsigned int sk_run_filter(struct sk_buff *skb, struct sock_filter *filter, int flen);
extern int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk);
+extern int sk_detach_filter(struct sock *sk);
extern int sk_chk_filter(struct sock_filter *filter, int flen);
#endif /* __KERNEL__ */
diff --git a/net/core/filter.c b/net/core/filter.c
index bd903aa..fd60758 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -433,5 +433,21 @@ int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk)
return err;
}
+int sk_detach_filter(struct sock *sk)
+{
+ int ret = -ENOENT;
+ struct sk_filter *filter;
+
+ rcu_read_lock_bh();
+ filter = rcu_dereference(sk->sk_filter);
+ if (filter) {
+ rcu_assign_pointer(sk->sk_filter, NULL);
+ sk_filter_release(sk, filter);
+ ret = 0;
+ }
+ rcu_read_unlock_bh();
+ return ret;
+}
+
EXPORT_SYMBOL(sk_chk_filter);
EXPORT_SYMBOL(sk_run_filter);
diff --git a/net/core/sock.c b/net/core/sock.c
index d45ecdc..0710138 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -428,7 +428,6 @@ int sock_setsockopt(struct socket *sock, int level, int optname,
char __user *optval, int optlen)
{
struct sock *sk=sock->sk;
- struct sk_filter *filter;
int val;
int valbool;
struct linger ling;
@@ -652,16 +651,7 @@ set_rcvbuf:
break;
case SO_DETACH_FILTER:
- rcu_read_lock_bh();
- filter = rcu_dereference(sk->sk_filter);
- if (filter) {
- rcu_assign_pointer(sk->sk_filter, NULL);
- sk_filter_release(sk, filter);
- rcu_read_unlock_bh();
- break;
- }
- rcu_read_unlock_bh();
- ret = -ENONET;
+ ret = sk_detach_filter(sk);
break;
case SO_PASSSEC:
--
1.5.3.4
^ permalink raw reply related
* [PATCH 2/4] Move the filter releasing into a separate call
From: Pavel Emelyanov @ 2007-10-17 9:49 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
In-Reply-To: <4715D9D2.8070102@openvz.org>
This is done merely as a preparation for the fix.
The sk_filter_uncharge() unaccounts the filter memory and calls
the sk_filter_release(), which in turn decrements the refcount
anf frees the filter.
The latter function will be required separately.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/include/net/sock.h b/include/net/sock.h
index 453c79d..b9cfe12 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -922,14 +922,18 @@ static inline void sk_filter_rcu_free(struct rcu_head *rcu)
* Remove a filter from a socket and release its resources.
*/
-static inline void sk_filter_release(struct sock *sk, struct sk_filter *fp)
+static inline void sk_filter_release(struct sk_filter *fp)
+{
+ if (atomic_dec_and_test(&fp->refcnt))
+ call_rcu_bh(&fp->rcu, sk_filter_rcu_free);
+}
+
+static inline void sk_filter_uncharge(struct sock *sk, struct sk_filter *fp)
{
unsigned int size = sk_filter_len(fp);
atomic_sub(size, &sk->sk_omem_alloc);
-
- if (atomic_dec_and_test(&fp->refcnt))
- call_rcu_bh(&fp->rcu, sk_filter_rcu_free);
+ sk_filter_release(fp);
}
static inline void sk_filter_charge(struct sock *sk, struct sk_filter *fp)
diff --git a/net/core/filter.c b/net/core/filter.c
index fd60758..2be1830 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -429,7 +429,7 @@ int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk)
}
if (fp)
- sk_filter_release(sk, fp);
+ sk_filter_uncharge(sk, fp);
return err;
}
@@ -442,7 +442,7 @@ int sk_detach_filter(struct sock *sk)
filter = rcu_dereference(sk->sk_filter);
if (filter) {
rcu_assign_pointer(sk->sk_filter, NULL);
- sk_filter_release(sk, filter);
+ sk_filter_uncharge(sk, filter);
ret = 0;
}
rcu_read_unlock_bh();
diff --git a/net/core/sock.c b/net/core/sock.c
index 0710138..d292b41 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -915,7 +915,7 @@ void sk_free(struct sock *sk)
filter = rcu_dereference(sk->sk_filter);
if (filter) {
- sk_filter_release(sk, filter);
+ sk_filter_uncharge(sk, filter);
rcu_assign_pointer(sk->sk_filter, NULL);
}
--
1.5.3.4
^ permalink raw reply related
* [PATCH 3/4] Cleanup the error path in sk_attach_filter
From: Pavel Emelyanov @ 2007-10-17 9:51 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
In-Reply-To: <4715D9D2.8070102@openvz.org>
The sk_filter_uncharge is called for error handling and
for releasing the former filter, but this will have to
be done in a bit different manner, so cleanup the error
path a bit.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/core/filter.c b/net/core/filter.c
index 2be1830..54dddc9 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -398,7 +398,7 @@ int sk_chk_filter(struct sock_filter *filter, int flen)
*/
int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk)
{
- struct sk_filter *fp;
+ struct sk_filter *fp, *old_fp;
unsigned int fsize = sizeof(struct sock_filter) * fprog->len;
int err;
@@ -418,19 +418,18 @@ int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk)
fp->len = fprog->len;
err = sk_chk_filter(fp->insns, fp->len);
- if (!err) {
- struct sk_filter *old_fp;
-
- rcu_read_lock_bh();
- old_fp = rcu_dereference(sk->sk_filter);
- rcu_assign_pointer(sk->sk_filter, fp);
- rcu_read_unlock_bh();
- fp = old_fp;
+ if (err) {
+ sk_filter_uncharge(sk, fp);
+ return err;
}
- if (fp)
- sk_filter_uncharge(sk, fp);
- return err;
+ rcu_read_lock_bh();
+ old_fp = rcu_dereference(sk->sk_filter);
+ rcu_assign_pointer(sk->sk_filter, fp);
+ rcu_read_unlock_bh();
+
+ sk_filter_uncharge(sk, old_fp);
+ return 0;
}
int sk_detach_filter(struct sock *sk)
--
1.5.3.4
^ permalink raw reply related
* [PATCH 4/4] Fix the race between sk_filter_(de|at)tach and sk_clone()
From: Pavel Emelyanov @ 2007-10-17 9:53 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
In-Reply-To: <4715D9D2.8070102@openvz.org>
The proposed fix is to delay the reference counter decrement
until the quiescent state pass. This will give sk_clone() a
chance to get the reference on the cloned filter.
Regular sk_filter_uncharge can happen from the sk_free() only
and there's no need in delaying the put - the socket is dead
anyway and is to be release itself.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/include/net/sock.h b/include/net/sock.h
index b9cfe12..43fc3fa 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -905,16 +905,6 @@ static inline int sk_filter(struct sock *sk, struct sk_buff *skb)
}
/**
- * sk_filter_rcu_free: Free a socket filter
- * @rcu: rcu_head that contains the sk_filter to free
- */
-static inline void sk_filter_rcu_free(struct rcu_head *rcu)
-{
- struct sk_filter *fp = container_of(rcu, struct sk_filter, rcu);
- kfree(fp);
-}
-
-/**
* sk_filter_release: Release a socket filter
* @sk: socket
* @fp: filter to remove
@@ -925,7 +915,7 @@ static inline void sk_filter_rcu_free(struct rcu_head *rcu)
static inline void sk_filter_release(struct sk_filter *fp)
{
if (atomic_dec_and_test(&fp->refcnt))
- call_rcu_bh(&fp->rcu, sk_filter_rcu_free);
+ kfree(fp);
}
static inline void sk_filter_uncharge(struct sock *sk, struct sk_filter *fp)
diff --git a/net/core/filter.c b/net/core/filter.c
index 54dddc9..b8bc7d3 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -387,6 +387,25 @@ int sk_chk_filter(struct sock_filter *filter, int flen)
}
/**
+ * sk_filter_rcu_release: Release a socket filter by rcu_head
+ * @rcu: rcu_head that contains the sk_filter to free
+ */
+static void sk_filter_rcu_release(struct rcu_head *rcu)
+{
+ struct sk_filter *fp = container_of(rcu, struct sk_filter, rcu);
+
+ sk_filter_release(fp);
+}
+
+static void sk_filter_delayed_uncharge(struct sock *sk, struct sk_filter *fp)
+{
+ unsigned int size = sk_filter_len(fp);
+
+ atomic_sub(size, &sk->sk_omem_alloc);
+ call_rcu_bh(&fp->rcu, sk_filter_rcu_release);
+}
+
+/**
* sk_attach_filter - attach a socket filter
* @fprog: the filter program
* @sk: the socket to use
@@ -428,7 +447,7 @@ int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk)
rcu_assign_pointer(sk->sk_filter, fp);
rcu_read_unlock_bh();
- sk_filter_uncharge(sk, old_fp);
+ sk_filter_delayed_uncharge(sk, old_fp);
return 0;
}
@@ -441,7 +460,7 @@ int sk_detach_filter(struct sock *sk)
filter = rcu_dereference(sk->sk_filter);
if (filter) {
rcu_assign_pointer(sk->sk_filter, NULL);
- sk_filter_uncharge(sk, filter);
+ sk_filter_delayed_uncharge(sk, filter);
ret = 0;
}
rcu_read_unlock_bh();
--
1.5.3.4
^ permalink raw reply related
* Re: Difference between device statistics from ifconfig and ip -s l l
From: Milan Kocian @ 2007-10-17 10:13 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev
In-Reply-To: <4715D79E.7020201@trash.net>
On Wed, Oct 17, 2007 at 11:36:30AM +0200, Patrick McHardy wrote:
> Milan Kocian wrote:
>> hello,
>> see dropped packets, please:
>> sit:~# ifconfig eth0
>> eth0 Link encap:Ethernet HWaddr 00:04:23:D6:D5:DE UP
>> BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:522284892 errors:0 dropped:16800 overruns:0 frame:0
>> TX packets:506064445 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000 RX bytes:1405350664 (1.3
>> GiB) TX bytes:4082649020 (3.8 GiB)
>> Base address:0xac00 Memory:ff6e0000-ff700000 see via ip l l
>> (here are no dropped packets):
>> sit:~# ip -s l l dev eth0
>> 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc htb qlen 1000
>> link/ether 00:04:23:d6:d5:de brd ff:ff:ff:ff:ff:ff
>> RX: bytes packets errors dropped overrun mcast 2494988681
>> 523755694 0 0 0 57458 TX: bytes packets errors
>> dropped carrier collsns 453184821 507470461 0 0 0 0
>> but see more detailed stats (dropped packet are as missed in RX
>> errors ?!):
>> sit:~# ip -s -s l l dev eth0
>> 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc htb qlen 1000
>> link/ether 00:04:23:d6:d5:de brd ff:ff:ff:ff:ff:ff
>> RX: bytes packets errors dropped overrun mcast 2752159866
>> 524110163 0 0 0 57485 RX errors: length crc
>> frame fifo missed
>> 0 0 0 0 16800 TX: bytes
>> packets errors dropped carrier collsns 607359337 507807361 0
>> 0 0 0 TX errors: aborted fifo window heartbeat
>> 0 0 0 0 Is this bug or feature ?
>> From my point of view is somewhere lost any sum.
>> Or is it driver dependent? Kernel 2.6.23.1 (in 2.6.20.20 is the same
>> behavior), driver e1000. iproute2-ss070313; net-tools 1.60, ifconfig 1.42
>> (2001-04-13)
>
>
> ifconfig gets its data from /proc/net/dev, which adds up rx_errors
> and rx_missed.
>
Adds up rx_errors and rx_missed and prints it as dropped ? Ok, ifconfig is
a little old. But why I don't see missed packets from RX errors detailed stats
(ip -s -s l l) in non-detailed stats as errors and see zero ?
regards,
--
Milan Kocian
^ permalink raw reply
* [PATCH] Fix return type for snmp6_free_dev()
From: Pavel Emelyanov @ 2007-10-17 10:29 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
This call is essentially void.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 52d10d2..edf06ca 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -283,12 +283,11 @@ err_ip:
return err;
}
-static int snmp6_free_dev(struct inet6_dev *idev)
+static void snmp6_free_dev(struct inet6_dev *idev)
{
snmp_mib_free((void **)idev->stats.icmpv6msg);
snmp_mib_free((void **)idev->stats.icmpv6);
snmp_mib_free((void **)idev->stats.ipv6);
- return 0;
}
/* Nobody refers to this device, we may destroy it. */
^ permalink raw reply related
* Re: Difference between device statistics from ifconfig and ip -s l l
From: Patrick McHardy @ 2007-10-17 10:35 UTC (permalink / raw)
To: Milan Kocian; +Cc: netdev
In-Reply-To: <20071017101303.GB16356@wq.cz>
Milan Kocian wrote:
> On Wed, Oct 17, 2007 at 11:36:30AM +0200, Patrick McHardy wrote:
>
>> ifconfig gets its data from /proc/net/dev, which adds up rx_errors
>> and rx_missed.
>>
>
> Adds up rx_errors and rx_missed and prints it as dropped ? Ok, ifconfig is
> a little old. But why I don't see missed packets from RX errors detailed stats
> (ip -s -s l l) in non-detailed stats as errors and see zero ?
I meant to write "adds up rx_dropped and rx_missed".
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at virtual address 000000b0
From: Eric Dumazet @ 2007-10-17 10:38 UTC (permalink / raw)
To: Krzysztof Oledzki; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0710171018470.21430@bizon.gios.gov.pl>
Krzysztof Oledzki a écrit :
>
>
> On Wed, 17 Oct 2007, Eric Dumazet wrote:
>
>> Krzysztof Oledzki a écrit :
>>> Hello,
>>>
>>> Today I found in my logs:
>>>
>>> BUG: unable to handle kernel NULL pointer dereference at virtual
>>> address 000000b0
>>> printing eip:
>>> 78395f65
>>> *pde = 00000000
>>> Oops: 0000 [#1]
>>> PREEMPT SMP
>>> CPU: 0
>>> EIP: 0060:[<78395f65>] Not tainted VLI
>>> EFLAGS: 00210286 (2.6.22.9 #1)
>>> EIP is at __ip_route_output_key+0x412/0x722
>>> eax: 80000000 ebx: 00000000 ecx: 5dd2b1c3 edx: 00000000
>>> esi: 00000000 edi: d44c7e30 ebp: ec8c4980 esp: d44c7ddc
>>> ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
>>> Process smtpd (pid: 12479, ti=d44c6000 task=9e759510 task.ti=d44c6000)
>>> Stack: d44c7e7c d44c7e7c d44c7eb8 00000000 d44c7e7c 00000000 00000000
>>> 00000005
>>> 00000000 ffffffff 5dd2b1c3 00000000 00000000 00000000 00000000
>>> 00000000
>>> 00000000 00000000 00000000 00000000 00000000 00030000 00000000
>>> d44c7e7c
>>> Call Trace:
>>> [<78396280>] ip_route_output_flow+0xb/0x3e
>>> [<783b2b29>] ip4_datagram_connect+0x1c9/0x308
>>> [<783ba70a>] inet_dgram_connect+0x45/0x4e
>>> [<7837135e>] sys_connect+0x72/0x9c
>>> [<78371607>] sock_map_fd+0x41/0x4a
>>> [<7840d1b1>] _spin_lock+0x33/0x3e
>>> [<7840d623>] _spin_unlock+0x25/0x3b
>>> [<78371607>] sock_map_fd+0x41/0x4a
>>> [<78372792>] sys_socketcall+0x8f/0x242
>>> [<7813e99c>] trace_hardirqs_on+0x122/0x14c
>>> [<78103dc6>] sysenter_past_esp+0x8f/0x99
>>> [<78103d96>] sysenter_past_esp+0x5f/0x99
>>> =======================
>>> Code: fa e0 00 00 00 75 07 c6 44 24 56 05 eb 14 81 fa f0 00 00 00 0f
>>> 84 e1 02 00 00 84 c0 0f 84 d9 02 00 00 8b 44 24 0c 0d 00 00 00 80
>>> <f6> 86 b0 00 00 00 08 0f 44 44 24 0c 89 44 24 0c b8 01 00 00 00
>>> EIP: [<78395f65>] __ip_route_output_key+0x412/0x722 SS:ESP 0068:d44c7ddc
>>>
>>> Shortly before it there was:
>>> Oct 17 07:17:55 cougar postfix/master[3400]: warning: process
>>> /usr/lib/postfix/smtpd pid 12479 killed by signal 11
>>>
>>> Best regards,
>>>
>>>
>>> Krzysztof Olędzki
>>
>> Hello Krzysztof
>>
>> Could you give us some details about this ? kernel version at least.
>
> Yes, I was little to hurry sending this bug report. Anyway, it is
> 2.6.22.9 like mentioned in the oops: EFLAGS: 00210286 (2.6.22.9 #1)
>
>> (you could for example take a look at REPORTING-BUGS, or run
>> scripts/ver_linux)
>
> Linux cougar 2.6.22.9 #1 SMP PREEMPT Wed Oct 3 10:24:19 CEST 2007 i686
> Intel(R) Pentium(R) D CPU 3.20GHz GenuineIntel GNU/Linux
>
> Gnu C 4.1.2
> Gnu make 3.81
> binutils 2.17
> util-linux 2.12r
> mount 2.12r
> module-init-tools 3.2.2
> e2fsprogs 1.40.2
> Linux C Library > libc.2.5
> Dynamic linker (ldd) 2.5
> Procps 3.2.7
> Net-tools 1.60
> Kbd 1.12
> Sh-utils 6.9
>
Yes indeed, version was on your initial report.
It seems this kernel is unusual (VMSPLIT_2G_OPT instead of stdandard
VMSPLIT_3G), any chance you provide full .config ?
^ 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