linux-stable.git/include/asm-generic, branch linux-3.18.y

asm-generic: Fix local variable shadow in __set_fixmap_offset

2019-04-03T04:22:09+00:00

[ Upstream commit 3694bd76781b76c4f8d2ecd85018feeb1609f0e5 ]

Currently __set_fixmap_offset is a macro function which has a local
variable called 'addr'. If a caller passes a 'phys' parameter which is
derived from a variable also called 'addr', the local variable will
shadow this, and the compiler will complain about the use of an
uninitialized variable. To avoid the issue with namespace clashes,
'addr' is prefixed with a liberal sprinkling of underscores.

Turning __set_fixmap_offset into a static inline breaks the build for
several architectures. Fixing this properly requires updates to a number
of architectures to make them agree on the prototype of __set_fixmap (it
could be done as a subsequent patch series).

Signed-off-by: Mark Rutland 
Cc: Arnd Bergmann 
[catalin.marinas@arm.com: squashed the original function patch and macro fixup]
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

asm-generic: provide generic_pmdp_establish()

2018-05-30T05:47:31+00:00

[ Upstream commit c58f0bb77ed8bf93dfdde762b01cb67eebbdfc29 ]

Patch series "Do not lose dirty bit on THP pages", v4.

Vlastimil noted that pmdp_invalidate() is not atomic and we can lose
dirty and access bits if CPU sets them after pmdp dereference, but
before set_pmd_at().

The bug can lead to data loss, but the race window is tiny and I haven't
seen any reports that suggested that it happens in reality.  So I don't
think it worth sending it to stable.

Unfortunately, there's no way to address the issue in a generic way.  We
need to fix all architectures that support THP one-by-one.

All architectures that have THP supported have to provide atomic
pmdp_invalidate() that returns previous value.

If generic implementation of pmdp_invalidate() is used, architecture
needs to provide atomic pmdp_estabish().

pmdp_estabish() is not used out-side generic implementation of
pmdp_invalidate() so far, but I think this can change in the future.

This patch (of 12):

This is an implementation of pmdp_establish() that is only suitable for
an architecture that doesn't have hardware dirty/accessed bits.  In this
case we can't race with CPU which sets these bits and non-atomic
approach is fine.

Link: http://lkml.kernel.org/r/20171213105756.69879-2-kirill.shutemov@linux.intel.com
Signed-off-by: Kirill A. Shutemov 
Cc: Vlastimil Babka 
Cc: Andrea Arcangeli 
Cc: Michal Hocko 
Cc: Aneesh Kumar K.V 
Cc: Catalin Marinas 
Cc: David Daney 
Cc: David Miller 
Cc: H. Peter Anvin 
Cc: Hugh Dickins 
Cc: Ingo Molnar 
Cc: Martin Schwidefsky 
Cc: Nitin Gupta 
Cc: Ralf Baechle 
Cc: Thomas Gleixner 
Cc: Vineet Gupta 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

cpumask: fix spurious cpumask_of_node() on non-NUMA multi-node configs

2017-09-07T06:32:20+00:00

commit b339752d054fb32863418452dff350a1086885b1 upstream.

When !NUMA, cpumask_of_node(@node) equals cpu_online_mask regardless of
@node.  The assumption seems that if !NUMA, there shouldn't be more than
one node and thus reporting cpu_online_mask regardless of @node is
correct.  However, that assumption was broken years ago to support
DISCONTIGMEM and whether a system has multiple nodes or not is
separately controlled by NEED_MULTIPLE_NODES.

This means that, on a system with !NUMA && NEED_MULTIPLE_NODES,
cpumask_of_node() will report cpu_online_mask for all possible nodes,
indicating that the CPUs are associated with multiple nodes which is an
impossible configuration.

This bug has been around forever but doesn't look like it has caused any
noticeable symptoms.  However, it triggers a WARN recently added to
workqueue to verify NUMA affinity configuration.

Fix it by reporting empty cpumask on non-zero nodes if !NUMA.

Signed-off-by: Tejun Heo 
Reported-and-tested-by: Geert Uytterhoeven 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Make asm/word-at-a-time.h available on all architectures

2017-08-11T16:30:13+00:00

commit a6e2f029ae34f41adb6ae3812c32c5d326e1abd2 upstream.

Added the x86 implementation of word-at-a-time to the
generic version, which previously only supported big-endian.

Omitted the x86-specific load_unaligned_zeropad(), which in
any case is also not present for the existing BE-only
implementation of a word-at-a-time, and is only used under
CONFIG_DCACHE_WORD_ACCESS.

Added as a "generic-y" to the Kbuilds of all architectures
that didn't previously have it.

Signed-off-by: Chris Metcalf 
Signed-off-by: Greg Kroah-Hartman

asm-generic: make get_user() clear the destination on errors

2016-10-06T02:40:20+00:00

[ Upstream commit 9ad18b75c2f6e4a78ce204e79f37781f8815c0fa ]

both for access_ok() failures and for faults halfway through

Cc: stable@vger.kernel.org
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin

asm-generic: {get,put}_user ptr argument evaluate only 1 time

2016-10-06T02:40:20+00:00

[ Upstream commit a02613a4ba679eacec8251976d02809d533fa717 ]

Current implemantation ptr argument evaluate 2 times.
It'll be an unexpected result.

Changes v5:
Remove unnecessary const.
Changes v4:
Temporary pointer type change to const void*
Changes v3:
Some build error fix.
Changes v2:
Argument x protect.

Signed-off-by: Yoshinori Sato 
Signed-off-by: Sasha Levin

asm-generic: make copy_from_user() zero the destination properly

2016-10-06T02:40:20+00:00

[ Upstream commit 2545e5da080b4839dd859e3b09343a884f6ab0e3 ]

... in all cases, including the failing access_ok()

Note that some architectures using asm-generic/uaccess.h have
__copy_from_user() not zeroing the tail on failure halfway
through.  This variant works either way.

Cc: stable@vger.kernel.org
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin

bitops: Do not default to __clear_bit() for __clear_bit_unlock()

2016-04-18T12:49:37+00:00

[ Upstream commit f75d48644c56a31731d17fa693c8175328957e1d ]

__clear_bit_unlock() is a special little snowflake. While it carries the
non-atomic '__' prefix, it is specifically documented to pair with
test_and_set_bit() and therefore should be 'somewhat' atomic.

Therefore the generic implementation of __clear_bit_unlock() cannot use
the fully non-atomic __clear_bit() as a default.

If an arch is able to do better; is must provide an implementation of
__clear_bit_unlock() itself.

Specifically, this came up as a result of hackbench livelock'ing in
slab_lock() on ARC with SMP + SLUB + !LLSC.

The issue was incorrect pairing of atomic ops.

 slab_lock() -> bit_spin_lock() -> test_and_set_bit()
 slab_unlock() -> __bit_spin_unlock() -> __clear_bit()

The non serializing __clear_bit() was getting "lost"

 80543b8e:	ld_s       r2,[r13,0] <--- (A) Finds PG_locked is set
 80543b90:	or         r3,r2,1    <--- (B) other core unlocks right here
 80543b94:	st_s       r3,[r13,0] <--- (C) sets PG_locked (overwrites unlock)

Fixes ARC STAR 9000817404 (and probably more).

Reported-by: Vineet Gupta 
Tested-by: Vineet Gupta 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Andrew Morton 
Cc: Christoph Lameter 
Cc: David Rientjes 
Cc: Helge Deller 
Cc: James E.J. Bottomley 
Cc: Joonsoo Kim 
Cc: Linus Torvalds 
Cc: Noam Camus 
Cc: Paul E. McKenney 
Cc: Pekka Enberg 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20160309114054.GJ6356@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

cputime: Prevent 32bit overflow in time[val|spec]_to_cputime()

2016-03-02T20:18:55+00:00

[ Upstream commit 0f26922fe5dc5724b1adbbd54b21bad03590b4f3 ]

The datatype __kernel_time_t is u32 on 32bit platform, so its subject to
overflows in the timeval/timespec to cputime conversion.

Currently the following functions are affected:
1. setitimer()
2. timer_create/timer_settime()
3. sys_clock_nanosleep

This can happen on MIPS32 and ARM32 with "Full dynticks CPU time accounting"
enabled, which is required for CONFIG_NO_HZ_FULL.

Enforce u64 conversion to prevent the overflow.

Fixes: 31c1fc818715 ("ARM: Kconfig: allow full nohz CPU accounting")
Signed-off-by: zengtao 
Reviewed-by: Arnd Bergmann 
Cc: 
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1454384314-154784-1-git-send-email-prime.zeng@huawei.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sasha Levin

mmu_gather: move minimal range calculations into generic code

2015-03-28T13:22:01+00:00

[ Upstream commit fb7332a9fedfd62b1ba6530c86f39f0fa38afd49 ]

On architectures with hardware broadcasting of TLB invalidation messages
, it makes sense to reduce the range of the mmu_gather structure when
unmapping page ranges based on the dirty address information passed to
tlb_remove_tlb_entry.

arm64 already does this by directly manipulating the start/end fields
of the gather structure, but this confuses the generic code which
does not expect these fields to change and can end up calculating
invalid, negative ranges when forcing a flush in zap_pte_range.

This patch moves the minimal range calculation out of the arm64 code
and into the generic implementation, simplifying zap_pte_range in the
process (which no longer needs to care about start/end, since they will
point to the appropriate ranges already). With the range being tracked
by core code, the need_flush flag is dropped in favour of checking that
the end of the range has actually been set.

Cc: Benjamin Herrenschmidt 
Cc: Peter Zijlstra 
Cc: Russell King - ARM Linux 
Cc: Michal Simek 
Acked-by: Linus Torvalds 
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin