Skip to content

L
linux
Switch branch/tag
  1. 10 Apr, 2006 34 commits
  3. 09 Apr, 2006 6 commits
    • Dave Jones's avatar
      [SELINUX] Fix build after ipsec decap state changes. · 67644726
      Dave Jones authored 
          security/selinux/xfrm.c: In function 'selinux_socket_getpeer_dgram':
    security/selinux/xfrm.c:284: error: 'struct sec_path' has no member named 'x'
    security/selinux/xfrm.c: In function 'selinux_xfrm_sock_rcv_skb':
    security/selinux/xfrm.c:317: error: 'struct sec_path' has no member named 'x'
Signed-off-by: default avatarDave Jones <davej@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      67644726
    • Linus Torvalds's avatar
      Move request_standard_resources() back to before PCI probing · 66004a6c
      Linus Torvalds authored 
      This effectively undoes the PCI resource allocation changes done in
commit b408cbc7, but leaves the cleanups
of that commit in place.

We're going back to marking the resources reported by e820 busy _before_
doing PCI probing, so that any PCI resource that clashes with the BIOS-
reported memory map will be reloacted to a non-clashing area.

The reason? Larry Finger reports that his laptop has the cardbus
controller set up by the BIOS so that it conflicts with the e820 memory
map, and needs to be relocated. See

   http://bugzilla.kernel.org/show_bug.cgi?id=6337

for more details.

We'll have to work out how to handle the fbcon problem that caused that
commit in the first place in some other way.

Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Antonino A. Daplas <adaplas@pol.net>
Cc: <bjk@luxsci.net>
Tested-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      66004a6c
    • Andi Kleen's avatar
      [PATCH] x86_64: Update 32-bit system call table · b8feb47f
      Andi Kleen authored 
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b8feb47f
    • Andi Kleen's avatar
      [PATCH] x86_64: Eliminate IA32_NR_syscalls define · 67d53ea5
      Andi Kleen authored 
      Or rather compute it based on the table length automatically.

This also has the intended side effect of not warning for new system calls
anymore.
Signed-off-by: default avatarAndi Kleen <ak@suse.de>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      67d53ea5
    • Sam Ravnborg's avatar
      [PATCH] x86_64: fix CONFIG_REORDER · bbd3aff8
      Sam Ravnborg authored 
      Fix CONFIG_REORDER.

The value of cflags-y was assined to CFLAGS before cflags-y was assigned
the value used for CONFIG_REORDER.

Use cflags-y for all CFLAGS options in the Makefile to avoid this
happening again.
Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
Signed-off-by: default avatarAndi Kleen <ak@suse.de>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      bbd3aff8
    • John Blackwood's avatar
      [PATCH] x86_64: Plug GS leak in arch_prctl() · 97c2803c
      John Blackwood authored 
      In linux-2.6.16, we have noticed a problem where the gs base value
returned from an arch_prtcl(ARCH_GET_GS, ...) call will be incorrect if:

   - the current/calling task has NOT set its own gs base yet to a
     non-zero value,

   - some other task that ran on the same processor previously set their
     own gs base to a non-zero value.

In this situation, the ARCH_GET_GS code will read and return the
MSR_KERNEL_GS_BASE msr register.

However, since the __switch_to() code does NOT load/zero the
MSR_KERNEL_GS_BASE register when the task that is switched IN has a zero
next->gs value, the caller of arch_prctl(ARCH_GET_GS, ...) will get back
the value of some previous tasks's gs base value instead of 0.

    Change the arch_prctl() ARCH_GET_GS code to only read and return
    the MSR_KERNEL_GS_BASE msr register if the 'gs' register of the calling
    task is non-zero.

    Side note: Since in addition to using arch_prctl(ARCH_SET_GS, ...),
    a task can also setup a gs base value by using modify_ldt() and write
    an index value into 'gs' from user space, the patch below reads
    'gs' instead of using thread.gs, since in the modify_ldt() case,
    the thread.gs value will be 0, and incorrect value would be returned
    (the task->thread.gs value).

    When the user has not set its own gs base value and the 'gs'
    register is zero, then the MSR_KERNEL_GS_BASE register will not be
    read and a value of zero will be returned by reading and returning
    'task->thread.gs'.

    The first patch shown below is an attempt at implementing this
    approach.
Signed-off-by: default avatarAndi Kleen <ak@suse.de>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      97c2803c
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7