<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git, branch v3.9.7</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.9.7</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.9.7'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2013-06-20T19:01:46Z</updated>
<entry>
<title>Linux 3.9.7</title>
<updated>2013-06-20T19:01:46Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2013-06-20T19:01:46Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=485f25fcc014f2744754f22de395f745f2c7e492'/>
<id>urn:sha1:485f25fcc014f2744754f22de395f745f2c7e492</id>
<content type='text'>
</content>
</entry>
<entry>
<title>ARM: Kirkwood: handle mv88f6282 cpu in __kirkwood_variant().</title>
<updated>2013-06-20T19:01:38Z</updated>
<author>
<name>Nicolas Schichan</name>
<email>nschichan@freebox.fr</email>
</author>
<published>2013-06-06T17:00:46Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8e8577e87943a83aa1b84b3d5202f1f4e8f088d0'/>
<id>urn:sha1:8e8577e87943a83aa1b84b3d5202f1f4e8f088d0</id>
<content type='text'>
commit 4089fe95bfed295c8ad38251d5fe02b6b0ba684c upstream.

MPP_F6281_MASK would be previously be returned when on mv88f6282,
which would disallow some valid MPP configurations.

Commit 830f8b91 (arm: plat-orion: fix printing of "MPP config
unavailable on this hardware") made this problem visible as an invalid
MPP configuration is now correctly detected and not applied.

Signed-off-by: Nicolas Schichan &lt;nschichan@freebox.fr&gt;
Signed-off-by: Jason Cooper &lt;jason@lakedaemon.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tg3: Wait for boot code to finish after power on</title>
<updated>2013-06-20T19:01:38Z</updated>
<author>
<name>Nithin Sujir</name>
<email>nsujir@broadcom.com</email>
</author>
<published>2013-06-12T18:08:59Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=43553a33ff54c011225967861e34f3f4047a3b7e'/>
<id>urn:sha1:43553a33ff54c011225967861e34f3f4047a3b7e</id>
<content type='text'>
commit df465abfe06f7dc4f33f4a96d17f096e9e8ac917 upstream.

Some systems that don't need wake-on-lan may choose to power down the
chip on system standby. Upon resume, the power on causes the boot code
to startup and initialize the hardware. On one new platform, this is
causing the device to go into a bad state due to a race between the
driver and boot code, once every several hundred resumes. The same race
exists on open since we come up from a power on.

This patch adds a wait for boot code signature at the beginning of
tg3_init_hw() which is common to both cases. If there has not been a
power-off or the boot code has already completed, the signature will be
present and poll_fw() returns immediately. Also return immediately if
the device does not have firmware.

Signed-off-by: Nithin Nayak Sujir &lt;nsujir@broadcom.com&gt;
Signed-off-by: Michael Chan &lt;mchan@broadcom.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: spcp8x5: fix device initialisation at open</title>
<updated>2013-06-20T19:01:38Z</updated>
<author>
<name>Johan Hovold</name>
<email>jhovold@gmail.com</email>
</author>
<published>2013-06-10T16:29:39Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=70b6bf5ba36ef71e7301553ee79f718380a546a7'/>
<id>urn:sha1:70b6bf5ba36ef71e7301553ee79f718380a546a7</id>
<content type='text'>
commit 5e4211f1c47560c36a8b3d4544dfd866dcf7ccd0 upstream.

Do not use uninitialised termios data to determine when to configure the
device at open.

Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: f81232: fix device initialisation at open</title>
<updated>2013-06-20T19:01:38Z</updated>
<author>
<name>Johan Hovold</name>
<email>jhovold@gmail.com</email>
</author>
<published>2013-06-10T16:29:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4f0856222860481ce20b248cdd824dce7c995d74'/>
<id>urn:sha1:4f0856222860481ce20b248cdd824dce7c995d74</id>
<content type='text'>
commit 21886725d58e92188159731c7c1aac803dd6b9dc upstream.

Do not use uninitialised termios data to determine when to configure the
device at open.

This also prevents stack data from leaking to userspace.

Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: pl2303: fix device initialisation at open</title>
<updated>2013-06-20T19:01:38Z</updated>
<author>
<name>Johan Hovold</name>
<email>jhovold@gmail.com</email>
</author>
<published>2013-06-10T16:29:38Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=96341bdc2ab71183c94d8fa5332eef78ada20423'/>
<id>urn:sha1:96341bdc2ab71183c94d8fa5332eef78ada20423</id>
<content type='text'>
commit 2d8f4447b58bba5f8cb895c07690434c02307eaf upstream.

Do not use uninitialised termios data to determine when to configure the
device at open.

This also prevents stack data from leaking to userspace in the OOM error
path.

Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: chipidea: fix id change handling</title>
<updated>2013-06-20T19:01:38Z</updated>
<author>
<name>Alexander Shishkin</name>
<email>alexander.shishkin@linux.intel.com</email>
</author>
<published>2013-06-11T10:41:48Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=139f4ebcf7a9f71a55666a3537c16b3eaa7f18f0'/>
<id>urn:sha1:139f4ebcf7a9f71a55666a3537c16b3eaa7f18f0</id>
<content type='text'>
commit 0c3f3dc68bb6e6950e8cd7851e7778c550e8dfb4 upstream.

Re-enable chipidea irq even if there's no role changing to do. This is
a problem since b183c19f ("USB: chipidea: re-order irq handling to avoid
unhandled irqs"); when it manifests, chipidea irq gets disabled for good.

Signed-off-by: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>powerpc: Fix missing/delayed calls to irq_work</title>
<updated>2013-06-20T19:01:38Z</updated>
<author>
<name>Benjamin Herrenschmidt</name>
<email>benh@kernel.crashing.org</email>
</author>
<published>2013-06-15T02:13:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=37759cb02de6e811c7e3d2c11ac2944666710392'/>
<id>urn:sha1:37759cb02de6e811c7e3d2c11ac2944666710392</id>
<content type='text'>
commit 230b3034793247f61e6a0b08c44cf415f6d92981 upstream.

When replaying interrupts (as a result of the interrupt occurring
while soft-disabled), in the case of the decrementer, we are exclusively
testing for a pending timer target. However we also use decrementer
interrupts to trigger the new "irq_work", which in this case would
be missed.

This change the logic to force a replay in both cases of a timer
boundary reached and a decrementer interrupt having actually occurred
while disabled. The former test is still useful to catch cases where
a CPU having been hard-disabled for a long time completely misses the
interrupt due to a decrementer rollover.

Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Tested-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>powerpc: Fix emulation of illegal instructions on PowerNV platform</title>
<updated>2013-06-20T19:01:33Z</updated>
<author>
<name>Paul Mackerras</name>
<email>paulus@samba.org</email>
</author>
<published>2013-06-14T10:07:41Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5cf1b34ca312b3626201ab7bafe5dc884e028616'/>
<id>urn:sha1:5cf1b34ca312b3626201ab7bafe5dc884e028616</id>
<content type='text'>
commit bf593907f7236e95698a76b7c7a2bbf8b1165327 upstream.

Normally, the kernel emulates a few instructions that are unimplemented
on some processors (e.g. the old dcba instruction), or privileged (e.g.
mfpvr).  The emulation of unimplemented instructions is currently not
working on the PowerNV platform.  The reason is that on these machines,
unimplemented and illegal instructions cause a hypervisor emulation
assist interrupt, rather than a program interrupt as on older CPUs.
Our vector for the emulation assist interrupt just calls
program_check_exception() directly, without setting the bit in SRR1
that indicates an illegal instruction interrupt.  This fixes it by
making the emulation assist interrupt set that bit before calling
program_check_interrupt().  With this, old programs that use no-longer
implemented instructions such as dcba now work again.

Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>powerpc: Fix stack overflow crash in resume_kernel when ftracing</title>
<updated>2013-06-20T19:01:32Z</updated>
<author>
<name>Michael Ellerman</name>
<email>michael@ellerman.id.au</email>
</author>
<published>2013-06-13T11:04:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a1fb10e6d2ee287036139b4f4a75763ffbf9b70b'/>
<id>urn:sha1:a1fb10e6d2ee287036139b4f4a75763ffbf9b70b</id>
<content type='text'>
commit 0e37739b1c96d65e6433998454985de994383019 upstream.

It's possible for us to crash when running with ftrace enabled, eg:

  Bad kernel stack pointer bffffd12 at c00000000000a454
  cpu 0x3: Vector: 300 (Data Access) at [c00000000ffe3d40]
      pc: c00000000000a454: resume_kernel+0x34/0x60
      lr: c00000000000335c: performance_monitor_common+0x15c/0x180
      sp: bffffd12
     msr: 8000000000001032
     dar: bffffd12
   dsisr: 42000000

If we look at current's stack (paca-&gt;__current-&gt;stack) we see it is
equal to c0000002ecab0000. Our stack is 16K, and comparing to
paca-&gt;kstack (c0000002ecab3e30) we can see that we have overflowed our
kernel stack. This leads to us writing over our struct thread_info, and
in this case we have corrupted thread_info-&gt;flags and set
_TIF_EMULATE_STACK_STORE.

Dumping the stack we see:

  3:mon&gt; t c0000002ecab0000
  [c0000002ecab0000] c00000000002131c .performance_monitor_exception+0x5c/0x70
  [c0000002ecab0080] c00000000000335c performance_monitor_common+0x15c/0x180
  --- Exception: f01 (Performance Monitor) at c0000000000fb2ec .trace_hardirqs_off+0x1c/0x30
  [c0000002ecab0370] c00000000016fdb0 .trace_graph_entry+0xb0/0x280 (unreliable)
  [c0000002ecab0410] c00000000003d038 .prepare_ftrace_return+0x98/0x130
  [c0000002ecab04b0] c00000000000a920 .ftrace_graph_caller+0x14/0x28
  [c0000002ecab0520] c0000000000d6b58 .idle_cpu+0x18/0x90
  [c0000002ecab05a0] c00000000000a934 .return_to_handler+0x0/0x34
  [c0000002ecab0620] c00000000001e660 .timer_interrupt+0x160/0x300
  [c0000002ecab06d0] c0000000000025dc decrementer_common+0x15c/0x180
  --- Exception: 901 (Decrementer) at c0000000000104d4 .arch_local_irq_restore+0x74/0xa0
  [c0000002ecab09c0] c0000000000fe044 .trace_hardirqs_on+0x14/0x30 (unreliable)
  [c0000002ecab0fb0] c00000000016fe3c .trace_graph_entry+0x13c/0x280
  [c0000002ecab1050] c00000000003d038 .prepare_ftrace_return+0x98/0x130
  [c0000002ecab10f0] c00000000000a920 .ftrace_graph_caller+0x14/0x28
  [c0000002ecab1160] c0000000000161f0 .__ppc64_runlatch_on+0x10/0x40
  [c0000002ecab11d0] c00000000000a934 .return_to_handler+0x0/0x34
  --- Exception: 901 (Decrementer) at c0000000000104d4 .arch_local_irq_restore+0x74/0xa0

  ... and so on

__ppc64_runlatch_on() is called from RUNLATCH_ON in the exception entry
path. At that point the irq state is not consistent, ie. interrupts are
hard disabled (by the exception entry), but the paca soft-enabled flag
may be out of sync.

This leads to the local_irq_restore() in trace_graph_entry() actually
enabling interrupts, which we do not want. Because we have not yet
reprogrammed the decrementer we immediately take another decrementer
exception, and recurse.

The fix is twofold. Firstly make sure we call DISABLE_INTS before
calling RUNLATCH_ON. The badly named DISABLE_INTS actually reconciles
the irq state in the paca with the hardware, making it safe again to
call local_irq_save/restore().

Although that should be sufficient to fix the bug, we also mark the
runlatch routines as notrace. They are called very early in the
exception entry and we are asking for trouble tracing them. They are
also fairly uninteresting and tracing them just adds unnecessary
overhead.

[ This regression was introduced by fe1952fc0afb9a2e4c79f103c08aef5d13db1873
  "powerpc: Rework runlatch code" by myself --BenH
]

Signed-off-by: Michael Ellerman &lt;michael@ellerman.id.au&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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