1. 06 10月, 2012 11 次提交
  2. 09 9月, 2009 1 次提交
    • E
      aoe: allocate unused request_queue for sysfs · 7135a71b
      Ed Cashin 提交于
      Andy Whitcroft reported an oops in aoe triggered by use of an
      incorrectly initialised request_queue object:
      
        [ 2645.959090] kobject '<NULL>' (ffff880059ca22c0): tried to add
      		an uninitialized object, something is seriously wrong.
        [ 2645.959104] Pid: 6, comm: events/0 Not tainted 2.6.31-5-generic #24-Ubuntu
        [ 2645.959107] Call Trace:
        [ 2645.959139] [<ffffffff8126ca2f>] kobject_add+0x5f/0x70
        [ 2645.959151] [<ffffffff8125b4ab>] blk_register_queue+0x8b/0xf0
        [ 2645.959155] [<ffffffff8126043f>] add_disk+0x8f/0x160
        [ 2645.959161] [<ffffffffa01673c4>] aoeblk_gdalloc+0x164/0x1c0 [aoe]
      
      The request queue of an aoe device is not used but can be allocated in
      code that does not sleep.
      
      Bruno bisected this regression down to
      
        cd43e26f
      
        block: Expose stacked device queues in sysfs
      
      "This seems to generate /sys/block/$device/queue and its contents for
       everyone who is using queues, not just for those queues that have a
       non-NULL queue->request_fn."
      
      Addresses http://bugs.launchpad.net/bugs/410198
      Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13942
      
      Note that embedding a queue inside another object has always been
      an illegal construct, since the queues are reference counted and
      must persist until the last reference is dropped. So aoe was
      always buggy in this respect (Jens).
      Signed-off-by: NEd Cashin <ecashin@coraid.com>
      Cc: Andy Whitcroft <apw@canonical.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Bruno Premont <bonbons@linux-vserver.org>
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      7135a71b
  3. 19 2月, 2009 1 次提交
  4. 25 11月, 2008 1 次提交
  5. 22 9月, 2008 1 次提交
  6. 29 4月, 2008 1 次提交
  7. 09 2月, 2008 6 次提交
    • E
      aoe: update copyright date · 52e112b3
      Ed L. Cashin 提交于
      Update the year in the copyright notices.
      Signed-off-by: NEd L. Cashin <ecashin@coraid.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      52e112b3
    • E
      aoe: dynamically allocate a capped number of skbs when necessary · 9bb237b6
      Ed L. Cashin 提交于
      What this Patch Does
      
        Even before this recent series of 12 patches to 2.6.22-rc4, the aoe
        driver was reusing a small set of skbs that were allocated once and
        were only used for outbound AoE commands.
      
        The network layer cannot be allowed to put_page on the data that is
        still associated with a bio we haven't returned to the block layer,
        so the aoe driver (even before the patch under discussion) is still
        the owner of skbs that have been handed to the network layer for
        transmission.  We need to keep track of these skbs so that we can
        free them, but by tracking them, we can also easily re-use them.
      
        The new patch was a response to the behavior of certain network
        drivers.  We cannot reuse an skb that the network driver still has
        in its transmit ring.  Network drivers can defer transmit ring
        cleanup and then use the state in the skb to determine how many data
        segments to clean up in its transmit ring.  The tg3 driver is one
        driver that behaves in this way.
      
        When the network driver defers cleanup of its transmit ring, the aoe
        driver can find itself in a situation where it would like to send an
        AoE command, and the AoE target is ready for more work, but the
        network driver still has all of the pre-allocated skbs.  In that
        case, the new patch just calls alloc_skb, as you'd expect.
      
        We don't want to get carried away, though.  We try not to do
        excessive allocation in the write path, so we cap the number of skbs
        we dynamically allocate.
      
        Probably calling it a "dynamic pool" is misleading.  We were already
        trying to use a small fixed-size set of pre-allocated skbs before
        this patch, and this patch just provides a little headroom (with a
        ceiling, though) to accomodate network drivers that hang onto skbs,
        by allocating when needed.  The d->skbpool_hd list of allocated skbs
        is necessary so that we can free them later.
      
        We didn't notice the need for this headroom until AoE targets got
        fast enough.
      
      Alternatives
      
        If the network layer never did a put_page on the pages in the bio's
        we get from the block layer, then it would be possible for us to
        hand skbs to the network layer and forget about them, allowing the
        network layer to free skbs itself (and thereby calling our own
        skb->destructor callback function if we needed that).  In that case
        we could get rid of the pre-allocated skbs and also the
        d->skbpool_hd, instead just calling alloc_skb every time we wanted
        to transmit a packet.  The slab allocator would effectively maintain
        the list of skbs.
      
        Besides a loss of CPU cache locality, the main concern with that
        approach the danger that it would increase the likelihood of
        deadlock when VM is trying to free pages by writing dirty data from
        the page cache through the aoe driver out to persistent storage on
        an AoE device.  Right now we have a situation where we have
        pre-allocation that corresponds to how much we use, which seems
        ideal.
      
        Of course, there's still the separate issue of receiving the packets
        that tell us that a write has successfully completed on the AoE
        target.  When memory is low and VM is using AoE to flush dirty data
        to free up pages, it would be perfect if there were a way for us to
        register a fast callback that could recognize write command
        completion responses.  But I don't think the current problems with
        the receive side of the situation are a justification for
        exacerbating the problem on the transmit side.
      Signed-off-by: NEd L. Cashin <ecashin@coraid.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9bb237b6
    • E
      aoe: user can ask driver to forget previously detected devices · 262bf541
      Ed L. Cashin 提交于
      When an AoE device is detected, the kernel is informed, and a new block device
      is created.  If the device is unused, the block device corresponding to remote
      device that is no longer available may be removed from the system by telling
      the aoe driver to "flush" its list of devices.
      
      Without this patch, software like GPFS and LVM may attempt to read from AoE
      devices that were discovered earlier but are no longer present, blocking until
      the I/O attempt times out.
      Signed-off-by: NEd L. Cashin <ecashin@coraid.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      262bf541
    • E
      aoe: mac_addr: avoid 64-bit arch compiler warnings · 1eb0da4c
      Ed L. Cashin 提交于
      By returning unsigned long long, mac_addr does not generate compiler warnings
      on 64-bit architectures.
      Signed-off-by: NEd L. Cashin <ecashin@coraid.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1eb0da4c
    • E
      aoe: handle multiple network paths to AoE device · 68e0d42f
      Ed L. Cashin 提交于
      A remote AoE device is something can process ATA commands and is identified by
      an AoE shelf number and an AoE slot number.  Such a device might have more
      than one network interface, and it might be reachable by more than one local
      network interface.  This patch tracks the available network paths available to
      each AoE device, allowing them to be used more efficiently.
      
      Andrew Morton asked about the call to msleep_interruptible in the revalidate
      function.  Yes, if a signal is pending, then msleep_interruptible will not
      return 0.  That means we will not loop but will call aoenet_xmit with a NULL
      skb, which is a noop.  If the system is too low on memory or the aoe driver is
      too low on frames, then the user can hit control-C to interrupt the attempt to
      do a revalidate.  I have added a comment to the code summarizing that.
      
      Andrew Morton asked whether the allocation performed inside addtgt could use a
      more relaxed allocation like GFP_KERNEL, but addtgt is called when the aoedev
      lock has been locked with spin_lock_irqsave.  It would be nice to allocate the
      memory under fewer restrictions, but targets are only added when the device is
      being discovered, and if the target can't be added right now, we can try again
      in a minute when then next AoE config query broadcast goes out.
      
      Andrew Morton pointed out that the "too many targets" message could be printed
      for failing GFP_ATOMIC allocations.  The last patch in this series makes the
      messages more specific.
      Signed-off-by: NEd L. Cashin <ecashin@coraid.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      68e0d42f
    • E
      aoe: bring driver version number to 47 · 8911ef4d
      Ed L. Cashin 提交于
      Signed-off-by: NEd L. Cashin <ecashin@coraid.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8911ef4d
  8. 17 10月, 2007 1 次提交
  9. 24 7月, 2007 1 次提交
  10. 26 4月, 2007 2 次提交
  11. 22 11月, 2006 1 次提交
  12. 19 10月, 2006 8 次提交
  13. 24 3月, 2006 3 次提交
  14. 29 10月, 2005 1 次提交
  15. 10 9月, 2005 1 次提交