1. 12 10月, 2010 1 次提交
    • Y
      x86, numa: For each node, register the memory blocks actually used · 73cf624d
      Yinghai Lu 提交于
      Russ reported SGI UV is broken recently. He said:
      
      | The SRAT table shows that memory range is spread over two nodes.
      |
      | SRAT: Node 0 PXM 0 100000000-800000000
      | SRAT: Node 1 PXM 1 800000000-1000000000
      | SRAT: Node 0 PXM 0 1000000000-1080000000
      |
      |Previously, the kernel early_node_map[] would show three entries
      |with the proper node.
      |
      |[    0.000000]     0: 0x00100000 -> 0x00800000
      |[    0.000000]     1: 0x00800000 -> 0x01000000
      |[    0.000000]     0: 0x01000000 -> 0x01080000
      |
      |The problem is recent community kernel early_node_map[] shows
      |only two entries with the node 0 entry overlapping the node 1
      |entry.
      |
      |    0: 0x00100000 -> 0x01080000
      |    1: 0x00800000 -> 0x01000000
      
      After looking at the changelog, Found out that it has been broken for a while by
      following commit
      
      |commit 8716273c
      |Author: David Rientjes <rientjes@google.com>
      |Date:   Fri Sep 25 15:20:04 2009 -0700
      |
      |    x86: Export srat physical topology
      
      Before that commit, register_active_regions() is called for every SRAT memory
      entry right away.
      
      Use nodememblk_range[] instead of nodes[] in order to make sure we
      capture the actual memory blocks registered with each node.  nodes[]
      contains an extended range which spans all memory regions associated
      with a node, but that does not mean that all the memory in between are
      included.
      Reported-by: NRuss Anderson <rja@sgi.com>
      Tested-by: NRuss Anderson <rja@sgi.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4CB27BDF.5000800@kernel.org>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Cc: <stable@kernel.org> 2.6.33 .34 .35 .36
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      73cf624d
  2. 11 10月, 2010 1 次提交
    • B
      x86, AMD, MCE thresholding: Fix the MCi_MISCj iteration order · 6dcbfe4f
      Borislav Petkov 提交于
      This fixes possible cases of not collecting valid error info in
      the MCE error thresholding groups on F10h hardware.
      
      The current code contains a subtle problem of checking only the
      Valid bit of MSR0000_0413 (which is MC4_MISC0 - DRAM
      thresholding group) in its first iteration and breaking out if
      the bit is cleared.
      
      But (!), this MSR contains an offset value, BlkPtr[31:24], which
      points to the remaining MSRs in this thresholding group which
      might contain valid information too. But if we bail out only
      after we checked the valid bit in the first MSR and not the
      block pointer too, we miss that other information.
      
      The thing is, MC4_MISC0[BlkPtr] is not predicated on
      MCi_STATUS[MiscV] or MC4_MISC0[Valid] and should be checked
      prior to iterating over the MCI_MISCj thresholding group,
      irrespective of the MC4_MISC0[Valid] setting.
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6dcbfe4f
  3. 08 10月, 2010 14 次提交
  4. 07 10月, 2010 15 次提交
    • A
      HWPOISON: Stop shrinking at right page count · 47f43e7e
      Andi Kleen 提交于
      When we call the slab shrinker to free a page we need to stop at
      page count one because the caller always holds a single reference, not zero.
      
      This avoids useless looping over slab shrinkers and freeing too much
      memory.
      Reviewed-by: NWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      47f43e7e
    • A
      HWPOISON: Report correct address granuality for AO huge page errors · 0d9ee6a2
      Andi Kleen 提交于
      The SIGBUS user space signalling is supposed to report the
      address granuality of a corruption. Pass this information correctly
      for huge pages by querying the hpage order.
      Reviewed-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Reviewed-by: NWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      0d9ee6a2
    • A
      HWPOISON: Copy si_addr_lsb to user · a337fdac
      Andi Kleen 提交于
      The original hwpoison code added a new siginfo field si_addr_lsb to
      pass the granuality of the fault address to user space. Unfortunately
      this field was never copied to user space. Fix this here.
      
      I added explicit checks for the MCEERR codes to avoid having
      to patch all potential callers to initialize the field.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      a337fdac
    • N
      page-types.c: fix name of unpoison interface · 67159813
      Naoya Horiguchi 提交于
      The page-types utility still uses an out of date name for the
      unpoison interface: debugfs:hwpoison/renew-pfn
      This patch renames and fixes it.
      Signed-off-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Acked-by: NWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      67159813
    • J
      elevator: fix oops on early call to elevator_change() · 430c62fb
      Jens Axboe 提交于
      2.6.36 introduces an API for drivers to switch the IO scheduler
      instead of manually calling the elevator exit and init functions.
      This API was added since q->elevator must be cleared in between
      those two calls. And since we already have this functionality
      directly from use by the sysfs interface to switch schedulers
      online, it was prudent to reuse it internally too.
      
      But this API needs the queue to be in a fully initialized state
      before it is called, or it will attempt to unregister elevator
      kobjects before they have been added. This results in an oops
      like this:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000051
      IP: [<ffffffff8116f15e>] sysfs_create_dir+0x2e/0xc0
      PGD 47ddfc067 PUD 47c6a1067 PMD 0
      Oops: 0000 [#1] PREEMPT SMP
      last sysfs file: /sys/devices/pci0000:00/0000:00:02.0/0000:04:00.1/irq
      CPU 2
      Modules linked in: t(+) loop hid_apple usbhid ahci ehci_hcd uhci_hcd libahci usbcore nls_base igb
      
      Pid: 7319, comm: modprobe Not tainted 2.6.36-rc6+ #132 QSSC-S4R/QSSC-S4R
      RIP: 0010:[<ffffffff8116f15e>]  [<ffffffff8116f15e>] sysfs_create_dir+0x2e/0xc0
      RSP: 0018:ffff88027da25d08  EFLAGS: 00010246
      RAX: ffff88047c68c528 RBX: 00000000fffffffe RCX: 0000000000000000
      RDX: 000000000000002f RSI: 000000000000002f RDI: ffff88047e196c88
      RBP: ffff88027da25d38 R08: 0000000000000000 R09: d84156c5635688c0
      R10: d84156c5635688c0 R11: 0000000000000000 R12: ffff88047e196c88
      R13: 0000000000000000 R14: 0000000000000000 R15: ffff88047c68c528
      FS:  00007fcb0b26f6e0(0000) GS:ffff880287400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000051 CR3: 000000047e76e000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process modprobe (pid: 7319, threadinfo ffff88027da24000, task ffff88027d377090)
      Stack:
       ffff88027da25d58 ffff88047c68c528 00000000fffffffe ffff88047e196c88
      <0> ffff88047c68c528 ffff88047e05bd90 ffff88027da25d78 ffffffff8123fb77
      <0> ffff88047e05bd90 0000000000000000 ffff88047e196c88 ffff88047c68c528
      Call Trace:
       [<ffffffff8123fb77>] kobject_add_internal+0xe7/0x1f0
       [<ffffffff8123fd98>] kobject_add_varg+0x38/0x60
       [<ffffffff8123feb9>] kobject_add+0x69/0x90
       [<ffffffff8116efe0>] ? sysfs_remove_dir+0x20/0xa0
       [<ffffffff8103d48d>] ? sub_preempt_count+0x9d/0xe0
       [<ffffffff8143de20>] ? _raw_spin_unlock+0x30/0x50
       [<ffffffff8116efe0>] ? sysfs_remove_dir+0x20/0xa0
       [<ffffffff8116eff4>] ? sysfs_remove_dir+0x34/0xa0
       [<ffffffff81224204>] elv_register_queue+0x34/0xa0
       [<ffffffff81224aad>] elevator_change+0xfd/0x250
       [<ffffffffa007e000>] ? t_init+0x0/0x361 [t]
       [<ffffffffa007e000>] ? t_init+0x0/0x361 [t]
       [<ffffffffa007e0a8>] t_init+0xa8/0x361 [t]
       [<ffffffff810001de>] do_one_initcall+0x3e/0x170
       [<ffffffff8108c3fd>] sys_init_module+0xbd/0x220
       [<ffffffff81002f2b>] system_call_fastpath+0x16/0x1b
      Code: e5 41 56 41 55 41 54 49 89 fc 53 48 83 ec 10 48 85 ff 74 52 48 8b 47 18 49 c7 c5 00 46 61 81 48 85 c0 74 04 4c 8b 68 30 45 31 f6 <41> 80 7d 51 00 74 0e 49 8b 44 24 28 4c 89 e7 ff 50 20 49 89 c6
      RIP  [<ffffffff8116f15e>] sysfs_create_dir+0x2e/0xc0
       RSP <ffff88027da25d08>
      CR2: 0000000000000051
      ---[ end trace a6541d3bf07945df ]---
      
      Fix this by adding a registered bit to the elevator queue, which is
      set when the sysfs kobjects have been registered.
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      430c62fb
    • D
      drm: don't drop handle reference on unload · dab8dcfa
      Dave Airlie 提交于
      since the handle references are all tied to a file_priv, and when it disappears
      all the handle refs go with it.
      
      The fbcon ones we'd only notice on unload, but the nouveau notifier one
      would would happen on reboot.
      
      nouveau: Reported-by: Marc Dionne <marc.c.dionne@gmail.com>
      nouveau: Tested-by: Marc Dionne <marc.c.dionne@gmail.com>
      i915 unload: Reported-by: Keith Packard <keithp@keithp.com>
      Acked-by: NBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      dab8dcfa
    • J
      xfs: properly account for reclaimed inodes · 081003ff
      Johannes Weiner 提交于
      When marking an inode reclaimable, a per-AG counter is increased, the
      inode is tagged reclaimable in its per-AG tree, and, when this is the
      first reclaimable inode in the AG, the AG entry in the per-mount tree
      is also tagged.
      
      When an inode is finally reclaimed, however, it is only deleted from
      the per-AG tree.  Neither the counter is decreased, nor is the parent
      tree's AG entry untagged properly.
      
      Since the tags in the per-mount tree are not cleared, the inode
      shrinker iterates over all AGs that have had reclaimable inodes at one
      point in time.
      
      The counters on the other hand signal an increasing amount of slab
      objects to reclaim.  Since "70e60ce7 xfs: convert inode shrinker to
      per-filesystem context" this is not a real issue anymore because the
      shrinker bails out after one iteration.
      
      But the problem was observable on a machine running v2.6.34, where the
      reclaimable work increased and each process going into direct reclaim
      eventually got stuck on the xfs inode shrinking path, trying to scan
      several million objects.
      
      Fix this by properly unwinding the reclaimable-state tracking of an
      inode when it is reclaimed.
      Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
      Cc: stable@kernel.org
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NAlex Elder <aelder@sgi.com>
      081003ff
    • V
      md: check return code of read_sb_page · 5c04f551
      Vasiliy Kulikov 提交于
      Function read_sb_page may return ERR_PTR(...). Check for it.
      Signed-off-by: NVasiliy Kulikov <segooon@gmail.com>
      Cc: Neil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      5c04f551
    • N
      md/raid1: minor bio initialisation improvements. · db8d9d35
      NeilBrown 提交于
      
      When performing a resync we pre-allocate some bios and repeatedly use
      them.  This requires us to re-initialise them each time.
      One field (bi_comp_cpu) and some flags weren't being initiaised
      reliably.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      db8d9d35
    • N
      md/raid1: avoid overflow in raid1 resync when bitmap is in use. · 7571ae88
      NeilBrown 提交于
      bitmap_start_sync returns - via a pass-by-reference variable - the
      number of sectors before we need to check with the bitmap again.
      Since commit ef425673 this number can be substantially larger,
      2^27 is a common value.
      
      Unfortunately it is an 'int' and so when raid1.c:sync_request shifts
      it 9 places to the left it becomes 0.  This results in a zero-length
      read which the scsi layer justifiably complains about.
      
      This patch just removes the shift so the common case becomes safe with
      a trivially-correct patch.
      
      In the next merge window we will convert this 'int' to a 'sector_t'
      Reported-by: N"George Spelvin" <linux@horizon.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      7571ae88
    • L
      Linux 2.6.36-rc7 · cb655d0f
      Linus Torvalds 提交于
      cb655d0f
    • L
      Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/upstream-linus · 81c20b96
      Linus Torvalds 提交于
      * 'upstream' of git://git.linux-mips.org/pub/scm/upstream-linus:
        MIPS: Octeon: Place cnmips_cu2_setup in __init memory.
        MIPS: Don't place cu2 notifiers in __cpuinitdata
        MIPS: Calculate VMLINUZ_LOAD_ADDRESS based on the length of vmlinux.bin
        MIPS: Alchemy: Resolve prom section mismatches
        MIPS: Fix syscall 64 bit number comments.
        MIPS: Hookup fanotify_init, fanotify_mark, and prlimit64 syscalls.
        MIPS: TX49xx: Rename ARCH_KMALLOC_MINALIGN to ARCH_DMA_MINALIGN
        MIPS: N32: Fix getdents64 syscall for n32
        MIPS: Remove pr_<level> uses of KERN_<level>
        MIPS: PNX8550: Sort out machine halt, restart and powerdown functions.
        MIPS: GIC: Remove dependencies from Malta files.
        MIPS: Kconfig: Fix and clarify kconfig help text for VSMP and SMTC.
        MIPS: DMA: Fix computation of DMA flags from device's coherent_dma_mask.
        MIPS: Audit: Fix hang in entry.S.
        MIPS: Document why RELOC_HIDE is there.
        MIPS: Octeon: Determine if helper needs to be built
        MIPS: Use generic atomic64 for 32-bit kernels
        MIPS: RM7000: Symbol should be static
        MIPS: kspd: Adjust confusing if indentation
        MIPS: Fix a typo.
      81c20b96
    • L
      Merge branch 'for-linus' of git://git.kernel.dk/linux-2.6-block · 089eed29
      Linus Torvalds 提交于
      * 'for-linus' of git://git.kernel.dk/linux-2.6-block:
        writeback: always use sb->s_bdi for writeback purposes
      089eed29
    • L
      Merge branch 'v2.6.36-rc6-urgent-fixes' of git://xenbits.xen.org/people/sstabellini/linux-pvhvm · 34984f54
      Linus Torvalds 提交于
      * 'v2.6.36-rc6-urgent-fixes' of git://xenbits.xen.org/people/sstabellini/linux-pvhvm:
        xen: do not initialize PV timers on HVM if !xen_have_vector_callback
        xen: do not set xenstored_ready before xenbus_probe on hvm
      34984f54
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse · 8fe9793a
      Linus Torvalds 提交于
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse:
        fuse: Initialize total_len in fuse_retrieve()
      8fe9793a
  5. 06 10月, 2010 6 次提交
  6. 05 10月, 2010 3 次提交
    • S
      xen: do not initialize PV timers on HVM if !xen_have_vector_callback · 31e7e931
      Stefano Stabellini 提交于
      if !xen_have_vector_callback do not initialize PV timer unconditionally
      because we still don't know how many cpus are available and if there is
      more than one we won't be able to receive the timer interrupts on
      cpu > 0.
      
      This patch fixes an hang at boot when Xen does not support vector
      callbacks and the guest has multiple vcpus.
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Acked-by: NJeremy Fitzhardinge <jeremy@goop.org>
      31e7e931
    • S
      xen: do not set xenstored_ready before xenbus_probe on hvm · a947f0f8
      Stefano Stabellini 提交于
      Register_xenstore_notifier should guarantee that the caller gets
      notified even if xenstore is already up.
      Therefore we revert "do not notify callers from
      register_xenstore_notifier" and set xenstored_read at the right time for
      PV on HVM guests too.
      In fact in case of PV on HVM guests xenstored is ready only after the
      platform pci driver has completed the initialization, so do not set
      xenstored_ready before the call to xenbus_probe().
      
      This patch fixes a shutdown_event watcher registration bug that causes
      "xm shutdown" not to work properly.
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Acked-by: NJeremy Fitzhardinge <jeremy@goop.org>
      a947f0f8
    • D
      Input: wacom - fix runtime PM related deadlock · f6cd3783
      Dmitry Torokhov 提交于
      When runtime PM is enabled by default for input devices, X hangs in
      wacom open:
      [<ffffffff814a00ea>] mutex_lock+0x1a/0x40
      [<ffffffffa02bc94b>] wacom_resume+0x3b/0x90 [wacom]
      [<ffffffff81327a32>] usb_resume_interface+0xd2/0x190
      [<ffffffff81327b5d>] usb_resume_both+0x6d/0x110
      [<ffffffff81327c24>] usb_runtime_resume+0x24/0x40
      [<ffffffff8130a2cf>] __pm_runtime_resume+0x26f/0x450
      [<ffffffff8130a23a>] __pm_runtime_resume+0x1da/0x450
      [<ffffffff8130a53a>] pm_runtime_resume+0x2a/0x50
      [<ffffffff81328176>] usb_autopm_get_interface+0x26/0x60
      [<ffffffffa02bc626>] wacom_open+0x36/0x90 [wacom]
      
      wacom_open() takes wacom->lock and calls usb_autopm_get_interface(),
      which in turn calls wacom_resume() which tries to acquire the lock
      again.
      
      The fix is to call usb_autopm_get_interface() first, before we take
      the lock.
      
      Since we do not do usb_autopm_put_interface() until wacom_close()
      is called runtime PM is effectively disabled for the driver, however
      changing it now would risk regressions so the complete fix will
      have to wait till the next merge window.
      Reported-by: NJiri Slaby <jslaby@suse.cz>
      Acked-by: NOliver Neukum <oneukum@suse.de>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      f6cd3783