1. 22 8月, 2013 8 次提交
  2. 20 8月, 2013 2 次提交
  3. 17 8月, 2013 2 次提交
  4. 14 8月, 2013 1 次提交
  5. 11 8月, 2013 6 次提交
  6. 24 7月, 2013 1 次提交
  7. 15 7月, 2013 4 次提交
  8. 13 7月, 2013 3 次提交
  9. 12 7月, 2013 3 次提交
  10. 11 7月, 2013 5 次提交
  11. 10 7月, 2013 5 次提交
    • M
      microblaze: Move __NR_syscalls from uapi · 40c2702a
      Michal Simek 提交于
      The reason is that other applications like strace
      think that every __NR_xx is syscall.
      Also __NR_syscalls is not used by user applications/libs.
      Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
      40c2702a
    • J
      ARM: 7778/1: smp_twd: twd_update_frequency need be run on all online CPUs · cbbe6f82
      Jason Liu 提交于
      When the local timer freq changed, the twd_update_frequency function
      should be run all the CPUs include itself, otherwise, the twd freq will
      not get updated and the local timer will not run correcttly.
      
      smp_call_function will run functions on all other CPUs, but not include
      himself, this is not correct,use on_each_cpu instead to fix this issue.
      
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: stable@vger.kernel.org
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Acked-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NJason Liu <r64343@freescale.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      cbbe6f82
    • F
      ARM: 7782/1: Kconfig: Let ARM_ERRATA_364296 not depend on CONFIG_SMP · fd832478
      Fabio Estevam 提交于
      imx_v6_v7_defconfig handles both multi-core and single-core SoCs, and it has CONFIG_SMP=y selected by default.
      
      With such config we cannot select ARM_ERRATA_364296, as it depends on !SMP.
      
      Let ARM_ERRATA_364296 be undependent on CONFIG_SMP, so that we can select this erratum for the ARM1136 SoCs, even if CONFIG_SMP=y is enabled.
      Reviewed-by: NDave Martin <Dave.Martin@arm.com>
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      fd832478
    • H
      parisc: Fix gcc miscompilation in pa_memcpy() · 5b879d78
      Helge Deller 提交于
      When running the LTP testsuite one may hit this kernel BUG() with the
      write06 testcase:
      
      kernel BUG at mm/filemap.c:2023!
      CPU: 1 PID: 8614 Comm: writev01 Not tainted 3.10.0-rc7-64bit-c3000+ #6
      IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000401e6e84 00000000401e6e88
       IIR: 03ffe01f    ISR: 0000000010340000  IOR: 000001fbe0380820
       CPU:        1   CR30: 00000000bef80000 CR31: ffffffffffffffff
       ORIG_R28: 00000000bdc192c0
       IAOQ[0]: iov_iter_advance+0x3c/0xc0
       IAOQ[1]: iov_iter_advance+0x40/0xc0
       RP(r2): generic_file_buffered_write+0x204/0x3f0
      Backtrace:
       [<00000000401e764c>] generic_file_buffered_write+0x204/0x3f0
       [<00000000401eab24>] __generic_file_aio_write+0x244/0x448
       [<00000000401eadc0>] generic_file_aio_write+0x98/0x150
       [<000000004024f460>] do_sync_readv_writev+0xc0/0x130
       [<000000004025037c>] compat_do_readv_writev+0x12c/0x340
       [<00000000402505f8>] compat_writev+0x68/0xa0
       [<0000000040251d88>] compat_SyS_writev+0x98/0xf8
      
      Reason for this crash is a gcc miscompilation in the fault handlers of
      pa_memcpy() which return the fault address instead of the copied bytes.
      Since this seems to be a generic problem with gcc-4.7.x (and below), it's
      better to simplify the fault handlers in pa_memcpy to avoid this problem.
      
      Here is a simple reproducer for the problem:
      
      int main(int argc, char **argv)
      {
      	int fd, nbytes;
      	struct iovec wr_iovec[] = {
      		{ "TEST STRING                     ",32},
      		{ (char*)0x40005000,32} }; // random memory.
      	fd = open(DATA_FILE, O_RDWR | O_CREAT, 0666);
      	nbytes = writev(fd, wr_iovec, 2);
      	printf("return value = %d, errno %d (%s)\n",
      		nbytes, errno, strerror(errno));
      	return 0;
      }
      
      In addition, John David Anglin wrote:
      There is no gcc PR as pa_memcpy is not legitimate C code. There is an
      implicit assumption that certain variables will contain correct values
      when an exception occurs and the code randomly jumps to one of the
      exception blocks.  There is no guarantee of this.  If a PR was filed, it
      would likely be marked as invalid.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # 3.8+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      5b879d78
    • J
      parisc: Ensure volatile space register %sr1 is not clobbered · e8d8fc21
      John David Anglin 提交于
      I still see the occasional random segv on rp3440.  Looking at one of
      these (a code 15), it appeared the problem must be with the cache
      handling of anonymous pages.  Reviewing this, I noticed that the space
      register %sr1 might be being clobbered when we flush an anonymous page.
      
      Register %sr1 is used for TLB purges in a couple of places.  These
      purges are needed on PA8800 and PA8900 processors to ensure cache
      consistency of flushed cache lines.
      
      The solution here is simply to move the %sr1 load into the TLB lock
      region needed to ensure that one purge executes at a time on SMP
      systems.  This was already the case for one use.  After a few days of
      operation, I haven't had a random segv on my rp3440.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # 3.10
      Signed-off-by: NHelge Deller <deller@gmx.de>
      e8d8fc21