1. 29 6月, 2013 1 次提交
  2. 23 6月, 2013 8 次提交
    • G
      h8300/boot: Use POSIX "$((..))" instead of bashism "$[...]" · fbc21c00
      Geert Uytterhoeven 提交于
      On Ubuntu, where /bin/sh -> dash, "make ARCH=h8300 clean" gives:
      
      printf: 1: $[0x00400000+0x00140000]: expected numeric value
      
      Replace the bash-specific "$[...]" by POSIX "$((..))" for arithmetic
      expansion to fix this.
      Note that according to the bash 4.1 manpage, "$[...]" is deprecated, and
      will be removed in upcoming versions of bash.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      fbc21c00
    • G
      h8300: Mark H83002 and H83048 CPU support broken · a4cb378f
      Geert Uytterhoeven 提交于
      arch/h8300/include/asm/io.h supports only H83007 (H8/3006,3007), H83068
      (H8/3065,3066,3067,3068,3069), and H8S2678 (H8S/2670,2673,2674R,2675,2676)
      CPU types.
      
      Hence disable H83002 (H8/3001,3002,3003) and H83048
      (H8/3044,3045,3046,3047,3048,3052) CPU support at the Kconfig level.
      
      This fixes build failures in allmodconfig/allyesconfig builds, as these
      always choose the first CPU type (H83002), which was unsupported:
      
      arch/h8300/include/asm/io.h:13:2: error: #error UNKNOWN CPU TYPE
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      a4cb378f
    • G
      h8300: Switch h8300 to drivers/Kconfig · 9ac6adbc
      Geert Uytterhoeven 提交于
      Convert the last remaining architecture to drivers/Kconfig.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      9ac6adbc
    • G
      h8300: Limit timer channel ranges in Kconfig · 4e8d1e48
      Geert Uytterhoeven 提交于
      arch/h8300/kernel/timer/itu.c and arch/h8300/kernel/timer/tpu.c
      only support 0--4 for CONFIG_H8300_ITU_CH resp. H8300_TPU_CH, hence limit
      them to that range in Kconfig.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      4e8d1e48
    • G
      h8300: Wire up asm-generic/xor.h · e71eccdb
      Geert Uytterhoeven 提交于
      crypto/xor.c:25:21: fatal error: asm/xor.h: No such file or directory
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      e71eccdb
    • G
      h8300: Fill the system call table using a CALL() macro · c9490255
      Geert Uytterhoeven 提交于
      The CALL() macro abstracts (a.o.) the underscore symbol prefix.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      c9490255
    • G
      h8300: Fix <asm/tlb.h> · 1e2b3bda
      Geert Uytterhoeven 提交于
      Ten years ago, a mismerge happened, concatenating two slightly different
      versions of the same file. As a consequence, <asm-generic/tlb.h> was never
      included, leading to a build failure only now:
      
      kernel/cpu/idle.c: In function 'cpu_idle_loop':
      kernel/cpu/idle.c:70:4: error: implicit declaration of function 'check_pgt_cache' [-Werror=implicit-function-declaration]
      
      Remove the duplicates, and the header comment with the no longer correct
      file name.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: NYoshinori Sato <ysato@users.sourceforge.jp>
      1e2b3bda
    • G
      h8300: Hardcode symbol prefixes in asm sources · db5ede6f
      Geert Uytterhoeven 提交于
      Commit e1b5bb6d ("consolidate cond_syscall
      and SYSCALL_ALIAS declarations") broke the h8300 build because it removed
      the duplicate SYMBOL_NAME() macro from arch/h8300/include/asm/linkage.h,
      and all the h8300 asm files include <asm/linkage.h> instead of
      <linux/linkage.h>:
      
          arch/h8300/kernel/entry.S: Assembler messages:
          arch/h8300/kernel/entry.S:158: Error: junk at end of line, first unrecognized character is `('
          ...
          arch/h8300/kernel/syscalls.S: Assembler messages:
          arch/h8300/kernel/syscalls.S:6: Error: junk at end of line, first unrecognized character is `('
          ...
          arch/h8300/lib/abs.S: Assembler messages:
          arch/h8300/lib/abs.S:12: Error: junk at end of line, first unrecognized character is `('
          ...
          arch/h8300/lib/memcpy.S: Assembler messages:
          arch/h8300/lib/memcpy.S:13: Error: junk at end of line, first unrecognized character is `('
          ...
          arch/h8300/lib/memset.S: Assembler messages:
          arch/h8300/lib/memset.S:13: Error: junk at end of line, first unrecognized character is `('
          ...
      
      Commit 126de6b2 ("linkage.h: fix build
      breakage due to symbol prefix handling") broke it even more, by removing
      SYMBOL_NAME() and replacing it by __SYMBOL_NAME().
      
      Commit f8ce1faf ("Merge tag
      'modules-next-for-linus' of
      git://git.kernel.org/pub/scm/linuxkernel/git/rusty/linux")
      also removed __SYMBOL_NAME(), hidden in a merge conflict resolution.
      
      Hence, replace the use of SYMBOL_NAME() and SYMBOL_NAME_LABEL() in h8300
      assembler sources by hardcoding the underscore symbol prefix, like other
      architectures (blackfin/metag) do.
      
      This allows to kill SYMBOL_NAME_LABEL(). Now <asm/linkage.h> becomes empty,
      and h8300 can be switched to asm-generic/linkage.h.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      db5ede6f
  3. 16 6月, 2013 1 次提交
    • J
      h8300: add missing definition for read_barries_depends() · c805a5b7
      Jiang Liu 提交于
      Add missing definition for read_barries_depends() for h8300 to fix error:
      kernel/task_work.c: In function 'task_work_cancel':
      kernel/task_work.c:38:3: error: implicit declaration of function 'read_barrier_depends' [-Werror=implicit-function-declaration]
      cc1: some warnings being treated as errors
      make[1]: *** [kernel/task_work.o] Error 1
      make: *** [kernel] Error 2
      
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
      c805a5b7
  4. 05 5月, 2013 1 次提交
  5. 01 5月, 2013 2 次提交
    • T
      dump_stack: unify debug information printed by show_regs() · a43cb95d
      Tejun Heo 提交于
      show_regs() is inherently arch-dependent but it does make sense to print
      generic debug information and some archs already do albeit in slightly
      different forms.  This patch introduces a generic function to print debug
      information from show_regs() so that different archs print out the same
      information and it's much easier to modify what's printed.
      
      show_regs_print_info() prints out the same debug info as dump_stack()
      does plus task and thread_info pointers.
      
      * Archs which didn't print debug info now do.
      
        alpha, arc, blackfin, c6x, cris, frv, h8300, hexagon, ia64, m32r,
        metag, microblaze, mn10300, openrisc, parisc, score, sh64, sparc,
        um, xtensa
      
      * Already prints debug info.  Replaced with show_regs_print_info().
        The printed information is superset of what used to be there.
      
        arm, arm64, avr32, mips, powerpc, sh32, tile, unicore32, x86
      
      * s390 is special in that it used to print arch-specific information
        along with generic debug info.  Heiko and Martin think that the
        arch-specific extra isn't worth keeping s390 specfic implementation.
        Converted to use the generic version.
      
      Note that now all archs print the debug info before actual register
      dumps.
      
      An example BUG() dump follows.
      
       kernel BUG at /work/os/work/kernel/workqueue.c:4841!
       invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
       Modules linked in:
       CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.9.0-rc1-work+ #7
       Hardware name: empty empty/S3992, BIOS 080011  10/26/2007
       task: ffff88007c85e040 ti: ffff88007c860000 task.ti: ffff88007c860000
       RIP: 0010:[<ffffffff8234a07e>]  [<ffffffff8234a07e>] init_workqueues+0x4/0x6
       RSP: 0000:ffff88007c861ec8  EFLAGS: 00010246
       RAX: ffff88007c861fd8 RBX: ffffffff824466a8 RCX: 0000000000000001
       RDX: 0000000000000046 RSI: 0000000000000001 RDI: ffffffff8234a07a
       RBP: ffff88007c861ec8 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff8234a07a
       R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
       FS:  0000000000000000(0000) GS:ffff88007dc00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: ffff88015f7ff000 CR3: 00000000021f1000 CR4: 00000000000007f0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
       Stack:
        ffff88007c861ef8 ffffffff81000312 ffffffff824466a8 ffff88007c85e650
        0000000000000003 0000000000000000 ffff88007c861f38 ffffffff82335e5d
        ffff88007c862080 ffffffff8223d8c0 ffff88007c862080 ffffffff81c47760
       Call Trace:
        [<ffffffff81000312>] do_one_initcall+0x122/0x170
        [<ffffffff82335e5d>] kernel_init_freeable+0x9b/0x1c8
        [<ffffffff81c47760>] ? rest_init+0x140/0x140
        [<ffffffff81c4776e>] kernel_init+0xe/0xf0
        [<ffffffff81c6be9c>] ret_from_fork+0x7c/0xb0
        [<ffffffff81c47760>] ? rest_init+0x140/0x140
        ...
      
      v2: Typo fix in x86-32.
      
      v3: CPU number dropped from show_regs_print_info() as
          dump_stack_print_info() has been updated to print it.  s390
          specific implementation dropped as requested by s390 maintainers.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NJesper Nilsson <jesper.nilsson@axis.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Acked-by: Chris Metcalf <cmetcalf@tilera.com>		[tile bits]
      Acked-by: Richard Kuo <rkuo@codeaurora.org>		[hexagon bits]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a43cb95d
    • T
      dump_stack: consolidate dump_stack() implementations and unify their behaviors · 196779b9
      Tejun Heo 提交于
      Both dump_stack() and show_stack() are currently implemented by each
      architecture.  show_stack(NULL, NULL) dumps the backtrace for the
      current task as does dump_stack().  On some archs, dump_stack() prints
      extra information - pid, utsname and so on - in addition to the
      backtrace while the two are identical on other archs.
      
      The usages in arch-independent code of the two functions indicate
      show_stack(NULL, NULL) should print out bare backtrace while
      dump_stack() is used for debugging purposes when something went wrong,
      so it does make sense to print additional information on the task which
      triggered dump_stack().
      
      There's no reason to require archs to implement two separate but mostly
      identical functions.  It leads to unnecessary subtle information.
      
      This patch expands the dummy fallback dump_stack() implementation in
      lib/dump_stack.c such that it prints out debug information (taken from
      x86) and invokes show_stack(NULL, NULL) and drops arch-specific
      dump_stack() implementations in all archs except blackfin.  Blackfin's
      dump_stack() does something wonky that I don't understand.
      
      Debug information can be printed separately by calling
      dump_stack_print_info() so that arch-specific dump_stack()
      implementation can still emit the same debug information.  This is used
      in blackfin.
      
      This patch brings the following behavior changes.
      
      * On some archs, an extra level in backtrace for show_stack() could be
        printed.  This is because the top frame was determined in
        dump_stack() on those archs while generic dump_stack() can't do that
        reliably.  It can be compensated by inlining dump_stack() but not
        sure whether that'd be necessary.
      
      * Most archs didn't use to print debug info on dump_stack().  They do
        now.
      
      An example WARN dump follows.
      
       WARNING: at kernel/workqueue.c:4841 init_workqueues+0x35/0x505()
       Hardware name: empty
       Modules linked in:
       CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.9.0-rc1-work+ #9
        0000000000000009 ffff88007c861e08 ffffffff81c614dc ffff88007c861e48
        ffffffff8108f50f ffffffff82228240 0000000000000040 ffffffff8234a03c
        0000000000000000 0000000000000000 0000000000000000 ffff88007c861e58
       Call Trace:
        [<ffffffff81c614dc>] dump_stack+0x19/0x1b
        [<ffffffff8108f50f>] warn_slowpath_common+0x7f/0xc0
        [<ffffffff8108f56a>] warn_slowpath_null+0x1a/0x20
        [<ffffffff8234a071>] init_workqueues+0x35/0x505
        ...
      
      v2: CPU number added to the generic debug info as requested by s390
          folks and dropped the s390 specific dump_stack().  This loses %ksp
          from the debug message which the maintainers think isn't important
          enough to keep the s390-specific dump_stack() implementation.
      
          dump_stack_print_info() is moved to kernel/printk.c from
          lib/dump_stack.c.  Because linkage is per objecct file,
          dump_stack_print_info() living in the same lib file as generic
          dump_stack() means that archs which implement custom dump_stack()
          - at this point, only blackfin - can't use dump_stack_print_info()
          as that will bring in the generic version of dump_stack() too.  v1
          The v1 patch broke build on blackfin due to this issue.  The build
          breakage was reported by Fengguang Wu.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      Acked-by: NJesper Nilsson <jesper.nilsson@axis.com>
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>	[s390 bits]
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Acked-by: Richard Kuo <rkuo@codeaurora.org>		[hexagon bits]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      196779b9
  6. 30 4月, 2013 2 次提交
  7. 17 4月, 2013 1 次提交
  8. 10 4月, 2013 1 次提交
  9. 08 4月, 2013 1 次提交
  10. 01 4月, 2013 1 次提交
    • K
      net: add option to enable error queue packets waking select · 7d4c04fc
      Keller, Jacob E 提交于
      Currently, when a socket receives something on the error queue it only wakes up
      the socket on select if it is in the "read" list, that is the socket has
      something to read. It is useful also to wake the socket if it is in the error
      list, which would enable software to wait on error queue packets without waking
      up for regular data on the socket. The main use case is for receiving
      timestamped transmit packets which return the timestamp to the socket via the
      error queue. This enables an application to select on the socket for the error
      queue only instead of for the regular traffic.
      
      -v2-
      * Added the SO_SELECT_ERR_QUEUE socket option to every architechture specific file
      * Modified every socket poll function that checks error queue
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Cc: Jeffrey Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Matthew Vick <matthew.vick@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d4c04fc
  11. 15 3月, 2013 1 次提交
    • R
      CONFIG_SYMBOL_PREFIX: cleanup. · b92021b0
      Rusty Russell 提交于
      We have CONFIG_SYMBOL_PREFIX, which three archs define to the string
      "_".  But Al Viro broke this in "consolidate cond_syscall and
      SYSCALL_ALIAS declarations" (in linux-next), and he's not the first to
      do so.
      
      Using CONFIG_SYMBOL_PREFIX is awkward, since we usually just want to
      prefix it so something.  So various places define helpers which are
      defined to nothing if CONFIG_SYMBOL_PREFIX isn't set:
      
      1) include/asm-generic/unistd.h defines __SYMBOL_PREFIX.
      2) include/asm-generic/vmlinux.lds.h defines VMLINUX_SYMBOL(sym)
      3) include/linux/export.h defines MODULE_SYMBOL_PREFIX.
      4) include/linux/kernel.h defines SYMBOL_PREFIX (which differs from #7)
      5) kernel/modsign_certificate.S defines ASM_SYMBOL(sym)
      6) scripts/modpost.c defines MODULE_SYMBOL_PREFIX
      7) scripts/Makefile.lib defines SYMBOL_PREFIX on the commandline if
         CONFIG_SYMBOL_PREFIX is set, so that we have a non-string version
         for pasting.
      
      (arch/h8300/include/asm/linkage.h defines SYMBOL_NAME(), too).
      
      Let's solve this properly:
      1) No more generic prefix, just CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX.
      2) Make linux/export.h usable from asm.
      3) Define VMLINUX_SYMBOL() and VMLINUX_SYMBOL_STR().
      4) Make everyone use them.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Reviewed-by: NJames Hogan <james.hogan@imgtec.com>
      Tested-by: James Hogan <james.hogan@imgtec.com> (metag)
      b92021b0
  12. 13 3月, 2013 1 次提交
  13. 04 3月, 2013 1 次提交
  14. 28 2月, 2013 1 次提交
  15. 26 2月, 2013 1 次提交
  16. 14 2月, 2013 1 次提交
    • A
      burying unused conditionals · d64008a8
      Al Viro 提交于
      __ARCH_WANT_SYS_RT_SIGACTION,
      __ARCH_WANT_SYS_RT_SIGSUSPEND,
      __ARCH_WANT_COMPAT_SYS_RT_SIGSUSPEND,
      __ARCH_WANT_COMPAT_SYS_SCHED_RR_GET_INTERVAL - not used anymore
      CONFIG_GENERIC_{SIGALTSTACK,COMPAT_RT_SIG{ACTION,QUEUEINFO,PENDING,PROCMASK}} -
      can be assumed always set.
      d64008a8
  17. 04 2月, 2013 6 次提交
  18. 24 1月, 2013 1 次提交
  19. 17 1月, 2013 1 次提交
    • V
      sk-filter: Add ability to lock a socket filter program · d59577b6
      Vincent Bernat 提交于
      While a privileged program can open a raw socket, attach some
      restrictive filter and drop its privileges (or send the socket to an
      unprivileged program through some Unix socket), the filter can still
      be removed or modified by the unprivileged program. This commit adds a
      socket option to lock the filter (SO_LOCK_FILTER) preventing any
      modification of a socket filter program.
      
      This is similar to OpenBSD BIOCLOCK ioctl on bpf sockets, except even
      root is not allowed change/drop the filter.
      
      The state of the lock can be read with getsockopt(). No error is
      triggered if the state is not changed. -EPERM is returned when a user
      tries to remove the lock or to change/remove the filter while the lock
      is active. The check is done directly in sk_attach_filter() and
      sk_detach_filter() and does not affect only setsockopt() syscall.
      Signed-off-by: NVincent Bernat <bernat@luffy.cx>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d59577b6
  20. 04 1月, 2013 1 次提交
  21. 20 12月, 2012 4 次提交
  22. 19 12月, 2012 1 次提交
    • F
      h8300: select generic atomic64_t support · d95bfe46
      Fengguang Wu 提交于
      Rationales from Eric:
      
      So I just looked a little deeper and it appears architectures that do
      not support atomic64_t are broken.
      
      The generic atomic64 support came in 2009 to support the perf subsystem
      with the expectation that all architectures would implement atomic64
      support.
      
      Furthermore upon inspection of the kernel atomic64_t is used in a fair
      number of places beyond the performance counters:
      
      block/blk-cgroup.c
      drivers/acpi/apei/
      drivers/block/rbd.c
      drivers/crypto/nx/nx.h
      drivers/gpu/drm/radeon/radeon.h
      drivers/infiniband/hw/ipath/
      drivers/infiniband/hw/qib/
      drivers/staging/octeon/
      fs/xfs/
      include/linux/perf_event.h
      include/net/netfilter/nf_conntrack_acct.h
      kernel/events/
      kernel/trace/
      net/mac80211/key.h
      net/rds/
      
      The block control group, infiniband, xfs, crypto, 802.11, netfilter.
      Nothing quite so fundamental as fs/namespace.c but definitely in
      multiplatform-code that should work, and is already broken on those
      architecutres.
      
      Looking at the implementation of atomic64_add_return in lib/atomic64.c the
      code looks as efficient as these kinds of things get.
      
      Which leads me to the conclusion that we need atomic64 support on all
      architectures.
      Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d95bfe46
  23. 10 12月, 2012 1 次提交