<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/arch/arc/kernel, branch v4.4.118</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.118</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.118'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2017-09-27T09:00:16Z</updated>
<entry>
<title>ARC: Re-enable MMU upon Machine Check exception</title>
<updated>2017-09-27T09:00:16Z</updated>
<author>
<name>Jose Abreu</name>
<email>Jose.Abreu@synopsys.com</email>
</author>
<published>2017-09-01T16:00:23Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=81306fc3dbb53b11f9c42d31403df3655d50f935'/>
<id>urn:sha1:81306fc3dbb53b11f9c42d31403df3655d50f935</id>
<content type='text'>
commit 1ee55a8f7f6b7ca4c0c59e0b4b4e3584a085c2d3 upstream.

I recently came upon a scenario where I would get a double fault
machine check exception tiriggered by a kernel module.
However the ensuing crash stacktrace (ksym lookup) was not working
correctly.

Turns out that machine check auto-disables MMU while modules are allocated
in kernel vaddr spapce.

This patch re-enables the MMU before start printing the stacktrace
making stacktracing of modules work upon a fatal exception.

Signed-off-by: Jose Abreu &lt;joabreu@synopsys.com&gt;
Reviewed-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
[vgupta: moved code into low level handler to avoid in 2 places]
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARC: [arcompact] brown paper bag bug in unaligned access delay slot fixup</title>
<updated>2017-02-14T23:22:50Z</updated>
<author>
<name>Vineet Gupta</name>
<email>Vineet.Gupta1@synopsys.com</email>
</author>
<published>2017-02-07T17:44:58Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e871ea6bcf99097731fceff3e8e1c5ed05b04ae2'/>
<id>urn:sha1:e871ea6bcf99097731fceff3e8e1c5ed05b04ae2</id>
<content type='text'>
commit a524c218bc94c705886a0e0fedeee45d1931da32 upstream.

Reported-by: Jo-Philipp Wich &lt;jo@mein.io&gt;
Fixes: 9aed02feae57bf7 ("ARC: [arcompact] handle unaligned access delay slot")
Cc: linux-kernel@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&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>ARC: [arcompact] handle unaligned access delay slot corner case</title>
<updated>2017-02-01T07:30:53Z</updated>
<author>
<name>Vineet Gupta</name>
<email>vgupta@synopsys.com</email>
</author>
<published>2017-01-27T18:45:27Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=acb63c8b576d9a853ffae2f25f21447be6f5c347'/>
<id>urn:sha1:acb63c8b576d9a853ffae2f25f21447be6f5c347</id>
<content type='text'>
commit 9aed02feae57bf7a40cb04ea0e3017cb7a998db4 upstream.

After emulating an unaligned access in delay slot of a branch, we
pretend as the delay slot never happened - so return back to actual
branch target (or next PC if branch was not taken).

Curently we did this by handling STATUS32.DE, we also need to clear the
BTA.T bit, which is disregarded when returning from original misaligned
exception, but could cause weirdness if it took the interrupt return
path (in case interrupt was acive too)

One ARC700 customer ran into this when enabling unaligned access fixup
for kernel mode accesses as well

Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARC: timer: rtc: implement read loop in "C" vs. inline asm</title>
<updated>2016-11-18T09:48:34Z</updated>
<author>
<name>Vineet Gupta</name>
<email>vgupta@synopsys.com</email>
</author>
<published>2016-10-31T21:09:52Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c45bfaa9211ef5936916503bdba639eae3761777'/>
<id>urn:sha1:c45bfaa9211ef5936916503bdba639eae3761777</id>
<content type='text'>
commit 922cc171998ac3dbe74d57011ef7ed57e9b0d7df upstream.

The current code doesn't even compile as somehow the inline assembly
can't see the register names defined as ARC_RTC_*
I'm pretty sure It worked when I first got it merged, but the tools were
definitely different then.

So better to write this in "C" anyways.

Acked-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arc: don't leak bits of kernel stack into coredump</title>
<updated>2016-10-28T07:01:32Z</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2016-09-10T20:31:04Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8cffabab018cad0dfcfe3ab44ff8c2510fc2408d'/>
<id>urn:sha1:8cffabab018cad0dfcfe3ab44ff8c2510fc2408d</id>
<content type='text'>
commit 7798bf2140ebcc36eafec6a4194fffd8d585d471 upstream.

On faulting sigreturn we do get SIGSEGV, all right, but anything
we'd put into pt_regs could end up in the coredump.  And since
__copy_from_user() never zeroed on arc, we'd better bugger off
on its failure without copying random uninitialized bits of
kernel stack into pt_regs...

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arc: unwind: warn only once if DW2_UNWIND is disabled</title>
<updated>2016-08-10T09:49:25Z</updated>
<author>
<name>Alexey Brodkin</name>
<email>Alexey.Brodkin@synopsys.com</email>
</author>
<published>2016-06-23T08:00:39Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e0bc4e7e1c876f8e58ba381bf5194a8b8c8d448f'/>
<id>urn:sha1:e0bc4e7e1c876f8e58ba381bf5194a8b8c8d448f</id>
<content type='text'>
commit 9bd54517ee86cb164c734f72ea95aeba4804f10b upstream.

If CONFIG_ARC_DW2_UNWIND is disabled every time arc_unwind_core()
gets called following message gets printed in debug console:
-----------------&gt;8---------------
CONFIG_ARC_DW2_UNWIND needs to be enabled
-----------------&gt;8---------------

That message makes sense if user indeed wants to see a backtrace or
get nice function call-graphs in perf but what if user disabled
unwinder for the purpose? Why pollute his debug console?

So instead we'll warn user about possibly missing feature once and
let him decide if that was what he or she really wanted.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARCv2: LLSC: software backoff is NOT needed starting HS2.1c</title>
<updated>2016-07-27T16:47:31Z</updated>
<author>
<name>Vineet Gupta</name>
<email>vgupta@synopsys.com</email>
</author>
<published>2016-03-15T06:06:43Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fb4d339f0ffdbe8b6b3aa57940c4a40f538a1887'/>
<id>urn:sha1:fb4d339f0ffdbe8b6b3aa57940c4a40f538a1887</id>
<content type='text'>
commit b31ac42697bef4a3aa5d0aa42375a55657f57174 upstream.

Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARCv2: Check for LL-SC livelock only if LLSC is enabled</title>
<updated>2016-07-27T16:47:31Z</updated>
<author>
<name>Vineet Gupta</name>
<email>vgupta@synopsys.com</email>
</author>
<published>2016-01-29T11:17:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f06a5a019b1161da6f47bde5e7ce63e70193caec'/>
<id>urn:sha1:f06a5a019b1161da6f47bde5e7ce63e70193caec</id>
<content type='text'>
commit 4d0cb15fccd1db9dac0c964b2ccf10874e69f5b8 upstream.

Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARCv2: SMP: Emulate IPI to self using software triggered interrupt</title>
<updated>2016-03-03T23:07:28Z</updated>
<author>
<name>Vineet Gupta</name>
<email>vgupta@synopsys.com</email>
</author>
<published>2016-02-23T06:25:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1de8f1bcb5321bdc35b64bafe4f4a9c389942167'/>
<id>urn:sha1:1de8f1bcb5321bdc35b64bafe4f4a9c389942167</id>
<content type='text'>
commit bb143f814ea488769ca2e79e0b376139cb5f134b upstream.

ARConnect/MCIP Inter-Core-Interrupt module can't send interrupt to
local core. So use core intc capability to trigger software
interrupt to self, using an unsued IRQ #21.

This showed up as csd deadlock with LTP trace_sched on a dual core
system. This test acts as scheduler fuzzer, triggering all sorts of
schedulting activity. Trouble starts with IPI to self, which doesn't get
delivered (effectively lost due to H/w capability), but the msg intended
to be sent remain enqueued in per-cpu @ipi_data.

All subsequent IPIs to this core from other cores get elided due to the
IPI coalescing optimization in ipi_send_msg_one() where a pending msg
implies an IPI already sent and assumes other core is yet to ack it.
After the elided IPI, other core simply goes into csd_lock_wait()
but never comes out as this core never sees the interrupt.

Fixes STAR 9001008624

Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARCv2: STAR 9000950267: Handle return from intr to Delay Slot #2</title>
<updated>2016-03-03T23:07:28Z</updated>
<author>
<name>Vineet Gupta</name>
<email>vgupta@synopsys.com</email>
</author>
<published>2016-01-08T06:59:10Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0bdce40ce0402ab4d46e33f452eb0c29470e0dc6'/>
<id>urn:sha1:0bdce40ce0402ab4d46e33f452eb0c29470e0dc6</id>
<content type='text'>
commit cbfe74a753e877b49dc54e9b04d5d42230ca0aed upstream.

Returning to delay slot, riding an interrupti, had one loose end.
AUX_USER_SP used for restoring user mode SP upon RTIE was not being
setup from orig task's saved value, causing task to use wrong SP,
leading to ProtV errors.

The reason being:
 - INTERRUPT_EPILOGUE returns to a kernel trampoline, thus not expected to restore it
 - EXCEPTION_EPILOGUE is not used at all

Fix that by restoring AUX_USER_SP explicitly in the trampoline.

This was broken in the original workaround, but the error scenarios got
reduced considerably since v3.14 due to following:

 1. The Linuxthreads.old based userspace at the time caused many more
    exceptions in delay slot than the current NPTL based one.
    Infact with current userspace the error doesn't happen at all.

 2. Return from interrupt (delay slot or otherwise) doesn't get exercised much
    after commit 4de0e52867d8 ("Really Re-enable interrupts to avoid deadlocks")
    since IRQ_ACTIVE.active being clear means most returns are as if from pure
    kernel (even for active interrupts)

Infact the issue only happened in an experimental branch where I was tinkering with
reverted 4de0e52867d8

Fixes: 4255b07f2c9c ("ARCv2: STAR 9000793984: Handle return from intr to Delay Slot")
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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