1. 07 Aug, 2009 3 commits
  2. 04 Aug, 2009 1 commit
  3. 31 Jul, 2009 1 commit
  4. 30 Jul, 2009 2 commits
    • Dave Hansen's avatar
      lib: flexible array implementation · 534acc05
      Dave Hansen authored
      Once a structure goes over PAGE_SIZE*2, we see occasional allocation
      failures.  Some people have chosen to switch over to things like vmalloc()
      that will let them keep array-like access to such a large structures.
      But, vmalloc() has plenty of downsides.
      Here's an alternative.  I think it's what Andrew was suggesting here:
      I call it a flexible array.  It does all of its work in PAGE_SIZE bits, so
      never does an order>0 allocation.  The base level has
      PAGE_SIZE-2*sizeof(int) bytes of storage for pointers to the second level.
       So, with a 32-bit arch, you get about 4MB (4183112 bytes) of total
      storage when the objects pack nicely into a page.  It is half that on
      64-bit because the pointers are twice the size.  There's a table detailing
      this in the code.
      There are kerneldocs for the functions, but here's an
      flex_array_alloc() - dynamically allocate a base structure
      flex_array_free() - free the array and all of the
      		    second-level pages
      flex_array_free_parts() - free the second-level pages, but
      			  not the base (for static bases)
      flex_array_put() - copy into the array at the given index
      flex_array_get() - copy out of the array at the given index
      flex_array_prealloc() - preallocate the second-level pages
      			between the given indexes to
      			guarantee no allocs will occur at
      			put() time.
      We could also potentially just pass the "element_size" into each of the
      API functions instead of storing it internally.  That would get us one
      more base pointer on 32-bit.
      I've been testing this by running it in userspace.  The header and patch
      that I've been using are here, as well as the little script I'm using to
      generate the size table which goes in the kerneldocs.
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: default avatarDave Hansen <dave@linux.vnet.ibm.com>
      Reviewed-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Roland Dreier's avatar
      lib: export generic atomic64_t functions · 3fc7b4b2
      Roland Dreier authored
      The generic atomic64_t implementation in lib/ did not export the functions
      it defined, which means that modules that use atomic64_t would not link on
      platforms (such as 32-bit powerpc).  For example, trying to build a kernel
      with CONFIG_NET_RDS on such a platform would fail with:
          ERROR: "atomic64_read" [net/rds/rds.ko] undefined!
          ERROR: "atomic64_set" [net/rds/rds.ko] undefined!
      Fix this by exporting the atomic64_t functions to modules.  (I export the
      entire API even if it's not all currently used by in-tree modules to avoid
      having to continue fixing this in dribs and drabs)
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      Acked-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  5. 28 Jul, 2009 1 commit
  6. 10 Jul, 2009 1 commit
    • Ingo Molnar's avatar
      dma-debug: Fix the overlap() function to be correct and readable · f39d1b97
      Ingo Molnar authored
      Linus noticed how unclean and buggy the overlap() function is:
       - It uses convoluted (and bug-causing) positive checks for
         range overlap - instead of using a more natural negative
       - Even the positive checks are buggy: a positive intersection
         check has four natural cases while we checked only for three,
         missing the (addr < start && addr2 == end) case for example.
       - The variables are mis-named, making it non-obvious how the
         check was done.
       - It needlessly uses u64 instead of unsigned long. Since these
         are kernel memory pointers and we explicitly exclude highmem
         ranges anyway we cannot ever overflow 32 bits, even if we
         could. (and on 64-bit it doesnt matter anyway)
      All in one, this function needs a total revamp. I used Linus's
      suggestions minus the paranoid checks (we cannot overflow really
      because if we get totally bad DMA ranges passed far more things
      break in the systems than just DMA debugging). I also fixed a
      few other small details i noticed.
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  7. 25 Jun, 2009 1 commit
  8. 23 Jun, 2009 1 commit
  9. 21 Jun, 2009 1 commit
  10. 19 Jun, 2009 1 commit
    • Arnd Bergmann's avatar
      lib/checksum.c: fix endianess bug · 32a9ff9c
      Arnd Bergmann authored
      The new generic checksum code has a small dependency on endianess and
      worked only on big-endian systems. I could not find a nice efficient
      way to express this, so I added an #ifdef. Using
      'result += le16_to_cpu(*buff);' would have worked as well, but
      would be slightly less efficient on big-endian systems and IMHO
      would not be clearer.
      Also fix a bug that prevents this from working on 64-bit machines.
      If you have a 64-bit CPU and want to use the generic checksum
      code, you should probably do some more optimizations anyway, but
      at least the code should not break.
      Reported-by: default avatarMike Frysinger <vapier@gentoo.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
  11. 18 Jun, 2009 1 commit
    • Florian Fainelli's avatar
      lib: add lib/gcd.c · d2829224
      Florian Fainelli authored
      This patch adds lib/gcd.c which contains a greatest common divider
      implementation taken from sound/core/pcm_timer.c
      Several usages of this new library function will be sent to subsystem
      [akpm@linux-foundation.org: use swap() (pointed out by Joe)]
      [akpm@linux-foundation.org: just add gcd.o to obj-y, remove Kconfig changes]
      Signed-off-by: default avatarFlorian Fainelli <florian@openwrt.org>
      Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Simon Horman <horms@verge.net.au>
      Cc: Julius Volz <juliusv@google.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Patrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  12. 17 Jun, 2009 9 commits
  13. 16 Jun, 2009 2 commits
  14. 15 Jun, 2009 5 commits
  15. 12 Jun, 2009 1 commit
    • Rusty Russell's avatar
      module: trim exception table on init free. · ad6561df
      Rusty Russell authored
      It's theoretically possible that there are exception table entries
      which point into the (freed) init text of modules.  These could cause
      future problems if other modules get loaded into that memory and cause
      an exception as we'd see the wrong fixup.  The only case I know of is
      kvm-intel.ko (when CONFIG_CC_OPTIMIZE_FOR_SIZE=n).
      Amerigo fixed this long-standing FIXME in the x86 version, but this
      patch is more general.
      This implements trim_init_extable(); most archs are simple since they
      use the standard lib/extable.c sort code.  Alpha and IA64 use relative
      addresses in their fixups, so thier trimming is a slight variation.
      Sparc32 is unique; it doesn't seem to define ARCH_HAS_SORT_EXTABLE,
      yet it defines its own sort_extable() which overrides the one in lib.
      It doesn't sort, so we have to mark deleted entries instead of
      actually trimming them.
      Inspired-by: default avatarAmerigo Wang <amwang@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Cc: linux-alpha@vger.kernel.org
      Cc: sparclinux@vger.kernel.org
      Cc: linux-ia64@vger.kernel.org
  16. 11 Jun, 2009 5 commits
  17. 09 Jun, 2009 1 commit
  18. 08 Jun, 2009 3 commits