<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/mips/mm, branch linux-4.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.1.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.1.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2018-05-23T01:36:28Z</updated>
<entry>
<title>MIPS: mm: fixed mappings: correct initialisation</title>
<updated>2018-05-23T01:36:28Z</updated>
<author>
<name>Marcin Nowakowski</name>
</author>
<published>2017-04-11T07:00:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=68e304e868fcaf9241b6ca1f00a3fcdd7c3620a6'/>
<id>urn:sha1:68e304e868fcaf9241b6ca1f00a3fcdd7c3620a6</id>
<content type='text'>
[ Upstream commit 71eb989ab5a110df8bcbb9609bacde73feacbedd ]

fixrange_init operates at PMD-granularity and expects the addresses to
be PMD-size aligned, but currently that might not be the case for
PKMAP_BASE unless it is defined properly, so ensure a correct alignment
is used before passing the address to fixrange_init.

fixed mappings: only align the start address that is passed to
fixrange_init rather than the value before adding the size, as we may
end up with uninitialised upper part of the range.

Signed-off-by: Marcin Nowakowski &lt;marcin.nowakowski@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15948/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>MIPS: IP22: Reformat inline assembler code to modern standards.</title>
<updated>2018-01-17T17:25:48Z</updated>
<author>
<name>Ralf Baechle</name>
</author>
<published>2016-12-15T11:27:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=aab728f85cfcce7db6d6b9d1578d8a39e33d9a86'/>
<id>urn:sha1:aab728f85cfcce7db6d6b9d1578d8a39e33d9a86</id>
<content type='text'>
[ Upstream commit f9f1c8db1c37253805eaa32265e1e1af3ae7d0a4 ]

Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>MIPS: microMIPS: Fix incorrect mask in insn_table_MM</title>
<updated>2017-12-07T02:20:01Z</updated>
<author>
<name>Gustavo A. R. Silva</name>
</author>
<published>2017-10-31T05:35:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cf9dfe611df7fed447c8d09943704dafa8cf87da'/>
<id>urn:sha1:cf9dfe611df7fed447c8d09943704dafa8cf87da</id>
<content type='text'>
[ Upstream commit 77238e76b9156d28d86c1e31c00ed2960df0e4de ]

It seems that this is a typo error and the proper bit masking is
"RT | RS" instead of "RS | RS".

This issue was detected with the help of Coccinelle.

Fixes: d6b3314b49e1 ("MIPS: uasm: Add lh uam instruction")
Reported-by: Julia Lawall &lt;julia.lawall@lip6.fr&gt;
Signed-off-by: Gustavo A. R. Silva &lt;garsilva@embeddedor.com&gt;
Reviewed-by: James Hogan &lt;jhogan@kernel.org&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 3.16+
Patchwork: https://patchwork.linux-mips.org/patch/17551/
Signed-off-by: James Hogan &lt;jhogan@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>mm: larger stack guard gap, between vmas</title>
<updated>2017-06-28T22:57:15Z</updated>
<author>
<name>Sasha Levin</name>
</author>
<published>2017-06-28T22:57:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8b18c6b2a0dde5186ed83a60c4915c0909cbeb0a'/>
<id>urn:sha1:8b18c6b2a0dde5186ed83a60c4915c0909cbeb0a</id>
<content type='text'>
[ Upstream commit 1be7107fbe18eed3e319a6c3e83c78254b693acb ]

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;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>MIPS: mm: Fix definition of R6 cache instruction</title>
<updated>2016-08-20T03:08:34Z</updated>
<author>
<name>Matt Redfearn</name>
</author>
<published>2016-06-14T13:59:38Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=333c2cf51f6a01388d4e5962ed585176ef7b6a86'/>
<id>urn:sha1:333c2cf51f6a01388d4e5962ed585176ef7b6a86</id>
<content type='text'>
[ Upstream commit 4f53989b0652ffe2605221c81ca8ffcfc90aed2a ]

Commit a168b8f1cde6 ("MIPS: mm: Add MIPS R6 instruction encodings") added
an incorrect definition of the redefined MIPSr6 cache instruction.

Executing any kernel code including this instuction results in a
reserved instruction exception and kernel panic.

Fix the instruction definition.

Fixes: a168b8f1cde6588ff7a67699fa11e01bc77a5ddd
Signed-off-by: Matt Redfearn &lt;matt.redfearn@imgtec.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 4.x-
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13663/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>MIPS: Sync icache &amp; dcache in set_pte_at</title>
<updated>2016-06-06T23:12:19Z</updated>
<author>
<name>Paul Burton</name>
</author>
<published>2016-03-01T02:37:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=de444b25c68049fb560e0530ee0425fd9db981f0'/>
<id>urn:sha1:de444b25c68049fb560e0530ee0425fd9db981f0</id>
<content type='text'>
[ Upstream commit 37d22a0d798b5c938b277d32cfd86dc231381342 ]

It's possible for pages to become visible prior to update_mmu_cache
running if a thread within the same address space preempts the current
thread or runs simultaneously on another CPU. That is, the following
scenario is possible:

    CPU0                            CPU1

    write to page
    flush_dcache_page
    flush_icache_page
    set_pte_at
                                    map page
    update_mmu_cache

If CPU1 maps the page in between CPU0's set_pte_at, which marks it valid
&amp; visible, and update_mmu_cache where the dcache flush occurs then CPU1s
icache will fill from stale data (unless it fills from the dcache, in
which case all is good, but most MIPS CPUs don't have this property).
Commit 4d46a67a3eb8 ("MIPS: Fix race condition in lazy cache flushing.")
attempted to fix that by performing the dcache flush in
flush_icache_page such that it occurs before the set_pte_at call makes
the page visible. However it has the problem that not all code that
writes to pages exposed to userland call flush_icache_page. There are
many callers of set_pte_at under mm/ and only 2 of them do call
flush_icache_page. Thus the race window between a page becoming visible
&amp; being coherent between the icache &amp; dcache remains open in some cases.

To illustrate some of the cases, a WARN was added to __update_cache with
this patch applied that triggered in cases where a page about to be
flushed from the dcache was not the last page provided to
flush_icache_page. That is, backtraces were obtained for cases in which
the race window is left open without this patch. The 2 standout examples
follow.

When forking a process:

[   15.271842] [&lt;80417630&gt;] __update_cache+0xcc/0x188
[   15.277274] [&lt;80530394&gt;] copy_page_range+0x56c/0x6ac
[   15.282861] [&lt;8042936c&gt;] copy_process.part.54+0xd40/0x17ac
[   15.289028] [&lt;80429f80&gt;] do_fork+0xe4/0x420
[   15.293747] [&lt;80413808&gt;] handle_sys+0x128/0x14c

When exec'ing an ELF binary:

[   14.445964] [&lt;80417630&gt;] __update_cache+0xcc/0x188
[   14.451369] [&lt;80538d88&gt;] move_page_tables+0x414/0x498
[   14.457075] [&lt;8055d848&gt;] setup_arg_pages+0x220/0x318
[   14.462685] [&lt;805b0f38&gt;] load_elf_binary+0x530/0x12a0
[   14.468374] [&lt;8055ec3c&gt;] search_binary_handler+0xbc/0x214
[   14.474444] [&lt;8055f6c0&gt;] do_execveat_common+0x43c/0x67c
[   14.480324] [&lt;8055f938&gt;] do_execve+0x38/0x44
[   14.485137] [&lt;80413808&gt;] handle_sys+0x128/0x14c

These code paths write into a page, call flush_dcache_page then call
set_pte_at without flush_icache_page inbetween. The end result is that
the icache can become corrupted &amp; userland processes may execute
unexpected or invalid code, typically resulting in a reserved
instruction exception, a trap or a segfault.

Fix this race condition fully by performing any cache maintenance
required to keep the icache &amp; dcache in sync in set_pte_at, before the
page is made valid. This has the added bonus of ensuring the cache
maintenance always happens in one location, rather than being duplicated
in flush_icache_page &amp; update_mmu_cache. It also matches the way other
architectures solve the same problem (see arm, ia64 &amp; powerpc).

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
Reported-by: Ionela Voinescu &lt;ionela.voinescu@imgtec.com&gt;
Cc: Lars Persson &lt;lars.persson@axis.com&gt;
Fixes: 4d46a67a3eb8 ("MIPS: Fix race condition in lazy cache flushing.")
Cc: Steven J. Hill &lt;sjhill@realitydiluted.com&gt;
Cc: David Daney &lt;david.daney@cavium.com&gt;
Cc: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: Aneesh Kumar K.V &lt;aneesh.kumar@linux.vnet.ibm.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Jerome Marchand &lt;jmarchan@redhat.com&gt;
Cc: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: stable &lt;stable@vger.kernel.org&gt; # v4.1+
Patchwork: https://patchwork.linux-mips.org/patch/12722/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>MIPS: Handle highmem pages in __update_cache</title>
<updated>2016-06-06T23:12:19Z</updated>
<author>
<name>Paul Burton</name>
</author>
<published>2016-03-01T02:37:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8c99d76129a9a429a9410df4811b13c091aaa889'/>
<id>urn:sha1:8c99d76129a9a429a9410df4811b13c091aaa889</id>
<content type='text'>
[ Upstream commit f4281bba818105c7c91799abe40bc05c0dbdaa25 ]

The following patch will expose __update_cache to highmem pages. Handle
them by mapping them in for the duration of the cache maintenance, just
like in __flush_dcache_page. The code for that isn't shared because we
need the page address in __update_cache so sharing became messy. Given
that the entirity is an extra 5 lines, just duplicate it.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: Lars Persson &lt;lars.persson@axis.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Jerome Marchand &lt;jmarchan@redhat.com&gt;
Cc: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: stable &lt;stable@vger.kernel.org&gt; # v4.1+
Patchwork: https://patchwork.linux-mips.org/patch/12721/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>MIPS: Flush highmem pages in __flush_dcache_page</title>
<updated>2016-06-06T23:12:19Z</updated>
<author>
<name>Paul Burton</name>
</author>
<published>2016-03-01T02:37:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e7c735b01d8fdfd7215a133dfe9072d73502acfd'/>
<id>urn:sha1:e7c735b01d8fdfd7215a133dfe9072d73502acfd</id>
<content type='text'>
[ Upstream commit 234859e49a15323cf1b2331bdde7f658c4cb45fb ]

When flush_dcache_page is called on an executable page, that page is
about to be provided to userland &amp; we can presume that the icache
contains no valid entries for its address range. However if the icache
does not fill from the dcache then we cannot presume that the pages
content has been written back as far as the memories that the dcache
will fill from (ie. L2 or further out).

This was being done for lowmem pages, but not for highmem which can lead
to icache corruption. Fix this by mapping highmem pages &amp; flushing their
content from the dcache in __flush_dcache_page before providing the page
to userland, just as is done for lowmem pages.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: Lars Persson &lt;lars.persson@axis.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12720/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>MIPS: Fix some missing CONFIG_CPU_MIPSR6 #ifdefs</title>
<updated>2016-02-15T20:45:26Z</updated>
<author>
<name>Huacai Chen</name>
</author>
<published>2016-01-21T13:09:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4470ba0e8a7f353cf3868eca475272d49605f823'/>
<id>urn:sha1:4470ba0e8a7f353cf3868eca475272d49605f823</id>
<content type='text'>
[ Upstream commit 4f33f6c522948fffc345261896042b58dea23754 ]

Commit be0c37c985eddc4 (MIPS: Rearrange PTE bits into fixed positions.)
defines fixed PTE bits for MIPS R2. Then, commit d7b631419b3d230a4d383
(MIPS: pgtable-bits: Fix XPA damage to R6 definitions.) adds the MIPS
R6 definitions in the same way as MIPS R2. But some R6 #ifdefs in the
later commit are missing, so in this patch I fix that.

Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: Aurelien Jarno &lt;aurelien@aurel32.net&gt;
Cc: Steven J. Hill &lt;Steven.Hill@imgtec.com&gt;
Cc: Fuxin Zhang &lt;zhangfx@lemote.com&gt;
Cc: Zhangjin Wu &lt;wuzhangjin@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12164/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>MIPS: dma-default: Fix 32-bit fall back to GFP_DMA</title>
<updated>2015-10-22T21:43:23Z</updated>
<author>
<name>James Hogan</name>
</author>
<published>2015-03-27T08:33:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=88108b384f4817c9f935ad0932e2fce80d790a2e'/>
<id>urn:sha1:88108b384f4817c9f935ad0932e2fce80d790a2e</id>
<content type='text'>
commit 53960059d56ecef67d4ddd546731623641a3d2d1 upstream.

If there is a DMA zone (usually 24bit = 16MB I believe), but no DMA32
zone, as is the case for some 32-bit kernels, then massage_gfp_flags()
will cause DMA memory allocated for devices with a 32..63-bit
coherent_dma_mask to fall back to using __GFP_DMA, even though there may
only be 32-bits of physical address available anyway.

Correct that case to compare against a mask the size of phys_addr_t
instead of always using a 64-bit mask.

Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Fixes: a2e715a86c6d ("MIPS: DMA: Fix computation of DMA flags from device's coherent_dma_mask.")
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9610/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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