1. 12 9月, 2013 2 次提交
  2. 04 7月, 2013 2 次提交
  3. 18 12月, 2012 10 次提交
  4. 06 10月, 2012 9 次提交
  5. 28 10月, 2010 1 次提交
  6. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  7. 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
  8. 04 3月, 2009 1 次提交
  9. 09 10月, 2008 1 次提交
  10. 22 9月, 2008 1 次提交
  11. 29 4月, 2008 1 次提交
  12. 09 2月, 2008 5 次提交
    • A
      aoe: statically initialise devlist_lock · 476aed38
      Andrew Morton 提交于
      I guess aoedev_init() can go away now.
      
      Cc: Greg KH <greg@kroah.com>
      Cc: "Ed L. Cashin" <ecashin@coraid.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      476aed38
    • 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: 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
  13. 10 10月, 2007 1 次提交
  14. 22 11月, 2006 1 次提交
  15. 19 10月, 2006 3 次提交