1. 10 10月, 2010 7 次提交
  2. 09 10月, 2010 2 次提交
  3. 08 10月, 2010 18 次提交
  4. 07 10月, 2010 13 次提交
    • S
      ceph: update issue_seq on cap grant · d91f2438
      Sage Weil 提交于
      We need to update the issue_seq on any grant operation, be it via an MDS
      reply or a separate grant message.  The update in the grant path was
      missing.  This broke cap release for inodes in which the MDS sent an
      explicit grant message that was not soon after followed by a successful
      MDS reply on the same inode.
      
      Also fix the signedness on seq locals.
      Signed-off-by: NSage Weil <sage@newdream.net>
      d91f2438
    • G
      ceph: send cap release message early on failed revoke. · 21b559de
      Greg Farnum 提交于
      If an MDS tries to revoke caps that we don't have, we want to send
      releases early since they probably contain the caps message the MDS
      is looking for.
      
      Previously, we only sent the messages if we didn't have the inode either. But
      in a multi-mds system we can retain the inode after dropping all caps for
      a single MDS.
      Signed-off-by: NGreg Farnum <gregf@hq.newdream.net>
      Signed-off-by: NSage Weil <sage@newdream.net>
      21b559de
    • A
      ceph: Update max_len with minimum required size · bba0cd0e
      Aneesh Kumar K.V 提交于
      encode_fh on error should update max_len with minimum required
      size, so that caller can redo the call with the reallocated buffer.
      This is required with open by handle patch series
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NSage Weil <sage@newdream.net>
      bba0cd0e
    • A
      ceph: Fix return value of encode_fh function · 92923dcb
      Aneesh Kumar K.V 提交于
      encode_fh function should return 255 on error as done by other file
      system to indicate EOVERFLOW. Also max_len is in sizeof(u32) units
      and not in bytes.
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NSage Weil <sage@newdream.net>
      92923dcb
    • S
      ceph: avoid null deref in osd request error path · 6bc18876
      Sage Weil 提交于
      If we interrupt an osd request, we call __cancel_request, but it wasn't
      verifying that req->r_osd was non-NULL before dereferencing it.  This could
      cause a crash if osds were flapping and we aborted a request on said osd.
      Reported-by: NHenry C Chang <henry_c_chang@tcloudcomputing.com>
      Signed-off-by: NSage Weil <sage@newdream.net>
      6bc18876
    • H
      ceph: fix list_add usage on unsafe_writes list · 936aeb5c
      Henry C Chang 提交于
      Fix argument order.
      Signed-off-by: NHenry C Chang <henry_c_chang@tcloudcomputing.com>
      Signed-off-by: NSage Weil <sage@newdream.net>
      936aeb5c
    • 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