1. 22 Sep, 2016 1 commit
  2. 13 Sep, 2016 2 commits
  3. 04 Aug, 2016 13 commits
  4. 02 Aug, 2016 2 commits
    • Andy Lutomirski's avatar
      signal: consolidate {TS,TLF}_RESTORE_SIGMASK code · 7e781418
      Andy Lutomirski authored
      In general, there's no need for the "restore sigmask" flag to live in
      ti->flags.  alpha, ia64, microblaze, powerpc, sh, sparc (64-bit only),
      tile, and x86 use essentially identical alternative implementations,
      placing the flag in ti->status.
      
      Replace those optimized implementations with an equally good common
      implementation that stores it in a bitfield in struct task_struct and
      drop the custom implementations.
      
      Additional architectures can opt in by removing their
      TIF_RESTORE_SIGMASK defines.
      
      Link: http://lkml.kernel.org/r/8a14321d64a28e40adfddc90e18a96c086a6d6f9.1468522723.git.luto@kernel.orgSigned-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Tested-by: Michael Ellerman <mpe@ellerman.id.au>	[powerpc]
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7e781418
    • Fabian Frederick's avatar
      treewide: replace obsolete _refok by __ref · bd721ea7
      Fabian Frederick authored
      There was only one use of __initdata_refok and __exit_refok
      
      __init_refok was used 46 times against 82 for __ref.
      
      Those definitions are obsolete since commit 312b1485 ("Introduce new
      section reference annotations tags: __ref, __refdata, __refconst")
      
      This patch removes the following compatibility definitions and replaces
      them treewide.
      
      /* compatibility defines */
      #define __init_refok     __ref
      #define __initdata_refok __refdata
      #define __exit_refok     __ref
      
      I can also provide separate patches if necessary.
      (One patch per tree and check in 1 month or 2 to remove old definitions)
      
      [akpm@linux-foundation.org: coding-style fixes]
      Link: http://lkml.kernel.org/r/1466796271-3043-1-git-send-email-fabf@skynet.beSigned-off-by: default avatarFabian Frederick <fabf@skynet.be>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bd721ea7
  5. 30 Jul, 2016 11 commits
    • Rich Felker's avatar
      sh: fix build regression with CONFIG_OF && !CONFIG_OF_FLATTREE · 03767daa
      Rich Felker authored
      Such a configuration could only be selected by manually selecting
      CONFIG_OF; SH_DEVICE_TREE selects both. The affected code is using the
      flat DTB at boot time and thus rightfully should depend on
      OF_FLATTREE, not just OF.
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
      03767daa
    • Rich Felker's avatar
      sh: allow clocksource drivers to register sched_clock backends · b46ed370
      Rich Felker authored
      There is no arch-specific sched_clock implementation for sh, resulting
      in use of the old default jiffies-based implementation. Instead, use
      the modern generic sched_clock framework so that drivers can register
      better backends.
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
      b46ed370
    • Paul Gortmaker's avatar
      sh: make heartbeat driver explicitly non-modular · e75438e2
      Paul Gortmaker authored
      The Kconfig for this driver is currently:
      
      config HEARTBEAT
              bool "Heartbeat LED"
      
      ....meaning that it currently is not being built as a module by anyone.
      Lets remove the modular code that is essentially orphaned, so that
      when reading the driver there is no doubt it is builtin-only.
      
      Since module_init translates to device_initcall in the non-modular
      case, the init ordering remains unchanged with this commit.
      
      We explicitly disallow a driver unbind, since that doesn't have a
      sensible use case anyway, and it allows us to drop the ".remove"
      code for non-modular drivers.
      
      We also delete the MODULE_LICENSE tag etc. since all that information
      is already contained at the top of the file in the comments.
      
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: linux-sh@vger.kernel.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
      e75438e2
    • Paul Gortmaker's avatar
      sh: make board-secureedge5410 explicitly non-modular · f368d475
      Paul Gortmaker authored
      The Kconfig currently controlling compilation of this code is:
      
      config SH_SECUREEDGE5410
              bool "SecureEdge5410"
      
      ....meaning that it currently is not being built as a module by anyone.
      
      Lets remove the couple traces of modularity so that when reading the
      driver there is no doubt it is builtin-only.
      
      Since module_init translates to device_initcall in the non-modular
      case, the init ordering remains unchanged with this commit.
      
      We don't replace module.h with init.h since the file already has that.
      
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: linux-sh@vger.kernel.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
      f368d475
    • Paul Gortmaker's avatar
      sh: make mm/asids-debugfs explicitly non-modular · f15412aa
      Paul Gortmaker authored
      The Makefile/Kconfig currently controlling compilation of this code is:
      
      obj-$(CONFIG_DEBUG_FS)          += $(debugfs-y)
      debugfs-y                       := asids-debugfs.o
      
      lib/Kconfig.debug:config DEBUG_FS
      lib/Kconfig.debug:      bool "Debug Filesystem"
      
      ....meaning that it currently is not being built as a module by anyone.
      
      Lets remove the couple traces of modular code, so that when reading the
      driver there is no doubt it is builtin-only.
      
      Since module_init translates to device_initcall in the non-modular
      case, the init ordering remains unchanged with this commit.
      
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: linux-sh@vger.kernel.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
      f15412aa
    • Paul Gortmaker's avatar
      sh: make time.c explicitly non-modular · 7a65a34f
      Paul Gortmaker authored
      The Makefile currently controlling compilation of this code is:
      
      obj-y   := debugtraps.o dma-nommu.o dumpstack.o                 \
      [...]
                 syscalls_$(BITS).o time.o topology.o traps.o         \
                 traps_$(BITS).o unwinder.o
      
      ....meaning that it currently is not being built as a module by anyone.
      
      Lets remove the couple traces of modular code, so that when reading
      the driver there is no doubt it is builtin-only.
      
      Since module_init translates to device_initcall in the non-modular
      case, the init ordering remains unchanged with this commit.
      
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: linux-sh@vger.kernel.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
      7a65a34f
    • Rich Felker's avatar
      sh: fix futex/robust_list on nommu models · 72cc564f
      Rich Felker authored
      The futex cmpxchg runtime testing in kernel/futex.c depends on
      accesses to address 0 producing EFAULT, which obviously does not work
      on nommu. Since SH always has cmpxchg, disable the broken runtime
      detection.
      
      At some point this should be fixed at the kernel/futex.c level. UP
      machines can always provide a working cmpxchg with interrupt masking,
      and SMP cannot function without a working cmpxchg anyway.
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
      72cc564f
    • Rich Felker's avatar
      sh: disable aliased page logic on NOMMU models · 57155c65
      Rich Felker authored
      SH3/4 (with MMU) have a virtually indexed cache, requiring explicit
      work to avoid consistency problems arising from having the same
      physical address range cached in multiple cache lines. This is
      unneeded for the NOMMU case, and some of the resulting code paths
      (kmap_coherent) don't work. SH2 only avoided this problem by having a
      4-way associative cache with way size equal to the page size (4k),
      yielding no cache index bits outside of the page offset and thus no
      aliases.
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
      57155c65
    • Rich Felker's avatar
      sh: make sigcontext definition consistent across fpu/nofpu models · bbe6c778
      Rich Felker authored
      Up until now, the SH version of the sigcontext structure, and thus
      mcontext_t/ucontext_t, varied depending on the cpu model the kernel
      was built to run on. SH-4 (including SH-4A) and SH-2A used the form
      with space for FPU registers, and everything else used a form that
      omitted them.
      
      From a userspace perspective, however, the structure layout must be
      fixed for a given ABI. Traditionally glibc and uClibc used the form
      with space for FPU registers only when __SH4__ (which implies FPU;
      __SH4_NOFPU__ is the predefined macro for SH-4 but with no-FPU ABI)
      was defined. As a result:
      
      - SH-4 no-FPU programs never matched kernel sigcontext.
      
      - SH-3 programs did not match kernel sigcontext if run on SH-4,
        despite an apparent intent that they be compatible.
      
      - SH-2 and SH-2A programs (using uClibc) did not match kernel
        sigcontext if run on SH-2A.
      
      The mismatch might seem inconsequential because it occurs at the end
      of the sigcontext structure, but sigcontext is embedded as uc_mcontext
      in ucontext_t, where it is followed by uc_sigmask, an important member
      for signal handlers to have access to. In particular, access to
      uc_sigmask is necessary for a correct implementation of thread
      cancellation.
      
      It would be possible to retain support for both sigcontext ABIs via a
      personality mechanism, but since many configurations were already
      broken and nobody noticed, and since there are very few if any users
      of legacy no-FPU models anymore, I have opted to just remove the
      variation and always include space for the FPU registers in
      sigcontext. This was proposed and discussed on a thread "SH sigcontext
      ABI is broken" cross-posted to linux-sh, libc-alpha, and musl libc
      lists in June 2015, and no objections were raised.
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
      bbe6c778
    • Rich Felker's avatar
    • Pan Xinhui's avatar
      sh: cmpxchg: fix a bit shift bug in big_endian os · ff18143c
      Pan Xinhui authored
      Correct bitoff in big endian OS.
      Current code works correctly for 1 byte but not for 2 bytes.
      
      Fixes: 3226aad8 ("sh: support 1 and 2 byte xchg")
      Signed-off-by: default avatarPan Xinhui <xinhui.pan@linux.vnet.ibm.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
      ff18143c
  6. 26 Jul, 2016 3 commits
  7. 14 Jul, 2016 1 commit
  8. 24 Jun, 2016 2 commits
    • Michal Hocko's avatar
      sh: get rid of superfluous __GFP_REPEAT · 884ed4cb
      Michal Hocko authored
      __GFP_REPEAT has a rather weak semantic but since it has been introduced
      around 2.6.12 it has been ignored for low order allocations.
      
      PGALLOC_GFP uses __GFP_REPEAT but {pgd,pmd}_alloc allocate from
      {pgd,pmd}_cache but both caches are allocating up to PAGE_SIZE objects.
      This means that this flag has never been actually useful here because it
      has always been used only for PAGE_ALLOC_COSTLY requests.
      
      Link: http://lkml.kernel.org/r/1464599699-30131-15-git-send-email-mhocko@kernel.orgSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      884ed4cb
    • Michal Hocko's avatar
      tree wide: get rid of __GFP_REPEAT for order-0 allocations part I · 32d6bd90
      Michal Hocko authored
      This is the third version of the patchset previously sent [1].  I have
      basically only rebased it on top of 4.7-rc1 tree and dropped "dm: get
      rid of superfluous gfp flags" which went through dm tree.  I am sending
      it now because it is tree wide and chances for conflicts are reduced
      considerably when we want to target rc2.  I plan to send the next step
      and rename the flag and move to a better semantic later during this
      release cycle so we will have a new semantic ready for 4.8 merge window
      hopefully.
      
      Motivation:
      
      While working on something unrelated I've checked the current usage of
      __GFP_REPEAT in the tree.  It seems that a majority of the usage is and
      always has been bogus because __GFP_REPEAT has always been about costly
      high order allocations while we are using it for order-0 or very small
      orders very often.  It seems that a big pile of them is just a
      copy&paste when a code has been adopted from one arch to another.
      
      I think it makes some sense to get rid of them because they are just
      making the semantic more unclear.  Please note that GFP_REPEAT is
      documented as
      
      * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt
      
      * _might_ fail.  This depends upon the particular VM implementation.
        while !costly requests have basically nofail semantic.  So one could
        reasonably expect that order-0 request with __GFP_REPEAT will not loop
        for ever.  This is not implemented right now though.
      
      I would like to move on with __GFP_REPEAT and define a better semantic
      for it.
      
        $ git grep __GFP_REPEAT origin/master | wc -l
        111
        $ git grep __GFP_REPEAT | wc -l
        36
      
      So we are down to the third after this patch series.  The remaining
      places really seem to be relying on __GFP_REPEAT due to large allocation
      requests.  This still needs some double checking which I will do later
      after all the simple ones are sorted out.
      
      I am touching a lot of arch specific code here and I hope I got it right
      but as a matter of fact I even didn't compile test for some archs as I
      do not have cross compiler for them.  Patches should be quite trivial to
      review for stupid compile mistakes though.  The tricky parts are usually
      hidden by macro definitions and thats where I would appreciate help from
      arch maintainers.
      
      [1] http://lkml.kernel.org/r/1461849846-27209-1-git-send-email-mhocko@kernel.org
      
      This patch (of 19):
      
      __GFP_REPEAT has a rather weak semantic but since it has been introduced
      around 2.6.12 it has been ignored for low order allocations.  Yet we
      have the full kernel tree with its usage for apparently order-0
      allocations.  This is really confusing because __GFP_REPEAT is
      explicitly documented to allow allocation failures which is a weaker
      semantic than the current order-0 has (basically nofail).
      
      Let's simply drop __GFP_REPEAT from those places.  This would allow to
      identify place which really need allocator to retry harder and formulate
      a more specific semantic for what the flag is supposed to do actually.
      
      Link: http://lkml.kernel.org/r/1464599699-30131-2-git-send-email-mhocko@kernel.orgSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Chen Liqin <liqin.linux@gmail.com>
      Cc: Chris Metcalf <cmetcalf@mellanox.com> [for tile]
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: John Crispin <blogic@openwrt.org>
      Cc: Lennox Wu <lennox.wu@gmail.com>
      Cc: Ley Foon Tan <lftan@altera.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      32d6bd90
  9. 23 Jun, 2016 2 commits
  10. 16 Jun, 2016 2 commits
    • Peter Zijlstra's avatar
      locking/atomic: Remove linux/atomic.h:atomic_fetch_or() · b53d6bed
      Peter Zijlstra authored
      Since all architectures have this implemented now natively, remove this
      dead code.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      b53d6bed
    • Peter Zijlstra's avatar
      locking/atomic, arch/sh: Implement atomic_fetch_{add,sub,and,or,xor}() · 7d9794e7
      Peter Zijlstra authored
      Implement FETCH-OP atomic primitives, these are very similar to the
      existing OP-RETURN primitives we already have, except they return the
      value of the atomic variable _before_ modification.
      
      This is especially useful for irreversible operations -- such as
      bitops (because it becomes impossible to reconstruct the state prior
      to modification).
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-sh@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      7d9794e7
  11. 14 Jun, 2016 1 commit
    • Peter Zijlstra's avatar
      locking/spinlock, arch: Update and fix spin_unlock_wait() implementations · 726328d9
      Peter Zijlstra authored
      This patch updates/fixes all spin_unlock_wait() implementations.
      
      The update is in semantics; where it previously was only a control
      dependency, we now upgrade to a full load-acquire to match the
      store-release from the spin_unlock() we waited on. This ensures that
      when spin_unlock_wait() returns, we're guaranteed to observe the full
      critical section we waited on.
      
      This fixes a number of spin_unlock_wait() users that (not
      unreasonably) rely on this.
      
      I also fixed a number of ticket lock versions to only wait on the
      current lock holder, instead of for a full unlock, as this is
      sufficient.
      
      Furthermore; again for ticket locks; I added an smp_rmb() in between
      the initial ticket load and the spin loop testing the current value
      because I could not convince myself the address dependency is
      sufficient, esp. if the loads are of different sizes.
      
      I'm more than happy to remove this smp_rmb() again if people are
      certain the address dependency does indeed work as expected.
      
      Note: PPC32 will be fixed independently
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: chris@zankel.net
      Cc: cmetcalf@mellanox.com
      Cc: davem@davemloft.net
      Cc: dhowells@redhat.com
      Cc: james.hogan@imgtec.com
      Cc: jejb@parisc-linux.org
      Cc: linux@armlinux.org.uk
      Cc: mpe@ellerman.id.au
      Cc: ralf@linux-mips.org
      Cc: realmz6@gmail.com
      Cc: rkuo@codeaurora.org
      Cc: rth@twiddle.net
      Cc: schwidefsky@de.ibm.com
      Cc: tony.luck@intel.com
      Cc: vgupta@synopsys.com
      Cc: ysato@users.sourceforge.jp
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      726328d9