Skip to content
  1. Mar 12, 2014
  3. Mar 04, 2014
  5. Mar 03, 2014
  7. Mar 02, 2014
  9. Mar 01, 2014
  11. Feb 28, 2014
    • Steve Capper's avatar
      arm64: mm: Add double logical invert to pte accessors · 84fe6826
      Steve Capper authored 
      

Page table entries on ARM64 are 64 bits, and some pte functions such as
pte_dirty return a bitwise-and of a flag with the pte value. If the
flag to be tested resides in the upper 32 bits of the pte, then we run
into the danger of the result being dropped if downcast.

For example:
	gather_stats(page, md, pte_dirty(*pte), 1);
where pte_dirty(*pte) is downcast to an int.

This patch adds a double logical invert to all the pte_ accessors to
ensure predictable downcasting.

Signed-off-by: default avatarSteve Capper <steve.capper@linaro.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      84fe6826
    • Heinz Mauelshagen's avatar
      dm cache: fix truncation bug when mapping I/O to >2TB fast device · e0d849fa
      Heinz Mauelshagen authored 
      

When remapping a block to the cache's fast device that is larger than
2TB we must not truncate the destination sector to 32bits.  The 32bit
temporary result of from_cblock() was being overflowed in
remap_to_cache() due to the logical left shift.

Use an intermediate 64bit type to store the 32bit from_cblock() result
to fix the overflow.

Signed-off-by: default avatarHeinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
      e0d849fa
    • Jiri Olsa's avatar
      perf tools: Fix strict alias issue for find_first_bit · b39c2a57
      Jiri Olsa authored 
      When compiling perf tool code with gcc 4.4.7 I'm getting
following error:

    CC       util/session.o
  cc1: warnings being treated as errors
  util/session.c: In function ‘perf_session_deliver_event’:
  tools/perf/util/include/linux/bitops.h:109: error: dereferencing pointer ‘p’ does break strict-aliasing rules
  tools/perf/util/include/linux/bitops.h:101: error: dereferencing pointer ‘p’ does break strict-aliasing rules
  util/session.c:697: note: initialized from here
  tools/perf/util/include/linux/bitops.h:101: note: initialized from here
  make[1]: *** [util/session.o] Error 1
  make: *** [util/session.o] Error 2

The aliased types here are u64 and unsigned long pointers, which is safe
for the find_first_bit processing.

This error shows up for me only for gcc 4.4 on 32bit x86, even for
-Wstrict-aliasing=3, while newer gcc are quiet and scream here for
-Wstrict-aliasing={2,1}. Looks like newer gcc changed the rules for
strict alias warnings.

The gcc documentation offers workaround for valid aliasing by using
__may_alias__ attribute:

  http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Type-Attributes.html



Using this workaround for the find_first_bit function.

Signed-off-by: default avatarJiri Olsa <jolsa@redhat.com>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1393434867-20271-1-git-send-email-jolsa@redhat.com


Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      b39c2a57
    • Benjamin Herrenschmidt's avatar
      powerpc/powernv: Fix indirect XSCOM unmangling · e0cf9576
      Benjamin Herrenschmidt authored 
      

We need to unmangle the full address, not just the register
number, and we also need to support the real indirect bit
being set for in-kernel uses.

Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org> [v3.13]
      e0cf9576
    • Benjamin Herrenschmidt's avatar
      powerpc/powernv: Fix opal_xscom_{read,write} prototype · 2f3f38e4
      Benjamin Herrenschmidt authored 
      

The OPAL firmware functions opal_xscom_read and opal_xscom_write
take a 64-bit argument for the XSCOM (PCB) address in order to
support the indirect mode on P8.

Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org> [v3.13]
      2f3f38e4
    • Gavin Shan's avatar
      powerpc/powernv: Refactor PHB diag-data dump · af87d2fe
      Gavin Shan authored 
      

As Ben suggested, the patch prints PHB diag-data with multiple
fields in one line and omits the line if the fields of that
line are all zero.

With the patch applied, the PHB3 diag-data dump looks like:

PHB3 PHB#3 Diag-data (Version: 1)

  brdgCtl:     00000002
  RootSts:     0000000f 00400000 b0830008 00100147 00002000
  nFir:        0000000000000000 0030006e00000000 0000000000000000
  PhbSts:      0000001c00000000 0000000000000000
  Lem:         0000000000100000 42498e327f502eae 0000000000000000
  InAErr:      8000000000000000 8000000000000000 0402030000000000 0000000000000000
  PE[  8] A/B: 8480002b00000000 8000000000000000

[ The current diag data is so big that it overflows the printk
  buffer pretty quickly in cases when we get a handful of errors
  at once which can happen. --BenH
]

Signed-off-by: default avatarGavin Shan <shangw@linux.vnet.ibm.com>
CC: <stable@vger.kernel.org>
Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      af87d2fe
    • Gavin Shan's avatar
      powerpc/powernv: Dump PHB diag-data immediately · 94716604
      Gavin Shan authored 
      

The PHB diag-data is important to help locating the root cause for
EEH errors such as frozen PE or fenced PHB. However, the EEH core
enables IO path by clearing part of HW registers before collecting
this data causing it to be corrupted.

This patch fixes this by dumping the PHB diag-data immediately when
frozen/fenced state on PE or PHB is detected for the first time in
eeh_ops::get_state() or next_error() backend.

Signed-off-by: default avatarGavin Shan <shangw@linux.vnet.ibm.com>
CC: <stable@vger.kernel.org>
Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      94716604
    • Paul Mackerras's avatar
      powerpc: Increase stack redzone for 64-bit userspace to 512 bytes · 573ebfa6
      Paul Mackerras authored 
      

The new ELFv2 little-endian ABI increases the stack redzone -- the
area below the stack pointer that can be used for storing data --
from 288 bytes to 512 bytes.  This means that we need to allow more
space on the user stack when delivering a signal to a 64-bit process.

To make the code a bit clearer, we define new USER_REDZONE_SIZE and
KERNEL_REDZONE_SIZE symbols in ptrace.h.  For now, we leave the
kernel redzone size at 288 bytes, since increasing it to 512 bytes
would increase the size of interrupt stack frames correspondingly.

Gcc currently only makes use of 288 bytes of redzone even when
compiling for the new little-endian ABI, and the kernel cannot
currently be compiled with the new ABI anyway.

In the future, hopefully gcc will provide an option to control the
amount of redzone used, and then we could reduce it even more.

This also changes the code in arch_compat_alloc_user_space() to
preserve the expanded redzone.  It is not clear why this function would
ever be used on a 64-bit process, though.

Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
CC: <stable@vger.kernel.org> [v3.13]
Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      573ebfa6
    • Liu Ping Fan's avatar
      powerpc/ftrace: bugfix for test_24bit_addr · a95fc585
      Liu Ping Fan authored 
      

The branch target should be the func addr, not the addr of func_descr_t.
So using ppc_function_entry() to generate the right target addr.

Signed-off-by: default avatarLiu Ping Fan <pingfank@linux.vnet.ibm.com>
Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      a95fc585