Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 2月, 2015 1 次提交
  3. 02 8月, 2014 2 次提交
    • A
      MIPS: ptrace: Fix user pt_regs definition, use in ptrace_{get, set}regs() · a79ebea6
      由 Alex Smith 提交于 
      In uapi/asm/ptrace.h, a user version of pt_regs is defined wrapped in
ifndef __KERNEL__. This structure definition does not match anything
used by any kernel API, in particular it does not match the format used
by PTRACE_{GET,SET}REGS.

Therefore, replace the structure definition with one matching what is
used by PTRACE_{GET,SET}REGS. The format used by these is the same for
both 32-bit and 64-bit.

Also, change the implementation of PTRACE_{GET,SET}REGS to use this new
structure definition. The structure is renamed to user_pt_regs when
__KERNEL__ is defined to avoid conflicts with the kernel's own pt_regs.
Signed-off-by: NAlex Smith <alex@alex-smith.me.uk>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7457/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a79ebea6
    • A
      MIPS: O32/32-bit: Fix bug which can cause incorrect system call restarts · e90e6fdd
      由 Alex Smith 提交于 
      On 32-bit/O32, pt_regs has a padding area at the beginning into which the
syscall arguments passed via the user stack are copied. 4 arguments
totalling 16 bytes are copied to offset 16 bytes into this area, however
the area is only 24 bytes long. This means the last 2 arguments overwrite
pt_regs->regs[{0,1}].

If a syscall function returns an error, handle_sys stores the original
syscall number in pt_regs->regs[0] for syscall restart. signal.c checks
whether regs[0] is non-zero, if it is it will check whether the syscall
return value is one of the ERESTART* codes to see if it must be
restarted.

Should a syscall be made that results in a non-zero value being copied
off the user stack into regs[0], and then returns a positive (non-error)
value that matches one of the ERESTART* error codes, this can be mistaken
for requiring a syscall restart.

While the possibility for this to occur has always existed, it is made
much more likely to occur by commit 46e12c07 ("MIPS: O32 / 32-bit:
Always copy 4 stack arguments."), since now every syscall will copy 4
arguments and overwrite regs[0], rather than just those with 7 or 8
arguments.

Since that commit, booting Debian under a 32-bit MIPS kernel almost
always results in a hang early in boot, due to a wait4 syscall returning
a PID that matches one of the ERESTART* codes, which then causes an
incorrect restart of the syscall.

The problem is fixed by increasing the size of the padding area so that
arguments copied off the stack will not overwrite pt_regs->regs[{0,1}].
Signed-off-by: NAlex Smith <alex.smith@imgtec.com>
Cc: <stable@vger.kernel.org> # v3.13+
Reviewed-by: NAurelien Jarno <aurelien@aurel32.net>
Tested-by: NAurelien Jarno <aurelien@aurel32.net>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7454/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      e90e6fdd
  5. 24 5月, 2014 1 次提交
    • R
      MIPS: MT: Remove SMTC support · b633648c
      由 Ralf Baechle 提交于 
      Nobody is maintaining SMTC anymore and there also seems to be no userbase.
Which is a pity - the SMTC technology primarily developed by Kevin D.
Kissell <kevink@paralogos.com> is an ingenious demonstration for the MT
ASE's power and elegance.

Based on Markos Chandras <Markos.Chandras@imgtec.com> patch
https://patchwork.linux-mips.org/patch/6719/ which while very similar did
no longer apply cleanly when I tried to merge it plus some additional
post-SMTC cleanup - SMTC was a feature as tricky to remove as it was to
merge once upon a time.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      b633648c
  7. 27 3月, 2014 2 次提交
  9. 30 10月, 2013 1 次提交
  11. 23 5月, 2013 1 次提交
  13. 20 12月, 2012 1 次提交
  15. 15 10月, 2012 1 次提交
  17. 09 10月, 2012 1 次提交
  19. 18 1月, 2012 1 次提交
    • E
      Audit: push audit success and retcode into arch ptrace.h · d7e7528b
      由 Eric Paris 提交于 
      The audit system previously expected arches calling to audit_syscall_exit to
supply as arguments if the syscall was a success and what the return code was.
Audit also provides a helper AUDITSC_RESULT which was supposed to simplify things
by converting from negative retcodes to an audit internal magic value stating
success or failure.  This helper was wrong and could indicate that a valid
pointer returned to userspace was a failed syscall.  The fix is to fix the
layering foolishness.  We now pass audit_syscall_exit a struct pt_reg and it
in turns calls back into arch code to collect the return value and to
determine if the syscall was a success or failure.  We also define a generic
is_syscall_success() macro which determines success/failure based on if the
value is < -MAX_ERRNO.  This works for arches like x86 which do not use a
separate mechanism to indicate syscall failure.

We make both the is_syscall_success() and regs_return_value() static inlines
instead of macros.  The reason is because the audit function must take a void*
for the regs.  (uml calls theirs struct uml_pt_regs instead of just struct
pt_regs so audit_syscall_exit can't take a struct pt_regs).  Since the audit
function takes a void* we need to use static inlines to cast it back to the
arch correct structure to dereference it.

The other major change is that on some arches, like ia64, MIPS and ppc, we
change regs_return_value() to give us the negative value on syscall failure.
THE only other user of this macro, kretprobe_example.c, won't notice and it
makes the value signed consistently for the audit functions across all archs.

In arch/sh/kernel/ptrace_64.c I see that we were using regs[9] in the old
audit code as the return value.  But the ptrace_64.h code defined the macro
regs_return_value() as regs[3].  I have no idea which one is correct, but this
patch now uses the regs_return_value() function, so it now uses regs[3].

For powerpc we previously used regs->result but now use the
regs_return_value() function which uses regs->gprs[3].  regs->gprs[3] is
always positive so the regs_return_value(), much like ia64 makes it negative
before calling the audit code when appropriate.
Signed-off-by: NEric Paris <eparis@redhat.com>
Acked-by: H. Peter Anvin <hpa@zytor.com> [for x86 portion]
Acked-by: Tony Luck <tony.luck@intel.com> [for ia64]
Acked-by: Richard Weinberger <richard@nod.at> [for uml]
Acked-by: David S. Miller <davem@davemloft.net> [for sparc]
Acked-by: Ralf Baechle <ralf@linux-mips.org> [for mips]
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> [for ppc]
      d7e7528b
  21. 13 1月, 2012 2 次提交
  23. 19 5月, 2011 1 次提交
  25. 05 8月, 2010 1 次提交
  27. 01 5月, 2010 1 次提交
  29. 31 1月, 2009 1 次提交
  31. 11 1月, 2009 1 次提交
  33. 01 12月, 2008 1 次提交
  35. 28 10月, 2008 2 次提交
    • Y
      MIPS: Fix KGDB build error · f6a3176a
      由 Yoichi Yuasa 提交于 
      In file included from include/linux/ptrace.h:49,
                 from arch/mips/kernel/kgdb.c:25:
/home/yuasa/src/linux/test/mips/linux/arch/mips/include/asm/ptrace.h:123: error: expected declaration specifiers or '...' before '__s64'
/home/yuasa/src/linux/test/mips/linux/arch/mips/include/asm/ptrace.h:124: error: expected declaration specifiers or '...' before '__s64'
/home/yuasa/src/linux/test/mips/linux/arch/mips/include/asm/ptrace.h:126: error: expected declaration specifiers or '...' before '__u32'
/home/yuasa/src/linux/test/mips/linux/arch/mips/include/asm/ptrace.h:127: error: expected declaration specifiers or '...' before '__u32'
make[1]: *** [arch/mips/kernel/kgdb.o] Error 1
Signed-off-by: NYoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      f6a3176a
    • D
      MIPS: Fix KGDB build error · c9440135
      由 David Daney 提交于 
      <asm/ptrace.h> is exported to userland so can't include <linux/ptrace.h>,
so replace the C99 types with their basic C type equivalents.

Bug originally reported and initial patch by Yoichi Yuasa
<yoichi_yuasa@tripeaks.co.jp>.
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      c9440135
  37. 11 10月, 2008 4 次提交
  39. 17 10月, 2007 1 次提交
    • R
      [MIPS] IP22: Fix warning. · eae23f2c
      由 Ralf Baechle 提交于 
        CC      arch/mips/sgi-ip22/ip22-berr.o
arch/mips/sgi-ip22/ip22-berr.c: In function 'ip22_be_interrupt':
arch/mips/sgi-ip22/ip22-berr.c:100: warning: passing argument 2 of 'die_if_kernel' discards qualifiers from pointer target type
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      eae23f2c
  41. 04 7月, 2007 1 次提交
  43. 22 2月, 2007 1 次提交
    • F
      [MIPS] Add basic SMARTMIPS ASE support · 9693a853
      由 Franck Bui-Huu 提交于 
      This patch adds trivial support for SMARTMIPS extension. This extension
is currently implemented by 4KS[CD] CPUs.

Basically it saves/restores ACX register, which is part of the SMARTMIPS
ASE, when needed. This patch does *not* add any support for Smartmips MMU
features.

Futhermore this patch does not add explicit support for 4KS[CD] CPUs since
they are respectively mips32 and mips32r2 compliant.  So with the current
processor configuration, a platform that has such CPUs needs to select
both configs:

	CPU_HAS_SMARTMIPS
	SYS_HAS_CPU_MIPS32_R[12]

This is due to the processor configuration which is mixing up all the
architecture variants and the processor types.

The drawback of this, is that we currently pass '-march=mips32' option to
gcc when building a kernel instead of '-march=4ksc' for 4KSC case. This
can lead to a kernel image a little bit bigger than required.
Signed-off-by: NFranck Bui-Huu <fbuihuu@gmail.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      9693a853
  45. 11 12月, 2006 1 次提交
  47. 30 11月, 2006 1 次提交
  49. 04 10月, 2006 1 次提交
  51. 27 9月, 2006 1 次提交
  53. 26 4月, 2006 1 次提交
  55. 19 4月, 2006 1 次提交
  57. 30 10月, 2005 2 次提交
  59. 05 9月, 2005 1 次提交
  61. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      由 Linus Torvalds 提交于 
      Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
      1da177e4