From: Patrick McHardy <kaber@trash.net>
To: Matthias Andree <matthias.andree@gmx.de>
Cc: linux-net@vger.kernel.org, linux-kernel@vger.kernel.org,
netfilter-devel@lists.netfilter.org,
Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [BK PATCH] Fix ip_conntrack_amanda data corruption bug that breaks amanda dumps
Date: Fri, 05 Nov 2004 00:59:23 +0100 [thread overview]
Message-ID: <418AC25B.4060401@trash.net> (raw)
In-Reply-To: <20041104235001.GB30029@merlin.emma.line.org>
Matthias Andree wrote:
>On Thu, 04 Nov 2004, Patrick McHardy wrote:
>
>
>>- data = amp;
>>- data_limit = amp + skb->len - dataoff;
>>+ skb_copy_bits(skb, dataoff, amanda_buffer, skb->len - dataoff);
>>+ data = amanda_buffer;
>>+ data_limit = amanda_buffer + skb->len - dataoff;
>>
>
>Does this mean the whole buffer is still copied?
>
Yes.
>
>If so: Making a local copy of the packet just to be able to stuff NUL
>bytes to suit or "optimize" strstr functions is plain nonsense - amanda
>pipes several GByte through the kernel at each run, and copying
>gazillions of bits around, wasting millions of CPU cycles, just because
>someone is too lazy to spell a more decent search function, is
>bad design.
>
This is just the UDP control connection, the data is not copied
or scanned. Feel free to send a patch that doesn't need to
copy linear skbs and doesn't need to modify the skb.
>Same consideration applies to FTP connection tracking.
>
>I wrote a memstr function for bogofilter (GPL v2) that we could use
>inside the kernel, as a length-limited strstr replacement, as in "search
>the first buffer_size bytes starting with buffer_base for the first
>occurrence of const char *needle". That avoids all buffer modifications
>in ip_conntrack_amanda.c AFAICS. It's also slow because it does a linear
>search and not an optimized search as the sophisticated KMP and other
>search algorithms would be able to do, but then again the generic strstr
>inside the kernel is linear, too.
>
non-linear skb have fragments scattered in memory, you have to
copy them or scan with a function that is aware of how the data
is layed out in memory. Look at Harald's notes from the netfilter
workshop for details on current work in this area.
http://www.netfilter.org/documentation/conferences/nf-workshop-2004-summary.html#AEN499
Regards
Patrick
WARNING: multiple messages have this Message-ID (diff)
From: Patrick McHardy <kaber@trash.net>
To: Matthias Andree <matthias.andree@gmx.de>
Cc: "David S. Miller" <davem@davemloft.net>,
Herbert Xu <herbert@gondor.apana.org.au>,
linux-net@vger.kernel.org, netfilter-devel@lists.netfilter.org,
linux-kernel@vger.kernel.org
Subject: Re: [BK PATCH] Fix ip_conntrack_amanda data corruption bug that breaks amanda dumps
Date: Fri, 05 Nov 2004 00:59:23 +0100 [thread overview]
Message-ID: <418AC25B.4060401@trash.net> (raw)
In-Reply-To: <20041104235001.GB30029@merlin.emma.line.org>
Matthias Andree wrote:
>On Thu, 04 Nov 2004, Patrick McHardy wrote:
>
>
>>- data = amp;
>>- data_limit = amp + skb->len - dataoff;
>>+ skb_copy_bits(skb, dataoff, amanda_buffer, skb->len - dataoff);
>>+ data = amanda_buffer;
>>+ data_limit = amanda_buffer + skb->len - dataoff;
>>
>
>Does this mean the whole buffer is still copied?
>
Yes.
>
>If so: Making a local copy of the packet just to be able to stuff NUL
>bytes to suit or "optimize" strstr functions is plain nonsense - amanda
>pipes several GByte through the kernel at each run, and copying
>gazillions of bits around, wasting millions of CPU cycles, just because
>someone is too lazy to spell a more decent search function, is
>bad design.
>
This is just the UDP control connection, the data is not copied
or scanned. Feel free to send a patch that doesn't need to
copy linear skbs and doesn't need to modify the skb.
>Same consideration applies to FTP connection tracking.
>
>I wrote a memstr function for bogofilter (GPL v2) that we could use
>inside the kernel, as a length-limited strstr replacement, as in "search
>the first buffer_size bytes starting with buffer_base for the first
>occurrence of const char *needle". That avoids all buffer modifications
>in ip_conntrack_amanda.c AFAICS. It's also slow because it does a linear
>search and not an optimized search as the sophisticated KMP and other
>search algorithms would be able to do, but then again the generic strstr
>inside the kernel is linear, too.
>
non-linear skb have fragments scattered in memory, you have to
copy them or scan with a function that is aware of how the data
is layed out in memory. Look at Harald's notes from the netfilter
workshop for details on current work in this area.
http://www.netfilter.org/documentation/conferences/nf-workshop-2004-summary.html#AEN499
Regards
Patrick
next prev parent reply other threads:[~2004-11-04 23:59 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-04 12:15 [BK PATCH] Fix ip_conntrack_amanda data corruption bug that breaks amanda dumps Matthias Andree
2004-11-04 18:55 ` Patrick McHardy
2004-11-04 18:55 ` Patrick McHardy
2004-11-04 20:45 ` Herbert Xu
2004-11-04 20:45 ` Herbert Xu
2004-11-04 21:00 ` David S. Miller
2004-11-04 21:00 ` David S. Miller
2004-11-04 21:53 ` Patrick McHardy
2004-11-04 21:53 ` Patrick McHardy
2004-11-04 23:50 ` Matthias Andree
2004-11-04 23:50 ` Matthias Andree
2004-11-04 23:59 ` Patrick McHardy [this message]
2004-11-04 23:59 ` Patrick McHardy
2004-11-04 23:17 ` Matthias Andree
2004-11-04 23:17 ` Matthias Andree
2004-11-04 23:53 ` Patrick McHardy
2004-11-04 23:53 ` Patrick McHardy
2004-11-05 0:06 ` David S. Miller
2004-11-05 0:06 ` David S. Miller
2004-11-05 0:40 ` Patrick McHardy
2004-11-05 0:40 ` Patrick McHardy
2004-11-05 1:04 ` Matthias Andree
2004-11-05 1:04 ` Matthias Andree
2004-11-05 0:58 ` David S. Miller
2004-11-05 0:58 ` David S. Miller
2004-11-05 11:30 ` Matthias Andree
2004-11-05 11:30 ` Matthias Andree
2004-11-05 20:23 ` Pablo Neira
2004-11-05 22:19 ` Patrick McHardy
2004-11-05 22:19 ` Patrick McHardy
2004-11-06 1:53 ` Pablo Neira
2004-11-06 1:53 ` Pablo Neira
2004-11-07 12:16 ` Matthias Andree
2004-11-07 16:39 ` Patrick McHardy
2004-11-05 22:24 ` Henrik Nordstrom
2004-11-05 22:24 ` Henrik Nordstrom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=418AC25B.4060401@trash.net \
--to=kaber@trash.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@vger.kernel.org \
--cc=matthias.andree@gmx.de \
--cc=netfilter-devel@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.