Skip to content
  1. Aug 22, 2013
  3. Aug 20, 2013
  5. Aug 17, 2013
  7. Aug 14, 2013
  9. Aug 11, 2013
  11. Jul 24, 2013
  13. Jul 15, 2013
  15. Jul 13, 2013
  17. Jul 12, 2013
  19. Jul 11, 2013
  21. Jul 10, 2013
    • Michal Simek's avatar
      microblaze: Move __NR_syscalls from uapi · 40c2702a
      Michal Simek authored 
      

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: default avatarMichal Simek <michal.simek@xilinx.com>
      40c2702a
    • Jason Liu's avatar
      ARM: 7778/1: smp_twd: twd_update_frequency need be run on all online CPUs · cbbe6f82
      Jason Liu authored 
      

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: default avatarLinus Walleij <linus.walleij@linaro.org>
Acked-by: default avatarShawn Guo <shawn.guo@linaro.org>
Signed-off-by: default avatarJason Liu <r64343@freescale.com>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      cbbe6f82
    • Fabio Estevam's avatar
      ARM: 7782/1: Kconfig: Let ARM_ERRATA_364296 not depend on CONFIG_SMP · fd832478
      Fabio Estevam authored 
      

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: default avatarDave Martin <Dave.Martin@arm.com>
Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      fd832478
    • Helge Deller's avatar
      parisc: Fix gcc miscompilation in pa_memcpy() · 5b879d78
      Helge Deller authored 
      

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: default avatarHelge Deller <deller@gmx.de>
Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
Cc: <stable@vger.kernel.org> # 3.8+
Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      5b879d78
    • John David Anglin's avatar
      parisc: Ensure volatile space register %sr1 is not clobbered · e8d8fc21
      John David Anglin authored 
      

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: default avatarJohn David Anglin <dave.anglin@bell.net>
Cc: <stable@vger.kernel.org> # 3.10
Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      e8d8fc21