1. 18 7月, 2007 3 次提交
  2. 17 7月, 2007 3 次提交
    • V
      diskquota: 32bit quota tools on 64bit architectures · b716395e
      Vasily Tarasov 提交于
      OpenVZ Linux kernel team has discovered the problem with 32bit quota tools
      working on 64bit architectures.  In 2.6.10 kernel sys32_quotactl() function
      was replaced by sys_quotactl() with the comment "sys_quotactl seems to be
      32/64bit clean, enable it for 32bit" However this isn't right.  Look at
      if_dqblk structure:
      
      struct if_dqblk {
              __u64 dqb_bhardlimit;
              __u64 dqb_bsoftlimit;
              __u64 dqb_curspace;
              __u64 dqb_ihardlimit;
              __u64 dqb_isoftlimit;
              __u64 dqb_curinodes;
              __u64 dqb_btime;
              __u64 dqb_itime;
              __u32 dqb_valid;
      };
      
      For 32 bit quota tools sizeof(if_dqblk) == 0x44.
      But for 64 bit kernel its size is 0x48, 'cause of alignment!
      Thus we got a problem. Attached patch reintroduce sys32_quotactl() function,
      that handles this and related situations.
      
      [michal.k.k.piotrowski@gmail.com: build fix]
      [akpm@linux-foundation.org: Make it link with CONFIG_QUOTA=n]
      Signed-off-by: NVasily Tarasov <vtaras@openvz.org>
      Cc: Andi Kleen <ak@suse.de>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Jan Kara <jack@ucw.cz>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NMichal Piotrowski <michal.k.k.piotrowski@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b716395e
    • J
      PIE randomization · 60bfba7e
      Jan Kratochvil 提交于
      This patch is using mmap()'s randomization functionality in such a way that
      it maps the main executable of (specially compiled/linked -pie/-fpie)
      ET_DYN binaries onto a random address (in cases in which mmap() is allowed
      to perform a randomization).
      
      Origin of this patch is in exec-shield
      (http://people.redhat.com/mingo/exec-shield/)
      
      [jkosina@suse.cz: pie randomization: fix BAD_ADDR macro]
      Signed-off-by: NJan Kratochvil <honza@jikos.cz>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      60bfba7e
    • Y
      serial: convert early_uart to earlycon for 8250 · 18a8bd94
      Yinghai Lu 提交于
      Beacuse SERIAL_PORT_DFNS is removed from include/asm-i386/serial.h and
      include/asm-x86_64/serial.h.  the serial8250_ports need to be probed late in
      serial initializing stage.  the console_init=>serial8250_console_init=>
      register_console=>serial8250_console_setup will return -ENDEV, and console
      ttyS0 can not be enabled at that time.  need to wait till uart_add_one_port in
      drivers/serial/serial_core.c to call register_console to get console ttyS0.
      that is too late.
      
      Make early_uart to use early_param, so uart console can be used earlier.  Make
      it to be bootconsole with CON_BOOT flag, so can use console handover feature.
      and it will switch to corresponding normal serial console automatically.
      
      new command line will be:
      	console=uart8250,io,0x3f8,9600n8
      	console=uart8250,mmio,0xff5e0000,115200n8
      or
      	earlycon=uart8250,io,0x3f8,9600n8
      	earlycon=uart8250,mmio,0xff5e0000,115200n8
      
      it will print in very early stage:
      	Early serial console at I/O port 0x3f8 (options '9600n8')
      	console [uart0] enabled
      later for console it will print:
      	console handover: boot [uart0] -> real [ttyS0]
      
      Signed-off-by: <yinghai.lu@sun.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Gerd Hoffmann <kraxel@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      18a8bd94
  3. 12 7月, 2007 4 次提交
    • M
      PCI: Only build PCI syscalls on architectures that want them · 36e23590
      Matthew Wilcox 提交于
      The PCI syscalls are built on every architecture except X86, but only
      a few have ever hooked them up.  Use a new Kconfig symbol to save a
      couple of kB on the architectures that have never used the syscalls.
      Tested on x86 and ia64 only.
      Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      36e23590
    • R
      [IA64] Support multiple CPUs going through OS_MCA · 1612b18c
      Russ Anderson 提交于
      Linux does not gracefully deal with multiple processors going
      through OS_MCA aa part of the same MCA event.  The first cpu
      into OS_MCA grabs the ia64_mca_serialize lock.  Subsequent
      cpus wait for that lock, preventing them from reporting in as
      rendezvoused.  The first cpu waits 5 seconds then complains
      that all the cpus have not rendezvoused.  The first cpu then
      handles its MCA and frees up all the rendezvoused cpus and
      releases the ia64_mca_serialize lock.  One of the subsequent
      cpus going thought OS_MCA then gets the ia64_mca_serialize
      lock, waits another 5 seconds and then complains that none of
      the other cpus have rendezvoused.
      
      This patch allows multiple CPUs to gracefully go through OS_MCA.
      
      The first CPU into ia64_mca_handler() grabs a mca_count lock.
      Subsequent CPUs into ia64_mca_handler() are added to a list of cpus
      that need to go through OS_MCA (a bit set in mca_cpu), and report
      in as rendezvoused, and but spin waiting their turn.
      
      The first CPU sees everyone rendezvous, handles his MCA, wakes up
      one of the other CPUs waiting to process their MCA (by clearing
      one mca_cpu bit), and then waits for the other cpus to complete
      their MCA handling.  The next CPU handles his MCA and the process
      repeats until all the CPUs have handled their MCA.  When the last
      CPU has handled it's MCA, it sets monarch_cpu to -1, releasing all
      the CPUs.
      
      In testing this works more reliably and faster.
      
      Thanks to Keith Owens for suggesting numerous improvements
      to this code.
      Signed-off-by: NRuss Anderson <rja@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      1612b18c
    • J
      [IA64] silence GCC ia64 unused variable warnings · 256a7e09
      Jes Sorensen 提交于
      Tell GCC to stop spewing out unnecessary warnings for unused variables
      passed to functions as pointers for ia64 files.
      Signed-off-by: NJes Sorensen <jes@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      256a7e09
    • A
      [IA64] prevent MCA when performing MMIO mmap to PCI config space · 012b7105
      Alex Chiang 提交于
      Example memory map (HP rx7640 with 'default' acpiconfig setting, VGA disabled):
         0x00000000 - 0x3FFFBFFF  supports only WB (cacheable) access
      
      If a user attempts to perform an MMIO mmap (using the PCIIOC_MMAP_IS_MEM ioctl)
      to PCI config space (like mmap'ing and accessing memory at 0xA0000),
      we will MCA because the kernel will attempt to use a mapping with the UC
      attribute.
      
      So check the memory attribute in kern_mmap and the EFI memmap. If WC is
      requested, and WC or UC access is supported for the region, allow it.
      Otherwise, use the same attribute the kernel uses.
      
      Updates documentation and test cases as well.
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      012b7105
  4. 10 7月, 2007 4 次提交
  5. 27 6月, 2007 5 次提交
  6. 25 5月, 2007 2 次提交
  7. 24 5月, 2007 1 次提交
  8. 23 5月, 2007 3 次提交
  9. 19 5月, 2007 3 次提交
  10. 17 5月, 2007 1 次提交
  11. 16 5月, 2007 1 次提交
  12. 15 5月, 2007 3 次提交
  13. 12 5月, 2007 4 次提交
  14. 11 5月, 2007 3 次提交