<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/net/llc, branch v2.6.19</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/net/llc?h=v2.6.19</id>
<link rel='self' href='https://git.amat.us/linux/atom/net/llc?h=v2.6.19'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2006-08-14T01:56:26Z</updated>
<entry>
<title>[LLC]: multicast receive device match</title>
<updated>2006-08-14T01:56:26Z</updated>
<author>
<name>Stephen Hemminger</name>
<email>shemminger@osdl.org</email>
</author>
<published>2006-08-14T01:56:26Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7ee66fcb94cb8be77d5f34cce7d315d11759f9c1'/>
<id>urn:sha1:7ee66fcb94cb8be77d5f34cce7d315d11759f9c1</id>
<content type='text'>
Fix from Aji_Srinivas@emc.com, STP packets are incorrectly received on
all LLC datagram sockets, whichever interface they are bound to.  The
llc_sap datagram receive logic sends packets with a unicast
destination MAC to one socket bound to that SAP and MAC, and multicast
packets to all sockets bound to that SAP. STP packets are multicast,
and we do need to know on which interface they were received.

Signed-off-by: Stephen Hemminger &lt;shemminger@osdl.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[LLX]: SOCK_DGRAM interface fixes</title>
<updated>2006-08-05T05:59:50Z</updated>
<author>
<name>Stephen Hemminger</name>
<email>shemminger@osdl.org</email>
</author>
<published>2006-08-03T23:38:49Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=30a584d944fbd599d4a8f470f75bf7af1a15b466'/>
<id>urn:sha1:30a584d944fbd599d4a8f470f75bf7af1a15b466</id>
<content type='text'>
The datagram interface of LLC is broken in a couple of ways.
These were discovered when trying to use it to build an out-of-kernel
version of STP.

First it didn't pass the source address of the received packet
in recvfrom(). It needs to copy the source address of received LLC packets
into the socket control block. At the same time fix a security issue
because there was uninitialized data leakage. Every recvfrom call
was just copying out old data.

Second, LLC should not merge multiple packets in one receive call
on datagram sockets. LLC should preserve packet boundaries on
SOCK_DGRAM.

This fix goes against the old historical comments about UNIX98 semantics
but without this fix SOCK_DGRAM is broken and useless. So either ANK's
interpretation was incorect or UNIX98 standard was wrong.

Signed-off-by: Stephen Hemminger &lt;shemminger@osdl.org&gt;
Acked-by: Arnaldo Carvalho de Melo &lt;acme@mandriva.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[NET]: Conversions from kmalloc+memset to k(z|c)alloc.</title>
<updated>2006-07-21T21:51:30Z</updated>
<author>
<name>Panagiotis Issaris</name>
<email>takis@issaris.org</email>
</author>
<published>2006-07-21T21:51:30Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0da974f4f303a6842516b764507e3c0a03f41e5a'/>
<id>urn:sha1:0da974f4f303a6842516b764507e3c0a03f41e5a</id>
<content type='text'>
Signed-off-by: Panagiotis Issaris &lt;takis@issaris.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;

</content>
</entry>
<entry>
<title>Remove obsolete #include &lt;linux/config.h&gt;</title>
<updated>2006-06-30T17:25:36Z</updated>
<author>
<name>Jörn Engel</name>
<email>joern@wohnheim.fh-wedel.de</email>
</author>
<published>2006-06-30T17:25:36Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6ab3d5624e172c553004ecc862bfeac16d9d68b7'/>
<id>urn:sha1:6ab3d5624e172c553004ecc862bfeac16d9d68b7</id>
<content type='text'>
Signed-off-by: Jörn Engel &lt;joern@wohnheim.fh-wedel.de&gt;
Signed-off-by: Adrian Bunk &lt;bunk@stusta.de&gt;
</content>
</entry>
<entry>
<title>[LLC]: Fix double receive of SKB.</title>
<updated>2006-06-18T04:29:19Z</updated>
<author>
<name>Andrew Morton</name>
<email>akpm@osdl.org</email>
</author>
<published>2006-06-02T23:29:20Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2f45c340e09242641d4f11498c3be48b35abb926'/>
<id>urn:sha1:2f45c340e09242641d4f11498c3be48b35abb926</id>
<content type='text'>
Oops fix from Stephen: remove duplicate rcv() calls.

Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[LLC]: add multicast support for datagrams</title>
<updated>2006-06-18T04:26:08Z</updated>
<author>
<name>Stephen Hemminger</name>
<email>shemminger@osdl.org</email>
</author>
<published>2006-05-25T22:10:37Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=bc0e646796928918e45b6465e02616f2fe65c3c1'/>
<id>urn:sha1:bc0e646796928918e45b6465e02616f2fe65c3c1</id>
<content type='text'>
Allow mulitcast reception of datagrams (similar to UDP).
All sockets bound to the same SAP receive a clone.

Signed-off-by: Stephen Hemminger &lt;shemminger@osdl.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[LLC]: allow applications to get copy of kernel datagrams</title>
<updated>2006-06-18T04:26:06Z</updated>
<author>
<name>Stephen Hemminger</name>
<email>shemminger@osdl.org</email>
</author>
<published>2006-05-25T22:10:02Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8f182b494f87799d6ae20a1401825c516da46081'/>
<id>urn:sha1:8f182b494f87799d6ae20a1401825c516da46081</id>
<content type='text'>
It is legal for an application to bind to a SAP that is also being
used by the kernel. This happens if the bridge module binds to the
STP SAP, and the user wants to have a daemon for STP as well.
It is possible to have kernel doing STP on one bridge, but
let application do RSTP on another bridge.

Signed-off-by: Stephen Hemminger &lt;shemminger@osdl.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[LLC]: use rcu_dereference on receive handler</title>
<updated>2006-06-18T04:26:04Z</updated>
<author>
<name>Stephen Hemminger</name>
<email>shemminger@osdl.org</email>
</author>
<published>2006-05-25T22:09:37Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=23dbe7912dad6be71bb9e69cb819d05e2442d362'/>
<id>urn:sha1:23dbe7912dad6be71bb9e69cb819d05e2442d362</id>
<content type='text'>
The receive hander pointer might be modified during network changes
of protocol. So use rcu_dereference (only matters on alpha).

Signed-off-by: Stephen Hemminger &lt;shemminger@osdl.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[LLC]: allow datagram recvmsg</title>
<updated>2006-06-18T04:26:02Z</updated>
<author>
<name>Stephen Hemminger</name>
<email>shemminger@osdl.org</email>
</author>
<published>2006-05-25T22:08:59Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=29efcd2666b3a465b40aa07ef1f4d79847303e2f'/>
<id>urn:sha1:29efcd2666b3a465b40aa07ef1f4d79847303e2f</id>
<content type='text'>
LLC receive is broken for SOCK_DGRAM.
If an application does recv() on a datagram socket and there
is no data present, don't return "not connected". Instead, just
do normal datagram semantics.

Signed-off-by: Stephen Hemminger &lt;shemminger@osdl.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[LLC]: use more efficient ether address routines</title>
<updated>2006-06-18T04:26:00Z</updated>
<author>
<name>Stephen Hemminger</name>
<email>shemminger@osdl.org</email>
</author>
<published>2006-05-25T22:08:30Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=aecbd4e45c2e469e0452ffb2c0b0d881e2815bb8'/>
<id>urn:sha1:aecbd4e45c2e469e0452ffb2c0b0d881e2815bb8</id>
<content type='text'>
Use more cache efficient Ethernet address manipulation functions
in etherdevice.h.

Signed-off-by: Stephen Hemminger &lt;shemminger@osdl.org&gt;
</content>
</entry>
</feed>
