1. 19 5月, 2015 5 次提交
    • I
      x86/fpu: Rename save_xstate_sig() to copy_fpstate_to_sigframe() · c8e14041
      Ingo Molnar 提交于
      Standardize the naming of save_xstate_sig() by renaming it to
      copy_fpstate_to_sigframe(): this tells us at a glance that
      the function copies an FPU fpstate to a signal frame.
      
      This naming also follows the naming of copy_fpregs_to_fpstate().
      
      Don't put 'xstate' into the name: since this is a generic name,
      it's expected that the function is able to handle xstate frames
      as well, beyond legacy frames.
      
      xstate used to be the odd case in the x86 FPU code - now it's the
      common case.
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      c8e14041
    • I
      x86/fpu: Rename fpu-internal.h to fpu/internal.h · 78f7f1e5
      Ingo Molnar 提交于
      This unifies all the FPU related header files under a unified, hiearchical
      naming scheme:
      
       - asm/fpu/types.h:      FPU related data types, needed for 'struct task_struct',
                               widely included in almost all kernel code, and hence kept
                               as small as possible.
      
       - asm/fpu/api.h:        FPU related 'public' methods exported to other subsystems.
      
       - asm/fpu/internal.h:   FPU subsystem internal methods
      
       - asm/fpu/xsave.h:      XSAVE support internal methods
      
      (Also standardize the header guard in asm/fpu/internal.h.)
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      78f7f1e5
    • I
      x86/fpu: Get rid of PF_USED_MATH usage, convert it to fpu->fpstate_active · c5bedc68
      Ingo Molnar 提交于
      Introduce a simple fpu->fpstate_active flag in the fpu context data structure
      and use that instead of PF_USED_MATH in task->flags.
      
      Testing for this flag byte should be slightly more efficient than
      testing a bit in a bitmask, but the main advantage is that most
      FPU functions can now be performed on a 'struct fpu' alone, they
      don't need access to 'struct task_struct' anymore.
      
      There's a slight linecount increase, mostly due to the 'fpu' local
      variables and due to extra comments. The local variables will go away
      once we move most of the FPU methods to pure 'struct fpu' parameters.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      c5bedc68
    • I
      x86/fpu: Open code PF_USED_MATH usages · 4c138410
      Ingo Molnar 提交于
      PF_USED_MATH is used directly, but also in a handful of helper inlines.
      
      To ease the elimination of PF_USED_MATH, convert all inline helpers
      to open-coded PF_USED_MATH usage.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      4c138410
    • I
      x86/fpu: Fix header file dependencies of fpu-internal.h · f89e32e0
      Ingo Molnar 提交于
      Fix a minor header file dependency bug in asm/fpu-internal.h: it
      relies on i387.h but does not include it. All users of fpu-internal.h
      included it explicitly.
      
      Also remove unnecessary includes, to reduce compilation time.
      
      This also makes it easier to use it as a standalone header file
      for FPU internals, such as an upcoming C module in arch/x86/kernel/fpu/.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      f89e32e0
  2. 06 4月, 2015 1 次提交
  3. 23 3月, 2015 1 次提交
    • B
      x86/asm/entry: Fix execve() and sigreturn() syscalls to always return via IRET · 1daeaa31
      Brian Gerst 提交于
      Both the execve() and sigreturn() family of syscalls have the
      ability to change registers in ways that may not be compatabile
      with the syscall path they were called from.
      
      In particular, SYSRET and SYSEXIT can't handle non-default %cs and %ss,
      and some bits in eflags.
      
      These syscalls have stubs that are hardcoded to jump to the IRET path,
      and not return to the original syscall path.
      
      The following commit:
      
         76f5df43 ("Always allocate a complete "struct pt_regs" on the kernel stack")
      
      recently changed this for some 32-bit compat syscalls, but introduced a bug where
      execve from a 32-bit program to a 64-bit program would fail because it still returned
      via SYSRETL. This caused Wine to fail when built for both 32-bit and 64-bit.
      
      This patch sets TIF_NOTIFY_RESUME for execve() and sigreturn() so
      that the IRET path is always taken on exit to userspace.
      Signed-off-by: NBrian Gerst <brgerst@gmail.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1426978461-32089-1-git-send-email-brgerst@gmail.com
      [ Improved the changelog and comments. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      1daeaa31
  4. 13 2月, 2015 1 次提交
    • A
      all arches, signal: move restart_block to struct task_struct · f56141e3
      Andy Lutomirski 提交于
      If an attacker can cause a controlled kernel stack overflow, overwriting
      the restart block is a very juicy exploit target.  This is because the
      restart_block is held in the same memory allocation as the kernel stack.
      
      Moving the restart block to struct task_struct prevents this exploit by
      making the restart_block harder to locate.
      
      Note that there are other fields in thread_info that are also easy
      targets, at least on some architectures.
      
      It's also a decent simplification, since the restart code is more or less
      identical on all architectures.
      
      [james.hogan@imgtec.com: metag: align thread_info::supervisor_stack]
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: David Miller <davem@davemloft.net>
      Acked-by: NRichard Weinberger <richard@nod.at>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Tested-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Chen Liqin <liqin.linux@gmail.com>
      Cc: Lennox Wu <lennox.wu@gmail.com>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f56141e3
  5. 06 5月, 2014 1 次提交
    • A
      x86, vdso: Reimplement vdso.so preparation in build-time C · 6f121e54
      Andy Lutomirski 提交于
      Currently, vdso.so files are prepared and analyzed by a combination
      of objcopy, nm, some linker script tricks, and some simple ELF
      parsers in the kernel.  Replace all of that with plain C code that
      runs at build time.
      
      All five vdso images now generate .c files that are compiled and
      linked in to the kernel image.
      
      This should cause only one userspace-visible change: the loaded vDSO
      images are stripped more heavily than they used to be.  Everything
      outside the loadable segment is dropped.  In particular, this causes
      the section table and section name strings to be missing.  This
      should be fine: real dynamic loaders don't load or inspect these
      tables anyway.  The result is roughly equivalent to eu-strip's
      --strip-sections option.
      
      The purpose of this change is to enable the vvar and hpet mappings
      to be moved to the page following the vDSO load segment.  Currently,
      it is possible for the section table to extend into the page after
      the load segment, so, if we map it, it risks overlapping the vvar or
      hpet page.  This happens whenever the load segment is just under a
      multiple of PAGE_SIZE.
      
      The only real subtlety here is that the old code had a C file with
      inline assembler that did 'call VDSO32_vsyscall' and a linker script
      that defined 'VDSO32_vsyscall = __kernel_vsyscall'.  This most
      likely worked by accident: the linker script entry defines a symbol
      associated with an address as opposed to an alias for the real
      dynamic symbol __kernel_vsyscall.  That caused ld to relocate the
      reference at link time instead of leaving an interposable dynamic
      relocation.  Since the VDSO32_vsyscall hack is no longer needed, I
      now use 'call __kernel_vsyscall', and I added -Bsymbolic to make it
      work.  vdso2c will generate an error and abort the build if the
      resulting image contains any dynamic relocations, so we won't
      silently generate bad vdso images.
      
      (Dynamic relocations are a problem because nothing will even attempt
      to relocate the vdso.)
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Link: http://lkml.kernel.org/r/2c4fcf45524162a34d87fdda1eb046b2a5cecee7.1399317206.git.luto@amacapital.netSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      6f121e54
  6. 09 11月, 2013 1 次提交
  7. 02 9月, 2013 1 次提交
  8. 28 5月, 2013 1 次提交
  9. 14 2月, 2013 1 次提交
  10. 04 2月, 2013 2 次提交
  11. 20 12月, 2012 2 次提交
  12. 22 9月, 2012 1 次提交
  13. 19 9月, 2012 1 次提交
    • S
      x86, fpu: Unify signal handling code paths for x86 and x86_64 kernels · 72a671ce
      Suresh Siddha 提交于
      Currently for x86 and x86_32 binaries, fpstate in the user sigframe is copied
      to/from the fpstate in the task struct.
      
      And in the case of signal delivery for x86_64 binaries, if the fpstate is live
      in the CPU registers, then the live state is copied directly to the user
      sigframe. Otherwise  fpstate in the task struct is copied to the user sigframe.
      During restore, fpstate in the user sigframe is restored directly to the live
      CPU registers.
      
      Historically, different code paths led to different bugs. For example,
      x86_64 code path was not preemption safe till recently. Also there is lot
      of code duplication for support of new features like xsave etc.
      
      Unify signal handling code paths for x86 and x86_64 kernels.
      
      New strategy is as follows:
      
      Signal delivery: Both for 32/64-bit frames, align the core math frame area to
      64bytes as needed by xsave (this where the main fpu/extended state gets copied
      to and excludes the legacy compatibility fsave header for the 32-bit [f]xsave
      frames). If the state is live, copy the register state directly to the user
      frame. If not live, copy the state in the thread struct to the user frame. And
      for 32-bit [f]xsave frames, construct the fsave header separately before
      the actual [f]xsave area.
      
      Signal return: As the 32-bit frames with [f]xstate has an additional
      'fsave' header, copy everything back from the user sigframe to the
      fpstate in the task structure and reconstruct the fxstate from the 'fsave'
      header (Also user passed pointers may not be correctly aligned for
      any attempt to directly restore any partial state). At the next fpstate usage,
      everything will be restored to the live CPU registers.
      For all the 64-bit frames and the 32-bit fsave frame, restore the state from
      the user sigframe directly to the live CPU registers. 64-bit signals always
      restored the math frame directly, so we can expect the math frame pointer
      to be correctly aligned. For 32-bit fsave frames, there are no alignment
      requirements, so we can restore the state directly.
      
      "lat_sig catch" microbenchmark numbers (for x86, x86_64, x86_32 binaries) are
      with in the noise range with this change.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Link: http://lkml.kernel.org/r/1343171129-2747-4-git-send-email-suresh.b.siddha@intel.com
      [ Merged in compilation fix ]
      Link: http://lkml.kernel.org/r/1344544736.8326.17.camel@sbsiddha-desk.sc.intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      72a671ce
  14. 05 9月, 2012 1 次提交
  15. 15 6月, 2012 1 次提交
  16. 02 6月, 2012 1 次提交
  17. 22 5月, 2012 1 次提交
  18. 14 4月, 2012 1 次提交
    • W
      signal, x86: add SIGSYS info and make it synchronous. · a0727e8c
      Will Drewry 提交于
      This change enables SIGSYS, defines _sigfields._sigsys, and adds
      x86 (compat) arch support.  _sigsys defines fields which allow
      a signal handler to receive the triggering system call number,
      the relevant AUDIT_ARCH_* value for that number, and the address
      of the callsite.
      
      SIGSYS is added to the SYNCHRONOUS_MASK because it is desirable for it
      to have setup_frame() called for it. The goal is to ensure that
      ucontext_t reflects the machine state from the time-of-syscall and not
      from another signal handler.
      
      The first consumer of SIGSYS would be seccomp filter.  In particular,
      a filter program could specify a new return value, SECCOMP_RET_TRAP,
      which would result in the system call being denied and the calling
      thread signaled.  This also means that implementing arch-specific
      support can be dependent upon HAVE_ARCH_SECCOMP_FILTER.
      Suggested-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NWill Drewry <wad@chromium.org>
      Acked-by: NSerge Hallyn <serge.hallyn@canonical.com>
      Reviewed-by: NH. Peter Anvin <hpa@zytor.com>
      Acked-by: NEric Paris <eparis@redhat.com>
      
      v18: - added acked by, rebase
      v17: - rebase and reviewed-by addition
      v14: - rebase/nochanges
      v13: - rebase on to 88ebdda6
      v12: - reworded changelog (oleg@redhat.com)
      v11: - fix dropped words in the change description
           - added fallback copy_siginfo support.
           - added __ARCH_SIGSYS define to allow stepped arch support.
      v10: - first version based on suggestion
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      a0727e8c
  19. 14 3月, 2012 1 次提交
  20. 13 3月, 2012 1 次提交
  21. 06 3月, 2012 1 次提交
    • H
      x32: Switch to a 64-bit clock_t · e7084fd5
      H. Peter Anvin 提交于
      clock_t is used mainly to give the number of jiffies a certain process
      has burned.  It is entirely feasible for a long-running process to
      consume more than 2^32 jiffies especially in a multiprocess system.
      As such, switch to a 64-bit clock_t for x32, just as we already
      switched to a 64-bit time_t.
      
      clock_t is only used in a handful of places, and as such it is really
      not a very significant change.  The one that has the biggest impact is
      in struct siginfo, but since the *size* of struct siginfo doesn't
      change (it is padded to the hilt) it is fairly easy to make this a
      localized change.
      
      This also gets rid of sys_x32_times, however since this is a pretty
      late change don't compactify the system call numbers; we can reuse
      system call slot 521 next time we need an x32 system call.
      Reported-by: NGregory M. Lueck <gregory.m.lueck@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: H. J. Lu <hjl.tools@gmail.com>
      Link: http://lkml.kernel.org/r/1329696488-16970-1-git-send-email-hpa@zytor.com
      e7084fd5
  22. 22 2月, 2012 1 次提交
    • L
      i387: Split up <asm/i387.h> into exported and internal interfaces · 1361b83a
      Linus Torvalds 提交于
      While various modules include <asm/i387.h> to get access to things we
      actually *intend* for them to use, most of that header file was really
      pretty low-level internal stuff that we really don't want to expose to
      others.
      
      So split the header file into two: the small exported interfaces remain
      in <asm/i387.h>, while the internal definitions that are only used by
      core architecture code are now in <asm/fpu-internal.h>.
      
      The guiding principle for this was to expose functions that we export to
      modules, and leave them in <asm/i387.h>, while stuff that is used by
      task switching or was marked GPL-only is in <asm/fpu-internal.h>.
      
      The fpu-internal.h file could be further split up too, especially since
      arch/x86/kvm/ uses some of the remaining stuff for its module.  But that
      kvm usage should probably be abstracted out a bit, and at least now the
      internal FPU accessor functions are much more contained.  Even if it
      isn't perhaps as contained as it _could_ be.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1202211340330.5354@i5.linux-foundation.orgSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      1361b83a
  23. 21 2月, 2012 1 次提交
    • H
      x86: Move some signal-handling definitions to a common header · f28f0c23
      H. Peter Anvin 提交于
      There are some definitions which are duplicated between
      kernel/signal.c and ia32/ia32_signal.c; move them to a common header
      file.
      
      Rather than adding stuff to existing header files which contain data
      structures, create a new header file; hence the slightly odd name
      ("all the good ones were taken.")
      
      Note: nothing relied on signal_fault() being defined in
      <asm/ptrace.h>.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      f28f0c23
  24. 15 7月, 2011 1 次提交
  25. 23 2月, 2009 3 次提交
  26. 24 1月, 2009 1 次提交
  27. 29 12月, 2008 1 次提交
    • J
      x86: introducing asm/sys_ia32.h · 2f06de06
      Jaswinder Singh Rajput 提交于
      Impact: cleanup, avoid 44 sparse warnings, new file asm/sys_ia32.h
      
      Fixes following sparse warnings:
      
        CHECK   arch/x86/ia32/sys_ia32.c
      arch/x86/ia32/sys_ia32.c:53:17: warning: symbol 'sys32_truncate64' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:60:17: warning: symbol 'sys32_ftruncate64' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:98:17: warning: symbol 'sys32_stat64' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:109:17: warning: symbol 'sys32_lstat64' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:119:17: warning: symbol 'sys32_fstat64' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:128:17: warning: symbol 'sys32_fstatat' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:164:17: warning: symbol 'sys32_mmap' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:195:17: warning: symbol 'sys32_mprotect' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:201:17: warning: symbol 'sys32_pipe' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:215:17: warning: symbol 'sys32_rt_sigaction' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:291:17: warning: symbol 'sys32_sigaction' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:330:17: warning: symbol 'sys32_rt_sigprocmask' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:370:17: warning: symbol 'sys32_alarm' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:383:17: warning: symbol 'sys32_old_select' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:393:17: warning: symbol 'sys32_waitpid' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:401:17: warning: symbol 'sys32_sysfs' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:406:17: warning: symbol 'sys32_sched_rr_get_interval' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:421:17: warning: symbol 'sys32_rt_sigpending' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:445:17: warning: symbol 'sys32_rt_sigqueueinfo' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:472:17: warning: symbol 'sys32_sysctl' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:517:17: warning: symbol 'sys32_pread' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:524:17: warning: symbol 'sys32_pwrite' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:532:17: warning: symbol 'sys32_personality' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:545:17: warning: symbol 'sys32_sendfile' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:565:17: warning: symbol 'sys32_mmap2' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:589:17: warning: symbol 'sys32_olduname' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:626:6: warning: symbol 'sys32_uname' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:641:6: warning: symbol 'sys32_ustat' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:663:17: warning: symbol 'sys32_execve' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:678:17: warning: symbol 'sys32_clone' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:693:6: warning: symbol 'sys32_lseek' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:698:6: warning: symbol 'sys32_kill' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:703:6: warning: symbol 'sys32_fadvise64_64' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:712:6: warning: symbol 'sys32_vm86_warning' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:726:6: warning: symbol 'sys32_lookup_dcookie' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:732:20: warning: symbol 'sys32_readahead' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:738:17: warning: symbol 'sys32_sync_file_range' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:746:17: warning: symbol 'sys32_fadvise64' was not declared. Should it be static?
      arch/x86/ia32/sys_ia32.c:753:17: warning: symbol 'sys32_fallocate' was not declared. Should it be static?
        CHECK   arch/x86/ia32/ia32_signal.c
      arch/x86/ia32/ia32_signal.c:126:17: warning: symbol 'sys32_sigsuspend' was not declared. Should it be static?
      arch/x86/ia32/ia32_signal.c:141:17: warning: symbol 'sys32_sigaltstack' was not declared. Should it be static?
      arch/x86/ia32/ia32_signal.c:249:17: warning: symbol 'sys32_sigreturn' was not declared. Should it be static?
      arch/x86/ia32/ia32_signal.c:279:17: warning: symbol 'sys32_rt_sigreturn' was not declared. Should it be static?
        CHECK   arch/x86/ia32/ipc32.c
      arch/x86/ia32/ipc32.c:12:17: warning: symbol 'sys32_ipc' was not declared. Should it be static?
      Signed-off-by: NJaswinder Singh Rajput <jaswinderrajput@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2f06de06
  28. 20 12月, 2008 1 次提交
  29. 18 12月, 2008 2 次提交
  30. 17 12月, 2008 2 次提交