<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/net/ipv6/ip6_output.c, branch linux-2.6.23.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.23.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.23.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2007-09-11T09:31:43Z</updated>
<entry>
<title>[IPv6]: Fix NULL pointer dereference in ip6_flush_pending_frames</title>
<updated>2007-09-11T09:31:43Z</updated>
<author>
<name>YOSHIFUJI Hideaki</name>
</author>
<published>2007-09-11T09:31:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e1f52208bb968291f7d9142eff60b62984b4a511'/>
<id>urn:sha1:e1f52208bb968291f7d9142eff60b62984b4a511</id>
<content type='text'>
Some of skbs in sk-&gt;write_queue do not have skb-&gt;dst because
we do not fill skb-&gt;dst when we allocate new skb in append_data().

BTW, I think we may not need to (or we should not) increment some stats
when using corking; if 100 sendmsg() (with MSG_MORE) result in 2 packets,
how many should we increment?

If 100, we should set skb-&gt;dst for every queued skbs.

If 1 (or 2 (*)), we increment the stats for the first queued skb and
we should just skip incrementing OutDiscards for the rest of queued skbs,
adn we should also impelement this semantics in other places;
e.g., we should increment other stats just once, not 100 times.

*: depends on the place we are discarding the datagram.

I guess should just increment by 1 (or 2).

Signed-off-by: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[IPV6]: Fix kernel panic while send SCTP data with IP fragments</title>
<updated>2007-08-22T03:59:08Z</updated>
<author>
<name>Wei Yongjun</name>
</author>
<published>2007-08-22T03:59:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8984e41d18a545320201950b8721e7ce3ac2a5e7'/>
<id>urn:sha1:8984e41d18a545320201950b8721e7ce3ac2a5e7</id>
<content type='text'>
If ICMP6 message with "Packet Too Big" is received after send SCTP DATA,
kernel panic will occur when SCTP DATA is send again.

This is because of a bad dest address when call to skb_copy_bits().

The messages sequence is like this:

Endpoint A                             Endpoint B
                               &lt;-------  SCTP DATA (size=1432)
ICMP6 message -------&gt;
(Packet Too Big pmtu=1280)
                               &lt;-------  Resend SCTP DATA (size=1432)
------------kernel panic---------------

 printing eip:
c05be62a
*pde = 00000000
Oops: 0002 [#1]
SMP
Modules linked in: scomm l2cap bluetooth ipv6 dm_mirror dm_mod video output sbs battery lp floppy sg i2c_piix4 i2c_core pcnet32 mii button ac parport_pc parport ide_cd cdrom serio_raw mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
CPU:    0
EIP:    0060:[&lt;c05be62a&gt;]    Not tainted VLI
EFLAGS: 00010282   (2.6.23-rc2 #1)
EIP is at skb_copy_bits+0x4f/0x1ef
eax: 000004d0   ebx: ce12a980   ecx: 00000134   edx: cfd5a880
esi: c8246858   edi: 00000000   ebp: c0759b14   esp: c0759adc
ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
Process swapper (pid: 0, ti=c0759000 task=c06d0340 task.ti=c0713000)
Stack: c0759b88 c0405867 ce12a980 c8bff838 c789c084 00000000 00000028 cfd5a880
       d09f1890 000005dc 0000007b ce12a980 cfd5a880 c8bff838 c0759b88 d09bc521
       000004d0 fffff96c 00000200 00000100 c0759b50 cfd5a880 00000246 c0759bd4
Call Trace:
 [&lt;c0405e1d&gt;] show_trace_log_lvl+0x1a/0x2f
 [&lt;c0405ecd&gt;] show_stack_log_lvl+0x9b/0xa3
 [&lt;c040608d&gt;] show_registers+0x1b8/0x289
 [&lt;c0406271&gt;] die+0x113/0x246
 [&lt;c0625dbc&gt;] do_page_fault+0x4ad/0x57e
 [&lt;c0624642&gt;] error_code+0x72/0x78
 [&lt;d09bc521&gt;] ip6_output+0x8e5/0xab2 [ipv6]
 [&lt;d09bcec1&gt;] ip6_xmit+0x2ea/0x3a3 [ipv6]
 [&lt;d0a3f2ca&gt;] sctp_v6_xmit+0x248/0x253 [sctp]
 [&lt;d0a3c934&gt;] sctp_packet_transmit+0x53f/0x5ae [sctp]
 [&lt;d0a34bf8&gt;] sctp_outq_flush+0x555/0x587 [sctp]
 [&lt;d0a34d3c&gt;] sctp_retransmit+0xf8/0x10f [sctp]
 [&lt;d0a3d183&gt;] sctp_icmp_frag_needed+0x57/0x5b [sctp]
 [&lt;d0a3ece2&gt;] sctp_v6_err+0xcd/0x148 [sctp]
 [&lt;d09cf1ce&gt;] icmpv6_notify+0xe6/0x167 [ipv6]
 [&lt;d09d009a&gt;] icmpv6_rcv+0x7d7/0x849 [ipv6]
 [&lt;d09be240&gt;] ip6_input+0x1dc/0x310 [ipv6]
 [&lt;d09be965&gt;] ipv6_rcv+0x294/0x2df [ipv6]
 [&lt;c05c3789&gt;] netif_receive_skb+0x2d2/0x335
 [&lt;c05c5733&gt;] process_backlog+0x7f/0xd0
 [&lt;c05c58f6&gt;] net_rx_action+0x96/0x17e
 [&lt;c042e722&gt;] __do_softirq+0x64/0xcd
 [&lt;c0406f37&gt;] do_softirq+0x5c/0xac
 =======================
Code: 00 00 29 ca 89 d0 2b 45 e0 89 55 ec 85 c0 7e 35 39 45 08 8b 55 e4 0f 4e 45 08 8b 75 e0 8b 7d dc 89 c1 c1 e9 02 03 b2 a0 00 00 00 &lt;f3&gt; a5 89 c1 83 e1 03 74 02 f3 a4 29 45 08 0f 84 7b 01 00 00 01
EIP: [&lt;c05be62a&gt;] skb_copy_bits+0x4f/0x1ef SS:ESP 0068:c0759adc
Kernel panic - not syncing: Fatal exception in interrupt

Arnaldo says:
====================
Thanks! I'm to blame for this one, problem was introduced in:

b0e380b1d8a8e0aca215df97702f99815f05c094

@@ -761,7 +762,7 @@ slow_path:
                /*
                 *      Copy a block of the IP datagram.
                 */
-               if (skb_copy_bits(skb, ptr, frag-&gt;h.raw, len))
+               if (skb_copy_bits(skb, ptr, skb_transport_header(skb),
len))
                        BUG();
                left -= len;
====================

Signed-off-by: Wei Yongjun &lt;yjwei@cn.fujitsu.com&gt;
Acked-by: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@ghostprotocols.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[NETFILTER]: x_tables: add TRACE target</title>
<updated>2007-07-11T05:17:14Z</updated>
<author>
<name>Jozsef Kadlecsik</name>
</author>
<published>2007-07-08T05:21:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ba9dda3ab5a865542e69dfe01edb2436857c9420'/>
<id>urn:sha1:ba9dda3ab5a865542e69dfe01edb2436857c9420</id>
<content type='text'>
The TRACE target can be used to follow IP and IPv6 packets through
the ruleset.

Signed-off-by: Jozsef Kadlecsik &lt;kadlec@blackhole.kfki.hu&gt;
Signed-off-by: Patrick NcHardy &lt;kaber@trash.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[IPV6] MIP6: Loadable module support for MIPv6.</title>
<updated>2007-07-11T05:15:42Z</updated>
<author>
<name>Masahide NAKAMURA</name>
</author>
<published>2007-06-27T06:56:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=59fbb3a61e02deaeaa4fb50792217921f3002d64'/>
<id>urn:sha1:59fbb3a61e02deaeaa4fb50792217921f3002d64</id>
<content type='text'>
This patch makes MIPv6 loadable module named "mip6".

Here is a modprobe.conf(5) example to load it automatically
when user application uses XFRM state for MIPv6:

alias xfrm-type-10-43 mip6
alias xfrm-type-10-60 mip6

Some MIPv6 feature is not included by this modular, however,
it should not be affected to other features like either IPsec
or IPv6 with and without the patch.
We may discuss XFRM, MH (RAW socket) and ancillary data/sockopt
separately for future work.

Loadable features:
* MH receiving check (to send ICMP error back)
* RO header parsing and building (i.e. RH2 and HAO in DSTOPTS)
* XFRM policy/state database handling for RO

These are NOT covered as loadable:
* Home Address flags and its rule on source address selection
* XFRM sub policy (depends on its own kernel option)
* XFRM functions to receive RO as IPv6 extension header
* MH sending/receiving through raw socket if user application
  opens it (since raw socket allows to do so)
* RH2 sending as ancillary data
* RH2 operation with setsockopt(2)

Signed-off-by: Masahide NAKAMURA &lt;nakam@linux-ipv6.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[IPV6]: Send ICMPv6 error on scope violations.</title>
<updated>2007-05-11T06:45:32Z</updated>
<author>
<name>David L Stevens</name>
</author>
<published>2007-05-09T20:53:44Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5bb1ab09e4f6287c0b6c9cdbd463147cbd003f54'/>
<id>urn:sha1:5bb1ab09e4f6287c0b6c9cdbd463147cbd003f54</id>
<content type='text'>
When an IPv6 router is forwarding a packet with a link-local scope source
address off-link, RFC 4007 requires it to send an ICMPv6 destination
unreachable with code 2 ("not neighbor"), but Linux doesn't. Fix below.

Signed-off-by: David L Stevens &lt;dlstevens@us.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[INET]: Add IP(V6)_PMTUDISC_RPOBE</title>
<updated>2007-04-26T05:29:10Z</updated>
<author>
<name>John Heffner</name>
</author>
<published>2007-04-20T22:53:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=628a5c561890a9a9a74dea017873530584aab06e'/>
<id>urn:sha1:628a5c561890a9a9a74dea017873530584aab06e</id>
<content type='text'>
Add IP(V6)_PMTUDISC_PROBE value for IP(V6)_MTU_DISCOVER.  This option forces
us not to fragment, but does not make use of the kernel path MTU discovery.
That is, it allows for user-mode MTU probing (or, packetization-layer path
MTU discovery).  This is particularly useful for diagnostic utilities, like
traceroute/tracepath.

Signed-off-by: John Heffner &lt;jheffner@psc.edu&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[IPV6]: MTU discovery check in ip6_fragment()</title>
<updated>2007-04-26T05:29:09Z</updated>
<author>
<name>John Heffner</name>
</author>
<published>2007-04-20T22:52:39Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b881ef7603230550aa0150b22af94089f07ab00d'/>
<id>urn:sha1:b881ef7603230550aa0150b22af94089f07ab00d</id>
<content type='text'>
Adds a check in ip6_fragment() mirroring ip_fragment() for packets
that we can't fragment, and sends an ICMP Packet Too Big message
in response.

Signed-off-by: John Heffner &lt;jheffner@psc.edu&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[SK_BUFF]: Introduce skb_copy_from_linear_data{_offset}</title>
<updated>2007-04-26T05:28:23Z</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
</author>
<published>2007-03-27T21:55:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d626f62b11e00c16e81e4308ab93d3f13551812a'/>
<id>urn:sha1:d626f62b11e00c16e81e4308ab93d3f13551812a</id>
<content type='text'>
To clearly state the intent of copying from linear sk_buffs, _offset being a
overly long variant but interesting for the sake of saving some bytes.

Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>[NET]: Allow forwarding of ip_summed except CHECKSUM_COMPLETE</title>
<updated>2007-04-26T05:28:16Z</updated>
<author>
<name>Herbert Xu</name>
</author>
<published>2007-03-27T06:22:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=35fc92a9deee0da6e35fdc3150bb134e58f2fd63'/>
<id>urn:sha1:35fc92a9deee0da6e35fdc3150bb134e58f2fd63</id>
<content type='text'>
Right now Xen has a horrible hack that lets it forward packets with
partial checksums.  One of the reasons that CHECKSUM_PARTIAL and
CHECKSUM_COMPLETE were added is so that we can get rid of this hack
(where it creates two extra bits in the skbuff to essentially mirror
ip_summed without being destroyed by the forwarding code).

I had forgotten that I've already gone through all the deivce drivers
last time around to make sure that they're looking at ip_summed ==
CHECKSUM_PARTIAL rather than ip_summed != 0 on transmit.  In any case,
I've now done that again so it should definitely be safe.

Unfortunately nobody has yet added any code to update CHECKSUM_COMPLETE
values on forward so we I'm setting that to CHECKSUM_NONE.  This should
be safe to remove for bridging but I'd like to check that code path
first.

So here is the patch that lets us get rid of the hack by preserving
ip_summed (mostly) on forwarded packets.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[SK_BUFF]: Convert skb-&gt;tail to sk_buff_data_t</title>
<updated>2007-04-26T05:26:28Z</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
</author>
<published>2007-04-20T03:29:13Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=27a884dc3cb63b93c2b3b643f5b31eed5f8a4d26'/>
<id>urn:sha1:27a884dc3cb63b93c2b3b643f5b31eed5f8a4d26</id>
<content type='text'>
So that it is also an offset from skb-&gt;head, reduces its size from 8 to 4 bytes
on 64bit architectures, allowing us to combine the 4 bytes hole left by the
layer headers conversion, reducing struct sk_buff size to 256 bytes, i.e. 4
64byte cachelines, and since the sk_buff slab cache is SLAB_HWCACHE_ALIGN...
:-)

Many calculations that previously required that skb-&gt;{transport,network,
mac}_header be first converted to a pointer now can be done directly, being
meaningful as offsets or pointers.

Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
