<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch/arm/kernel/swp_emulate.c, branch linux-4.2.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ARM: 8322/1: keep .text and .fixup regions closer together</title>
<updated>2015-03-29T22:11:56+00:00</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ard.biesheuvel@linaro.org</email>
</author>
<published>2015-03-24T09:41:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c4a84ae39b4a5bdf609c0001e14207aa731aab30'/>
<id>c4a84ae39b4a5bdf609c0001e14207aa731aab30</id>
<content type='text'>
This moves all fixup snippets to the .text.fixup section, which is
a special section that gets emitted along with the .text section
for each input object file, i.e., the snippets are kept much closer
to the code they refer to, which helps prevent linker failure on
large kernels.

Acked-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This moves all fixup snippets to the .text.fixup section, which is
a special section that gets emitted along with the .text section
for each input object file, i.e., the snippets are kept much closer
to the code they refer to, which helps prevent linker failure on
large kernels.

Acked-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: convert printk(KERN_* to pr_*</title>
<updated>2014-11-21T15:24:50+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@arm.linux.org.uk</email>
</author>
<published>2014-10-28T11:26:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4ed89f2228061422ce5f62545fd0b6f6648bd2cc'/>
<id>4ed89f2228061422ce5f62545fd0b6f6648bd2cc</id>
<content type='text'>
Convert many (but not all) printk(KERN_* to pr_* to simplify the code.
We take the opportunity to join some printk lines together so we don't
split the message across several lines, and we also add a few levels
to some messages which were previously missing them.

Tested-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Tested-by: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Convert many (but not all) printk(KERN_* to pr_* to simplify the code.
We take the opportunity to join some printk lines together so we don't
split the message across several lines, and we also add a few levels
to some messages which were previously missing them.

Tested-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Tested-by: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 8135/1: Fix in-correct barrier usage in SWP{B} emulation</title>
<updated>2014-09-12T16:38:58+00:00</updated>
<author>
<name>Punit Agrawal</name>
<email>punit.agrawal@arm.com</email>
</author>
<published>2014-09-01T16:16:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e918a62a2ba81d10a3cc2c513dc70034c9524a95'/>
<id>e918a62a2ba81d10a3cc2c513dc70034c9524a95</id>
<content type='text'>
According to the ARM ARMv7, explicit barriers are necessary when using
synchronisation primitives such as SWP{B}. The use of these
instructions does not automatically imply a barrier and any ordering
requirements by the software must be explicitly expressed with the use
of suitable barriers.

Based on this, remove the barriers from SWP{B} emulation.

Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Punit Agrawal &lt;punit.agrawal@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
According to the ARM ARMv7, explicit barriers are necessary when using
synchronisation primitives such as SWP{B}. The use of these
instructions does not automatically imply a barrier and any ordering
requirements by the software must be explicitly expressed with the use
of suitable barriers.

Based on this, remove the barriers from SWP{B} emulation.

Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Punit Agrawal &lt;punit.agrawal@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: SWP emulation: only initialise on ARMv7 CPUs</title>
<updated>2014-07-18T11:29:49+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@arm.linux.org.uk</email>
</author>
<published>2014-07-04T13:49:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7397aa48fff47c2386867a3fbfce8f3e664843a9'/>
<id>7397aa48fff47c2386867a3fbfce8f3e664843a9</id>
<content type='text'>
Previous CPUs do not have the ability to trap SWP instructions, so
it's pointless initialising this code there.

Tested-by: Tony Lindgren &lt;tony@atomide.com&gt;
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previous CPUs do not have the ability to trap SWP instructions, so
it's pointless initialising this code there.

Tested-by: Tony Lindgren &lt;tony@atomide.com&gt;
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm: single_open() leaks</title>
<updated>2013-05-05T04:07:22+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2013-05-05T04:07:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b11ac20ecab194428deebf31f20c04fad5253628'/>
<id>b11ac20ecab194428deebf31f20c04fad5253628</id>
<content type='text'>
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm: Don't use create_proc_read_entry()</title>
<updated>2013-04-29T19:42:00+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2013-04-11T02:05:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=526c59784c09fb794a5f0181429525bc473453c9'/>
<id>526c59784c09fb794a5f0181429525bc473453c9</id>
<content type='text'>
Don't use create_proc_read_entry() as that is deprecated, but rather use
proc_create_data() and seq_file instead.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
cc: Russell King &lt;linux@arm.linux.org.uk&gt;
cc: Kevin Hilman &lt;khilman@deeprootsystems.com&gt;
cc: Tony Lindgren &lt;tony@atomide.com&gt;
cc: linux-arm-kernel@lists.infradead.org
cc: linux-omap@vger.kernel.org
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Don't use create_proc_read_entry() as that is deprecated, but rather use
proc_create_data() and seq_file instead.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
cc: Russell King &lt;linux@arm.linux.org.uk&gt;
cc: Kevin Hilman &lt;khilman@deeprootsystems.com&gt;
cc: Tony Lindgren &lt;tony@atomide.com&gt;
cc: linux-arm-kernel@lists.infradead.org
cc: linux-omap@vger.kernel.org
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>get rid of a bunch of open-coded create_proc_read_entry()</title>
<updated>2013-04-09T18:13:10+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2013-03-30T17:26:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e784788ddb7000dbea8bd2986a3f83c4d77f96ff'/>
<id>e784788ddb7000dbea8bd2986a3f83c4d77f96ff</id>
<content type='text'>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: missing -&gt;mmap_sem around find_vma() in swp_emulate.c</title>
<updated>2012-12-20T10:40:24+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@ZenIV.linux.org.uk</email>
</author>
<published>2012-12-16T00:25:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7bf9b7bef881aac820bf1f2e9951a17b09bd7e04'/>
<id>7bf9b7bef881aac820bf1f2e9951a17b09bd7e04</id>
<content type='text'>
find_vma() is *not* safe when somebody else is removing vmas.  Not just
the return value might get bogus just as you are getting it (this instance
doesn't try to dereference the resulting vma), the search itself can get
buggered in rather spectacular ways.  IOW, -&gt;mmap_sem really, really is
not optional here.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
find_vma() is *not* safe when somebody else is removing vmas.  Not just
the return value might get bogus just as you are getting it (this instance
doesn't try to dereference the resulting vma), the search itself can get
buggered in rather spectacular ways.  IOW, -&gt;mmap_sem really, really is
not optional here.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 7208/1: Add condition code checking to SWP emulation handler.</title>
<updated>2011-12-13T08:52:03+00:00</updated>
<author>
<name>Leif Lindholm</name>
<email>leif.lindholm@arm.com</email>
</author>
<published>2011-12-12T18:45:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c245dcd326fb9f8cca4b396796f0d2e54171b5c9'/>
<id>c245dcd326fb9f8cca4b396796f0d2e54171b5c9</id>
<content type='text'>
This patch fixes two separate issues with the SWP emulation handler:
1: Certain processors implementing ARMv7-A can (legally) take an
   undef exception even when the condition code would have meant that
   the instruction should not have been executed.
2: Opcodes with all flags set (condition code = 0xf) have been reused
   in recent, and not-so-recent, versions of the ARM architecture to
   implement unconditional extensions to the instruction set. The
   existing code would still have processed any undefs triggered by
   executing an opcode with such a value.

This patch uses the new generic ARM instruction set condition code
checks to implement proper handling of these situations.

Signed-off-by: Leif Lindholm &lt;leif.lindholm@arm.com&gt;
Reviewed-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch fixes two separate issues with the SWP emulation handler:
1: Certain processors implementing ARMv7-A can (legally) take an
   undef exception even when the condition code would have meant that
   the instruction should not have been executed.
2: Opcodes with all flags set (condition code = 0xf) have been reused
   in recent, and not-so-recent, versions of the ARM architecture to
   implement unconditional extensions to the instruction set. The
   existing code would still have processed any undefs triggered by
   executing an opcode with such a value.

This patch uses the new generic ARM instruction set condition code
checks to implement proper handling of these situations.

Signed-off-by: Leif Lindholm &lt;leif.lindholm@arm.com&gt;
Reviewed-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>perf: Remove the nmi parameter from the swevent and overflow interface</title>
<updated>2011-07-01T09:06:35+00:00</updated>
<author>
<name>Peter Zijlstra</name>
<email>a.p.zijlstra@chello.nl</email>
</author>
<published>2011-06-27T12:41:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a8b0ca17b80e92faab46ee7179ba9e99ccb61233'/>
<id>a8b0ca17b80e92faab46ee7179ba9e99ccb61233</id>
<content type='text'>
The nmi parameter indicated if we could do wakeups from the current
context, if not, we would set some state and self-IPI and let the
resulting interrupt do the wakeup.

For the various event classes:

  - hardware: nmi=0; PMI is in fact an NMI or we run irq_work_run from
    the PMI-tail (ARM etc.)
  - tracepoint: nmi=0; since tracepoint could be from NMI context.
  - software: nmi=[0,1]; some, like the schedule thing cannot
    perform wakeups, and hence need 0.

As one can see, there is very little nmi=1 usage, and the down-side of
not using it is that on some platforms some software events can have a
jiffy delay in wakeup (when arch_irq_work_raise isn't implemented).

The up-side however is that we can remove the nmi parameter and save a
bunch of conditionals in fast paths.

Signed-off-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Cc: Michael Cree &lt;mcree@orcon.net.nz&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Deng-Cheng Zhu &lt;dengcheng.zhu@gmail.com&gt;
Cc: Anton Blanchard &lt;anton@samba.org&gt;
Cc: Eric B Munson &lt;emunson@mgebm.net&gt;
Cc: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Cc: Paul Mundt &lt;lethal@linux-sh.org&gt;
Cc: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Cc: Jason Wessel &lt;jason.wessel@windriver.com&gt;
Cc: Don Zickus &lt;dzickus@redhat.com&gt;
Link: http://lkml.kernel.org/n/tip-agjev8eu666tvknpb3iaj0fg@git.kernel.org
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The nmi parameter indicated if we could do wakeups from the current
context, if not, we would set some state and self-IPI and let the
resulting interrupt do the wakeup.

For the various event classes:

  - hardware: nmi=0; PMI is in fact an NMI or we run irq_work_run from
    the PMI-tail (ARM etc.)
  - tracepoint: nmi=0; since tracepoint could be from NMI context.
  - software: nmi=[0,1]; some, like the schedule thing cannot
    perform wakeups, and hence need 0.

As one can see, there is very little nmi=1 usage, and the down-side of
not using it is that on some platforms some software events can have a
jiffy delay in wakeup (when arch_irq_work_raise isn't implemented).

The up-side however is that we can remove the nmi parameter and save a
bunch of conditionals in fast paths.

Signed-off-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Cc: Michael Cree &lt;mcree@orcon.net.nz&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Deng-Cheng Zhu &lt;dengcheng.zhu@gmail.com&gt;
Cc: Anton Blanchard &lt;anton@samba.org&gt;
Cc: Eric B Munson &lt;emunson@mgebm.net&gt;
Cc: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Cc: Paul Mundt &lt;lethal@linux-sh.org&gt;
Cc: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Cc: Jason Wessel &lt;jason.wessel@windriver.com&gt;
Cc: Don Zickus &lt;dzickus@redhat.com&gt;
Link: http://lkml.kernel.org/n/tip-agjev8eu666tvknpb3iaj0fg@git.kernel.org
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</pre>
</div>
</content>
</entry>
</feed>
