* Re: Slab corruption mm3 + davem fixes
[not found] <20030511031940.97C24251B@oscar.casa.dyndns.org>
@ 2003-05-11 16:21 ` Ed Tomlinson
[not found] ` <1052690490.4471.2.camel@rth.ninka.net>
0 siblings, 1 reply; 6+ messages in thread
From: Ed Tomlinson @ 2003-05-11 16:21 UTC (permalink / raw)
To: akpm, davem, linux-mm; +Cc: linux-kernel
Hi,
I am also seeing this on 69-bk (as of Sunday morning)
Ed
On May 10, 2003 11:19 pm, Ed Tomlinson wrote:
> Hi,
>
> I looked at my logs and found the following error in it. My kernel is
> 69-mm3 with two davem fixes on it.
>
> May 10 22:41:06 oscar kernel:
> ***************************************************************************
>**********
> ***************************************************************************
>****************************************
> ***************************************************************************
>****************************************
> ***************************************************************************
>****************************************
> ***************************************************************************
>****************************************
> ***************************************************************************
>****************************************
> ***************************************************************************
>****************************************
> ***************************************************************************
>****************************************
> ***************************************************************************
>****************************** May 10 22:41:06 oscar kernel:
> **********************************************************************A5
> May 10 22:41:06 oscar kernel: Call Trace:
> May 10 22:41:06 oscar kernel: [__slab_error+30/32] __slab_error+0x1e/0x20
> May 10 22:41:06 oscar kernel: [check_poison_obj+376/384]
> check_poison_obj+0x178/0x180 May 10 22:41:06 oscar kernel:
> [kmalloc+221/392] kmalloc+0xdd/0x188 May 10 22:41:06 oscar kernel:
> [alloc_skb+64/240] alloc_skb+0x40/0xf0 May 10 22:41:06 oscar kernel:
> [alloc_skb+64/240] alloc_skb+0x40/0xf0 May 10 22:41:06 oscar kernel:
> [skb_copy+45/204] skb_copy+0x2d/0xcc May 10 22:41:06 oscar kernel:
> [_end+615445203/1070187180] skb_ip_make_writable+0xcf/0x164 [iptable_nat]
> May 10 22:41:06 oscar kernel: [cache_init_objs+71/308]
> cache_init_objs+0x47/0x134 May 10 22:41:06 oscar kernel:
> [_end+615444563/1070187180] icmp_reply_translation+0x33/0x1e4 [iptable_nat]
> May 10 22:41:06 oscar kernel: [_end+615450270/1070187180]
> gcc2_compiled.+0xc2/0x1d8 [iptable_nat] May 10 22:41:06 oscar kernel:
> [_end+615450641/1070187180] ip_nat_out+0x5d/0x64 [iptable_nat] May 10
> 22:41:06 oscar kernel: [ip_finish_output2+0/416]
> ip_finish_output2+0x0/0x1a0 May 10 22:41:06 oscar kernel:
> [nf_iterate+63/156] nf_iterate+0x3f/0x9c May 10 22:41:06 oscar kernel:
> [ip_finish_output2+0/416] ip_finish_output2+0x0/0x1a0 May 10 22:41:06 oscar
> kernel: [nf_hook_slow+149/296] nf_hook_slow+0x95/0x128 May 10 22:41:06
> oscar kernel: [ip_finish_output2+0/416] ip_finish_output2+0x0/0x1a0 May 10
> 22:41:06 oscar kernel: [_end+615462636/1070187180] ip_nat_out_ops+0x0/0x1c
> [iptable_nat] May 10 22:41:06 oscar kernel: [ip_output+535/544]
> ip_output+0x217/0x220 May 10 22:41:06 oscar kernel:
> [ip_finish_output2+0/416] ip_finish_output2+0x0/0x1a0 May 10 22:41:06 oscar
> kernel: [nf_hook_slow+149/296] nf_hook_slow+0x95/0x128 May 10 22:41:06
> oscar kernel: [ip_forward_finish+39/60] ip_forward_finish+0x27/0x3c May 10
> 22:41:06 oscar kernel: [nf_hook_slow+208/296] nf_hook_slow+0xd0/0x128 May
> 10 22:41:06 oscar kernel: [ip_forward+490/564] ip_forward+0x1ea/0x234 May
> 10 22:41:06 oscar kernel: [ip_forward_finish+0/60]
> ip_forward_finish+0x0/0x3c May 10 22:41:06 oscar kernel:
> [ip_rcv_finish+441/512] ip_rcv_finish+0x1b9/0x200 May 10 22:41:06 oscar
> kernel: [nf_hook_slow+208/296] nf_hook_slow+0xd0/0x128 May 10 22:41:06
> oscar kernel: [ip_rcv+924/984] ip_rcv+0x39c/0x3d8 May 10 22:41:06 oscar
> kernel: [ip_rcv_finish+0/512] ip_rcv_finish+0x0/0x200 May 10 22:41:06
> oscar kernel: [netif_receive_skb+283/332] netif_receive_skb+0x11b/0x14c
> May 10 22:41:06 oscar kernel: [process_backlog+113/292]
> process_backlog+0x71/0x124 May 10 22:41:06 oscar kernel:
> [net_rx_action+114/328] net_rx_action+0x72/0x148 May 10 22:41:06 oscar
> kernel: [do_softirq+82/172] do_softirq+0x52/0xac May 10 22:41:06 oscar
> kernel: [local_bh_enable+82/108] local_bh_enable+0x52/0x6c May 10 22:41:06
> oscar kernel: [_end+614250407/1070187180] ppp_asynctty_receive+0x4f/0x84
> [ppp_async] May 10 22:41:06 oscar kernel: [pty_write+237/336]
> pty_write+0xed/0x150 May 10 22:41:06 oscar kernel: [write_chan+424/516]
> write_chan+0x1a8/0x204 May 10 22:41:06 oscar kernel:
> [default_wake_function+0/24] default_wake_function+0x0/0x18 May 10 22:41:06
> oscar kernel: [default_wake_function+0/24] default_wake_function+0x0/0x18
> May 10 22:41:06 oscar kernel: [tty_write+515/708] tty_write+0x203/0x2c4
> May 10 22:41:06 oscar kernel: [write_chan+0/516] write_chan+0x0/0x204 May
> 10 22:41:06 oscar kernel: [vfs_write+162/208] vfs_write+0xa2/0xd0 May 10
> 22:41:06 oscar kernel: [sys_write+46/76] sys_write+0x2e/0x4c May 10
> 22:41:06 oscar kernel: [syscall_call+7/11] syscall_call+0x7/0xb May 10
> 22:41:06 oscar kernel:
>
> And with an ipchains based firewall:
>
> May 9 19:55:54 oscar kernel:
> ***************************************************************************
>**********
> ***************************************************************************
>****************************************
> ***************************************************************************
>****************************************
> ***************************************************************************
>****************************************
> ***************************************************************************
>****************************************
> ***************************************************************************
>****************************************
> ***************************************************************************
>****************************************
> ***************************************************************************
>****************************************
> ***************************************************************************
>****************************** May 9 19:55:54 oscar kernel:
> **********************************************************************A5
> May 9 19:55:54 oscar kernel: Call Trace:
> May 9 19:55:55 oscar kernel: [__slab_error+30/32] __slab_error+0x1e/0x20
> May 9 19:55:55 oscar kernel: [check_poison_obj+376/384]
> check_poison_obj+0x178/0x180 May 9 19:55:55 oscar kernel:
> [kmalloc+221/392] kmalloc+0xdd/0x188 May 9 19:55:55 oscar kernel:
> [alloc_skb+64/240] alloc_skb+0x40/0xf0 May 9 19:55:55 oscar kernel:
> [alloc_skb+64/240] alloc_skb+0x40/0xf0 May 9 19:55:55 oscar kernel:
> [_end+547372157/1070273676] icmp_manip_pkt+0x45/0x64 [ipchains] May 9
> 19:55:55 oscar kernel: [skb_copy+45/204] skb_copy+0x2d/0xcc May 9
> 19:55:55 oscar kernel: [_end+547367523/1070273676]
> skb_ip_make_writable+0xcf/0x164 [ipchains] May 9 19:55:55 oscar kernel:
> [_end+547367236/1070273676] icmp_reply_translation+0x194/0x1e4 [ipchains]
> May 9 19:55:55 oscar kernel: [_end+547366883/1070273676]
> icmp_reply_translation+0x33/0x1e4 [ipchains] May 9 19:55:55 oscar kernel:
> [_end+547362523/1070273676] check_for_demasq+0xbb/0x1bc [ipchains] May 9
> 19:55:55 oscar kernel: [_end+547400300/1070273676]
> ip_conntrack_protocol_icmp+0x0/0x40 [ipchains] May 9 19:55:55 oscar
> kernel: [_end+547359450/1070273676] fw_in+0x162/0x2b8 [ipchains] May 9
> 19:55:55 oscar kernel: [_end+547400948/1070273676] ipfw_ops+0x0/0x18
> [ipchains] May 9 19:55:55 oscar kernel: [_end+547359672/1070273676]
> fw_in+0x240/0x2b8 [ipchains] May 9 19:55:55 oscar kernel:
> [nf_iterate+63/156] nf_iterate+0x3f/0x9c May 9 19:55:55 oscar kernel:
> [ip_rcv_finish+0/512] ip_rcv_finish+0x0/0x200 May 9 19:55:55 oscar kernel:
> [nf_hook_slow+149/296] nf_hook_slow+0x95/0x128 May 9 19:55:55 oscar
> kernel: [ip_rcv_finish+0/512] ip_rcv_finish+0x0/0x200 May 9 19:55:55
> oscar kernel: [_end+547400364/1070273676] preroute_ops+0x0/0x1c [ipchains]
> May 9 19:55:55 oscar kernel: [ip_rcv+924/984] ip_rcv+0x39c/0x3d8 May 9
> 19:55:55 oscar kernel: [ip_rcv_finish+0/512] ip_rcv_finish+0x0/0x200 May
> 9 19:55:55 oscar kernel: [netif_receive_skb+283/332]
> netif_receive_skb+0x11b/0x14c May 9 19:55:55 oscar kernel:
> [process_backlog+113/292] process_backlog+0x71/0x124 May 9 19:55:55 oscar
> kernel: [net_rx_action+114/328] net_rx_action+0x72/0x148 May 9 19:55:55
> oscar kernel: [do_softirq+82/172] do_softirq+0x52/0xac May 9 19:55:55
> oscar kernel: [local_bh_enable+82/108] local_bh_enable+0x52/0x6c May 9
> 19:55:55 oscar kernel: [_end+547215751/1070273676]
> ppp_asynctty_receive+0x4f/0x84 [ppp_async] May 9 19:55:55 oscar kernel:
> [pty_write+237/336] pty_write+0xed/0x150 May 9 19:55:55 oscar kernel:
> [write_chan+424/516] write_chan+0x1a8/0x204 May 9 19:55:55 oscar kernel:
> [default_wake_function+0/24] default_wake_function+0x0/0x18 May 9 19:55:55
> oscar kernel: [default_wake_function+0/24] default_wake_function+0x0/0x18
> May 9 19:55:55 oscar kernel: [tty_write+515/708] tty_write+0x203/0x2c4
> May 9 19:55:55 oscar kernel: [write_chan+0/516] write_chan+0x0/0x204 May
> 9 19:55:55 oscar kernel: [vfs_write+162/208] vfs_write+0xa2/0xd0 May 9
> 19:55:55 oscar kernel: [sys_write+46/76] sys_write+0x2e/0x4c May 9
> 19:55:55 oscar kernel: [syscall_call+7/11] syscall_call+0x7/0xb May 9
> 19:55:55 oscar kernel:
>
> Hope this helps,
> Ed Tomlinson
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Slab corruption mm3 + davem fixes
2003-05-11 22:15 ` Andrew Morton
@ 2003-05-11 21:24 ` David S. Miller
2003-05-11 22:34 ` David S. Miller
1 sibling, 0 replies; 6+ messages in thread
From: David S. Miller @ 2003-05-11 21:24 UTC (permalink / raw)
To: akpm; +Cc: tomlins, linux-mm, linux-kernel, rusty, laforge
From: Andrew Morton <akpm@digeo.com>
Date: Sun, 11 May 2003 15:15:06 -0700
Did you mean to send a one megabyte diff?
Fuck wrong patch, that one was a 2.4.x backport of IPSEC enjoy :-)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Slab corruption mm3 + davem fixes
[not found] ` <1052690490.4471.2.camel@rth.ninka.net>
@ 2003-05-11 22:15 ` Andrew Morton
2003-05-11 21:24 ` David S. Miller
2003-05-11 22:34 ` David S. Miller
0 siblings, 2 replies; 6+ messages in thread
From: Andrew Morton @ 2003-05-11 22:15 UTC (permalink / raw)
To: David S. Miller; +Cc: tomlins, linux-mm, linux-kernel, rusty, laforge
"David S. Miller" <davem@redhat.com> wrote:
>
> On Sun, 2003-05-11 at 09:21, Ed Tomlinson wrote:
> > I am also seeing this on 69-bk (as of Sunday morning)
> ...
> > On May 10, 2003 11:19 pm, Ed Tomlinson wrote:
> > > I looked at my logs and found the following error in it. My kernel is
> > > 69-mm3 with two davem fixes on it.
> ...
> > > May 10 22:41:06 oscar kernel: Call Trace:
> > > May 10 22:41:06 oscar kernel: [__slab_error+30/32] __slab_error+0x1e/0x20
> > > May 10 22:41:06 oscar kernel: [check_poison_obj+376/384]
> > > check_poison_obj+0x178/0x180 May 10 22:41:06 oscar kernel:
> > > [kmalloc+221/392] kmalloc+0xdd/0x188 May 10 22:41:06 oscar kernel:
> > > [alloc_skb+64/240] alloc_skb+0x40/0xf0 May 10 22:41:06 oscar kernel:
>
> Yeah, more bugs in the NAT netfilter changes. Debugging this one
> patch is becomming a full time job :-(
>
> This should fix it. Rusty, you're computing checksums and mangling
> src/dst using header pointers potentially pointing to free'd skbs.
>
Did you mean to send a one megabyte diff?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Slab corruption mm3 + davem fixes
2003-05-11 22:15 ` Andrew Morton
2003-05-11 21:24 ` David S. Miller
@ 2003-05-11 22:34 ` David S. Miller
2003-05-12 7:44 ` Ed Tomlinson
1 sibling, 1 reply; 6+ messages in thread
From: David S. Miller @ 2003-05-11 22:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: tomlins, linux-mm, linux-kernel, rusty, laforge
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]
On Sun, 2003-05-11 at 15:15, Andrew Morton wrote:
> "David S. Miller" <davem@redhat.com> wrote:
> >
> > On Sun, 2003-05-11 at 09:21, Ed Tomlinson wrote:
> > > I am also seeing this on 69-bk (as of Sunday morning)
> > ...
> > > On May 10, 2003 11:19 pm, Ed Tomlinson wrote:
> > > > I looked at my logs and found the following error in it. My kernel is
> > > > 69-mm3 with two davem fixes on it.
> > ...
> > > > May 10 22:41:06 oscar kernel: Call Trace:
> > > > May 10 22:41:06 oscar kernel: [__slab_error+30/32] __slab_error+0x1e/0x20
> > > > May 10 22:41:06 oscar kernel: [check_poison_obj+376/384]
> > > > check_poison_obj+0x178/0x180 May 10 22:41:06 oscar kernel:
> > > > [kmalloc+221/392] kmalloc+0xdd/0x188 May 10 22:41:06 oscar kernel:
> > > > [alloc_skb+64/240] alloc_skb+0x40/0xf0 May 10 22:41:06 oscar kernel:
> >
> > Yeah, more bugs in the NAT netfilter changes. Debugging this one
> > patch is becomming a full time job :-(
> >
> > This should fix it. Rusty, you're computing checksums and mangling
> > src/dst using header pointers potentially pointing to free'd skbs.
> >
>
> Did you mean to send a one megabyte diff?
Let's try this again, here is the correct patch :-)
--
David S. Miller <davem@redhat.com>
[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 4379 bytes --]
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.1105 -> 1.1106
# net/ipv4/netfilter/ip_nat_core.c 1.25 -> 1.26
# net/ipv4/netfilter/ip_fw_compat_masq.c 1.8 -> 1.9
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/05/11 davem@nuts.ninka.net 1.1106
# [NETFILTER]: Fix stale skb data pointer usage in ipv4 NAT.
# --------------------------------------------
#
diff -Nru a/net/ipv4/netfilter/ip_fw_compat_masq.c b/net/ipv4/netfilter/ip_fw_compat_masq.c
--- a/net/ipv4/netfilter/ip_fw_compat_masq.c Sun May 11 15:31:41 2003
+++ b/net/ipv4/netfilter/ip_fw_compat_masq.c Sun May 11 15:31:41 2003
@@ -35,16 +35,15 @@
unsigned int
do_masquerade(struct sk_buff **pskb, const struct net_device *dev)
{
- struct iphdr *iph = (*pskb)->nh.iph;
struct ip_nat_info *info;
enum ip_conntrack_info ctinfo;
struct ip_conntrack *ct;
unsigned int ret;
/* Sorry, only ICMP, TCP and UDP. */
- if (iph->protocol != IPPROTO_ICMP
- && iph->protocol != IPPROTO_TCP
- && iph->protocol != IPPROTO_UDP)
+ if ((*pskb)->nh.iph->protocol != IPPROTO_ICMP
+ && (*pskb)->nh.iph->protocol != IPPROTO_TCP
+ && (*pskb)->nh.iph->protocol != IPPROTO_UDP)
return NF_DROP;
/* Feed it to connection tracking; in fact we're in NF_IP_FORWARD,
@@ -68,7 +67,7 @@
/* Setup the masquerade, if not already */
if (!info->initialized) {
u_int32_t newsrc;
- struct flowi fl = { .nl_u = { .ip4_u = { .daddr = iph->daddr } } };
+ struct flowi fl = { .nl_u = { .ip4_u = { .daddr = (*pskb)->nh.iph->daddr } } };
struct rtable *rt;
struct ip_nat_multi_range range;
@@ -124,19 +123,18 @@
check_for_demasq(struct sk_buff **pskb)
{
struct ip_conntrack_tuple tuple;
- struct iphdr *iph = (*pskb)->nh.iph;
struct ip_conntrack_protocol *protocol;
struct ip_conntrack_tuple_hash *h;
enum ip_conntrack_info ctinfo;
struct ip_conntrack *ct;
int ret;
- protocol = ip_ct_find_proto(iph->protocol);
+ protocol = ip_ct_find_proto((*pskb)->nh.iph->protocol);
/* We don't feed packets to conntrack system unless we know
they're part of an connection already established by an
explicit masq command. */
- switch (iph->protocol) {
+ switch ((*pskb)->nh.iph->protocol) {
case IPPROTO_ICMP:
/* ICMP errors. */
ct = icmp_error_track(*pskb, &ctinfo, NF_IP_PRE_ROUTING);
@@ -146,12 +144,6 @@
server here (== DNAT). Do SNAT icmp manips
in POST_ROUTING handling. */
if (CTINFO2DIR(ctinfo) == IP_CT_DIR_REPLY) {
- /* FIXME: Remove once NAT handled non-linear.
- */
- if (skb_is_nonlinear(*pskb)
- && skb_linearize(*pskb, GFP_ATOMIC) != 0)
- return NF_DROP;
-
icmp_reply_translation(pskb, ct,
NF_IP_PRE_ROUTING,
CTINFO2DIR(ctinfo));
@@ -166,7 +158,7 @@
case IPPROTO_UDP:
IP_NF_ASSERT(((*pskb)->nh.iph->frag_off & htons(IP_OFFSET)) == 0);
- if (!get_tuple(iph, *pskb, iph->ihl*4, &tuple, protocol)) {
+ if (!get_tuple((*pskb)->nh.iph, *pskb, (*pskb)->nh.iph->ihl*4, &tuple, protocol)) {
if (net_ratelimit())
printk("ip_fw_compat_masq: Can't get tuple\n");
return NF_ACCEPT;
diff -Nru a/net/ipv4/netfilter/ip_nat_core.c b/net/ipv4/netfilter/ip_nat_core.c
--- a/net/ipv4/netfilter/ip_nat_core.c Sun May 11 15:31:41 2003
+++ b/net/ipv4/netfilter/ip_nat_core.c Sun May 11 15:31:41 2003
@@ -717,10 +717,13 @@
iph = (void *)(*pskb)->data + iphdroff;
/* Manipulate protcol part. */
- if (!find_nat_proto(proto)->manip_pkt(pskb, iphdroff + iph->ihl*4,
+ if (!find_nat_proto(proto)->manip_pkt(pskb,
+ iphdroff + iph->ihl*4,
manip, maniptype))
return 0;
+ iph = (void *)(*pskb)->data + iphdroff;
+
if (maniptype == IP_NAT_MANIP_SRC) {
iph->check = ip_nat_cheat_check(~iph->saddr, manip->ip,
iph->check);
@@ -952,6 +955,8 @@
READ_UNLOCK(&ip_nat_lock);
hdrlen = (*pskb)->nh.iph->ihl * 4;
+
+ inside = (void *)(*pskb)->data + (*pskb)->nh.iph->ihl*4;
inside->icmp.checksum = 0;
inside->icmp.checksum = csum_fold(skb_checksum(*pskb, hdrlen,
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Slab corruption mm3 + davem fixes
2003-05-12 7:44 ` Ed Tomlinson
@ 2003-05-12 6:42 ` David S. Miller
0 siblings, 0 replies; 6+ messages in thread
From: David S. Miller @ 2003-05-12 6:42 UTC (permalink / raw)
To: tomlins; +Cc: akpm, linux-mm, linux-kernel, rusty, laforge
From: Ed Tomlinson <tomlins@cam.org>
Date: Mon, 12 May 2003 03:44:50 -0400
On May 11, 2003 06:34 pm, David S. Miller wrote:
> > > Yeah, more bugs in the NAT netfilter changes. Debugging this one
> > > patch is becomming a full time job :-(
But you do it well... Looks like this fixes the slab problems here with
69-bk from Sunday am.
Thank you for testing.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Slab corruption mm3 + davem fixes
2003-05-11 22:34 ` David S. Miller
@ 2003-05-12 7:44 ` Ed Tomlinson
2003-05-12 6:42 ` David S. Miller
0 siblings, 1 reply; 6+ messages in thread
From: Ed Tomlinson @ 2003-05-12 7:44 UTC (permalink / raw)
To: David S. Miller, Andrew Morton; +Cc: linux-mm, linux-kernel, rusty, laforge
On May 11, 2003 06:34 pm, David S. Miller wrote:
> > > Yeah, more bugs in the NAT netfilter changes. Debugging this one
> > > patch is becomming a full time job :-(
But you do it well... Looks like this fixes the slab problems here with
69-bk from Sunday am.
> > > This should fix it. Rusty, you're computing checksums and mangling
> > > src/dst using header pointers potentially pointing to free'd skbs.
> >
> > Did you mean to send a one megabyte diff?
>
> Let's try this again, here is the correct patch :-)
Thanks
Ed Tomlinson
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-05-12 7:35 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20030511031940.97C24251B@oscar.casa.dyndns.org>
2003-05-11 16:21 ` Slab corruption mm3 + davem fixes Ed Tomlinson
[not found] ` <1052690490.4471.2.camel@rth.ninka.net>
2003-05-11 22:15 ` Andrew Morton
2003-05-11 21:24 ` David S. Miller
2003-05-11 22:34 ` David S. Miller
2003-05-12 7:44 ` Ed Tomlinson
2003-05-12 6:42 ` David S. Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox