1. 29 Feb, 2012 1 commit
  2. 31 May, 2011 1 commit
    • Robert Richter's avatar
      oprofile, dcookies: Fix possible circular locking dependency · fe47ae7f
      Robert Richter authored
      The lockdep warning below detects a possible A->B/B->A locking
      dependency of mm->mmap_sem and dcookie_mutex. The order in
      sync_buffer() is mm->mmap_sem/dcookie_mutex, while in
      sys_lookup_dcookie() it is vice versa.
      Fixing it in sys_lookup_dcookie() by unlocking dcookie_mutex before
      oprofiled/4432 is trying to acquire lock:
       (&mm->mmap_sem){++++++}, at: [<ffffffff810b444b>] might_fault+0x53/0xa3
      but task is already holding lock:
       (dcookie_mutex){+.+.+.}, at: [<ffffffff81124d28>] sys_lookup_dcookie+0x45/0x149
      which lock already depends on the new lock.
      the existing dependency chain (in reverse order) is:
      -> #1 (dcookie_mutex){+.+.+.}:
             [<ffffffff8106557f>] lock_acquire+0xf8/0x11e
             [<ffffffff814634f0>] mutex_lock_nested+0x63/0x309
             [<ffffffff81124e5c>] get_dcookie+0x30/0x144
             [<ffffffffa0000fba>] sync_buffer+0x196/0x3ec [oprofile]
             [<ffffffffa0001226>] task_exit_notify+0x16/0x1a [oprofile]
             [<ffffffff81467b96>] notifier_call_chain+0x37/0x63
             [<ffffffff8105803d>] __blocking_notifier_call_chain+0x50/0x67
             [<ffffffff81058068>] blocking_notifier_call_chain+0x14/0x16
             [<ffffffff8105a718>] profile_task_exit+0x1a/0x1c
             [<ffffffff81039e8f>] do_exit+0x2a/0x6fc
             [<ffffffff8103a5e4>] do_group_exit+0x83/0xae
             [<ffffffff8103a626>] sys_exit_group+0x17/0x1b
             [<ffffffff8146ad4b>] system_call_fastpath+0x16/0x1b
      -> #0 (&mm->mmap_sem){++++++}:
             [<ffffffff81064dfb>] __lock_acquire+0x1085/0x1711
             [<ffffffff8106557f>] lock_acquire+0xf8/0x11e
             [<ffffffff810b4478>] might_fault+0x80/0xa3
             [<ffffffff81124de7>] sys_lookup_dcookie+0x104/0x149
             [<ffffffff8146ad4b>] system_call_fastpath+0x16/0x1b
      other info that might help us debug this:
      1 lock held by oprofiled/4432:
       #0:  (dcookie_mutex){+.+.+.}, at: [<ffffffff81124d28>] sys_lookup_dcookie+0x45/0x149
      stack backtrace:
      Pid: 4432, comm: oprofiled Not tainted 2.6.39-00008-ge5a450d #9
      Call Trace:
       [<ffffffff81063193>] print_circular_bug+0xae/0xbc
       [<ffffffff81064dfb>] __lock_acquire+0x1085/0x1711
       [<ffffffff8102ef13>] ? get_parent_ip+0x11/0x42
       [<ffffffff810b444b>] ? might_fault+0x53/0xa3
       [<ffffffff8106557f>] lock_acquire+0xf8/0x11e
       [<ffffffff810b444b>] ? might_fault+0x53/0xa3
       [<ffffffff810d7d54>] ? path_put+0x22/0x27
       [<ffffffff810b4478>] might_fault+0x80/0xa3
       [<ffffffff810b444b>] ? might_fault+0x53/0xa3
       [<ffffffff81124de7>] sys_lookup_dcookie+0x104/0x149
       [<ffffffff8146ad4b>] system_call_fastpath+0x16/0x1b
      References: https://bugzilla.kernel.org/show_bug.cgi?id=13809
      Cc: <stable@kernel.org> # .27+
      Signed-off-by: default avatarRobert Richter <robert.richter@amd.com>
  3. 14 Jan, 2009 1 commit
    • Heiko Carstens's avatar
      [CVE-2009-0029] System call wrapper special cases · 6673e0c3
      Heiko Carstens authored
      System calls with an unsigned long long argument can't be converted with
      the standard wrappers since that would include a cast to long, which in
      turn means that we would lose the upper 32 bit on 32 bit architectures.
      Also semctl can't use the standard wrapper since it has a 'union'
      So we handle them as special case and add some extra wrappers instead.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
  4. 31 Dec, 2008 1 commit
    • Nick Piggin's avatar
      shrink struct dentry · c2452f32
      Nick Piggin authored
      struct dentry is one of the most critical structures in the kernel. So it's
      sad to see it going neglected.
      With CONFIG_PROFILING turned on (which is probably the common case at least
      for distros and kernel developers), sizeof(struct dcache) == 208 here
      (64-bit). This gives 19 objects per slab.
      I packed d_mounted into a hole, and took another 4 bytes off the inline
      name length to take the padding out from the end of the structure. This
      shinks it to 200 bytes. I could have gone the other way and increased the
      length to 40, but I'm aiming for a magic number, read on...
      I then got rid of the d_cookie pointer. This shrinks it to 192 bytes. Rant:
      why was this ever a good idea? The cookie system should increase its hash
      size or use a tree or something if lookups are a problem. Also the "fast
      dcookie lookups" in oprofile should be moved into the dcookie code -- how
      can oprofile possibly care about the dcookie_mutex? It gets dropped after
      get_dcookie() returns so it can't be providing any sort of protection.
      At 192 bytes, 21 objects fit into a 4K page, saving about 3MB on my system
      with ~140 000 entries allocated. 192 is also a multiple of 64, so we get
      nice cacheline alignment on 64 and 32 byte line systems -- any given dentry
      will now require 3 cachelines to touch all fields wheras previously it
      would require 4.
      I know the inline name size was chosen quite carefully, however with the
      reduction in cacheline footprint, it should actually be just about as fast
      to do a name lookup for a 36 character name as it was before the patch (and
      faster for other sizes). The memory footprint savings for names which are
      <= 32 or > 36 bytes long should more than make up for the memory cost for
      33-36 byte names.
      Performance is a feature...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  5. 15 Feb, 2008 2 commits
  6. 30 Jul, 2007 1 commit
    • Alexey Dobriyan's avatar
      Remove fs.h from mm.h · 4e950f6f
      Alexey Dobriyan authored
      Remove fs.h from mm.h. For this,
       1) Uninline vma_wants_writenotify(). It's pretty huge anyway.
       2) Add back fs.h or less bloated headers (err.h) to files that need it.
      As result, on x86_64 allyesconfig, fs.h dependencies cut down from 3929 files
      rebuilt down to 3444 (-12.3%).
      Cross-compile tested without regressions on my two usual configs and (sigh):
      alpha              arm-mx1ads        mips-bigsur          powerpc-ebony
      alpha-allnoconfig  arm-neponset      mips-capcella        powerpc-g5
      alpha-defconfig    arm-netwinder     mips-cobalt          powerpc-holly
      alpha-up           arm-netx          mips-db1000          powerpc-iseries
      arm                arm-ns9xxx        mips-db1100          powerpc-linkstation
      arm-assabet        arm-omap_h2_1610  mips-db1200          powerpc-lite5200
      arm-at91rm9200dk   arm-onearm        mips-db1500          powerpc-maple
      arm-at91rm9200ek   arm-picotux200    mips-db1550          powerpc-mpc7448_hpc2
      arm-at91sam9260ek  arm-pleb          mips-ddb5477         powerpc-mpc8272_ads
      arm-at91sam9261ek  arm-pnx4008       mips-decstation      powerpc-mpc8313_rdb
      arm-at91sam9263ek  arm-pxa255-idp    mips-e55             powerpc-mpc832x_mds
      arm-at91sam9rlek   arm-realview      mips-emma2rh         powerpc-mpc832x_rdb
      arm-ateb9200       arm-realview-smp  mips-excite          powerpc-mpc834x_itx
      arm-badge4         arm-rpc           mips-fulong          powerpc-mpc834x_itxgp
      arm-carmeva        arm-s3c2410       mips-ip22            powerpc-mpc834x_mds
      arm-cerfcube       arm-shannon       mips-ip27            powerpc-mpc836x_mds
      arm-clps7500       arm-shark         mips-ip32            powerpc-mpc8540_ads
      arm-collie         arm-simpad        mips-jazz            powerpc-mpc8544_ds
      arm-corgi          arm-spitz         mips-jmr3927         powerpc-mpc8560_ads
      arm-csb337         arm-trizeps4      mips-malta           powerpc-mpc8568mds
      arm-csb637         arm-versatile     mips-mipssim         powerpc-mpc85xx_cds
      arm-ebsa110        i386              mips-mpc30x          powerpc-mpc8641_hpcn
      arm-edb7211        i386-allnoconfig  mips-msp71xx         powerpc-mpc866_ads
      arm-em_x270        i386-defconfig    mips-ocelot          powerpc-mpc885_ads
      arm-ep93xx         i386-up           mips-pb1100          powerpc-pasemi
      arm-footbridge     ia64              mips-pb1500          powerpc-pmac32
      arm-fortunet       ia64-allnoconfig  mips-pb1550          powerpc-ppc64
      arm-h3600          ia64-bigsur       mips-pnx8550-jbs     powerpc-prpmc2800
      arm-h7201          ia64-defconfig    mips-pnx8550-stb810  powerpc-ps3
      arm-h7202          ia64-gensparse    mips-qemu            powerpc-pseries
      arm-hackkit        ia64-sim          mips-rbhma4200       powerpc-up
      arm-integrator     ia64-sn2          mips-rbhma4500       s390
      arm-iop13xx        ia64-tiger        mips-rm200           s390-allnoconfig
      arm-iop32x         ia64-up           mips-sb1250-swarm    s390-defconfig
      arm-iop33x         ia64-zx1          mips-sead            s390-up
      arm-ixp2000        m68k              mips-tb0219          sparc
      arm-ixp23xx        m68k-amiga        mips-tb0226          sparc-allnoconfig
      arm-ixp4xx         m68k-apollo       mips-tb0287          sparc-defconfig
      arm-jornada720     m68k-atari        mips-workpad         sparc-up
      arm-kafa           m68k-bvme6000     mips-wrppmc          sparc64
      arm-kb9202         m68k-hp300        mips-yosemite        sparc64-allnoconfig
      arm-ks8695         m68k-mac          parisc               sparc64-defconfig
      arm-lart           m68k-mvme147      parisc-allnoconfig   sparc64-up
      arm-lpd270         m68k-mvme16x      parisc-defconfig     um-x86_64
      arm-lpd7a400       m68k-q40          parisc-up            x86_64
      arm-lpd7a404       m68k-sun3         powerpc              x86_64-allnoconfig
      arm-lubbock        m68k-sun3x        powerpc-cell         x86_64-defconfig
      arm-lusl7200       mips              powerpc-celleb       x86_64-up
      arm-mainstone      mips-atlas        powerpc-chrp32
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  7. 20 Jul, 2007 1 commit
    • Paul Mundt's avatar
      mm: Remove slab destructors from kmem_cache_create(). · 20c2df83
      Paul Mundt authored
      Slab destructors were no longer supported after Christoph's
      c59def9f change. They've been
      BUGs for both slab and slub, and slob never supported them
      This rips out support for the dtor pointer from kmem_cache_create()
      completely and fixes up every single callsite in the kernel (there were
      about 224, not including the slab allocator definitions themselves,
      or the documentation references).
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
  8. 07 Dec, 2006 1 commit
  9. 30 Jun, 2006 1 commit
  10. 26 Mar, 2006 2 commits
  11. 12 Jan, 2006 1 commit
  12. 08 Jul, 2005 1 commit
  13. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!