<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/arch, branch v3.5.1</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/arch?h=v3.5.1</id>
<link rel='self' href='https://git.amat.us/linux/atom/arch?h=v3.5.1'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2012-08-09T15:23:15Z</updated>
<entry>
<title>m68k: Make sys_atomic_cmpxchg_32 work on classic m68k</title>
<updated>2012-08-09T15:23:15Z</updated>
<author>
<name>Andreas Schwab</name>
<email>schwab@linux-m68k.org</email>
</author>
<published>2012-07-27T22:20:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=34fbbeb1bd9c5d68d136eeaba9b305bed45417f5'/>
<id>urn:sha1:34fbbeb1bd9c5d68d136eeaba9b305bed45417f5</id>
<content type='text'>
commit 9e2760d18b3cf179534bbc27692c84879c61b97c upstream.

User space access must always go through uaccess accessors, since on
classic m68k user space and kernel space are completely separate.

Signed-off-by: Andreas Schwab &lt;schwab@linux-m68k.org&gt;
Tested-by: Thorsten Glaser &lt;tg@debian.org&gt;
Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>posix_types.h: Cleanup stale __NFDBITS and related definitions</title>
<updated>2012-08-09T15:23:11Z</updated>
<author>
<name>Josh Boyer</name>
<email>jwboyer@redhat.com</email>
</author>
<published>2012-07-25T14:40:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f74a7c968090d6db642c70657c742bc313524e9b'/>
<id>urn:sha1:f74a7c968090d6db642c70657c742bc313524e9b</id>
<content type='text'>
commit 8ded2bbc1845e19c771eb55209aab166ef011243 upstream.

Recently, glibc made a change to suppress sign-conversion warnings in
FD_SET (glibc commit ceb9e56b3d1).  This uncovered an issue with the
kernel's definition of __NFDBITS if applications #include
&lt;linux/types.h&gt; after including &lt;sys/select.h&gt;.  A build failure would
be seen when passing the -Werror=sign-compare and -D_FORTIFY_SOURCE=2
flags to gcc.

It was suggested that the kernel should either match the glibc
definition of __NFDBITS or remove that entirely.  The current in-kernel
uses of __NFDBITS can be replaced with BITS_PER_LONG, and there are no
uses of the related __FDELT and __FDMASK defines.  Given that, we'll
continue the cleanup that was started with commit 8b3d1cda4f5f
("posix_types: Remove fd_set macros") and drop the remaining unused
macros.

Additionally, linux/time.h has similar macros defined that expand to
nothing so we'll remove those at the same time.

Reported-by: Jeff Law &lt;law@redhat.com&gt;
Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Josh Boyer &lt;jwboyer@redhat.com&gt;
[ .. and fix up whitespace as per akpm ]
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>s390/mm: fix fault handling for page table walk case</title>
<updated>2012-08-09T15:22:53Z</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2012-07-27T07:45:39Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=05e4b43a37ef048498d4b326d9014923de4d4cd1'/>
<id>urn:sha1:05e4b43a37ef048498d4b326d9014923de4d4cd1</id>
<content type='text'>
commit 008c2e8f247f0a8db1e8e26139da12f3a3abcda0 upstream.

Make sure the kernel does not incorrectly create a SIGBUS signal during
user space accesses:

For user space accesses in the switched addressing mode case the kernel
may walk page tables and access user address space via the kernel
mapping. If a page table entry is invalid the function __handle_fault()
gets called in order to emulate a page fault and trigger all the usual
actions like paging in a missing page etc. by calling handle_mm_fault().

If handle_mm_fault() returns with an error fixup handling is necessary.
For the switched addressing mode case all errors need to be mapped to
-EFAULT, so that the calling uaccess function can return -EFAULT to
user space.

Unfortunately the __handle_fault() incorrectly calls do_sigbus() if
VM_FAULT_SIGBUS is set. This however should only happen if a page fault
was triggered by a user space instruction. For kernel mode uaccesses
the correct action is to only return -EFAULT.
So user space may incorrectly see SIGBUS signals because of this bug.

For current machines this would only be possible for the switched
addressing mode case in conjunction with futex operations.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>s390/mm: downgrade page table after fork of a 31 bit process</title>
<updated>2012-08-09T15:22:53Z</updated>
<author>
<name>Martin Schwidefsky</name>
<email>schwidefsky@de.ibm.com</email>
</author>
<published>2012-07-26T06:53:06Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6f1498585789591dc5ab066149bd091d7aac84fd'/>
<id>urn:sha1:6f1498585789591dc5ab066149bd091d7aac84fd</id>
<content type='text'>
commit 0f6f281b731d20bfe75c13f85d33f3f05b440222 upstream.

The downgrade of the 4 level page table created by init_new_context is
currently done only in start_thread31. If a 31 bit process forks the
new mm uses a 4 level page table, including the task size of 2&lt;&lt;42
that goes along with it. This is incorrect as now a 31 bit process
can map memory beyond 2GB. Define arch_dup_mmap to do the downgrade
after fork.

Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>s390/idle: fix sequence handling vs cpu hotplug</title>
<updated>2012-08-09T15:22:53Z</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2012-07-13T13:45:33Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=465f25e8db7cfdc04fad80250f141bcacb865ce2'/>
<id>urn:sha1:465f25e8db7cfdc04fad80250f141bcacb865ce2</id>
<content type='text'>
commit 0008204ffe85d23382d6fd0f971f3f0fbe70bae2 upstream.

The s390 idle accounting code uses a sequence counter which gets used
when the per cpu idle statistics get updated and read.

One assumption on read access is that only when the sequence counter is
even and did not change while reading all values the result is valid.
On cpu hotplug however the per cpu data structure gets initialized via
a cpu hotplug notifier on CPU_ONLINE.
CPU_ONLINE however is too late, since the onlined cpu is already running
and might access the per cpu data. Worst case is that the data structure
gets initialized while an idle thread is updating its idle statistics.
This will result in an uneven sequence counter after an update.

As a result user space tools like top, which access /proc/stat in order
to get idle stats, will busy loop waiting for the sequence counter to
become even again, which will never happen until the queried cpu will
update its idle statistics again. And even then the sequence counter
will only have an even value for a couple of cpu cycles.

Fix this by moving the initialization of the per cpu idle statistics
to cpu_init(). I prefer that solution in favor of changing the
notifier to CPU_UP_PREPARE, which would be a different solution to
the problem.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>x86/mce: Fix siginfo_t-&gt;si_addr value for non-recoverable memory faults</title>
<updated>2012-08-09T15:22:51Z</updated>
<author>
<name>Tony Luck</name>
<email>tony.luck@intel.com</email>
</author>
<published>2012-07-11T17:20:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1a556b7cf880f1bc1edc7d8617c6ac53274e9e02'/>
<id>urn:sha1:1a556b7cf880f1bc1edc7d8617c6ac53274e9e02</id>
<content type='text'>
commit 6751ed65dc6642af64f7b8a440a75563c8aab7ae upstream.

In commit dad1743e5993f1 ("x86/mce: Only restart instruction after machine
check recovery if it is safe") we fixed mce_notify_process() to force a
signal to the current process if it was not restartable (RIPV bit not
set in MCG_STATUS). But doing it here means that the process doesn't
get told the virtual address of the fault via siginfo_t-&gt;si_addr. This
would prevent application level recovery from the fault.

Make a new MF_MUST_KILL flag bit for memory_failure() et al. to use so
that we will provide the right information with the signal.

Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
Acked-by: Borislav Petkov &lt;borislav.petkov@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>x86, microcode: Sanitize per-cpu microcode reloading interface</title>
<updated>2012-08-09T15:22:50Z</updated>
<author>
<name>Borislav Petkov</name>
<email>borislav.petkov@amd.com</email>
</author>
<published>2012-06-21T12:07:16Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7d5fdbb9069bbdc679a24cd6ca634c0dc2d66442'/>
<id>urn:sha1:7d5fdbb9069bbdc679a24cd6ca634c0dc2d66442</id>
<content type='text'>
commit c9fc3f778a6a215ace14ee556067c73982b6d40f upstream.

Microcode reloading in a per-core manner is a very bad idea for both
major x86 vendors. And the thing is, we have such interface with which
we can end up with different microcode versions applied on different
cores of an otherwise homogeneous wrt (family,model,stepping) system.

So turn off the possibility of doing that per core and allow it only
system-wide.

This is a minimal fix which we'd like to see in stable too thus the
more-or-less arbitrary decision to allow system-wide reloading only on
the BSP:

$ echo 1 &gt; /sys/devices/system/cpu/cpu0/microcode/reload
...

and disable the interface on the other cores:

$ echo 1 &gt; /sys/devices/system/cpu/cpu23/microcode/reload
-bash: echo: write error: Invalid argument

Also, allowing the reload only from one CPU (the BSP in
that case) doesn't allow the reload procedure to degenerate
into an O(n^2) deal when triggering reloads from all
/sys/devices/system/cpu/cpuX/microcode/reload sysfs nodes
simultaneously.

A more generic fix will follow.

Cc: Henrique de Moraes Holschuh &lt;hmh@hmh.eng.br&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Signed-off-by: Borislav Petkov &lt;borislav.petkov@amd.com&gt;
Link: http://lkml.kernel.org/r/1340280437-7718-2-git-send-email-bp@amd64.org
Signed-off-by: H. Peter Anvin &lt;hpa@zytor.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: dt: tegra trimslice: add vbus-gpio property</title>
<updated>2012-08-09T15:22:37Z</updated>
<author>
<name>Stephen Warren</name>
<email>swarren@nvidia.com</email>
</author>
<published>2012-07-25T20:02:44Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=91352cfc7d2b1029a2659fadf69cf278aa2f1557'/>
<id>urn:sha1:91352cfc7d2b1029a2659fadf69cf278aa2f1557</id>
<content type='text'>
commit 01ad8063a5db9ac8320f197577a34b423ba64eca upstream.

On TrimSlice, Tegra's USB1 port may be routed to either an external micro
USB port, or an internal USB-&gt;SATA bridge for SSD or HDD. This muxing is
controlled by a GPIO. Whilst not strictly a VBUS GPIO, the TrimSlice
board files caused this GPIO to be set appropriately to enable the SATA
bridge by passing it as the VBUS GPIO to the USB driver. Echo this same
configuration in device tree to enable the SATA bridge.

An alternative might be to implement a full USB bus mux driver. However,
that seems over-complex right now.

Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: OMAP2+: OPP: Fix to ensure check of right oppdef after bad one</title>
<updated>2012-08-09T15:22:37Z</updated>
<author>
<name>Nishanth Menon</name>
<email>nm@ti.com</email>
</author>
<published>2012-05-18T17:26:19Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ca32dc5c86cc621749853495b9244231f0b2e6e3'/>
<id>urn:sha1:ca32dc5c86cc621749853495b9244231f0b2e6e3</id>
<content type='text'>
commit b110547e586eb5825bc1d04aa9147bff83b57672 upstream.

Commit 9fa2df6b90786301b175e264f5fa9846aba81a65
(ARM: OMAP2+: OPP: allow OPP enumeration to continue if device is not present)
makes the logic:
for (i = 0; i &lt; opp_def_size; i++) {
	&lt;snip&gt;
	if (!oh || !oh-&gt;od) {
		&lt;snip&gt;
		continue;
	}
&lt;snip&gt;
opp_def++;
}

In short, the moment we hit a "Bad OPP", we end up looping the list
comparing against the bad opp definition pointer for the rest of the
iteration count. Instead, increment opp_def in the for loop itself
and allow continue to be used in code without much thought so that
we check the next set of OPP definition pointers :)

Cc: Steve Sakoman &lt;steve@sakoman.com&gt;
Cc: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Nishanth Menon &lt;nm@ti.com&gt;
Signed-off-by: Kevin Hilman &lt;khilman@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: dt: tegra trimslice: enable USB2 port</title>
<updated>2012-08-09T15:22:37Z</updated>
<author>
<name>Stephen Warren</name>
<email>swarren@nvidia.com</email>
</author>
<published>2012-07-25T20:02:43Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=9f1dc74c1378d02d9cbc318851300b8c341da904'/>
<id>urn:sha1:9f1dc74c1378d02d9cbc318851300b8c341da904</id>
<content type='text'>
commit a6a3dd1aed31ace7c827236c53d83f4e845dcff2 upstream.

This was accidentally disabled by commit 2a5fdc9 "ARM: dt: tegra:
invert status=disable vs status=okay".

Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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