<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/arch/xtensa, branch v4.9.110</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>futex: Remove duplicated code and fix undefined behaviour</title>
<updated>2018-05-19T08:27:00+00:00</updated>
<author>
<name>Jiri Slaby</name>
<email>jslaby@suse.cz</email>
</author>
<published>2017-08-24T07:31:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=81da9f87ad9d5b77014f0d11946ffbc887bdec70'/>
<id>81da9f87ad9d5b77014f0d11946ffbc887bdec70</id>
<content type='text'>
commit 30d6e0a4190d37740e9447e4e4815f06992dd8c3 upstream.

There is code duplicated over all architecture's headers for
futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
and comparison of the result.

Remove this duplication and leave up to the arches only the needed
assembly which is now in arch_futex_atomic_op_inuser.

This effectively distributes the Will Deacon's arm64 fix for undefined
behaviour reported by UBSAN to all architectures. The fix was done in
commit 5f16a046f8e1 (arm64: futex: Fix undefined behaviour with
FUTEX_OP_OPARG_SHIFT usage). Look there for an example dump.

And as suggested by Thomas, check for negative oparg too, because it was
also reported to cause undefined behaviour report.

Note that s390 removed access_ok check in d12a29703 ("s390/uaccess:
remove pointless access_ok() checks") as access_ok there returns true.
We introduce it back to the helper for the sake of simplicity (it gets
optimized away anyway).

Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Acked-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt; (powerpc)
Acked-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt; [s390]
Acked-by: Chris Metcalf &lt;cmetcalf@mellanox.com&gt; [for tile]
Reviewed-by: Darren Hart (VMware) &lt;dvhart@infradead.org&gt;
Reviewed-by: Will Deacon &lt;will.deacon@arm.com&gt; [core/arm64]
Cc: linux-mips@linux-mips.org
Cc: Rich Felker &lt;dalias@libc.org&gt;
Cc: linux-ia64@vger.kernel.org
Cc: linux-sh@vger.kernel.org
Cc: peterz@infradead.org
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: sparclinux@vger.kernel.org
Cc: Jonas Bonn &lt;jonas@southpole.se&gt;
Cc: linux-s390@vger.kernel.org
Cc: linux-arch@vger.kernel.org
Cc: Yoshinori Sato &lt;ysato@users.sourceforge.jp&gt;
Cc: linux-hexagon@vger.kernel.org
Cc: Helge Deller &lt;deller@gmx.de&gt;
Cc: "James E.J. Bottomley" &lt;jejb@parisc-linux.org&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Matt Turner &lt;mattst88@gmail.com&gt;
Cc: linux-snps-arc@lists.infradead.org
Cc: Fenghua Yu &lt;fenghua.yu@intel.com&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: linux-xtensa@linux-xtensa.org
Cc: Stefan Kristiansson &lt;stefan.kristiansson@saunalahti.fi&gt;
Cc: openrisc@lists.librecores.org
Cc: Ivan Kokshaysky &lt;ink@jurassic.park.msu.ru&gt;
Cc: Stafford Horne &lt;shorne@gmail.com&gt;
Cc: linux-arm-kernel@lists.infradead.org
Cc: Richard Henderson &lt;rth@twiddle.net&gt;
Cc: Chris Zankel &lt;chris@zankel.net&gt;
Cc: Michal Simek &lt;monstr@monstr.eu&gt;
Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: linux-parisc@vger.kernel.org
Cc: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Richard Kuo &lt;rkuo@codeaurora.org&gt;
Cc: linux-alpha@vger.kernel.org
Cc: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Cc: linuxppc-dev@lists.ozlabs.org
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Link: http://lkml.kernel.org/r/20170824073105.3901-1-jslaby@suse.cz
Cc: Ben Hutchings &lt;ben.hutchings@codethink.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 30d6e0a4190d37740e9447e4e4815f06992dd8c3 upstream.

There is code duplicated over all architecture's headers for
futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
and comparison of the result.

Remove this duplication and leave up to the arches only the needed
assembly which is now in arch_futex_atomic_op_inuser.

This effectively distributes the Will Deacon's arm64 fix for undefined
behaviour reported by UBSAN to all architectures. The fix was done in
commit 5f16a046f8e1 (arm64: futex: Fix undefined behaviour with
FUTEX_OP_OPARG_SHIFT usage). Look there for an example dump.

And as suggested by Thomas, check for negative oparg too, because it was
also reported to cause undefined behaviour report.

Note that s390 removed access_ok check in d12a29703 ("s390/uaccess:
remove pointless access_ok() checks") as access_ok there returns true.
We introduce it back to the helper for the sake of simplicity (it gets
optimized away anyway).

Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Acked-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt; (powerpc)
Acked-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt; [s390]
Acked-by: Chris Metcalf &lt;cmetcalf@mellanox.com&gt; [for tile]
Reviewed-by: Darren Hart (VMware) &lt;dvhart@infradead.org&gt;
Reviewed-by: Will Deacon &lt;will.deacon@arm.com&gt; [core/arm64]
Cc: linux-mips@linux-mips.org
Cc: Rich Felker &lt;dalias@libc.org&gt;
Cc: linux-ia64@vger.kernel.org
Cc: linux-sh@vger.kernel.org
Cc: peterz@infradead.org
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: sparclinux@vger.kernel.org
Cc: Jonas Bonn &lt;jonas@southpole.se&gt;
Cc: linux-s390@vger.kernel.org
Cc: linux-arch@vger.kernel.org
Cc: Yoshinori Sato &lt;ysato@users.sourceforge.jp&gt;
Cc: linux-hexagon@vger.kernel.org
Cc: Helge Deller &lt;deller@gmx.de&gt;
Cc: "James E.J. Bottomley" &lt;jejb@parisc-linux.org&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Matt Turner &lt;mattst88@gmail.com&gt;
Cc: linux-snps-arc@lists.infradead.org
Cc: Fenghua Yu &lt;fenghua.yu@intel.com&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: linux-xtensa@linux-xtensa.org
Cc: Stefan Kristiansson &lt;stefan.kristiansson@saunalahti.fi&gt;
Cc: openrisc@lists.librecores.org
Cc: Ivan Kokshaysky &lt;ink@jurassic.park.msu.ru&gt;
Cc: Stafford Horne &lt;shorne@gmail.com&gt;
Cc: linux-arm-kernel@lists.infradead.org
Cc: Richard Henderson &lt;rth@twiddle.net&gt;
Cc: Chris Zankel &lt;chris@zankel.net&gt;
Cc: Michal Simek &lt;monstr@monstr.eu&gt;
Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: linux-parisc@vger.kernel.org
Cc: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Richard Kuo &lt;rkuo@codeaurora.org&gt;
Cc: linux-alpha@vger.kernel.org
Cc: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Cc: linuxppc-dev@lists.ozlabs.org
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Link: http://lkml.kernel.org/r/20170824073105.3901-1-jslaby@suse.cz
Cc: Ben Hutchings &lt;ben.hutchings@codethink.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xtensa: fix high memory/reserved memory collision</title>
<updated>2018-02-28T09:18:30+00:00</updated>
<author>
<name>Max Filippov</name>
<email>jcmvbkbc@gmail.com</email>
</author>
<published>2018-02-13T23:31:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a5ecf56cb25462c07afabeee1ba12e09cd8484bd'/>
<id>a5ecf56cb25462c07afabeee1ba12e09cd8484bd</id>
<content type='text'>
commit 6ac5a11dc674bc5016ea716e8082fff61f524dc1 upstream.

Xtensa memory initialization code frees high memory pages without
checking whether they are in the reserved memory regions or not. That
results in invalid value of totalram_pages and duplicate page usage by
CMA and highmem. It produces a bunch of BUGs at startup looking like
this:

BUG: Bad page state in process swapper  pfn:70800
page:be60c000 count:0 mapcount:-127 mapping:  (null) index:0x1
flags: 0x80000000()
raw: 80000000 00000000 00000001 ffffff80 00000000 be60c014 be60c014 0000000a
page dumped because: nonzero mapcount
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Tainted: G    B            4.16.0-rc1-00015-g7928b2cbe55b-dirty #23
Stack:
 bd839d33 00000000 00000018 ba97b64c a106578c bd839d70 be60c000 00000000
 a1378054 bd86a000 00000003 ba97b64c a1066166 bd839da0 be60c000 ffe00000
 a1066b58 bd839dc0 be504000 00000000 000002f4 bd838000 00000000 0000001e
Call Trace:
 [&lt;a1065734&gt;] bad_page+0xac/0xd0
 [&lt;a106578c&gt;] free_pages_check_bad+0x34/0x4c
 [&lt;a1066166&gt;] __free_pages_ok+0xae/0x14c
 [&lt;a1066b58&gt;] __free_pages+0x30/0x64
 [&lt;a1365de5&gt;] init_cma_reserved_pageblock+0x35/0x44
 [&lt;a13682dc&gt;] cma_init_reserved_areas+0xf4/0x148
 [&lt;a10034b8&gt;] do_one_initcall+0x80/0xf8
 [&lt;a1361c16&gt;] kernel_init_freeable+0xda/0x13c
 [&lt;a125b59d&gt;] kernel_init+0x9/0xd0
 [&lt;a1004304&gt;] ret_from_kernel_thread+0xc/0x18

Only free high memory pages that are not reserved.

Cc: stable@vger.kernel.org
Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6ac5a11dc674bc5016ea716e8082fff61f524dc1 upstream.

Xtensa memory initialization code frees high memory pages without
checking whether they are in the reserved memory regions or not. That
results in invalid value of totalram_pages and duplicate page usage by
CMA and highmem. It produces a bunch of BUGs at startup looking like
this:

BUG: Bad page state in process swapper  pfn:70800
page:be60c000 count:0 mapcount:-127 mapping:  (null) index:0x1
flags: 0x80000000()
raw: 80000000 00000000 00000001 ffffff80 00000000 be60c014 be60c014 0000000a
page dumped because: nonzero mapcount
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Tainted: G    B            4.16.0-rc1-00015-g7928b2cbe55b-dirty #23
Stack:
 bd839d33 00000000 00000018 ba97b64c a106578c bd839d70 be60c000 00000000
 a1378054 bd86a000 00000003 ba97b64c a1066166 bd839da0 be60c000 ffe00000
 a1066b58 bd839dc0 be504000 00000000 000002f4 bd838000 00000000 0000001e
Call Trace:
 [&lt;a1065734&gt;] bad_page+0xac/0xd0
 [&lt;a106578c&gt;] free_pages_check_bad+0x34/0x4c
 [&lt;a1066166&gt;] __free_pages_ok+0xae/0x14c
 [&lt;a1066b58&gt;] __free_pages+0x30/0x64
 [&lt;a1365de5&gt;] init_cma_reserved_pageblock+0x35/0x44
 [&lt;a13682dc&gt;] cma_init_reserved_areas+0xf4/0x148
 [&lt;a10034b8&gt;] do_one_initcall+0x80/0xf8
 [&lt;a1361c16&gt;] kernel_init_freeable+0xda/0x13c
 [&lt;a125b59d&gt;] kernel_init+0x9/0xd0
 [&lt;a1004304&gt;] ret_from_kernel_thread+0xc/0x18

Only free high memory pages that are not reserved.

Cc: stable@vger.kernel.org
Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xtensa: fix futex_atomic_cmpxchg_inatomic</title>
<updated>2018-02-17T12:21:19+00:00</updated>
<author>
<name>Max Filippov</name>
<email>jcmvbkbc@gmail.com</email>
</author>
<published>2018-01-05T22:27:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2d4e295284a9614726cf02b3da1bb2591ec60770'/>
<id>2d4e295284a9614726cf02b3da1bb2591ec60770</id>
<content type='text'>
commit ca47480921587ae30417dd234a9f79af188e3666 upstream.

Return 0 if the operation was successful, not the userspace memory
value. Check that userspace value equals passed oldval, not itself.
Don't update *uval if the value wasn't read from userspace memory.

This fixes process hang due to infinite loop in futex_lock_pi.
It also fixes a bunch of glibc tests nptl/tst-mutexpi*.

Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ca47480921587ae30417dd234a9f79af188e3666 upstream.

Return 0 if the operation was successful, not the userspace memory
value. Check that userspace value equals passed oldval, not itself.
Don't update *uval if the value wasn't read from userspace memory.

This fixes process hang due to infinite loop in futex_lock_pi.
It also fixes a bunch of glibc tests nptl/tst-mutexpi*.

Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xtensa: don't limit csum_partial export by CONFIG_NET</title>
<updated>2017-08-16T20:43:16+00:00</updated>
<author>
<name>Max Filippov</name>
<email>jcmvbkbc@gmail.com</email>
</author>
<published>2017-08-01T18:02:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a311810903c700ff7411be16489df09ad6f3faee'/>
<id>a311810903c700ff7411be16489df09ad6f3faee</id>
<content type='text'>
commit 7f81e55c737a8fa82c71f290945d729a4902f8d2 upstream.

csum_partial and csum_partial_copy_generic are defined unconditionally
and are available even when CONFIG_NET is disabled. They are used not
only by the network drivers, but also by scsi and media.
Don't limit these functions export by CONFIG_NET.

Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7f81e55c737a8fa82c71f290945d729a4902f8d2 upstream.

csum_partial and csum_partial_copy_generic are defined unconditionally
and are available even when CONFIG_NET is disabled. They are used not
only by the network drivers, but also by scsi and media.
Don't limit these functions export by CONFIG_NET.

Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xtensa: mm/cache: add missing EXPORT_SYMBOLs</title>
<updated>2017-08-16T20:43:15+00:00</updated>
<author>
<name>Max Filippov</name>
<email>jcmvbkbc@gmail.com</email>
</author>
<published>2017-08-01T18:15:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a3ab0f069f466acb7da4f960d8e1bc3cfdf1309e'/>
<id>a3ab0f069f466acb7da4f960d8e1bc3cfdf1309e</id>
<content type='text'>
commit bc652eb6a0d5cffaea7dc8e8ad488aab2a1bf1ed upstream.

Functions clear_user_highpage, copy_user_highpage, flush_dcache_page,
local_flush_cache_range and local_flush_cache_page may be used from
modules. Export them.

Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bc652eb6a0d5cffaea7dc8e8ad488aab2a1bf1ed upstream.

Functions clear_user_highpage, copy_user_highpage, flush_dcache_page,
local_flush_cache_range and local_flush_cache_page may be used from
modules. Export them.

Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xtensa: fix cache aliasing handling code for WT cache</title>
<updated>2017-08-16T20:43:15+00:00</updated>
<author>
<name>Max Filippov</name>
<email>jcmvbkbc@gmail.com</email>
</author>
<published>2017-07-29T00:42:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=03973c57e1a27de080ed06a3961f1d6afec27539'/>
<id>03973c57e1a27de080ed06a3961f1d6afec27539</id>
<content type='text'>
commit 6d0f581d1768d3eaba15776e7dd1fdfec10cfe36 upstream.

Currently building kernel for xtensa core with aliasing WT cache fails
with the following messages:

  mm/memory.c:2152: undefined reference to `flush_dcache_page'
  mm/memory.c:2332: undefined reference to `local_flush_cache_page'
  mm/memory.c:1919: undefined reference to `local_flush_cache_range'
  mm/memory.c:4179: undefined reference to `copy_to_user_page'
  mm/memory.c:4183: undefined reference to `copy_from_user_page'

This happens because implementation of these functions is only compiled
when data cache is WB, which looks wrong: even when data cache doesn't
need flushing it still needs invalidation. The functions like
__flush_[invalidate_]dcache_* are correctly defined for both WB and WT
caches (and even if they weren't that'd still be ok, just slower).

Fix this by providing the same implementation of the above functions for
both WB and WT cache.

Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6d0f581d1768d3eaba15776e7dd1fdfec10cfe36 upstream.

Currently building kernel for xtensa core with aliasing WT cache fails
with the following messages:

  mm/memory.c:2152: undefined reference to `flush_dcache_page'
  mm/memory.c:2332: undefined reference to `local_flush_cache_page'
  mm/memory.c:1919: undefined reference to `local_flush_cache_range'
  mm/memory.c:4179: undefined reference to `copy_to_user_page'
  mm/memory.c:4183: undefined reference to `copy_from_user_page'

This happens because implementation of these functions is only compiled
when data cache is WB, which looks wrong: even when data cache doesn't
need flushing it still needs invalidation. The functions like
__flush_[invalidate_]dcache_* are correctly defined for both WB and WT
caches (and even if they weren't that'd still be ok, just slower).

Fix this by providing the same implementation of the above functions for
both WB and WT cache.

Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mm: larger stack guard gap, between vmas</title>
<updated>2017-06-24T05:11:18+00:00</updated>
<author>
<name>Hugh Dickins</name>
<email>hughd@google.com</email>
</author>
<published>2017-06-19T11:03:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cfc0eb403816c5c4f9667d959de5e22789b5421e'/>
<id>cfc0eb403816c5c4f9667d959de5e22789b5421e</id>
<content type='text'>
commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream.

Stack guard page is a useful feature to reduce a risk of stack smashing
into a different mapping. We have been using a single page gap which
is sufficient to prevent having stack adjacent to a different mapping.
But this seems to be insufficient in the light of the stack usage in
userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
which is 256kB or stack strings with MAX_ARG_STRLEN.

This will become especially dangerous for suid binaries and the default
no limit for the stack size limit because those applications can be
tricked to consume a large portion of the stack and a single glibc call
could jump over the guard page. These attacks are not theoretical,
unfortunatelly.

Make those attacks less probable by increasing the stack guard gap
to 1MB (on systems with 4k pages; but make it depend on the page size
because systems with larger base pages might cap stack allocations in
the PAGE_SIZE units) which should cover larger alloca() and VLA stack
allocations. It is obviously not a full fix because the problem is
somehow inherent, but it should reduce attack space a lot.

One could argue that the gap size should be configurable from userspace,
but that can be done later when somebody finds that the new 1MB is wrong
for some special case applications.  For now, add a kernel command line
option (stack_guard_gap) to specify the stack gap size (in page units).

Implementation wise, first delete all the old code for stack guard page:
because although we could get away with accounting one extra page in a
stack vma, accounting a larger gap can break userspace - case in point,
a program run with "ulimit -S -v 20000" failed when the 1MB gap was
counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
and strict non-overcommit mode.

Instead of keeping gap inside the stack vma, maintain the stack guard
gap as a gap between vmas: using vm_start_gap() in place of vm_start
(or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
places which need to respect the gap - mainly arch_get_unmapped_area(),
and and the vma tree's subtree_gap support for that.

Original-patch-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Original-patch-by: Michal Hocko &lt;mhocko@suse.com&gt;
Signed-off-by: Hugh Dickins &lt;hughd@google.com&gt;
Acked-by: Michal Hocko &lt;mhocko@suse.com&gt;
Tested-by: Helge Deller &lt;deller@gmx.de&gt; # parisc
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
[wt: backport to 4.11: adjust context]
[wt: backport to 4.9: adjust context ; kernel doc was not in admin-guide]
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream.

Stack guard page is a useful feature to reduce a risk of stack smashing
into a different mapping. We have been using a single page gap which
is sufficient to prevent having stack adjacent to a different mapping.
But this seems to be insufficient in the light of the stack usage in
userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
which is 256kB or stack strings with MAX_ARG_STRLEN.

This will become especially dangerous for suid binaries and the default
no limit for the stack size limit because those applications can be
tricked to consume a large portion of the stack and a single glibc call
could jump over the guard page. These attacks are not theoretical,
unfortunatelly.

Make those attacks less probable by increasing the stack guard gap
to 1MB (on systems with 4k pages; but make it depend on the page size
because systems with larger base pages might cap stack allocations in
the PAGE_SIZE units) which should cover larger alloca() and VLA stack
allocations. It is obviously not a full fix because the problem is
somehow inherent, but it should reduce attack space a lot.

One could argue that the gap size should be configurable from userspace,
but that can be done later when somebody finds that the new 1MB is wrong
for some special case applications.  For now, add a kernel command line
option (stack_guard_gap) to specify the stack gap size (in page units).

Implementation wise, first delete all the old code for stack guard page:
because although we could get away with accounting one extra page in a
stack vma, accounting a larger gap can break userspace - case in point,
a program run with "ulimit -S -v 20000" failed when the 1MB gap was
counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
and strict non-overcommit mode.

Instead of keeping gap inside the stack vma, maintain the stack guard
gap as a gap between vmas: using vm_start_gap() in place of vm_start
(or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
places which need to respect the gap - mainly arch_get_unmapped_area(),
and and the vma tree's subtree_gap support for that.

Original-patch-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Original-patch-by: Michal Hocko &lt;mhocko@suse.com&gt;
Signed-off-by: Hugh Dickins &lt;hughd@google.com&gt;
Acked-by: Michal Hocko &lt;mhocko@suse.com&gt;
Tested-by: Helge Deller &lt;deller@gmx.de&gt; # parisc
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
[wt: backport to 4.11: adjust context]
[wt: backport to 4.9: adjust context ; kernel doc was not in admin-guide]
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xtensa: don't use linux IRQ #0</title>
<updated>2017-06-17T04:41:58+00:00</updated>
<author>
<name>Max Filippov</name>
<email>jcmvbkbc@gmail.com</email>
</author>
<published>2017-06-05T09:43:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a2f68276822cd3a09ed9ae23e5c5e1cd8259af65'/>
<id>a2f68276822cd3a09ed9ae23e5c5e1cd8259af65</id>
<content type='text'>
commit e5c86679d5e864947a52fb31e45a425dea3e7fa9 upstream.

Linux IRQ #0 is reserved for error reporting and may not be used.
Increase NR_IRQS for one additional slot and increase
irq_domain_add_legacy parameter first_irq value to 1, so that linux
IRQ #0 is not associated with hardware IRQ #0 in legacy IRQ domains.
Introduce macro XTENSA_PIC_LINUX_IRQ for static translation of xtensa
PIC hardware IRQ # to linux IRQ #. Use this macro in XTFPGA platform
data definitions.

This fixes inability to use hardware IRQ #0 in configurations that don't
use device tree and allows for non-identity mapping between linux IRQ #
and hardware IRQ #.

Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e5c86679d5e864947a52fb31e45a425dea3e7fa9 upstream.

Linux IRQ #0 is reserved for error reporting and may not be used.
Increase NR_IRQS for one additional slot and increase
irq_domain_add_legacy parameter first_irq value to 1, so that linux
IRQ #0 is not associated with hardware IRQ #0 in legacy IRQ domains.
Introduce macro XTENSA_PIC_LINUX_IRQ for static translation of xtensa
PIC hardware IRQ # to linux IRQ #. Use this macro in XTFPGA platform
data definitions.

This fixes inability to use hardware IRQ #0 in configurations that don't
use device tree and allows for non-identity mapping between linux IRQ #
and hardware IRQ #.

Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xtensa: make __pa work with uncached KSEG addresses</title>
<updated>2017-04-12T10:41:14+00:00</updated>
<author>
<name>Max Filippov</name>
<email>jcmvbkbc@gmail.com</email>
</author>
<published>2017-03-29T22:44:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6a776f6ae3f8b27a55c7d3479b7a6f13bc5e54bd'/>
<id>6a776f6ae3f8b27a55c7d3479b7a6f13bc5e54bd</id>
<content type='text'>
commit 2b83878dd74a7c73bedcb6600663c1c46836e8af upstream.

When __pa is applied to virtual address in uncached KSEG region the
result is incorrect. Fix it by checking if the original address is in
the uncached KSEG and adjusting the result. It looks better than masking
off bits because pfn_valid would correctly work with new __pa results
and it may be made working in noMMU case, once we get definition for
uncached memory view.

This is required for the dma_common_mmap and DMA debug code to work
correctly: they both indirectly use __pa with coherent DMA addresses.
In case of DMA debug the visible effect is false reports that an address
mapped for DMA is accessed by CPU.

Tested-by: Boris Brezillon &lt;boris.brezillon@free-electrons.com&gt;
Reviewed-by: Boris Brezillon &lt;boris.brezillon@free-electrons.com&gt;
Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2b83878dd74a7c73bedcb6600663c1c46836e8af upstream.

When __pa is applied to virtual address in uncached KSEG region the
result is incorrect. Fix it by checking if the original address is in
the uncached KSEG and adjusting the result. It looks better than masking
off bits because pfn_valid would correctly work with new __pa results
and it may be made working in noMMU case, once we get definition for
uncached memory view.

This is required for the dma_common_mmap and DMA debug code to work
correctly: they both indirectly use __pa with coherent DMA addresses.
In case of DMA debug the visible effect is false reports that an address
mapped for DMA is accessed by CPU.

Tested-by: Boris Brezillon &lt;boris.brezillon@free-electrons.com&gt;
Reviewed-by: Boris Brezillon &lt;boris.brezillon@free-electrons.com&gt;
Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xtensa: move parse_tag_fdt out of #ifdef CONFIG_BLK_DEV_INITRD</title>
<updated>2017-03-15T02:02:47+00:00</updated>
<author>
<name>Max Filippov</name>
<email>jcmvbkbc@gmail.com</email>
</author>
<published>2017-01-03T17:37:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a7b9c9ddb6f457bab2fc8527ffccf16eefba4af4'/>
<id>a7b9c9ddb6f457bab2fc8527ffccf16eefba4af4</id>
<content type='text'>
commit 4ab18701c66552944188dbcd0ce0012729baab84 upstream.

FDT tag parsing is not related to whether BLK_DEV_INITRD is configured
or not, move it out of the corresponding #ifdef/#endif block.
This fixes passing external FDT to the kernel configured w/o
BLK_DEV_INITRD support.

Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4ab18701c66552944188dbcd0ce0012729baab84 upstream.

FDT tag parsing is not related to whether BLK_DEV_INITRD is configured
or not, move it out of the corresponding #ifdef/#endif block.
This fixes passing external FDT to the kernel configured w/o
BLK_DEV_INITRD support.

Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
