1. 29 6月, 2017 4 次提交
  2. 28 6月, 2017 23 次提交
  3. 27 6月, 2017 2 次提交
    • K
      MIPS: defconfig: Cleanup from old Kconfig options · 59baa24d
      Krzysztof Kozlowski 提交于
      Remove old, dead Kconfig options (in order appearing in this commit):
       - EXPERIMENTAL is gone since v3.9;
       - INET_LRO: commit 7bbf3cae ("ipv4: Remove inet_lro library");
       - MTD_CONCAT: commit f53fdebc ("mtd: drop MTD_CONCAT from Kconfig
         entirely");
       - MTD_CHAR: commit 660685d9 ("mtd: merge mtdchar module with
         mtdcore");
       - NETDEV_1000 and NETDEV_10000: commit f860b052 ("drivers/net:
         Kconfig and Makefile cleanup"); NET_ETHERNET should be replaced with
         just ETHERNET but that is separate change;
       - MISC_DEVICES: commit 7c5763b8 ("drivers: misc: Remove
         MISC_DEVICES config option");
       - HID_SUPPORT: commit 1f41a6a9 ("HID: Fix the generic Kconfig
         options");
       - BT_L2CAP and BT_SCO: commit f1e91e16 ("Bluetooth: Always compile
         SCO and L2CAP in Bluetooth Core");
       - DEBUG_ERRORS: commit b025a3f8 ("ARM: 6876/1: Kconfig.debug:
         Remove unused CONFIG_DEBUG_ERRORS");
       - USB_DEVICE_CLASS: commit 007bab91 ("USB: remove
         CONFIG_USB_DEVICE_CLASS");
       - RCU_CPU_STALL_DETECTOR: commit a00e0d71 ("rcu: Remove conditional
         compilation for RCU CPU stall warnings");
       - IP_NF_QUEUE: commit 3dd6664f ("netfilter: remove unused "config
         IP_NF_QUEUE"");
       - IP_NF_TARGET_ULOG: commit d4da843e ("netfilter: kill remnants of
         ulog targets");
       - IP6_NF_QUEUE: commit d16cf20e ("netfilter: remove ip_queue
         support");
       - IP6_NF_TARGET_LOG: commit 6939c33a ("netfilter: merge ipt_LOG and
         ip6_LOG into xt_LOG");
       - USB_LED: commit a335aaf3 ("usb: misc: remove outdated USB LED
         driver");
       - MMC_UNSAFE_RESUME: commit 2501c917 ("mmc: core: Use
         MMC_UNSAFE_RESUME as default behavior");
       - AUTOFS_FS: commit 561c5cf9 ("staging: Remove autofs3");
       - VIDEO_OUTPUT_CONTROL: commit f167a64e ("video / output: Drop
         display output class support");
       - USB_LIBUSUAL: commit f61870ee ("usb: remove libusual");
       - CRYPTO_ZLIB: 11049218 ("crypto: compress - remove unused pcomp
         interface");
       - BLK_DEV_UB: commit 68a5059e ("block: remove the deprecated ub
         driver");
      Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: linux-kernel@vger.kernel.org
      Cc: bcm-kernel-feedback-list@broadcom.com
      Cc: linux-mips@linux-mips.org
      Cc: linux-arm-kernel@lists.infradead.org
      Patchwork: https://patchwork.linux-mips.org/patch/16342/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      59baa24d
    • M
      MIPS: Sort MIPS Kconfig Alphabetically. · 12597988
      Matt Redfearn 提交于
      Sort the entries in config MIPS alphabetically so as to make entries
      easier to find.
      Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/16068/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      12597988
  4. 20 6月, 2017 1 次提交
    • J
      KVM: MIPS: Fix maybe-uninitialized build failure · e27a9eca
      James Cowgill 提交于
      This commit fixes a "maybe-uninitialized" build failure in
      arch/mips/kvm/tlb.c when KVM, DYNAMIC_DEBUG and JUMP_LABEL are all
      enabled. The failure is:
      
      In file included from ./include/linux/printk.h:329:0,
                       from ./include/linux/kernel.h:13,
                       from ./include/asm-generic/bug.h:15,
                       from ./arch/mips/include/asm/bug.h:41,
                       from ./include/linux/bug.h:4,
                       from ./include/linux/thread_info.h:11,
                       from ./include/asm-generic/current.h:4,
                       from ./arch/mips/include/generated/asm/current.h:1,
                       from ./include/linux/sched.h:11,
                       from arch/mips/kvm/tlb.c:13:
      arch/mips/kvm/tlb.c: In function ‘kvm_mips_host_tlb_inv’:
      ./include/linux/dynamic_debug.h:126:3: error: ‘idx_kernel’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
         __dynamic_pr_debug(&descriptor, pr_fmt(fmt), \
         ^~~~~~~~~~~~~~~~~~
      arch/mips/kvm/tlb.c:169:16: note: ‘idx_kernel’ was declared here
        int idx_user, idx_kernel;
                      ^~~~~~~~~~
      
      There is a similar error relating to "idx_user". Both errors were
      observed with GCC 6.
      
      As far as I can tell, it is impossible for either idx_user or idx_kernel
      to be uninitialized when they are later read in the calls to kvm_debug,
      but to satisfy the compiler, add zero initializers to both variables.
      Signed-off-by: NJames Cowgill <James.Cowgill@imgtec.com>
      Fixes: 57e3869c ("KVM: MIPS/TLB: Generalise host TLB invalidate to kernel ASID")
      Cc: <stable@vger.kernel.org> # 4.11+
      Acked-by: NJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      e27a9eca
  5. 19 6月, 2017 1 次提交
    • H
      mm: larger stack guard gap, between vmas · 1be7107f
      Hugh Dickins 提交于
      Stack guard page is a useful feature to reduce a risk of stack smashing
      into a different mapping. We have been using a single page gap which
      is sufficient to prevent having stack adjacent to a different mapping.
      But this seems to be insufficient in the light of the stack usage in
      userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
      used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
      which is 256kB or stack strings with MAX_ARG_STRLEN.
      
      This will become especially dangerous for suid binaries and the default
      no limit for the stack size limit because those applications can be
      tricked to consume a large portion of the stack and a single glibc call
      could jump over the guard page. These attacks are not theoretical,
      unfortunatelly.
      
      Make those attacks less probable by increasing the stack guard gap
      to 1MB (on systems with 4k pages; but make it depend on the page size
      because systems with larger base pages might cap stack allocations in
      the PAGE_SIZE units) which should cover larger alloca() and VLA stack
      allocations. It is obviously not a full fix because the problem is
      somehow inherent, but it should reduce attack space a lot.
      
      One could argue that the gap size should be configurable from userspace,
      but that can be done later when somebody finds that the new 1MB is wrong
      for some special case applications.  For now, add a kernel command line
      option (stack_guard_gap) to specify the stack gap size (in page units).
      
      Implementation wise, first delete all the old code for stack guard page:
      because although we could get away with accounting one extra page in a
      stack vma, accounting a larger gap can break userspace - case in point,
      a program run with "ulimit -S -v 20000" failed when the 1MB gap was
      counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
      and strict non-overcommit mode.
      
      Instead of keeping gap inside the stack vma, maintain the stack guard
      gap as a gap between vmas: using vm_start_gap() in place of vm_start
      (or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
      places which need to respect the gap - mainly arch_get_unmapped_area(),
      and and the vma tree's subtree_gap support for that.
      Original-patch-by: NOleg Nesterov <oleg@redhat.com>
      Original-patch-by: NMichal Hocko <mhocko@suse.com>
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Tested-by: Helge Deller <deller@gmx.de> # parisc
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1be7107f
  6. 15 6月, 2017 2 次提交
    • P
      MIPS: .its targets depend on vmlinux · bcd7c45e
      Paul Burton 提交于
      The .its targets require information about the kernel binary, such as
      its entry point, which is extracted from the vmlinux ELF. We therefore
      require that the ELF is built before the .its files are generated.
      Declare this requirement in the Makefile such that make will ensure this
      is always the case, otherwise in corner cases we can hit issues as the
      .its is generated with an incorrect (either invalid or stale) entry
      point.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Fixes: cf2a5e0b ("MIPS: Support generating Flattened Image Trees (.itb)")
      Cc: linux-mips@linux-mips.org
      Cc: stable <stable@vger.kernel.org> # v4.9+
      Patchwork: https://patchwork.linux-mips.org/patch/16179/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      bcd7c45e
    • P
      MIPS: Fix bnezc/jialc return address calculation · 1a73d931
      Paul Burton 提交于
      The code handling the pop76 opcode (ie. bnezc & jialc instructions) in
      __compute_return_epc_for_insn() needs to set the value of $31 in the
      jialc case, which is encoded with rs = 0. However its check to
      differentiate bnezc (rs != 0) from jialc (rs = 0) was unfortunately
      backwards, meaning that if we emulate a bnezc instruction we clobber $31
      & if we emulate a jialc instruction it actually behaves like a jic
      instruction.
      
      Fix this by inverting the check of rs to match the way the instructions
      are actually encoded.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Fixes: 28d6f93d ("MIPS: Emulate the new MIPS R6 BNEZC and JIALC instructions")
      Cc: stable <stable@vger.kernel.org> # v4.0+
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16178/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      1a73d931
  7. 08 6月, 2017 6 次提交
  8. 30 5月, 2017 1 次提交
    • V
      kthread: fix boot hang (regression) on MIPS/OpenRISC · b0f5a8f3
      Vegard Nossum 提交于
      This fixes a regression in commit 4d6501dc where I didn't notice
      that MIPS and OpenRISC were reinitialising p->{set,clear}_child_tid to
      NULL after our initialisation in copy_process().
      
      We can simply get rid of the arch-specific initialisation here since it
      is now always done in copy_process() before hitting copy_thread{,_tls}().
      
      Review notes:
      
       - As far as I can tell, copy_process() is the only user of
         copy_thread_tls(), which is the only caller of copy_thread() for
         architectures that don't implement copy_thread_tls().
      
       - After this patch, there is no arch-specific code touching
         p->set_child_tid or p->clear_child_tid whatsoever.
      
       - It may look like MIPS/OpenRISC wanted to always have these fields be
         NULL, but that's not true, as copy_process() would unconditionally
         set them again _after_ calling copy_thread_tls() before commit
         4d6501dc.
      
      Fixes: 4d6501dc ("kthread: Fix use-after-free if kthread fork fails")
      Reported-by: NGuenter Roeck <linux@roeck-us.net>
      Tested-by: Guenter Roeck <linux@roeck-us.net> # MIPS only
      Acked-by: NStafford Horne <shorne@gmail.com>
      Acked-by: NOleg Nesterov <oleg@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
      Cc: openrisc@lists.librecores.org
      Cc: Jamie Iles <jamie.iles@oracle.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NVegard Nossum <vegard.nossum@oracle.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b0f5a8f3