<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/include, branch v2.6.33.19</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/include?h=v2.6.33.19</id>
<link rel='self' href='https://git.amat.us/linux/atom/include?h=v2.6.33.19'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2011-08-16T02:01:54Z</updated>
<entry>
<title>net: Compute protocol sequence numbers and fragment IDs using MD5.</title>
<updated>2011-08-16T02:01:54Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2011-08-04T03:50:44Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4f92dd0dba4a3000b7ce3a7dfbe2be1ffbeb2bd1'/>
<id>urn:sha1:4f92dd0dba4a3000b7ce3a7dfbe2be1ffbeb2bd1</id>
<content type='text'>
Computers have become a lot faster since we compromised on the
partial MD4 hash which we use currently for performance reasons.

MD5 is a much safer choice, and is inline with both RFC1948 and
other ISS generators (OpenBSD, Solaris, etc.)

Furthermore, only having 24-bits of the sequence number be truly
unpredictable is a very serious limitation.  So the periodic
regeneration and 8-bit counter have been removed.  We compute and
use a full 32-bit sequence number.

For ipv6, DCCP was found to use a 32-bit truncated initial sequence
number (it needs 43-bits) and that is fixed here as well.

Reported-by: Dan Kaminsky &lt;dan@doxpara.com&gt;
Tested-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
</entry>
<entry>
<title>crypto: Move md5_transform to lib/md5.c</title>
<updated>2011-08-16T02:01:54Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2011-08-04T02:45:10Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3f77dab7c5fa1cde0139e85ff33d7ee5875f1371'/>
<id>urn:sha1:3f77dab7c5fa1cde0139e85ff33d7ee5875f1371</id>
<content type='text'>
We are going to use this for TCP/IP sequence number and fragment ID
generation.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
</entry>
<entry>
<title>drm/i915: Fix typo in DRM_I915_OVERLAY_PUT_IMAGE ioctl define</title>
<updated>2011-08-08T17:36:11Z</updated>
<author>
<name>Ole Henrik Jahren</name>
<email>olehenja@alumni.ntnu.no</email>
</author>
<published>2011-07-22T13:56:01Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8b65599076036bbb2830391b0ca00f2d9f4bd5ce'/>
<id>urn:sha1:8b65599076036bbb2830391b0ca00f2d9f4bd5ce</id>
<content type='text'>
commit 842d452985300f4ec14c68cb86046e8a1a3b7251 upstream.

Because of a typo, calling ioctl with DRM_IOCTL_I915_OVERLAY_PUT_IMAGE
is broken if the macro is used directly. When using libdrm the bug is
not hit, since libdrm handles the ioctl encoding internally.

The typo also leads to the .cmd and .cmd_drv fields of the drm_ioctl
structure for DRM_I915_OVERLAY_PUT_IMAGE having inconsistent content.

Signed-off-by: Ole Henrik Jahren &lt;olehenja@alumni.ntnu.no&gt;
Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Keith Packard &lt;keithp@keithp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>gro: Only reset frag0 when skb can be pulled</title>
<updated>2011-08-08T17:35:52Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2011-07-27T13:16:28Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d2b8665554f9c074e7290801584b1a1a82d2ed27'/>
<id>urn:sha1:d2b8665554f9c074e7290801584b1a1a82d2ed27</id>
<content type='text'>
commit 17dd759c67f21e34f2156abcf415e1f60605a188 upstream.

Currently skb_gro_header_slow unconditionally resets frag0 and
frag0_len.  However, when we can't pull on the skb this leaves
the GRO fields in an inconsistent state.

This patch fixes this by only resetting those fields after the
pskb_may_pull test.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>mm: prevent concurrent unmap_mapping_range() on the same inode</title>
<updated>2011-07-13T03:31:27Z</updated>
<author>
<name>Miklos Szeredi</name>
<email>mszeredi@suse.cz</email>
</author>
<published>2011-02-23T12:49:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7cf46ba5d43e2596e559df7988eaf7ada966a6c8'/>
<id>urn:sha1:7cf46ba5d43e2596e559df7988eaf7ada966a6c8</id>
<content type='text'>
commit 2aa15890f3c191326678f1bd68af61ec6b8753ec upstream.

Michael Leun reported that running parallel opens on a fuse filesystem
can trigger a "kernel BUG at mm/truncate.c:475"

Gurudas Pai reported the same bug on NFS.

The reason is, unmap_mapping_range() is not prepared for more than
one concurrent invocation per inode.  For example:

  thread1: going through a big range, stops in the middle of a vma and
     stores the restart address in vm_truncate_count.

  thread2: comes in with a small (e.g. single page) unmap request on
     the same vma, somewhere before restart_address, finds that the
     vma was already unmapped up to the restart address and happily
     returns without doing anything.

Another scenario would be two big unmap requests, both having to
restart the unmapping and each one setting vm_truncate_count to its
own value.  This could go on forever without any of them being able to
finish.

Truncate and hole punching already serialize with i_mutex.  Other
callers of unmap_mapping_range() do not, and it's difficult to get
i_mutex protection for all callers.  In particular -&gt;d_revalidate(),
which calls invalidate_inode_pages2_range() in fuse, may be called
with or without i_mutex.

This patch adds a new mutex to 'struct address_space' to prevent
running multiple concurrent unmap_mapping_range() on the same mapping.

[ We'll hopefully get rid of all this with the upcoming mm
  preemptibility series by Peter Zijlstra, the "mm: Remove i_mmap_mutex
  lockbreak" patch in particular.  But that is for 2.6.39 ]

Signed-off-by: Miklos Szeredi &lt;mszeredi@suse.cz&gt;
Reported-by: Michael Leun &lt;lkml20101129@newton.leun.net&gt;
Reported-by: Gurudas Pai &lt;gurudas.pai@oracle.com&gt;
Tested-by: Gurudas Pai &lt;gurudas.pai@oracle.com&gt;
Acked-by: Hugh Dickins &lt;hughd@google.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>af_packet: prevent information leak</title>
<updated>2011-07-13T03:31:27Z</updated>
<author>
<name>Eric Dumazet</name>
<email>eric.dumazet@gmail.com</email>
</author>
<published>2011-06-07T05:42:06Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=26d3cbdece9463926d553dbeed3df10af22bb161'/>
<id>urn:sha1:26d3cbdece9463926d553dbeed3df10af22bb161</id>
<content type='text'>
[ Upstream commit 13fcb7bd322164c67926ffe272846d4860196dc6 ]

In 2.6.27, commit 393e52e33c6c2 (packet: deliver VLAN TCI to userspace)
added a small information leak.

Add padding field and make sure its zeroed before copy to user.

Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
CC: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
</entry>
<entry>
<title>bug.h: Add WARN_RATELIMIT</title>
<updated>2011-07-13T03:31:26Z</updated>
<author>
<name>Joe Perches</name>
<email>joe@perches.com</email>
</author>
<published>2011-05-21T07:48:39Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7cad013caa9a0f16f47b1b5139b67bdf1bf5c7d1'/>
<id>urn:sha1:7cad013caa9a0f16f47b1b5139b67bdf1bf5c7d1</id>
<content type='text'>
[ Upstream commit b3eec79b0776e5340a3db75b34953977c7e5086e ]

Add a generic mechanism to ratelimit WARN(foo, fmt, ...) messages
using a hidden per call site static struct ratelimit_state.

Also add an __WARN_RATELIMIT variant to be able to use a specific
struct ratelimit_state.

Signed-off-by: Joe Perches &lt;joe@perches.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
</entry>
<entry>
<title>netlink: Make nlmsg_find_attr take a const nlmsghdr*.</title>
<updated>2011-07-13T03:31:26Z</updated>
<author>
<name>Nelson Elhage</name>
<email>nelhage@ksplice.com</email>
</author>
<published>2010-11-03T16:35:40Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=29ee67cbbaac453bea60fcf843e91b9cb3f49874'/>
<id>urn:sha1:29ee67cbbaac453bea60fcf843e91b9cb3f49874</id>
<content type='text'>
commit 6b8c92ba07287578718335ce409de8e8d7217e40 upstream.

This will let us use it on a nlmsghdr stored inside a netlink_callback.

Signed-off-by: Nelson Elhage &lt;nelhage@ksplice.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>clocksource: Make watchdog robust vs. interruption</title>
<updated>2011-07-13T03:31:23Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2011-06-16T14:22:08Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=43b951e4185f3132e77e6340d1aed42e90618e4b'/>
<id>urn:sha1:43b951e4185f3132e77e6340d1aed42e90618e4b</id>
<content type='text'>
commit b5199515c25cca622495eb9c6a8a1d275e775088 upstream.

The clocksource watchdog code is interruptible and it has been
observed that this can trigger false positives which disable the TSC.

The reason is that an interrupt storm or a long running interrupt
handler between the read of the watchdog source and the read of the
TSC brings the two far enough apart that the delta is larger than the
unstable treshold. Move both reads into a short interrupt disabled
region to avoid that.

Reported-and-tested-by: Vernon Mauery &lt;vernux@us.ibm.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>pata_cm64x: fix boot crash on parisc</title>
<updated>2011-06-23T22:28:42Z</updated>
<author>
<name>James Bottomley</name>
<email>James.Bottomley@suse.de</email>
</author>
<published>2011-04-24T19:30:14Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d1ce81094e627b7d1f3b64ae3c727b4e8e63f2f4'/>
<id>urn:sha1:d1ce81094e627b7d1f3b64ae3c727b4e8e63f2f4</id>
<content type='text'>
commit 9281b16caac1276817b77033c5b8a1f5ca30102c upstream.

The old IDE cmd64x checks the status of the CNTRL register to see if
the ports are enabled before probing them.  pata_cmd64x doesn't do
this, which causes a HPMC on parisc when it tries to poke at the
secondary port because apparently the BAR isn't wired up (and a
non-responding piece of memory causes a HPMC).

Fix this by porting the CNTRL register port detection logic from IDE
cmd64x.  In addition, following converns from Alan Cox, add a check to
see if a mobility electronics bridge is the immediate parent and forgo
the check if it is (prevents problems on hotplug controllers).

Signed-off-by: James Bottomley &lt;James.Bottomley@suse.de&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@pobox.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
</feed>
