libipq, kernel panics/oopses, and other undesirable traits

libipq, kernel panics/oopses, and other undesirable traits

[Matt Walters]

Evening, all-

	I've got a fun one here.   I've been developing some userspace packet
filtering stuff with netfilter using libipq with varying levels of
success.  As long as I'm only dropping or accepting packets without
modifying them, life is peachy.  I can modify packets as well - as long
as the data rate is low.  Once the data rate reaches a certain point,
the kernel panics, dumps a stack trace, or what have you (I saw my first
double fault today, which I don't think is a very good sign -- all the
issues I'm having just scream "race condition").  Sporadically the
phrase "Debug: sleeping function called from invalid context at
include/linux/rwsem.h" will appear on the console, as well as "KERNEL:
assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at
netlink/af_netlink.c (98)" -- this one almost always appears when the
application locks up and I rmmod ip_queue (which makes sense, and
hopefully points some fingers at where this issue is happening). 
Unloading the ip_queue module, restarting iptables (when it will
restart), and modprobing ip_queue allows my software to continue life
happily (until everything blows up again).

	I'd been working on the assumption that it was my code stomping on
something and causing the issue, but after sanity-checking everything
(and then sanity-checking the sanity checks), I have become convinced
that this is not the case.  On a hunch, I modified the libipq test code
(from the manpage) to copy the packet contents back from userspace
(without modifying them, of course), set up a quick pingflood (large
packets) across a gigabit network, and the kernel panicked after a dozen
or so pings made it back to the source.  The only packets being sent to
the QUEUE target are inbound or outbound ICMP, incidentally.

	I replaced the following line:
status = ipq_set_verdict(h, m->packet_id, NF_ACCEPT, 0, NULL);

	With:
status = ipq_set_verdict(h, m->packet_id, NF_ACCEPT, m->data_len,
m->payload);

	The machine in question is a Supermicro server, dual Intel e1000
gigabit NICs, dual Xeon 2.8GHz (HT enabled), 2GB of RAM.  It's a 2.6.7
kernel, I'm playing with / linking to iptables 1.2.11.

	I'm at the end of my rope on this one, and someone slapping me upside
the head would be great.

	Below is one of the stack traces that actually made it into the logs
(oh yeah - did I mention that sometimes the machine is kind of alright
after this?  mostly it locks up immediately, or locks up trying to stop
iptables though).  The trace is from one of the times that it exploded
with my application, not the test code.

	Thanks in advance for any hints, confirmations, denials, drop-kicks or
head smacks you might be able to offer.  I'm going to try compiling a
non-SMP kernel tonight or tomorrow to see if the issue persists, and I
will update the list.

-Matt

trace:

kernel: Unable to handle kernel paging request at virtual address
2f2e2d2c
kernel:  printing eip:
kernel: c0144d2b
kernel: *pde = 35c9d001
kernel: *pte = 00000000
kernel: Oops: 0000 [#1]
kernel: SMP
kernel: Modules linked in: ip_queue autofs4 ipt_state ip_conntrack
iptable_filter ip_tables sg dm_mod uhci_hcd ext3 jbd raid5 xor raid1
aic79xx sd_mod scsi_mod
kernel: CPU:    0
kernel: EIP:    0060:[<c0144d2b>]    Not tainted
kernel: EFLAGS: 00010282   (2.6.7-3)
kernel: EIP is at put_page+0x7/0x8a
kernel: eax: 2f2e2d2c   ebx: 00000001   ecx: f3b02c80   edx: 2f2e2d2c
kernel: esi: f512ea80   edi: f512ea80   ebp: f3cd6800   esp: f3bdbb20
kernel: ds: 007b   es: 007b   ss: 0068
kernel: Process trafficd (pid: 2823, threadinfo=f3bda000 task=f5b65870)
kernel: Stack: 00000000 c0288317 2f2e2d2c 001d4000 f3cd6c80 c028c9e3
f512ea80 fffffffe
kernel:        f3cd6800 0000043c f7ba6800 2b2a2928 f3b02810 fffffff4
c028cc8e f512ea80
kernel:        00000020 f512ea80 c217617c f3b02810 c2176154 c02ab25b
f512ea80 f7ba6800
kernel: Call Trace:
kernel:  [<c0288317>] skb_release_data+0x74/0x8f
kernel:  [<c028c9e3>] __skb_linearize+0xdf/0x120
kernel:  [<c028cc8e>] dev_queue_xmit+0x26a/0x27c
kernel:  [<c02ab25b>] ip_finish_output2+0xa6/0x1a7
kernel:  [<c02ab1b5>] ip_finish_output2+0x0/0x1a7
kernel:  [<c02ab1b5>] ip_finish_output2+0x0/0x1a7
kernel:  [<c0296435>] nf_hook_slow+0xc4/0xf9
kernel:  [<c02ab1b5>] ip_finish_output2+0x0/0x1a7
kernel:  [<c02a8d42>] ip_finish_output+0x1fb/0x200
kernel:  [<c02ab1b5>] ip_finish_output2+0x0/0x1a7
kernel:  [<c02a9c3b>] ip_fragment+0x635/0x748
kernel:  [<c0288405>] __kfree_skb+0xa7/0x12c
kernel:  [<c02cd32b>] icmp_rcv+0xfc/0x1c6
kernel:  [<c02a8f66>] ip_output+0x6c/0x78
kernel:  [<c02a8b47>] ip_finish_output+0x0/0x200
kernel:  [<c02ab1a0>] dst_output+0x14/0x29
kernel:  [<c0296677>] nf_reinject+0x20d/0x23c
kernel:  [<c02ab18c>] dst_output+0x0/0x29
kernel:  [<f8a3e025>] ipq_issue_verdict+0x25/0x35 [ip_queue]
kernel:  [<f8a3e841>] ipq_set_verdict+0x51/0x82 [ip_queue]
kernel:  [<f8a3e941>] ipq_receive_peer+0x4c/0x62 [ip_queue]
kernel:  [<f8a3eb0c>] ipq_rcv_sk+0x156/0x1c9 [ip_queue]
kernel:  [<c029f6c7>] netlink_data_ready+0x62/0x6a
kernel:  [<c029ed65>] netlink_sendskb+0xa4/0xa6
kernel:  [<c029f36c>] netlink_sendmsg+0x205/0x2f4
kernel:  [<c0284867>] sock_sendmsg+0x9e/0xca
kernel:  [<c028492f>] sock_recvmsg+0x9c/0xb7
kernel:  [<c01b38b0>] copy_from_user+0x52/0x7e
kernel:  [<c01b38b0>] copy_from_user+0x52/0x7e
kernel:  [<c0289d78>] verify_iovec+0x3c/0x94
kernel:  [<c02861e6>] sys_sendmsg+0x189/0x1e6
kernel:  [<c02843d1>] move_addr_to_user+0x62/0x6d
kernel:  [<c016ba55>] poll_freewait+0x38/0x40
kernel:  [<c016ba5d>] __pollwait+0x0/0xc7
kernel:  [<c01b38b0>] copy_from_user+0x52/0x7e
kernel:  [<c0286670>] sys_socketcall+0x236/0x254
kernel:  [<c0105edd>] sysenter_past_esp+0x52/0x71
kernel:
kernel: Code: 8b 02 a9 00 00 08 00 75 41 8b 02 f6 c4 08 75 22 8b 02 89
d1

Re: libipq, kernel panics/oopses, and other undesirable traits

[Patrick McHardy]

Matt Walters wrote:
> 	Below is one of the stack traces that actually made it into the logs
> (oh yeah - did I mention that sometimes the machine is kind of alright
> after this?  mostly it locks up immediately, or locks up trying to stop
> iptables though).  The trace is from one of the times that it exploded
> with my application, not the test code.
> 
> 	Thanks in advance for any hints, confirmations, denials, drop-kicks or
> head smacks you might be able to offer.  I'm going to try compiling a
> non-SMP kernel tonight or tomorrow to see if the issue persists, and I
> will update the list.

This looks like the packet contents (ping) of a non-linear skb corrupted
the registers. Please try the ip_queue_nonlinear_skbs patch from
patch-o-matic-ng.

Regards
Patrick

> 
> -Matt
> 
> trace:
> 
> kernel: Unable to handle kernel paging request at virtual address
> 2f2e2d2c
> kernel:  printing eip:
> kernel: c0144d2b
> kernel: *pde = 35c9d001
> kernel: *pte = 00000000
> kernel: Oops: 0000 [#1]
> kernel: SMP
> kernel: Modules linked in: ip_queue autofs4 ipt_state ip_conntrack
> iptable_filter ip_tables sg dm_mod uhci_hcd ext3 jbd raid5 xor raid1
> aic79xx sd_mod scsi_mod
> kernel: CPU:    0
> kernel: EIP:    0060:[<c0144d2b>]    Not tainted
> kernel: EFLAGS: 00010282   (2.6.7-3)
> kernel: EIP is at put_page+0x7/0x8a
> kernel: eax: 2f2e2d2c   ebx: 00000001   ecx: f3b02c80   edx: 2f2e2d2c
> kernel: esi: f512ea80   edi: f512ea80   ebp: f3cd6800   esp: f3bdbb20
> kernel: ds: 007b   es: 007b   ss: 0068
> kernel: Process trafficd (pid: 2823, threadinfo=f3bda000 task=f5b65870)
> kernel: Stack: 00000000 c0288317 2f2e2d2c 001d4000 f3cd6c80 c028c9e3
> f512ea80 fffffffe
> kernel:        f3cd6800 0000043c f7ba6800 2b2a2928 f3b02810 fffffff4
> c028cc8e f512ea80
> kernel:        00000020 f512ea80 c217617c f3b02810 c2176154 c02ab25b
> f512ea80 f7ba6800
> kernel: Call Trace:
> kernel:  [<c0288317>] skb_release_data+0x74/0x8f
> kernel:  [<c028c9e3>] __skb_linearize+0xdf/0x120
> kernel:  [<c028cc8e>] dev_queue_xmit+0x26a/0x27c
> kernel:  [<c02ab25b>] ip_finish_output2+0xa6/0x1a7
> kernel:  [<c02ab1b5>] ip_finish_output2+0x0/0x1a7
> kernel:  [<c02ab1b5>] ip_finish_output2+0x0/0x1a7
> kernel:  [<c0296435>] nf_hook_slow+0xc4/0xf9
> kernel:  [<c02ab1b5>] ip_finish_output2+0x0/0x1a7
> kernel:  [<c02a8d42>] ip_finish_output+0x1fb/0x200
> kernel:  [<c02ab1b5>] ip_finish_output2+0x0/0x1a7
> kernel:  [<c02a9c3b>] ip_fragment+0x635/0x748
> kernel:  [<c0288405>] __kfree_skb+0xa7/0x12c
> kernel:  [<c02cd32b>] icmp_rcv+0xfc/0x1c6
> kernel:  [<c02a8f66>] ip_output+0x6c/0x78
> kernel:  [<c02a8b47>] ip_finish_output+0x0/0x200
> kernel:  [<c02ab1a0>] dst_output+0x14/0x29
> kernel:  [<c0296677>] nf_reinject+0x20d/0x23c
> kernel:  [<c02ab18c>] dst_output+0x0/0x29
> kernel:  [<f8a3e025>] ipq_issue_verdict+0x25/0x35 [ip_queue]
> kernel:  [<f8a3e841>] ipq_set_verdict+0x51/0x82 [ip_queue]
> kernel:  [<f8a3e941>] ipq_receive_peer+0x4c/0x62 [ip_queue]
> kernel:  [<f8a3eb0c>] ipq_rcv_sk+0x156/0x1c9 [ip_queue]
> kernel:  [<c029f6c7>] netlink_data_ready+0x62/0x6a
> kernel:  [<c029ed65>] netlink_sendskb+0xa4/0xa6
> kernel:  [<c029f36c>] netlink_sendmsg+0x205/0x2f4
> kernel:  [<c0284867>] sock_sendmsg+0x9e/0xca
> kernel:  [<c028492f>] sock_recvmsg+0x9c/0xb7
> kernel:  [<c01b38b0>] copy_from_user+0x52/0x7e
> kernel:  [<c01b38b0>] copy_from_user+0x52/0x7e
> kernel:  [<c0289d78>] verify_iovec+0x3c/0x94
> kernel:  [<c02861e6>] sys_sendmsg+0x189/0x1e6
> kernel:  [<c02843d1>] move_addr_to_user+0x62/0x6d
> kernel:  [<c016ba55>] poll_freewait+0x38/0x40
> kernel:  [<c016ba5d>] __pollwait+0x0/0xc7
> kernel:  [<c01b38b0>] copy_from_user+0x52/0x7e
> kernel:  [<c0286670>] sys_socketcall+0x236/0x254
> kernel:  [<c0105edd>] sysenter_past_esp+0x52/0x71
> kernel:
> kernel: Code: 8b 02 a9 00 00 08 00 75 41 8b 02 f6 c4 08 75 22 8b 02 89
> d1
> 
> 
> 

RE: Re: libipq, kernel panics/oopses, and other undesirable traits

[Matt Walters]

> Matt Walters wrote:
> > 	Below is one of the stack traces that actually made it into the
logs
> > (oh yeah - did I mention that sometimes the machine is kind of
alright
> > after this?  mostly it locks up immediately, or locks up trying to
stop
> > iptables though).  The trace is from one of the times that it
exploded
> > with my application, not the test code.
> > 
> > 	Thanks in advance for any hints, confirmations, denials,
drop-kicks or
> > head smacks you might be able to offer.  I'm going to try compiling
a
> > non-SMP kernel tonight or tomorrow to see if the issue persists,
and I
> > will update the list.
> 
> This looks like the packet contents (ping) of a non-linear skb
corrupted
> the registers. Please try the ip_queue_nonlinear_skbs patch from
> patch-o-matic-ng.

Patrick et al-

  Firstly, thanks for the input.  I applied the patch yesterday to the
2.6.7 kernel without luck.  I then noticed that 2.6.8 was at
kernel.org, so I downloaded it, applied the nonlinear_skbs patch to it,
and built it.  No love there either.

  When I say "without luck", incidentally, I mean that the issue isn't
resolved.  It's become more predictable and repeatible though, which is
good, since it means I'll be able to roll up my sleeves today and dig
in.  Any packet being copied back from userspace that is larger than
the destination device's MTU (that is being fragmented, that is) is
causing the machine to throw a bunch of "Unable to handle kernel paging
request at [foo]" messages.  The good news?  Even between boots, and
even with the ip_queue module compiled statically into the kernel
(something else I tried, just for giggles), the address it is
complaining about is identical, and it's one of those suspicious
addresses (0xbcbcbcbc or something like it, sorry I don't have it
written down here).  As I said, I'll dig into it later on today and
keep the list updated.

  Thanks again,

-Matt

Re: libipq, kernel panics/oopses, and other undesirable traits

[Matt Walters]

Greetings, friends-

	I've inlined a patch for ip_queue.c (diff -u is the standard
patch-o-matic format, right?) which will fix the issue I've been having
with large packets coming back from userspace causing kernel panics.  It
should probably be added to the nonlinear_skbs patch, since it's the
same type of fix (memcpy --> copy_skb_bits).  There's also a
storage-type modification for ipq_rcv_skb - skb_len is an unsigned int
and it was being stored in an int.

	I also noticed several storage-type issues in the netlink code, which
I've messed with ("corrected" - maybe) on my machine, but messed with
*prior* to finding the memcpy in ip_queue.c, so I'll have to revert
those changes and see if it stays fixed, otherwise I guess I'll have to
get ahold of the netlink guys and send them a patch too.  :)

	Do please ignore the fact that my development machine thinks it's
tomorrow.  I've just noticed.

	I'm interested in doing further development for netfilter.  Please feel
free to add my name to a list somewhere or something.

	(addendum: I'm currently testing the code with icmp on INPUT and OUTPUT
going through userspace and having TOS bits tickled, etc, copied back
into kernelspace, with a flood of 64kB pings across a pair of Intel
e1000s -- IN octets: 2159535768  packets: 33458 // OUT octets:
2159470740  packets: 33457 -- looking really good)

-Matt

--- ip_queue.c.orig     2004-08-16 14:32:43.000000000 -0700
+++ ip_queue.c  2004-08-17 15:02:11.583159408 -0700
@@ -333,7 +333,7 @@
 static int
 ipq_mangle_ipv4(ipq_verdict_msg_t *v, struct ipq_queue_entry *e)
 {
-       int diff;
+       int diff, status;
        struct iphdr *user_iph = (struct iphdr *)v->payload;

        if (v->data_len < sizeof(*user_iph))
@@ -346,7 +346,7 @@
                        return -EINVAL;
                if (diff > skb_tailroom(e->skb)) {
                        struct sk_buff *newskb;
-
+
                        newskb = skb_copy_expand(e->skb,
                                                 skb_headroom(e->skb),
                                                 diff,
@@ -363,7 +363,10 @@
                }
                skb_put(e->skb, diff);
        }
-       memcpy(e->skb->data, v->payload, v->data_len);
+
+       if ((status = skb_copy_bits(e->skb, 0, v->payload, v->data_len))) {
+               return status;
+       }
        e->skb->nfcache |= NFC_ALTERED;

        /*
@@ -477,7 +480,8 @@
 static inline void
 ipq_rcv_skb(struct sk_buff *skb)
 {
-       int status, type, pid, flags, nlmsglen, skblen;
+       int status, type, pid, flags;
+       size_t nlmsglen, skblen;
        struct nlmsghdr *nlh;

        skblen = skb->len;

Re: libipq, kernel panics/oopses, and other undesirable traits

[Patrick McHardy]

Matt Walters wrote:

>Greetings, friends-
>
>	I've inlined a patch for ip_queue.c (diff -u is the standard
>patch-o-matic format, right?) which will fix the issue I've been having
>with large packets coming back from userspace causing kernel panics.  It
>should probably be added to the nonlinear_skbs patch, since it's the
>same type of fix (memcpy --> copy_skb_bits).  There's also a
>storage-type modification for ipq_rcv_skb - skb_len is an unsigned int
>and it was being stored in an int.
>
The skb_copy_bits can't be right. You change skb from being the destination
to the source. If the skb really is nonlinear, we need to linearize it. But
skb_tailroom should return 0 in this case and the skb should be linearized
by skb_copy_expand already. The check isn't triggered because this line is
wrong:

diff = v->data_len - e->skb->len

skb->len is the total length, including fragments. If we want to copy to it,
we either need to linearize it or look at skb_headlen(skb). It's complicated
getting everything right, I need to think about it some more.

Regards
Patrick

Re: libipq, kernel panics/oopses, and other undesirable traits

[Matt Walters]

On Mon, 2004-08-16 at 15:38, Patrick McHardy wrote:
> Matt Walters wrote:
> 
> >Greetings, friends-
> >
> >	I've inlined a patch for ip_queue.c (diff -u is the standard
> >patch-o-matic format, right?) which will fix the issue I've been having
> >with large packets coming back from userspace causing kernel panics.  It
> >should probably be added to the nonlinear_skbs patch, since it's the
> >same type of fix (memcpy --> copy_skb_bits).  There's also a
> >storage-type modification for ipq_rcv_skb - skb_len is an unsigned int
> >and it was being stored in an int.
> >
> The skb_copy_bits can't be right. You change skb from being the destination
> to the source. If the skb really is nonlinear, we need to linearize it. But

	..whoops.  Perhaps some sleep is in order.  It seemed like a  success
because (naturally) the test program wasn't mangling the packets...

> skb_tailroom should return 0 in this case and the skb should be linearized
> by skb_copy_expand already. The check isn't triggered because this line is
> wrong:
> 
> diff = v->data_len - e->skb->len
> 
> skb->len is the total length, including fragments. If we want to copy to it,
> we either need to linearize it or look at skb_headlen(skb). It's complicated
> getting everything right, I need to think about it some more.

	Yeah, and for some twisted reason I was figuring on skb_copy_bits to do
that (since it *does* unwind fragment lists, etc).  My apologies for the
waste of bandwidth.

	I'm going to get some sleep and have another look at this later. 
Thanks for the smack on the head.

-Matt

Re: libipq, kernel panics/oopses, and other undesirable traits

[Patrick McHardy]

Matt Walters wrote:

>On Mon, 2004-08-16 at 15:38, Patrick McHardy wrote:
>  
>
>>skb_tailroom should return 0 in this case and the skb should be linearized
>>by skb_copy_expand already. The check isn't triggered because this line is
>>wrong:
>>
>>diff = v->data_len - e->skb->len
>>
>>skb->len is the total length, including fragments. If we want to copy to it,
>>we either need to linearize it or look at skb_headlen(skb). It's complicated
>>getting everything right, I need to think about it some more.
>>    
>>
>
>	Yeah, and for some twisted reason I was figuring on skb_copy_bits to do
>that (since it *does* unwind fragment lists, etc).  My apologies for the
>waste of bandwidth.
>  
>
No problem, your testing provided valuable information about the cause 
of the
problem.

Regards
Patrick

Re: libipq, kernel panics/oopses, and other undesirable traits

[Patrick McHardy]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

Matt Walters wrote:

>On Mon, 2004-08-16 at 15:38, Patrick McHardy wrote:
>
>>skb_tailroom should return 0 in this case and the skb should be linearized
>>by skb_copy_expand already. The check isn't triggered because this line is
>>wrong:
>>
>>diff = v->data_len - e->skb->len
>>
>>skb->len is the total length, including fragments. If we want to copy to it,
>>we either need to linearize it or look at skb_headlen(skb). It's complicated
>>getting everything right, I need to think about it some more.
>>    
>>

This patch on top of the ip_queue_nonlinear_skbs patch should fix the 
problem.
It wastes a couple of bytes when enlarging a non-linear skb, but that 
shouldn't be
a problem. When you test it, please try all three possibilities (replace 
by smaller,
equally sized and larger packet).

Regards
Patrick




[-- Attachment #2: x --]
[-- Type: text/plain, Size: 401 bytes --]

===== net/ipv4/netfilter/ip_queue.c 1.16 vs edited =====
--- 1.16/net/ipv4/netfilter/ip_queue.c	2004-01-29 00:59:33 +01:00
+++ edited/net/ipv4/netfilter/ip_queue.c	2004-08-17 12:35:05 +02:00
@@ -362,6 +362,8 @@
 		}
 		skb_put(e->skb, diff);
 	}
+	if (!skb_ip_make_writable(&e->skb, v->data_len))
+		return -ENOMEM;
 	memcpy(e->skb->data, v->payload, v->data_len);
 	e->skb->nfcache |= NFC_ALTERED;
 

Re: libipq, kernel panics/oopses, and other undesirable traits

[Matt Walters]

On Tue, 2004-08-17 at 03:40, Patrick McHardy wrote:
> Matt Walters wrote:
> 
> >On Mon, 2004-08-16 at 15:38, Patrick McHardy wrote:
> >
> >>skb_tailroom should return 0 in this case and the skb should be linearized
> >>by skb_copy_expand already. The check isn't triggered because this line is
> >>wrong:
> >>
> >>diff = v->data_len - e->skb->len
> >>
> >>skb->len is the total length, including fragments. If we want to copy to it,
> >>we either need to linearize it or look at skb_headlen(skb). It's complicated
> >>getting everything right, I need to think about it some more.
> >>    
> >>
> 
> This patch on top of the ip_queue_nonlinear_skbs patch should fix the 
> problem.
> It wastes a couple of bytes when enlarging a non-linear skb, but that 
> shouldn't be
> a problem. When you test it, please try all three possibilities (replace 
> by smaller,
> equally sized and larger packet).

Thanks Patrick-

	A quick test shows that unaltered packets being passed back from
userspace no longer cause kernel panics (yay) but also that they are not
being responded to (boo).  I'll have a look deeper into it later on.

-Matt

Re: libipq, kernel panics/oopses, and other undesirable traits

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

On Tue, Aug 17, 2004 at 01:40:15PM -0700, Matt Walters wrote:
> Thanks Patrick-
> 
> 	A quick test shows that unaltered packets being passed back from
> userspace no longer cause kernel panics (yay) but also that they are not
> being responded to (boo).  I'll have a look deeper into it later on.

Patrkick, do you think we should push your make_writable fix to davem
yet?

> -Matt

-- 
- Harald Welte <laforge@netfilter.org>             http://www.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: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: libipq, kernel panics/oopses, and other undesirable traits

[Patrick McHardy]

Harald Welte wrote:

>On Tue, Aug 17, 2004 at 01:40:15PM -0700, Matt Walters wrote:
>  
>
>>Thanks Patrick-
>>
>>	A quick test shows that unaltered packets being passed back from
>>userspace no longer cause kernel panics (yay) but also that they are not
>>being responded to (boo).  I'll have a look deeper into it later on.
>>    
>>
>
>Patrkick, do you think we should push your make_writable fix to davem
>yet?
>  
>

No, let's wait until we know what's causing Matt's problems.

Regards
Patrick

Re: libipq, kernel panics/oopses, and other undesirable traits

[Patrick McHardy]

Hi Matt,

Matt Walters wrote:

>Thanks Patrick-
>
>	A quick test shows that unaltered packets being passed back from
>userspace no longer cause kernel panics (yay) but also that they are not
>being responded to (boo).  I'll have a look deeper into it later on.
>  
>
any news on this ?

Regards
Patrick

>-Matt
>
>  
>

Re: libipq, kernel panics/oopses, and other undesirable traits

[Matt Walters]

On Mon, 2004-08-23 at 12:07, Patrick McHardy wrote:
> Hi Matt,
> 
> Matt Walters wrote:
> 
> >Thanks Patrick-
> >
> >	A quick test shows that unaltered packets being passed back from
> >userspace no longer cause kernel panics (yay) but also that they are not
> >being responded to (boo).  I'll have a look deeper into it later on.
> >  
> >
> any news on this ?

	I apologize, work didn't allow me to dig into this last week (pesky
deadlines).  This week isn't nearly as insane, so I'll have a look at it
and get back to the list.

-Matt

Re: libipq, kernel panics/oopses, and other undesirable traits

[Patrick McHardy]

Matt Walters wrote:

>	I'm interested in doing further development for netfilter.  Please feel
>free to add my name to a list somewhere or something.
>
I missed this before. You are already on the only list, the development 
list ;)
There is no official contributor-list, but we always welcome help. If you're
looking for things to do, we have multiple todo-lists in CVS. I can also 
give
you some additional pointers if you want.

Regards
Patrick

Re: libipq, kernel panics/oopses, and other undesirable traits

[Matt Walters]

On Mon, 2004-08-16 at 17:53, Patrick McHardy wrote:
> Matt Walters wrote:
> 
> >	I'm interested in doing further development for netfilter.  Please feel
> >free to add my name to a list somewhere or something.
> >
> I missed this before. You are already on the only list, the development 
> list ;)
> There is no official contributor-list, but we always welcome help. If you're
> looking for things to do, we have multiple todo-lists in CVS. I can also 
> give
> you some additional pointers if you want.

	That would be luverly.  Maybe the next patch I submit will do something
other than short-circuit the path it was intending to mend!  ;)

-Matt