<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/include, branch v2.6.32.26</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/include?h=v2.6.32.26</id>
<link rel='self' href='https://git.amat.us/linux/atom/include?h=v2.6.32.26'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2010-10-29T04:44:18Z</updated>
<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>
<entry>
<title>mm: page allocator: calculate a better estimate of NR_FREE_PAGES when memory is low and kswapd is awake</title>
<updated>2010-09-27T00:21:34Z</updated>
<author>
<name>Christoph Lameter</name>
<email>cl@linux.com</email>
</author>
<published>2010-09-09T23:38:17Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c2222d66adedc567318a7c288726363daeb3374b'/>
<id>urn:sha1:c2222d66adedc567318a7c288726363daeb3374b</id>
<content type='text'>
commit aa45484031ddee09b06350ab8528bfe5b2c76d1c upstream.

Ordinarily watermark checks are based on the vmstat NR_FREE_PAGES as it is
cheaper than scanning a number of lists.  To avoid synchronization
overhead, counter deltas are maintained on a per-cpu basis and drained
both periodically and when the delta is above a threshold.  On large CPU
systems, the difference between the estimated and real value of
NR_FREE_PAGES can be very high.  If NR_FREE_PAGES is much higher than
number of real free page in buddy, the VM can allocate pages below min
watermark, at worst reducing the real number of pages to zero.  Even if
the OOM killer kills some victim for freeing memory, it may not free
memory if the exit path requires a new page resulting in livelock.

This patch introduces a zone_page_state_snapshot() function (courtesy of
Christoph) that takes a slightly more accurate view of an arbitrary vmstat
counter.  It is used to read NR_FREE_PAGES while kswapd is awake to avoid
the watermark being accidentally broken.  The estimate is not perfect and
may result in cache line bounces but is expected to be lighter than the
IPI calls necessary to continually drain the per-cpu counters while kswapd
is awake.

Signed-off-by: Christoph Lameter &lt;cl@linux.com&gt;
Signed-off-by: Mel Gorman &lt;mel@csn.ul.ie&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&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: Prevent overzealous packetization by SWS logic.</title>
<updated>2010-09-27T00:21:20Z</updated>
<author>
<name>Alexey Kuznetsov</name>
<email>kuznet@ms2.inr.ac.ru</email>
</author>
<published>2010-09-15T17:27:52Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=36f2140e8f572790a71899e9db7ff6f2986987cd'/>
<id>urn:sha1:36f2140e8f572790a71899e9db7ff6f2986987cd</id>
<content type='text'>
[ Upstream commit 01f83d69844d307be2aa6fea88b0e8fe5cbdb2f4 ]

If peer uses tiny MSS (say, 75 bytes) and similarly tiny advertised
window, the SWS logic will packetize to half the MSS unnecessarily.

This causes problems with some embedded devices.

However for large MSS devices we do want to half-MSS packetize
otherwise we never get enough packets into the pipe for things
like fast retransmit and recovery to work.

Be careful also to handle the case where MSS &gt; window, otherwise
we'll never send until the probe timer.

Reported-by: ツ Leandro Melo de Sales &lt;leandroal@gmail.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>tcp: Combat per-cpu skew in orphan tests.</title>
<updated>2010-09-27T00:21:17Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2010-08-25T09:27:49Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a89d316f2bdf5df8f9a109d32f0e7b0940041e7f'/>
<id>urn:sha1:a89d316f2bdf5df8f9a109d32f0e7b0940041e7f</id>
<content type='text'>
[ Upstream commit ad1af0fedba14f82b240a03fe20eb9b2fdbd0357 ]

As reported by Anton Blanchard when we use
percpu_counter_read_positive() to make our orphan socket limit checks,
the check can be off by up to num_cpus_online() * batch (which is 32
by default) which on a 128 cpu machine can be as large as the default
orphan limit itself.

Fix this by doing the full expensive sum check if the optimized check
triggers.

Reported-by: Anton Blanchard &lt;anton@samba.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Acked-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
</entry>
<entry>
<title>sched: Pre-compute cpumask_weight(sched_domain_span(sd))</title>
<updated>2010-09-20T20:18:11Z</updated>
<author>
<name>Peter Zijlstra</name>
<email>a.p.zijlstra@chello.nl</email>
</author>
<published>2010-04-16T12:59:29Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6efd9bbce0d4b02d295f28054caa74e6edf811b7'/>
<id>urn:sha1:6efd9bbce0d4b02d295f28054caa74e6edf811b7</id>
<content type='text'>
commit 669c55e9f99b90e46eaa0f98a67ec53d46dc969a upstream

Dave reported that his large SPARC machines spend lots of time in
hweight64(), try and optimize some of those needless cpumask_weight()
invocations (esp. with the large offstack cpumasks these are very
expensive indeed).

Reported-by: David Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
LKML-Reference: &lt;new-submission&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Mike Galbraith &lt;efault@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
</entry>
<entry>
<title>sched: Fix vmark regression on big machines</title>
<updated>2010-09-20T20:18:11Z</updated>
<author>
<name>Mike Galbraith</name>
<email>efault@gmx.de</email>
</author>
<published>2010-01-04T13:44:56Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b971284b4af79650f4d7f4caae21c824be3dd7fb'/>
<id>urn:sha1:b971284b4af79650f4d7f4caae21c824be3dd7fb</id>
<content type='text'>
commit 50b926e439620c469565e8be0f28be78f5fca1ce upstream

SD_PREFER_SIBLING is set at the CPU domain level if power saving isn't
enabled, leading to many cache misses on large machines as we traverse
looking for an idle shared cache to wake to.  Change the enabler of
select_idle_sibling() to SD_SHARE_PKG_RESOURCES, and enable same at the
sibling domain level.

Reported-by: Lin Ming &lt;ming.m.lin@intel.com&gt;
Signed-off-by: Mike Galbraith &lt;efault@gmx.de&gt;
Signed-off-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
LKML-Reference: &lt;1262612696.15495.15.camel@marge.simson.net&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
</entry>
</feed>
