<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/include, branch v2.6.32.27</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/include?h=v2.6.32.27</id>
<link rel='self' href='https://git.amat.us/linux/atom/include?h=v2.6.32.27'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2010-12-09T21:27:13Z</updated>
<entry>
<title>net: Limit socket I/O iovec total length to INT_MAX.</title>
<updated>2010-12-09T21:27:13Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2010-10-28T18:41:55Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f342cb14f58813fe972a152b5034306a08c2de70'/>
<id>urn:sha1:f342cb14f58813fe972a152b5034306a08c2de70</id>
<content type='text'>
commit 8acfe468b0384e834a303f08ebc4953d72fb690a upstream.

This helps protect us from overflow issues down in the
individual protocol sendmsg/recvmsg handlers.  Once
we hit INT_MAX we truncate out the rest of the iovec
by setting the iov_len members to zero.

This works because:

1) For SOCK_STREAM and SOCK_SEQPACKET sockets, partial
   writes are allowed and the application will just continue
   with another write to send the rest of the data.

2) For datagram oriented sockets, where there must be a
   one-to-one correspondance between write() calls and
   packets on the wire, INT_MAX is going to be far larger
   than the packet size limit the protocol is going to
   check for and signal with -EMSGSIZE.

Based upon a patch by Linus Torvalds.

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>x25: Patch to fix bug 15678 - x25 accesses fields beyond end of packet.</title>
<updated>2010-12-09T21:27:09Z</updated>
<author>
<name>John Hughes</name>
<email>john@calva.com</email>
</author>
<published>2010-04-08T04:29:25Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7281524c6476cbb85cd5156bde7c12df793bfeb3'/>
<id>urn:sha1:7281524c6476cbb85cd5156bde7c12df793bfeb3</id>
<content type='text'>
commit f5eb917b861828da18dc28854308068c66d1449a upstream.

Here is a patch to stop X.25 examining fields beyond the end of the packet.

For example, when a simple CALL ACCEPTED was received:

	10 10 0f

x25_parse_facilities was attempting to decode the FACILITIES field, but this
packet contains no facilities field.

Signed-off-by: John Hughes &lt;john@calva.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>ssb: b43-pci-bridge: Add new vendor for BCM4318</title>
<updated>2010-12-09T21:26:41Z</updated>
<author>
<name>Daniel Klaffenbach</name>
<email>danielklaffenbach@gmail.com</email>
</author>
<published>2010-11-20T03:25:21Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0b5059be74532f799ba09bfa6dfb6f11e98fdb17'/>
<id>urn:sha1:0b5059be74532f799ba09bfa6dfb6f11e98fdb17</id>
<content type='text'>
commit 1d8638d4038eb8709edc80e37a0bbb77253d86e9 upstream.

Add new vendor for Broadcom 4318.

Signed-off-by: Daniel Klaffenbach &lt;danielklaffenbach@gmail.com&gt;
Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>ahci,ata_generic: let ata_generic handle new MBP w/ MCP89</title>
<updated>2010-12-09T21:26:40Z</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2010-06-17T09:42:22Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=12683d690b40c7f76dd921a624c3879b49ab8bbd'/>
<id>urn:sha1:12683d690b40c7f76dd921a624c3879b49ab8bbd</id>
<content type='text'>
commit c6353b4520788e34098bbf61c73fb9618ca7fdd6 upstream.

For yet unknown reason, MCP89 on MBP 7,1 doesn't work w/ ahci under
linux but the controller doesn't require explicit mode setting and
works fine with ata_generic.  Make ahci ignore the controller on MBP
7,1 and let ata_generic take it for now.

Reported in bko#15923.

  https://bugzilla.kernel.org/show_bug.cgi?id=15923

NVIDIA is investigating why ahci mode doesn't work.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Cc: Peer Chen &lt;pchen@nvidia.com&gt;
Reported-by: Anders Østhus &lt;grapz666@gmail.com&gt;
Reported-by: Andreas Graf &lt;andreas_graf@csgraf.de&gt;
Reported-by: Benoit Gschwind &lt;gschwind@gnu-log.net&gt;
Reported-by: Damien Cassou &lt;damien.cassou@gmail.com&gt;
Reported-by: tixetsal@juno.com
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Cc: Nobuhiro Iwamatsu &lt;iwamatsu@nigauri.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>block: Ensure physical block size is unsigned int</title>
<updated>2010-12-09T21:26:28Z</updated>
<author>
<name>Martin K. Petersen</name>
<email>martin.petersen@oracle.com</email>
</author>
<published>2010-10-13T19:18:03Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a4340113f9a3a4ebcbf988f1c1a27c07d70185b9'/>
<id>urn:sha1:a4340113f9a3a4ebcbf988f1c1a27c07d70185b9</id>
<content type='text'>
commit 892b6f90db81cccb723d5d92f4fddc2d68b206e1 upstream.

Physical block size was declared unsigned int to accomodate the maximum
size reported by READ CAPACITY(16).  Make sure we use the right type in
the related functions.

Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Acked-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;jaxboe@fusionio.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>mm: Move vma_stack_continue into mm.h</title>
<updated>2010-10-29T04:44:18Z</updated>
<author>
<name>Stefan Bader</name>
<email>stefan.bader@canonical.com</email>
</author>
<published>2010-08-31T13:52:27Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=78b8fca43dc4f315aa0b59b788902a4b60bee93d'/>
<id>urn:sha1:78b8fca43dc4f315aa0b59b788902a4b60bee93d</id>
<content type='text'>
commit 39aa3cb3e8250db9188a6f1e3fb62ffa1a717678 upstream.

So it can be used by all that need to check for that.

Signed-off-by: Stefan Bader &lt;stefan.bader@canonical.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>tcp: Fix &gt;4GB writes on 64-bit.</title>
<updated>2010-10-29T04:44:07Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2010-09-28T03:24:54Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=237a9f8f234fde5441f1102b8820b8425f4c1e16'/>
<id>urn:sha1:237a9f8f234fde5441f1102b8820b8425f4c1e16</id>
<content type='text'>
[ Upstream commit 01db403cf99f739f86903314a489fb420e0e254f ]

Fixes kernel bugzilla #16603

tcp_sendmsg() truncates iov_len to an 'int' which a 4GB write to write
zero bytes, for example.

There is also the problem higher up of how verify_iovec() works.  It
wants to prevent the total length from looking like an error return
value.

However it does this using 'int', but syscalls return 'long' (and
thus signed 64-bit on 64-bit machines).  So it could trigger
false-positives on 64-bit as written.  So fix it to use 'long'.

Reported-by: Olaf Bonorden &lt;bono@onlinehome.de&gt;
Reported-by: Daniel Büse &lt;dbuese@gmx.de&gt;
Reported-by: Andrew Morton &lt;akpm@linux-foundation.org&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>drm/radeon: fix PCI ID 5657 to be an RV410</title>
<updated>2010-10-29T04:44:06Z</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2010-09-25T07:45:50Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=94210a7fc93031ec4994e6cf566d3ec561549472'/>
<id>urn:sha1:94210a7fc93031ec4994e6cf566d3ec561549472</id>
<content type='text'>
commit f459ffbdfd04edb4a8ce6eea33170eb057a5e695 upstream.

fixes https://bugzilla.kernel.org/show_bug.cgi?id=19012

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>x86/amd-iommu: Work around S3 BIOS bug</title>
<updated>2010-10-29T04:43:57Z</updated>
<author>
<name>Joerg Roedel</name>
<email>joerg.roedel@amd.com</email>
</author>
<published>2010-09-23T13:15:19Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=9be2cbb804d686835ce738ea633d9517b9735c39'/>
<id>urn:sha1:9be2cbb804d686835ce738ea633d9517b9735c39</id>
<content type='text'>
commit 4c894f47bb49284008073d351c0ddaac8860864e upstream.

This patch adds a workaround for an IOMMU BIOS problem to
the AMD IOMMU driver. The result of the bug is that the
IOMMU does not execute commands anymore when the system
comes out of the S3 state resulting in system failure. The
bug in the BIOS is that is does not restore certain hardware
specific registers correctly. This workaround reads out the
contents of these registers at boot time and restores them
on resume from S3. The workaround is limited to the specific
IOMMU chipset where this problem occurs.

Signed-off-by: Joerg Roedel &lt;joerg.roedel@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>guard page for stacks that grow upwards</title>
<updated>2010-09-27T00:21:34Z</updated>
<author>
<name>Luck, Tony</name>
<email>tony.luck@intel.com</email>
</author>
<published>2010-08-24T18:44:18Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c837b58c0ea48760cc83a2e3ffddd92ac88dd156'/>
<id>urn:sha1:c837b58c0ea48760cc83a2e3ffddd92ac88dd156</id>
<content type='text'>
commit 8ca3eb08097f6839b2206e2242db4179aee3cfb3 upstream.

pa-risc and ia64 have stacks that grow upwards. Check that
they do not run into other mappings. By making VM_GROWSUP
0x0 on architectures that do not ever use it, we can avoid
some unpleasant #ifdefs in check_stack_guard_page().

Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: dann frazier &lt;dannf@debian.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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