<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/net/pppoe.c, branch linux-2.6.22.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.22.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.22.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2007-04-26T05:29:21Z</updated>
<entry>
<title>[PPPOE]: Fix device tear-down notification.</title>
<updated>2007-04-26T05:29:21Z</updated>
<author>
<name>Michal Ostrowski</name>
</author>
<published>2007-04-20T23:59:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=42dc9cd54b7290f862874a2544e50395e5719985'/>
<id>urn:sha1:42dc9cd54b7290f862874a2544e50395e5719985</id>
<content type='text'>
pppoe_flush_dev() kicks all sockets bound to a device that is going down.
In doing so, locks must be taken in the right order consistently (sock lock,
followed by the pppoe_hash_lock).  However, the scan process is based on
us holding the sock lock.  So, when something is found in the scan we must
release the lock we're holding and grab the sock lock.

This patch fixes race conditions between this code and pppoe_release(),
both of which perform similar functions but would naturally prefer to grab
locks in opposing orders.  Both code paths are now going after these locks
in a consistent manner.

pppoe_hash_lock protects the contents of the "pppox_sock" objects that reside
inside the hash.  Thus, NULL'ing out the pppoe_dev field should be done
under the protection of this lock.

Signed-off-by: Michal Ostrowski &lt;mostrows@earthlink.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[PPPOE]: race between interface going down and connect()</title>
<updated>2007-04-26T05:29:19Z</updated>
<author>
<name>Florian Zumbiehl</name>
</author>
<published>2007-04-20T23:57:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=74b885cf86def9bc836772e3c1788c00b72a35c9'/>
<id>urn:sha1:74b885cf86def9bc836772e3c1788c00b72a35c9</id>
<content type='text'>
below you find a patch that (hopefully) fixes a race between an interface
going down and a connect() to a peer on that interface. Before,
connect() would determine that an interface is up, then the interface
could go down and all entries referring to that interface in the
item_hash_table would be marked as ZOMBIEs and their references to
the device would be freed, and after that, connect() would put a new
entry into the hash table referring to the device that meanwhile is
down already - which also would cause unregister_netdevice() to wait
until the socket has been release()d.

This patch does not suffice if we are not allowed to accept connect()s
referring to a device that we already acked a NETDEV_GOING_DOWN for
(that is: all references are only guaranteed to be freed after
NETDEV_DOWN has been acknowledged, not necessarily after the
NETDEV_GOING_DOWN already). And if we are allowed to, we could avoid
looking through the hash table upon NETDEV_GOING_DOWN completely and
only do that once we get the NETDEV_DOWN ...

mostrows:
pppoe_flush_dev is called on NETDEV_GOING_DOWN and NETDEV_DOWN to deal with
this "late connect" issue.  Ideally one would hope to notify users at the
"NETDEV_GOING_DOWN" phase (just to pretend to be nice).  However, it is the
NETDEV_DOWN scan that takes all the responsibility for ensuring nobody is
hanging around at that time.

Signed-off-by: Florian Zumbiehl &lt;florz@florz.de&gt;
Acked-by: Michal Ostrowski &lt;mostrows@earthlink.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[PPPoE]: miscellaneous smaller cleanups</title>
<updated>2007-04-26T05:29:18Z</updated>
<author>
<name>Florian Zumbiehl</name>
</author>
<published>2007-04-20T23:56:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bfafb26e11849fe99e03cc1902a91f7f65354e47'/>
<id>urn:sha1:bfafb26e11849fe99e03cc1902a91f7f65354e47</id>
<content type='text'>
below is a patch that just removes dead code/initializers without any
effect (first access is an assignment) that I stumbled accross while
reading the source.

Signed-off-by: Florian Zumbiehl &lt;florz@florz.de&gt;
Acked-by: Michal Ostrowski &lt;mostrows@earthlink.net&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>[SK_BUFF]: Introduce skb_reset_network_header(skb)</title>
<updated>2007-04-26T05:24:46Z</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
</author>
<published>2007-04-11T03:45:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c1d2bbe1cd6c7bbdc6d532cefebb66c7efb789ce'/>
<id>urn:sha1:c1d2bbe1cd6c7bbdc6d532cefebb66c7efb789ce</id>
<content type='text'>
For the common, open coded 'skb-&gt;nh.raw = skb-&gt;data' operation, so that we can
later turn skb-&gt;nh.raw into a offset, reducing the size of struct sk_buff in
64bit land while possibly keeping it as a pointer on 32bit.

This one touches just the most simple case, next will handle the slightly more
"complex" cases.

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>
<entry>
<title>[PPPOE]: Introduce pppoe_hdr()</title>
<updated>2007-04-26T05:24:43Z</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
</author>
<published>2007-03-10T18:56:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=797659fb4a4a511649cd71028141c32ad1698a12'/>
<id>urn:sha1:797659fb4a4a511649cd71028141c32ad1698a12</id>
<content type='text'>
For consistency with all the other skb-&gt;nh.raw accessors.

Also do some really obvious simplifications in pppoe_recvmsg, well the
kfree_skb one is not so obvious, but free() and kfree() have the same behaviour
(hint :-) ).

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>
<entry>
<title>[PPPOE]: Use ifindex instead of device pointer in key lookups.</title>
<updated>2007-03-05T21:25:28Z</updated>
<author>
<name>Florian Zumbiehl</name>
</author>
<published>2007-03-05T00:03:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6f30e1867cb73602c6ed7f97e15a48e0a0c96cde'/>
<id>urn:sha1:6f30e1867cb73602c6ed7f97e15a48e0a0c96cde</id>
<content type='text'>
Otherwise we can potentially try to dereference a NULL device
pointer in some cases.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[PPPOE]: Key connections properly on local device.</title>
<updated>2007-03-03T04:37:35Z</updated>
<author>
<name>Florian Zumbiehl</name>
</author>
<published>2007-03-02T21:16:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=90719dbeafdb40a15105ff0c899485b43c2a2a55'/>
<id>urn:sha1:90719dbeafdb40a15105ff0c899485b43c2a2a55</id>
<content type='text'>
It is based on the assumption that an interface's ifindex is basically
an alias for a local MAC address, so incoming packets now are matched
to sockets based on remote MAC, session id, and ifindex of the
interface the packet came in on/the socket was bound to by connect().

For relayed packets, the socket that's used for relaying is selected
based on destination MAC, session ID and the interface index of the
interface whose name currently matches the name requested by userspace
as the relaying source interface.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[PATCH] mark struct file_operations const 5</title>
<updated>2007-02-12T17:48:45Z</updated>
<author>
<name>Arjan van de Ven</name>
</author>
<published>2007-02-12T08:55:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d54b1fdb1d9f82e375a299e22bd366aad52d4c34'/>
<id>urn:sha1:d54b1fdb1d9f82e375a299e22bd366aad52d4c34</id>
<content type='text'>
Many struct file_operations in the kernel can be "const".  Marking them const
moves these to the .rodata section, which avoids false sharing with potential
dirty data.  In addition it'll catch accidental writes at compile time to
these shared resources.

Signed-off-by: Arjan van de Ven &lt;arjan@linux.intel.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>[NET]: Conditionally use bh_lock_sock_nested in sk_receive_skb</title>
<updated>2006-12-03T05:23:51Z</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
</author>
<published>2006-11-16T16:06:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=58a5a7b9555ea231b557ebef5cabeaf8e951df0b'/>
<id>urn:sha1:58a5a7b9555ea231b557ebef5cabeaf8e951df0b</id>
<content type='text'>
Spotted by Ian McDonald, tentatively fixed by Gerrit Renker:

http://www.mail-archive.com/dccp%40vger.kernel.org/msg00599.html

Rewritten not to unroll sk_receive_skb, in the common case, i.e. no lock
debugging, its optimized away.

Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@mandriva.com&gt;
</content>
</entry>
</feed>
