Skip to content
  1. Aug 05, 2009
  2. Aug 04, 2009
    • Subrata Modak's avatar
      x86: Work around compilation warning in arch/x86/kernel/apm_32.c · dc731fbb
      Subrata Modak authored
      The following fix was initially inspired by David Howells fix
      few days back:
      
        http://lkml.org/lkml/2009/7/9/109
      
      However, Ingo disapproves such fixes as it's dangerous (it can
      hide future, relevant warnings) - in something as
      performance-uncritical.
      
      So, initialize 'err' to '0' to work around a GCC false positive
      warning:
      
        http://lkml.org/lkml/2009/7/18/89
      
      
      
      Signed-off-by: default avatarSubrata <Modak&lt;subrata@linux.vnet.ibm.com>
      Cc: Sachin P Sant <sachinp@linux.vnet.ibm.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      LKML-Reference: <20090721023226.31855.67236.sendpatchset@subratamodak.linux.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      dc731fbb
    • Jack Steiner's avatar
      x86, UV: Complete IRQ interrupt migration in arch_enable_uv_irq() · 2a5ef416
      Jack Steiner authored
      
      
      In uv_setup_irq(), the call to create_irq() initially assigns
      IRQ vectors to cpu 0. The subsequent call to
      assign_irq_vector() in arch_enable_uv_irq() migrates the IRQ to
      another cpu and frees the cpu 0 vector - at least it will be
      freed as soon as the "IRQ move" completes.
      
      arch_enable_uv_irq() needs to send a cleanup IPI to complete
      the IRQ move. Otherwise, assignment of GRU interrupts on large
      systems (>200 cpus) will exhaust the cpu 0 interrupt vectors
      and initialization of the GRU driver will fail.
      
      Signed-off-by: default avatarJack Steiner <steiner@sgi.com>
      LKML-Reference: <20090720142840.GA8885@sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      2a5ef416
    • Jan Beulich's avatar
      x86, 32-bit: Fix double accounting in reserve_top_address() · 6abf6551
      Jan Beulich authored
      
      
      With VMALLOC_END included in the calculation of MAXMEM (as of
      2.6.28) it is no longer correct to also bump __VMALLOC_RESERVE
      in reserve_top_address(). Doing so results in needlessly small
      lowmem.
      
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      LKML-Reference: <4A71DD2A020000780000D482@vpn.id2.novell.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      6abf6551
    • Yinghai Lu's avatar
      x86: Don't use current_cpu_data in x2apic phys_pkg_id · d8c7eb34
      Yinghai Lu authored
      
      
      One system has socket 1 come up as BSP.
      
      kexeced kernel reports BSP as:
      
      [    1.524550] Initializing cgroup subsys cpuacct
      [    1.536064] initial_apicid:20
      [    1.537135] ht_mask_width:1
      [    1.538128] core_select_mask:f
      [    1.539126] core_plus_mask_width:5
      [    1.558479] CPU: Physical Processor ID: 0
      [    1.559501] CPU: Processor Core ID: 0
      [    1.560539] CPU: L1 I cache: 32K, L1 D cache: 32K
      [    1.579098] CPU: L2 cache: 256K
      [    1.580085] CPU: L3 cache: 24576K
      [    1.581108] CPU 0/0x20 -> Node 0
      [    1.596193] CPU 0 microcode level: 0xffff0008
      
      It doesn't have correct physical processor id and will get an
      error:
      
      [   38.840859] CPU0 attaching sched-domain:
      [   38.848287]  domain 0: span 0,8,72 level SIBLING
      [   38.851151]   groups: 0 8 72
      [   38.858137]   domain 1: span 0,8-15,72-79 level MC
      [   38.868944]    groups: 0,8,72 9,73 10,74 11,75 12,76 13,77 14,78 15,79
      [   38.881383] ERROR: parent span is not a superset of domain->span
      [   38.890724]    domain 2: span 0-7,64-71 level CPU
      [   38.899237] ERROR: domain->groups does not contain CPU0
      [   38.909229]     groups: 8-15,72-79
      [   38.912547] ERROR: groups don't span domain->span
      [   38.919665]     domain 3: span 0-127 level NODE
      [   38.930739]      groups: 0-7,64-71 8-15,72-79 16-23,80-87 24-31,88-95 32-39,96-103 40-47,104-111 48-55,112-119 56-63,120-127
      
      it turns out: we can not use current_cpu_data in phys_pgd_id
      for x2apic.
      
      identify_boot_cpu() is called by check_bugs() before
      smp_prepare_cpus() and till smp_prepare_cpus() current_cpu_data
      for bsp is assigned with boot_cpu_data.
      
      Just make phys_pkg_id for x2apic is aligned to xapic.
      
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Acked-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <4A6ADD0D.10002@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d8c7eb34
    • Jack Steiner's avatar
      x86, UV: Fix UV apic mode · c5997fa8
      Jack Steiner authored
      
      
      Change SGI UV default apicid mode to "physical". This is
      required to match settings in the UV hub chip.
      
      Signed-off-by: default avatarJack Steiner <steiner@sgi.com>
      LKML-Reference: <20090727143856.GA8905@sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      c5997fa8
    • Jack Steiner's avatar
      x86, UV: Fix macros for accessing large node numbers · 67e83f30
      Jack Steiner authored
      
      
      The UV chipset automatically supplies the upper bits on nodes
      being referenced by MMR accesses. These bit can be deleted from
      the hub addressing macros.
      
      Signed-off-by: default avatarJack Steiner <steiner@sgi.com>
      LKML-Reference: <20090727143808.GA8076@sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      67e83f30
    • Jack Steiner's avatar
      x86, UV: Delete mapping of MMR rangs mapped by BIOS · cc5e4fa1
      Jack Steiner authored
      
      
      The UV BIOS has added additional MMR ranges that are mapped via
      EFI virtual mode mappings. These ranges should be deleted from
      ranges mapped by uv_system_init().
      
      Signed-off-by: default avatarJack Steiner <steiner@sgi.com>
      Cc: linux-mm@kvack.org
      LKML-Reference: <20090727143656.GA7698@sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      cc5e4fa1
    • Jack Steiner's avatar
      x86, UV: Handle missing blade-local memory correctly · 6c7184b7
      Jack Steiner authored
      
      
      UV blades may not have any blade-local memory. Add a field
      (nid) to the UV blade structure to indicates whether the node
      has local memory. This is needed by the GRU driver (pushed
      separately).
      
      Signed-off-by: default avatarJack Steiner <steiner@sgi.com>
      Cc: linux-mm@kvack.org
      LKML-Reference: <20090727143507.GA7006@sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      6c7184b7
    • Ingo Molnar's avatar
      Merge branch 'tracing/fixes' of... · e16852cf
      Ingo Molnar authored
      Merge branch 'tracing/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing into tracing/urgent
      e16852cf
    • Hiroshi Shimamoto's avatar
      posix-timers: Fix oops in clock_nanosleep() with CLOCK_MONOTONIC_RAW · 70d715fd
      Hiroshi Shimamoto authored
      
      
      Prevent calling do_nanosleep() with clockid
      CLOCK_MONOTONIC_RAW, it may cause oops, such as NULL pointer
      dereference.
      
      Signed-off-by: default avatarHiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: John Stultz <johnstul@us.ibm.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <4A764FF3.50607@ct.jp.nec.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      70d715fd
    • Steve French's avatar
      d098564f
    • H. Peter Anvin's avatar
      x86: fix assembly constraints in native_save_fl() · f1f029c7
      H. Peter Anvin authored
      
      
      From Gabe Black in bugzilla 13888:
      
      native_save_fl is implemented as follows:
      
        11static inline unsigned long native_save_fl(void)
        12{
        13        unsigned long flags;
        14
        15        asm volatile("# __raw_save_flags\n\t"
        16                     "pushf ; pop %0"
        17                     : "=g" (flags)
        18                     : /* no input */
        19                     : "memory");
        20
        21        return flags;
        22}
      
      If gcc chooses to put flags on the stack, for instance because this is
      inlined into a larger function with more register pressure, the offset
      of the flags variable from the stack pointer will change when the
      pushf is performed. gcc doesn't attempt to understand that fact, and
      address used for pop will still be the same. It will write to
      somewhere near flags on the stack but not actually into it and
      overwrite some other value.
      
      I saw this happen in the ide_device_add_all function when running in a
      simulator I work on. I'm assuming that some quirk of how the simulated
      hardware is set up caused the code path this is on to be executed when
      it normally wouldn't.
      
      A simple fix might be to change "=g" to "=r".
      
      Reported-by: default avatarGabe Black <spamforgabe@umich.edu>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Stable Team <stable@kernel.org>
      f1f029c7
    • Borislav Petkov's avatar
      x86, msr: execute on the correct CPU subset · bab9a3da
      Borislav Petkov authored
      
      
      Make rdmsr_on_cpus/wrmsr_on_cpus execute on the current CPU only if it
      is in the supplied bitmask.
      
      Signed-off-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      bab9a3da
    • H. Peter Anvin's avatar
      x86: Fix assert syntax in vmlinux.lds.S · d2ba8b21
      H. Peter Anvin authored
      
      
      Older versions of binutils did not accept the naked "ASSERT" syntax;
      it is considered an expression whose value needs to be assigned to
      something.
      
      Reported-tested-and-fixed-by: default avatarJean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      d2ba8b21
    • Roel Kluin's avatar
      cifs: Read buffer overflow · 24e2fb61
      Roel Kluin authored
      
      
      Check whether index is within bounds before testing the element.
      
      Acked-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarRoel Kluin <roel.kluin@gmail.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      24e2fb61
    • Jeff Layton's avatar
      cifs: show noforceuid/noforcegid mount options (try #2) · 4486d6ed
      Jeff Layton authored
      
      
      Since forceuid is the default, we now need to show when it's disabled.
      
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      4486d6ed
    • Paul Mackerras's avatar
      x86: Make 64-bit efi_ioremap use ioremap on MMIO regions · 6a7bbd57
      Paul Mackerras authored
      
      
      Booting current 64-bit x86 kernels on the latest Apple MacBook
      (MacBook5,2) via EFI gives the following warning:
      
      [    0.182209] ------------[ cut here ]------------
      [    0.182222] WARNING: at arch/x86/mm/pageattr.c:581 __cpa_process_fault+0x44/0xa0()
      [    0.182227] Hardware name: MacBook5,2
      [    0.182231] CPA: called for zero pte. vaddr = ffff8800ffe00000 cpa->vaddr = ffff8800ffe00000
      [    0.182236] Modules linked in:
      [    0.182242] Pid: 0, comm: swapper Not tainted 2.6.31-rc4 #6
      [    0.182246] Call Trace:
      [    0.182254]  [<ffffffff8102c754>] ? __cpa_process_fault+0x44/0xa0
      [    0.182261]  [<ffffffff81048668>] warn_slowpath_common+0x78/0xd0
      [    0.182266]  [<ffffffff81048744>] warn_slowpath_fmt+0x64/0x70
      [    0.182272]  [<ffffffff8102c7ec>] ? update_page_count+0x3c/0x50
      [    0.182280]  [<ffffffff818d25c5>] ? phys_pmd_init+0x140/0x22e
      [    0.182286]  [<ffffffff8102c754>] __cpa_process_fault+0x44/0xa0
      [    0.182292]  [<ffffffff8102ce60>] __change_page_attr_set_clr+0x5f0/0xb40
      [    0.182301]  [<ffffffff810d1035>] ? vm_unmap_aliases+0x175/0x190
      [    0.182307]  [<ffffffff8102d4ae>] change_page_attr_set_clr+0xfe/0x3d0
      [    0.182314]  [<ffffffff8102dcca>] _set_memory_uc+0x2a/0x30
      [    0.182319]  [<ffffffff8102dd4b>] set_memory_uc+0x7b/0xb0
      [    0.182327]  [<ffffffff818afe31>] efi_enter_virtual_mode+0x2ad/0x2c9
      [    0.182334]  [<ffffffff818a1c66>] start_kernel+0x2db/0x3f4
      [    0.182340]  [<ffffffff818a1289>] x86_64_start_reservations+0x99/0xb9
      [    0.182345]  [<ffffffff818a1389>] x86_64_start_kernel+0xe0/0xf2
      [    0.182357] ---[ end trace 4eaa2a86a8e2da22 ]---
      [    0.182982] init_memory_mapping: 00000000ffffc000-0000000100000000
      [    0.182993]  00ffffc000 - 0100000000 page 4k
      
      This happens because the 64-bit version of efi_ioremap calls
      init_memory_mapping for all addresses, regardless of whether they are
      RAM or MMIO.  The EFI tables on this machine ask for runtime access to
      some MMIO regions:
      
      [    0.000000] EFI: mem195: type=11, attr=0x8000000000000000, range=[0x0000000093400000-0x0000000093401000) (0MB)
      [    0.000000] EFI: mem196: type=11, attr=0x8000000000000000, range=[0x00000000ffc00000-0x00000000ffc40000) (0MB)
      [    0.000000] EFI: mem197: type=11, attr=0x8000000000000000, range=[0x00000000ffc40000-0x00000000ffc80000) (0MB)
      [    0.000000] EFI: mem198: type=11, attr=0x8000000000000000, range=[0x00000000ffc80000-0x00000000ffca4000) (0MB)
      [    0.000000] EFI: mem199: type=11, attr=0x8000000000000000, range=[0x00000000ffca4000-0x00000000ffcb4000) (0MB)
      [    0.000000] EFI: mem200: type=11, attr=0x8000000000000000, range=[0x00000000ffcb4000-0x00000000ffffc000) (3MB)
      [    0.000000] EFI: mem201: type=11, attr=0x8000000000000000, range=[0x00000000ffffc000-0x0000000100000000) (0MB)
      
      This arranges to pass the EFI memory type through to efi_ioremap, and
      makes efi_ioremap use ioremap rather than init_memory_mapping if the
      type is EFI_MEMORY_MAPPED_IO.  With this, the above warning goes away.
      
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      LKML-Reference: <19062.55858.533494.471153@cargo.ozlabs.ibm.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      6a7bbd57
    • Paul Mackerras's avatar
      x86: Add quirk to make Apple MacBook5,2 use reboot=pci · 6c6c51e4
      Paul Mackerras authored
      
      
      The latest Apple MacBook (MacBook5,2) doesn't reboot successfully
      under Linux; neither the EFI reboot method nor the default method
      using the keyboard controller works (the system just hangs and doesn't
      reset).  However, the method using the "PCI reset register" at 0xcf9
      does work.
      
      This adds a quirk to detect this machine via DMI and force the
      reboot_type to BOOT_CF9.  With this it reboots successfully without
      requiring a command-line option.  Note that the EFI code forces
      reboot_type to BOOT_EFI when the machine is booted via EFI, but this
      overrides that since the core_initcall runs after the EFI
      initialization code.
      
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      LKML-Reference: <19062.56420.501516.316181@cargo.ozlabs.ibm.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      6c6c51e4
    • Thomas Hellstrom's avatar
      x86: Fix CPA memtype reserving in the set_pages_array*() cases · 8523acfe
      Thomas Hellstrom authored
      The code was incorrectly reserving memtypes using the page
      virtual address instead of the physical address. Furthermore,
      the code was not ignoring highmem pages as it ought to.
      
      ( upstream does not pass in highmem pages yet - but upcoming
        graphics code will do it and there's no reason to not handle
        this properly in the CPA APIs.)
      
      Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=13884
      
      
      
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Acked-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: <stable@kernel.org>
      Cc: dri-devel@lists.sourceforge.net
      Cc: venkatesh.pallipadi@intel.com
      LKML-Reference: <1249284345-7654-1-git-send-email-thellstrom@vmware.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      8523acfe
  3. Aug 03, 2009
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://neil.brown.name/md · a33a052f
      Linus Torvalds authored
      * 'for-linus' of git://neil.brown.name/md:
        md: Use revalidate_disk to effect changes in size of device.
        md: allow raid5_quiesce to work properly when reshape is happening.
        md/raid5: set reshape_position correctly when reshape starts.
        md: Handle growth of v1.x metadata correctly.
        md: avoid array overflow with bad v1.x metadata
        md: when a level change reduces the number of devices, remove the excess.
        md: Push down data integrity code to personalities.
        md/raid6: release spare page at ->stop()
      a33a052f
    • NeilBrown's avatar
      md: Use revalidate_disk to effect changes in size of device. · 449aad3e
      NeilBrown authored
      
      
      As revalidate_disk calls check_disk_size_change, it will cause
      any capacity change of a gendisk to be propagated to the blockdev
      inode.  So use that instead of mucking about with locks and
      i_size_write.
      
      Also add a call to revalidate_disk in do_md_run and a few other places
      where the gendisk capacity is changed.
      
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      449aad3e
    • NeilBrown's avatar
      md: allow raid5_quiesce to work properly when reshape is happening. · 64bd660b
      NeilBrown authored
      
      
      The ->quiesce method is not supposed to stop resync/recovery/reshape,
      just normal IO.
      But in raid5 we don't have a way to know which stripes are being
      used for normal IO and which for resync etc, so we need to wait for
      all stripes to be idle to be sure that all writes have completed.
      
      However reshape keeps at least some stripe busy for an extended period
      of time, so a call to raid5_quiesce can block for several seconds
      needlessly.
      So arrange for reshape etc to pause briefly while raid5_quiesce is
      trying to quiesce the array so that the active_stripes count can
      drop to zero.
      
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      64bd660b
    • NeilBrown's avatar
      md/raid5: set reshape_position correctly when reshape starts. · e516402c
      NeilBrown authored
      
      
      As the internal reshape_progress counter is the main driver
      for reshape, the fact that reshape_position sometimes starts with the
      wrong value has minimal effect.  It is visible in sysfs and that
      is all.
      
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      e516402c
    • NeilBrown's avatar
      md: Handle growth of v1.x metadata correctly. · 70471daf
      NeilBrown authored
      
      
      The v1.x metadata does not have a fixed size and can grow
      when devices are added.
      If it grows enough to require an extra sector of storage,
      we need to update the 'sb_size' to match.
      
      Without this, md can write out an incomplete superblock with a
      bad checksum, which will be rejected when trying to re-assemble
      the array.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      70471daf
    • NeilBrown's avatar
      md: avoid array overflow with bad v1.x metadata · 3673f305
      NeilBrown authored
      
      
      We trust the 'desc_nr' field in v1.x metadata enough to use it
      as an index in an array.  This isn't really safe.
      So range-check the value first.
      
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      3673f305
    • NeilBrown's avatar
      md: when a level change reduces the number of devices, remove the excess. · 3a981b03
      NeilBrown authored
      
      
      When an array is changed from RAID6 to RAID5, fewer drives are
      needed.  So any device that is made superfluous by the level
      conversion must be marked as not-active.
      For the RAID6->RAID5 conversion, this will be a drive which only
      has 'Q' blocks on it.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      3a981b03
    • Andre Noll's avatar
      md: Push down data integrity code to personalities. · ac5e7113
      Andre Noll authored
      
      
      This patch replaces md_integrity_check() by two new public functions:
      md_integrity_register() and md_integrity_add_rdev() which are both
      personality-independent.
      
      md_integrity_register() is called from the ->run and ->hot_remove
      methods of all personalities that support data integrity.  The
      function iterates over the component devices of the array and
      determines if all active devices are integrity capable and if their
      profiles match. If this is the case, the common profile is registered
      for the mddev via blk_integrity_register().
      
      The second new function, md_integrity_add_rdev() is called from the
      ->hot_add_disk methods, i.e. whenever a new device is being added
      to a raid array. If the new device does not support data integrity,
      or has a profile different from the one already registered, data
      integrity for the mddev is disabled.
      
      For raid0 and linear, only the call to md_integrity_register() from
      the ->run method is necessary.
      
      Signed-off-by: default avatarAndre Noll <maan@systemlinux.org>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      ac5e7113
    • Linus Torvalds's avatar