<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v3.0.35</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.0.35</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.0.35'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2012-06-17T18:23:33+00:00</updated>
<entry>
<title>Linux 3.0.35</title>
<updated>2012-06-17T18:23:33+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2012-06-17T18:23:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=839cf7a236278ae358ff12141a168c0982fa0cd9'/>
<id>urn:sha1:839cf7a236278ae358ff12141a168c0982fa0cd9</id>
<content type='text'>
</content>
</entry>
<entry>
<title>hugetlb: fix resv_map leak in error path</title>
<updated>2012-06-17T18:23:13+00:00</updated>
<author>
<name>Dave Hansen</name>
<email>dave@linux.vnet.ibm.com</email>
</author>
<published>2012-05-29T22:06:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2209ffb965c6b17602aae5e637961e4f0f8a4162'/>
<id>urn:sha1:2209ffb965c6b17602aae5e637961e4f0f8a4162</id>
<content type='text'>
commit c50ac050811d6485616a193eb0f37bfbd191cc89 and
4523e1458566a0e8ecfaff90f380dd23acc44d27 upstream.

When called for anonymous (non-shared) mappings, hugetlb_reserve_pages()
does a resv_map_alloc().  It depends on code in hugetlbfs's
vm_ops-&gt;close() to release that allocation.

However, in the mmap() failure path, we do a plain unmap_region() without
the remove_vma() which actually calls vm_ops-&gt;close().

This is a decent fix.  This leak could get reintroduced if new code (say,
after hugetlb_reserve_pages() in hugetlbfs_file_mmap()) decides to return
an error.  But, I think it would have to unroll the reservation anyway.

Christoph's test case:

	http://marc.info/?l=linux-mm&amp;m=133728900729735

This patch applies to 3.4 and later.  A version for earlier kernels is at
https://lkml.org/lkml/2012/5/22/418.

Signed-off-by: Dave Hansen &lt;dave@linux.vnet.ibm.com&gt;
Acked-by: Mel Gorman &lt;mel@csn.ul.ie&gt;
Acked-by: KOSAKI Motohiro &lt;kosaki.motohiro@jp.fujitsu.com&gt;
Reported-by: Christoph Lameter &lt;cl@linux.com&gt;
Tested-by: Christoph Lameter &lt;cl@linux.com&gt;
Cc: Andrea Arcangeli &lt;aarcange@redhat.com&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@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>mm: fix faulty initialization in vmalloc_init()</title>
<updated>2012-06-17T18:23:13+00:00</updated>
<author>
<name>KyongHo</name>
<email>pullip.cho@samsung.com</email>
</author>
<published>2012-05-29T22:06:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c201beec4842674cd4773771931d25c9a5d45d66'/>
<id>urn:sha1:c201beec4842674cd4773771931d25c9a5d45d66</id>
<content type='text'>
commit dbda591d920b4c7692725b13e3f68ecb251e9080 upstream.

The transfer of -&gt;flags causes some of the static mapping virtual
addresses to be prematurely freed (before the mapping is removed) because
VM_LAZY_FREE gets "set" if tmp-&gt;flags has VM_IOREMAP set.  This might
cause subsequent vmalloc/ioremap calls to fail because it might allocate
one of the freed virtual address ranges that aren't unmapped.

va-&gt;flags has different types of flags from tmp-&gt;flags.  If a region with
VM_IOREMAP set is registered with vm_area_add_early(), it will be removed
by __purge_vmap_area_lazy().

Fix vmalloc_init() to correctly initialize vmap_area for the given
vm_struct.

Also initialise va-&gt;vm.  If it is not set, find_vm_area() for the early
vm regions will always fail.

Signed-off-by: KyongHo Cho &lt;pullip.cho@samsung.com&gt;
Cc: "Olav Haugan" &lt;ohaugan@codeaurora.org&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@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mm/vmalloc.c: change void* into explict vm_struct*</title>
<updated>2012-06-17T18:23:13+00:00</updated>
<author>
<name>Minchan Kim</name>
<email>minchan@kernel.org</email>
</author>
<published>2012-01-10T23:08:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5c2d31dda012797578d012425a785d58e14d2053'/>
<id>urn:sha1:5c2d31dda012797578d012425a785d58e14d2053</id>
<content type='text'>
commit db1aecafef58b5dda39c4228debe2c845e4a27ab upstream.

vmap_area-&gt;private is void* but we don't use the field for various purpose
but use only for vm_struct.  So change it to a vm_struct* with naming to
improve for readability and type checking.

Signed-off-by: Minchan Kim &lt;minchan@kernel.org&gt;
Acked-by: David Rientjes &lt;rientjes@google.com&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@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>e1000: save skb counts in TX to avoid cache misses</title>
<updated>2012-06-17T18:23:12+00:00</updated>
<author>
<name>Dean Nelson</name>
<email>dnelson@redhat.com</email>
</author>
<published>2011-08-25T14:39:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=52f81dc563e58bfbd22f1b0e2037da855a26b995'/>
<id>urn:sha1:52f81dc563e58bfbd22f1b0e2037da855a26b995</id>
<content type='text'>
commit 31c15a2f24ebdab14333d9bf5df49757842ae2ec upstream.

Virtual Machines with emulated e1000 network adapter running on Parallels'
server were seeing kernel panics due to the e1000 driver dereferencing an
unexpected NULL pointer retrieved from buffer_info-&gt;skb.

The problem has been addressed for the e1000e driver, but not for the e1000.
Since the two drivers share similar code in the affected area, a port of the
following e1000e driver commit solves the issue for the e1000 driver:

commit 9ed318d546a29d7a591dbe648fd1a2efe3be1180
Author: Tom Herbert &lt;therbert@google.com&gt;
Date:   Wed May 5 14:02:27 2010 +0000

    e1000e: save skb counts in TX to avoid cache misses

    In e1000_tx_map, precompute number of segements and bytecounts which
    are derived from fields in skb; these are stored in buffer_info.  When
    cleaning tx in e1000_clean_tx_irq use the values in the associated
    buffer_info for statistics counting, this eliminates cache misses
    on skb fields.

Signed-off-by: Dean Nelson &lt;dnelson@redhat.com&gt;
Acked-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Roman Kagan &lt;rkagan@parallels.com&gt;

</content>
</entry>
<entry>
<title>fuse: fix stat call on 32 bit platforms</title>
<updated>2012-06-17T18:23:12+00:00</updated>
<author>
<name>Pavel Shilovsky</name>
<email>piastry@etersoft.ru</email>
</author>
<published>2012-05-10T15:49:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6140710c5dba509a20b26dfe38b58f40baf2a2c8'/>
<id>urn:sha1:6140710c5dba509a20b26dfe38b58f40baf2a2c8</id>
<content type='text'>
commit 45c72cd73c788dd18c8113d4a404d6b4a01decf1 upstream.

Now we store attr-&gt;ino at inode-&gt;i_ino, return attr-&gt;ino at the
first time and then return inode-&gt;i_ino if the attribute timeout
isn't expired. That's wrong on 32 bit platforms because attr-&gt;ino
is 64 bit and inode-&gt;i_ino is 32 bit in this case.

Fix this by saving 64 bit ino in fuse_inode structure and returning
it every time we call getattr. Also squash attr-&gt;ino into inode-&gt;i_ino
explicitly.

Signed-off-by: Pavel Shilovsky &lt;piastry@etersoft.ru&gt;
Signed-off-by: Miklos Szeredi &lt;mszeredi@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>x86, MCE, AMD: Make APIC LVT thresholding interrupt optional</title>
<updated>2012-06-17T18:23:12+00:00</updated>
<author>
<name>Borislav Petkov</name>
<email>borislav.petkov@amd.com</email>
</author>
<published>2012-04-16T16:01:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=33b3689af55ddec6efd608bd82f09a83e4e4042c'/>
<id>urn:sha1:33b3689af55ddec6efd608bd82f09a83e4e4042c</id>
<content type='text'>
commit f227d4306cf30e1d5b6f231e8ef9006c34f3d186 upstream.

Currently, the APIC LVT interrupt for error thresholding is implicitly
enabled. However, there are models in the F15h range which do not enable
it. Make the code machinery which sets up the APIC interrupt support
an optional setting and add an -&gt;interrupt_capable member to the bank
representation mirroring that capability and enable the interrupt offset
programming only if it is true.

Simplify code and fixup comment style while at it.

Signed-off-by: Borislav Petkov &lt;borislav.petkov@amd.com&gt;
Signed-off-by: Robert Richter &lt;robert.richter@amd.com&gt;


</content>
</entry>
<entry>
<title>iwlwifi: don't mess up the SCD when removing a key</title>
<updated>2012-06-17T18:23:12+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2012-06-06T07:13:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e2b55892ceb923d9ff6c204e59be5f2b43a0009c'/>
<id>urn:sha1:e2b55892ceb923d9ff6c204e59be5f2b43a0009c</id>
<content type='text'>
commit d6ee27eb13beab94056e0de52d81220058ca2297 upstream.

When we remove a key, we put a key index which was supposed
to tell the fw that we are actually removing the key. But
instead the fw took that index as a valid index and messed
up the SRAM of the device.

This memory corruption on the device mangled the data of
the SCD. The impact on the user is that SCD queue 2 got
stuck after having removed keys.
The message is the log that was printed is:

Queue 2 stuck for 10000ms

This doesn't seem to fix the higher queues that get stuck
from time to time.

Reviewed-by: Meenakshi Venkataraman &lt;meenakshi.venkataraman@intel.com&gt;
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>sched: Fix the relax_domain_level boot parameter</title>
<updated>2012-06-17T18:23:12+00:00</updated>
<author>
<name>Dimitri Sivanich</name>
<email>sivanich@sgi.com</email>
</author>
<published>2012-06-05T18:44:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=34b1a9eb1db3de73460f3a21d8ffb48ea7cbd338'/>
<id>urn:sha1:34b1a9eb1db3de73460f3a21d8ffb48ea7cbd338</id>
<content type='text'>
commit a841f8cef4bb124f0f5563314d0beaf2e1249d72 upstream.

It does not get processed because sched_domain_level_max is 0 at the
time that setup_relax_domain_level() is run.

Simply accept the value as it is, as we don't know the value of
sched_domain_level_max until sched domain construction is completed.

Fix sched_relax_domain_level in cpuset.  The build_sched_domain() routine calls
the set_domain_attribute() routine prior to setting the sd-&gt;level, however,
the set_domain_attribute() routine relies on the sd-&gt;level to decide whether
idle load balancing will be off/on.

Signed-off-by: Dimitri Sivanich &lt;sivanich@sgi.com&gt;
Signed-off-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Link: http://lkml.kernel.org/r/20120605184436.GA15668@sgi.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>acpi_video: fix leaking PCI references</title>
<updated>2012-06-17T18:23:11+00:00</updated>
<author>
<name>Alan Cox</name>
<email>alan@linux.intel.com</email>
</author>
<published>2012-04-25T13:33:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ae797dcdae86481103b6ed79d97ac09e57e2feef'/>
<id>urn:sha1:ae797dcdae86481103b6ed79d97ac09e57e2feef</id>
<content type='text'>
commit cfb46f433a4da97c31780e08a259fac2cb6bd61f upstream.

Signed-off-by: Alan Cox &lt;alan@linux.intel.com&gt;
Acked-by: Matthew Garrett &lt;mjg@redhat.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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