1. 29 6月, 2013 1 次提交
  2. 27 6月, 2013 8 次提交
  3. 21 6月, 2013 1 次提交
  4. 20 6月, 2013 1 次提交
  5. 19 6月, 2013 2 次提交
  6. 17 6月, 2013 4 次提交
  7. 05 6月, 2013 3 次提交
  8. 28 5月, 2013 1 次提交
  9. 22 5月, 2013 2 次提交
  10. 21 5月, 2013 5 次提交
  11. 17 5月, 2013 1 次提交
  12. 15 5月, 2013 1 次提交
    • H
      s390/ftrace: fix mcount adjustment · aca91209
      Heiko Carstens 提交于
      Tony Jones reported that the ftrace self tests on s390 do not work:
      
      <6>Testing dynamic ftrace ops #1: (0 0 0 0 0) FAILED!
      <6>Testing tracer irqsoff:
      <3>failed to start irqsoff tracer
      <4>.. no entries found ..FAILED!
      <6>Testing tracer wakeup:
      <3>failed to start wakeup tracer
      <4>.. no entries found ..FAILED!
      <6>Testing tracer function_graph:
      <4>Failed to init function_graph tracer, init returned -19
      <4>FAILED!
      
      This happens because we forgot to adjust the instruction pointer that gets
      passed to the ftrace trace function by MCOUNT_INSN_SIZE.
      
      In addition change MCOUNT_INSN_SIZE to the correct value on 31 bit.
      It only worked so far because the to be patched instruction was identical.
      Reported-by: NTony Jones <tonyj@suse.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      aca91209
  13. 07 5月, 2013 1 次提交
  14. 03 5月, 2013 2 次提交
  15. 02 5月, 2013 2 次提交
  16. 30 4月, 2013 1 次提交
    • G
      mm/hugetlb: add more arch-defined huge_pte functions · 106c992a
      Gerald Schaefer 提交于
      Commit abf09bed ("s390/mm: implement software dirty bits")
      introduced another difference in the pte layout vs.  the pmd layout on
      s390, thoroughly breaking the s390 support for hugetlbfs.  This requires
      replacing some more pte_xxx functions in mm/hugetlbfs.c with a
      huge_pte_xxx version.
      
      This patch introduces those huge_pte_xxx functions and their generic
      implementation in asm-generic/hugetlb.h, which will now be included on
      all architectures supporting hugetlbfs apart from s390.  This change
      will be a no-op for those architectures.
      
      [akpm@linux-foundation.org: fix warning]
      Signed-off-by: NGerald Schaefer <gerald.schaefer@de.ibm.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Hillf Danton <dhillf@gmail.com>
      Acked-by: Michal Hocko <mhocko@suse.cz>	[for !s390 parts]
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      106c992a
  17. 26 4月, 2013 2 次提交
  18. 23 4月, 2013 2 次提交
    • H
      s390/uapi: change struct statfs[64] member types to unsigned values · b8668fd0
      Heiko Carstens 提交于
      Kay Sievers reported that coreutils' stat tool has a problem with
      s390's statfs[64] definition:
      
      > The definition of struct statfs::f_type needs a fix. s390 is the only
      > architecture in the kernel that uses an int and expects magic
      > constants lager than INT_MAX to fit into.
      >
      > A fix is needed to make Fedora boot on s390, it currently fails to do
      > so. Userspace does not want to add code to paper-over this issue.
      
      [...]
      
      > Even coreutils cannot handle it:
      >   #define RAMFS_MAGIC  0x858458f6
      >   # stat -f -c%t /
      >   ffffffff858458f6
      >
      >   #define BTRFS_SUPER_MAGIC 0x9123683E
      >   # stat -f -c%t /mnt
      >   ffffffff9123683e
      
      The bug is caused by an implicit sign extension within the stat tool:
      
      out_uint_x (pformat, prefix_len, statfsbuf->f_type);
      
      where the format finally will be "%lx".
      A similar problem can be found in the 'tail' tool.
      s390 is the only architecture which has an int type f_type member in
      struct statfs[64]. Other architectures have either unsigned ints or
      long values, so that the problem doesn't occur there.
      
      Therefore change the type of the f_type member to unsigned int, so
      that we get zero extension instead of sign extension when assignment to
      a long value happens.
      
      This patch changes the s390 uapi struct stafs[64] definition in the kernel
      to contain only unsigned values.
      This was true for 32 bit builds anyway, since we use the generic uapi
      header file in that case. So lets not include conditionally the generic
      uapi header file but have the s390 implementation completely independent.
      
      Also fix the types of struct compat_stafs to match reality and move the
      definition of struct compat_statfs64 to asm/compat.h since it is not part
      of the api.
      Reported-by: NKay Sievers <kay@vrfy.org>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      b8668fd0
    • H
      63dd9b44