linux.git/arch/mips/include, branch v4.14.98

MIPS: Only include mmzone.h when CONFIG_NEED_MULTIPLE_NODES=y

2019-01-09T16:14:53+00:00

commit 66a4059ba72c23ae74a7c702894ff76c4b7eac1f upstream.

MIPS' asm/mmzone.h includes the machine/platform mmzone.h
unconditionally, but since commit bb53fdf395ee ("MIPS: c-r4k: Add
r4k_blast_scache_node for Loongson-3") is included by asm/rk4cache.h for
all r4k-style configs regardless of CONFIG_NEED_MULTIPLE_NODES.

This is problematic when CONFIG_NEED_MULTIPLE_NODES=n because both the
loongson3 & ip27 mmzone.h headers unconditionally define the NODE_DATA
preprocessor macro which is aready defined by linux/mmzone.h, resulting
in the following build error:

  In file included from ./arch/mips/include/asm/mmzone.h:10,
                   from ./arch/mips/include/asm/r4kcache.h:23,
                   from arch/mips/mm/c-r4k.c:33:
  ./arch/mips/include/asm/mach-loongson64/mmzone.h:48: error: "NODE_DATA" redefined [-Werror]
   #define NODE_DATA(n)  (&__node_data[(n)]->pglist)

  In file included from ./include/linux/topology.h:32,
                   from ./include/linux/irq.h:19,
                   from ./include/asm-generic/hardirq.h:13,
                   from ./arch/mips/include/asm/hardirq.h:16,
                   from ./include/linux/hardirq.h:9,
                   from arch/mips/mm/c-r4k.c:11:
  ./include/linux/mmzone.h:907: note: this is the location of the previous definition
   #define NODE_DATA(nid)  (&contig_page_data)

Resolve this by only including the machine mmzone.h when
CONFIG_NEED_MULTIPLE_NODES=y, which also removes the need for the empty
mach-generic version of the header which we delete.

Signed-off-by: Paul Burton 
Fixes: bb53fdf395ee ("MIPS: c-r4k: Add r4k_blast_scache_node for Loongson-3")
Signed-off-by: Greg Kroah-Hartman

MIPS: Expand MIPS32 ASIDs to 64 bits

2019-01-09T16:14:52+00:00

commit ff4dd232ec45a0e45ea69f28f069f2ab22b4908a upstream.

ASIDs have always been stored as unsigned longs, ie. 32 bits on MIPS32
kernels. This is problematic because it is feasible for the ASID version
to overflow & wrap around to zero.

We currently attempt to handle this overflow by simply setting the ASID
version to 1, using asid_first_version(), but we make no attempt to
account for the fact that there may be mm_structs with stale ASIDs that
have versions which we now reuse due to the overflow & wrap around.

Encountering this requires that:

  1) A struct mm_struct X is active on CPU A using ASID (V,n).

  2) That mm is not used on CPU A for the length of time that it takes
     for CPU A's asid_cache to overflow & wrap around to the same
     version V that the mm had in step 1. During this time tasks using
     the mm could either be sleeping or only scheduled on other CPUs.

  3) Some other mm Y becomes active on CPU A and is allocated the same
     ASID (V,n).

  4) mm X now becomes active on CPU A again, and now incorrectly has the
     same ASID as mm Y.

Where struct mm_struct ASIDs are represented above in the format
(version, EntryHi.ASID), and on a typical MIPS32 system version will be
24 bits wide & EntryHi.ASID will be 8 bits wide.

The length of time required in step 2 is highly dependent upon the CPU &
workload, but for a hypothetical 2GHz CPU running a workload which
generates a new ASID every 10000 cycles this period is around 248 days.
Due to this long period of time & the fact that tasks need to be
scheduled in just the right (or wrong, depending upon your inclination)
way, this is obviously a difficult bug to encounter but it's entirely
possible as evidenced by reports.

In order to fix this, simply extend ASIDs to 64 bits even on MIPS32
builds. This will extend the period of time required for the
hypothetical system above to encounter the problem from 28 days to
around 3 trillion years, which feels safely outside of the realms of
possibility.

The cost of this is slightly more generated code in some commonly
executed paths, but this is pretty minimal:

                         | Code Size Gain | Percentage
  -----------------------|----------------|-------------
    decstation_defconfig |           +270 | +0.00%
        32r2el_defconfig |           +652 | +0.01%
        32r6el_defconfig |          +1000 | +0.01%

I have been unable to measure any change in performance of the LMbench
lat_ctx or lat_proc tests resulting from the 64b ASIDs on either
32r2el_defconfig+interAptiv or 32r6el_defconfig+I6500 systems.

Signed-off-by: Paul Burton 
Suggested-by: James Hogan 
References: https://lore.kernel.org/linux-mips/80B78A8B8FEE6145A87579E8435D78C30205D5F3@fzex.ruijie.com.cn/
References: https://lore.kernel.org/linux-mips/1488684260-18867-1-git-send-email-jiwei.sun@windriver.com/
Cc: Jiwei Sun 
Cc: Yu Huabing 
Cc: stable@vger.kernel.org # 2.6.12+
Cc: linux-mips@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

MIPS: Ensure pmd_present() returns false after pmd_mknotpresent()

2019-01-09T16:14:52+00:00

commit 92aa0718c9fa5160ad2f0e7b5bffb52f1ea1e51a upstream.

This patch is borrowed from ARM64 to ensure pmd_present() returns false
after pmd_mknotpresent(). This is needed for THP.

References: 5bb1cc0ff9a6 ("arm64: Ensure pmd_present() returns false after pmd_mknotpresent()")
Reviewed-by: James Hogan 
Signed-off-by: Huacai Chen 
Signed-off-by: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/21135/
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: Steven J . Hill 
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang 
Cc: Zhangjin Wu 
Cc:  # 3.8+
Signed-off-by: Greg Kroah-Hartman

MIPS: c-r4k: Add r4k_blast_scache_node for Loongson-3

2019-01-09T16:14:52+00:00

commit bb53fdf395eed103f85061bfff3b116cee123895 upstream.

For multi-node Loongson-3 (NUMA configuration), r4k_blast_scache() can
only flush Node-0's scache. So we add r4k_blast_scache_node() by using
(CAC_BASE | (node_id << NODE_ADDRSPACE_SHIFT)) instead of CKSEG0 as the
start address.

Signed-off-by: Huacai Chen 
[paul.burton@mips.com: Include asm/mmzone.h from asm/r4kcache.h for
		       nid_to_addrbase(). Add asm/mach-generic/mmzone.h
		       to allow inclusion for all platforms.]
Signed-off-by: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/21129/
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: Steven J . Hill 
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang 
Cc: Zhangjin Wu 
Cc:  # 3.15+
Signed-off-by: Greg Kroah-Hartman

mips: fix mips_get_syscall_arg o32 check

2018-12-08T12:03:37+00:00

commit c50cbd85cd7027d32ac5945bb60217936b4f7eaf upstream.

When checking for TIF_32BIT_REGS flag, mips_get_syscall_arg() should
use the task specified as its argument instead of the current task.

This potentially affects all syscall_get_arguments() users
who specify tasks different from the current.

Fixes: c0ff3c53d4f99 ("MIPS: Enable HAVE_ARCH_TRACEHOOK.")
Signed-off-by: Dmitry V. Levin 
Signed-off-by: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/21185/
Cc: Elvira Khabirova 
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: Greg Kroah-Hartman

MIPS: Loongson-3: Fix BRIDGE irq delivery problem

2018-11-21T08:24:06+00:00

[ Upstream commit 360fe725f8849aaddc53475fef5d4a0c439b05ae ]

After commit e509bd7da149dc349160 ("genirq: Allow migration of chained
interrupts by installing default action") Loongson-3 fails at here:

setup_irq(LOONGSON_HT1_IRQ, &cascade_irqaction);

This is because both chained_action and cascade_irqaction don't have
IRQF_SHARED flag. This will cause Loongson-3 resume fails because HPET
timer interrupt can't be delivered during S3. So we set the irqchip of
the chained irq to loongson_irq_chip which doesn't disable the chained
irq in CP0.Status.

Cc: stable@vger.kernel.org
Signed-off-by: Huacai Chen 
Signed-off-by: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/20434/
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang 
Cc: Zhangjin Wu 
Cc: Huacai Chen 
Signed-off-by: Sasha Levin

MIPS: Workaround GCC __builtin_unreachable reordering bug

2018-11-04T13:52:44+00:00

[ Upstream commit 906d441febc0de974b2a6ef848a8f058f3bfada3 ]

Some versions of GCC for the MIPS architecture suffer from a bug which
can lead to instructions from beyond an unreachable statement being
incorrectly reordered into earlier branch delay slots if the unreachable
statement is the only content of a case in a switch statement. This can
lead to seemingly random behaviour, such as invalid memory accesses from
incorrectly reordered loads or stores, and link failures on microMIPS
builds.

See this potential GCC fix for details:

    https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html

Runtime problems resulting from this bug were initially observed using a
maltasmvp_defconfig v4.4 kernel built using GCC 4.9.2 (from a Codescape
SDK 2015.06-05 toolchain), with the result being an address exception
taken after log messages about the L1 caches (during probe of the L2
cache):

    Initmem setup node 0 [mem 0x0000000080000000-0x000000009fffffff]
    VPE topology {2,2} total 4
    Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
    Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes
    

This is early enough that the kernel exception vectors are not in use,
so any further output depends upon the bootloader. This is reproducible
in QEMU where no further output occurs - ie. the system hangs here.
Given the nature of the bug it may potentially be hit with differing
symptoms. The bug is known to affect GCC versions as recent as 7.3, and
it is unclear whether GCC 8 fixed it or just happens not to encounter
the bug in the testcase found at the link above due to differing
optimizations.

This bug can be worked around by placing a volatile asm statement, which
GCC is prevented from reordering past, prior to the
__builtin_unreachable call.

That was actually done already for other reasons by commit 173a3efd3edb
("bug.h: work around GCC PR82365 in BUG()"), but creates problems for
microMIPS builds due to the lack of a .insn directive. The microMIPS ISA
allows for interlinking with regular MIPS32 code by repurposing bit 0 of
the program counter as an ISA mode bit. To switch modes one changes the
value of this bit in the PC. However typical branch instructions encode
their offsets as multiples of 2-byte instruction halfwords, which means
they cannot change ISA mode - this must be done using either an indirect
branch (a jump-register in MIPS terminology) or a dedicated jalx
instruction. In order to ensure that regular branches don't attempt to
target code in a different ISA which they can't actually switch to, the
linker will check that branch targets are code in the same ISA as the
branch.

Unfortunately our empty asm volatile statements don't qualify as code,
and the link for microMIPS builds fails with errors such as:

    arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA mode
    arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA mode

Resolve this by adding a .insn directive within the asm statement which
declares that what comes next is code. This may or may not be true,
since we don't really know what comes next, but as this code is in an
unreachable path anyway that doesn't matter since we won't execute it.

We do this in asm/compiler.h & select CONFIG_HAVE_ARCH_COMPILER_H in
order to have this included by linux/compiler_types.h after
linux/compiler-gcc.h. This will result in asm/compiler.h being included
in all C compilations via the -include linux/compiler_types.h argument
in c_flags, which should be harmless.

Signed-off-by: Paul Burton 
Fixes: 173a3efd3edb ("bug.h: work around GCC PR82365 in BUG()")
Patchwork: https://patchwork.linux-mips.org/patch/20270/
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: Arnd Bergmann 
Cc: linux-mips@linux-mips.org
Signed-off-by: Sasha Levin

MIPS: VDSO: Always map near top of user memory

2018-10-18T07:16:23+00:00

commit ea7e0480a4b695d0aa6b3fa99bd658a003122113 upstream.

When using the legacy mmap layout, for example triggered using ulimit -s
unlimited, get_unmapped_area() fills memory from bottom to top starting
from a fairly low address near TASK_UNMAPPED_BASE.

This placement is suboptimal if the user application wishes to allocate
large amounts of heap memory using the brk syscall. With the VDSO being
located low in the user's virtual address space, the amount of space
available for access using brk is limited much more than it was prior to
the introduction of the VDSO.

For example:

  # ulimit -s unlimited; cat /proc/self/maps
  00400000-004ec000 r-xp 00000000 08:00 71436      /usr/bin/coreutils
  004fc000-004fd000 rwxp 000ec000 08:00 71436      /usr/bin/coreutils
  004fd000-0050f000 rwxp 00000000 00:00 0
  00cc3000-00ce4000 rwxp 00000000 00:00 0          [heap]
  2ab96000-2ab98000 r--p 00000000 00:00 0          [vvar]
  2ab98000-2ab99000 r-xp 00000000 00:00 0          [vdso]
  2ab99000-2ab9d000 rwxp 00000000 00:00 0
  ...

Resolve this by adjusting STACK_TOP to reserve space for the VDSO &
providing an address hint to get_unmapped_area() causing it to use this
space even when using the legacy mmap layout.

We reserve enough space for the VDSO, plus 1MB or 256MB for 32 bit & 64
bit systems respectively within which we randomize the VDSO base
address. Previously this randomization was taken care of by the mmap
base address randomization performed by arch_mmap_rnd(). The 1MB & 256MB
sizes are somewhat arbitrary but chosen such that we have some
randomization without taking up too much of the user's virtual address
space, which is often in short supply for 32 bit systems.

With this the VDSO is always mapped at a high address, leaving lots of
space for statically linked programs to make use of brk:

  # ulimit -s unlimited; cat /proc/self/maps
  00400000-004ec000 r-xp 00000000 08:00 71436      /usr/bin/coreutils
  004fc000-004fd000 rwxp 000ec000 08:00 71436      /usr/bin/coreutils
  004fd000-0050f000 rwxp 00000000 00:00 0
  00c28000-00c49000 rwxp 00000000 00:00 0          [heap]
  ...
  7f67c000-7f69d000 rwxp 00000000 00:00 0          [stack]
  7f7fc000-7f7fd000 rwxp 00000000 00:00 0
  7fcf1000-7fcf3000 r--p 00000000 00:00 0          [vvar]
  7fcf3000-7fcf4000 r-xp 00000000 00:00 0          [vdso]

Signed-off-by: Paul Burton 
Reported-by: Huacai Chen 
Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Cc: Huacai Chen 
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Greg Kroah-Hartman

MIPS: ath79: fix system restart

2018-09-26T06:38:00+00:00

[ Upstream commit f8a7bfe1cb2c1ebfa07775c9c8ac0ad3ba8e5ff5 ]

This patch disables irq on reboot to fix hang issues that were observed
due to pending interrupts.

Signed-off-by: Felix Fietkau 
Signed-off-by: John Crispin 
Signed-off-by: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/19913/
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: linux-mips@linux-mips.org
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

MIPS: Fix ISA virt/bus conversion for non-zero PHYS_OFFSET

2018-09-19T20:43:41+00:00

[ Upstream commit 0494d7ffdcebc6935410ea0719b24ab626675351 ]

isa_virt_to_bus() & isa_bus_to_virt() claim to treat ISA bus addresses
as being identical to physical addresses, but they fail to do so in the
presence of a non-zero PHYS_OFFSET.

Correct this by having them use virt_to_phys() & phys_to_virt(), which
consolidates the calculations to one place & ensures that ISA bus
addresses do indeed match physical addresses.

Signed-off-by: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/20047/
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: linux-mips@linux-mips.org
Cc: Vladimir Kondratiev 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman