30 Jan, 2014

1 commit

  • Commit d5dc77bfeeab ("consolidate compat lookup_dcookie()") coverted all
    architectures to the new compat_sys_lookup_dcookie() syscall.

    The "len" paramater of the new compat syscall must have the type
    compat_size_t in order to enforce zero extension for architectures where
    the ABI requires that the caller of a function performed zero and/or
    sign extension to 64 bit of all parameters.

    Signed-off-by: Heiko Carstens
    Cc: Al Viro
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"
    Cc: Hendrik Brueckner
    Cc: Martin Schwidefsky
    Cc: [v3.10+]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Heiko Carstens
     

04 Mar, 2013

2 commits


29 Feb, 2012

1 commit


31 May, 2011

1 commit

  • 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
    copy_to_user().

    oprofiled/4432 is trying to acquire lock:
    (&mm->mmap_sem){++++++}, at: [] might_fault+0x53/0xa3

    but task is already holding lock:
    (dcookie_mutex){+.+.+.}, at: [] sys_lookup_dcookie+0x45/0x149

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #1 (dcookie_mutex){+.+.+.}:
    [] lock_acquire+0xf8/0x11e
    [] mutex_lock_nested+0x63/0x309
    [] get_dcookie+0x30/0x144
    [] sync_buffer+0x196/0x3ec [oprofile]
    [] task_exit_notify+0x16/0x1a [oprofile]
    [] notifier_call_chain+0x37/0x63
    [] __blocking_notifier_call_chain+0x50/0x67
    [] blocking_notifier_call_chain+0x14/0x16
    [] profile_task_exit+0x1a/0x1c
    [] do_exit+0x2a/0x6fc
    [] do_group_exit+0x83/0xae
    [] sys_exit_group+0x17/0x1b
    [] system_call_fastpath+0x16/0x1b

    -> #0 (&mm->mmap_sem){++++++}:
    [] __lock_acquire+0x1085/0x1711
    [] lock_acquire+0xf8/0x11e
    [] might_fault+0x80/0xa3
    [] sys_lookup_dcookie+0x104/0x149
    [] system_call_fastpath+0x16/0x1b

    other info that might help us debug this:

    1 lock held by oprofiled/4432:
    #0: (dcookie_mutex){+.+.+.}, at: [] sys_lookup_dcookie+0x45/0x149

    stack backtrace:
    Pid: 4432, comm: oprofiled Not tainted 2.6.39-00008-ge5a450d #9
    Call Trace:
    [] print_circular_bug+0xae/0xbc
    [] __lock_acquire+0x1085/0x1711
    [] ? get_parent_ip+0x11/0x42
    [] ? might_fault+0x53/0xa3
    [] lock_acquire+0xf8/0x11e
    [] ? might_fault+0x53/0xa3
    [] ? path_put+0x22/0x27
    [] might_fault+0x80/0xa3
    [] ? might_fault+0x53/0xa3
    [] sys_lookup_dcookie+0x104/0x149
    [] system_call_fastpath+0x16/0x1b

    References: https://bugzilla.kernel.org/show_bug.cgi?id=13809
    Cc: # .27+
    Signed-off-by: Robert Richter

    Robert Richter
     

14 Jan, 2009

1 commit

  • 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'
    parameter.

    So we handle them as special case and add some extra wrappers instead.

    Signed-off-by: Heiko Carstens

    Heiko Carstens
     

01 Jan, 2009

1 commit

  • 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
    36 bytes long should more than make up for the memory cost for
    33-36 byte names.

    Performance is a feature...

    Signed-off-by: Al Viro

    Nick Piggin
     

15 Feb, 2008

2 commits

  • d_path() is used on a pair. Lets use a struct path to
    reflect this.

    [akpm@linux-foundation.org: fix build in mm/memory.c]
    Signed-off-by: Jan Blunck
    Acked-by: Bryan Wu
    Acked-by: Christoph Hellwig
    Cc: Al Viro
    Cc: "J. Bruce Fields"
    Cc: Neil Brown
    Cc: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Blunck
     
  • get_dcookie() is always called with a dentry and a vfsmount from a struct
    path. Make get_dcookie() take it directly as an argument.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Jan Blunck
    Acked-by: Christoph Hellwig
    Cc: Al Viro
    Cc: "J. Bruce Fields"
    Cc: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Blunck
     

30 Jul, 2007

1 commit

  • 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: Alexey Dobriyan
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     

20 Jul, 2007

1 commit

  • Slab destructors were no longer supported after Christoph's
    c59def9f222d44bb7e2f0a559f2906191a0862d7 change. They've been
    BUGs for both slab and slub, and slob never supported them
    either.

    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: Paul Mundt

    Paul Mundt
     

08 Dec, 2006

1 commit

  • Replace all uses of kmem_cache_t with struct kmem_cache.

    The patch was generated using the following script:

    #!/bin/sh
    #
    # Replace one string by another in all the kernel sources.
    #

    set -e

    for file in `find * -name "*.c" -o -name "*.h"|xargs grep -l $1`; do
    quilt add $file
    sed -e "1,\$s/$1/$2/g" $file >/tmp/$$
    mv /tmp/$$ $file
    quilt refresh
    done

    The script was run like this

    sh replace kmem_cache_t "struct kmem_cache"

    Signed-off-by: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     

01 Jul, 2006

1 commit


27 Mar, 2006

2 commits

  • I discovered on oprofile hunting on a SMP platform that dentry lookups were
    slowed down because d_hash_mask, d_hash_shift and dentry_hashtable were in
    a cache line that contained inodes_stat. So each time inodes_stats is
    changed by a cpu, other cpus have to refill their cache line.

    This patch moves some variables to the __read_mostly section, in order to
    avoid false sharing. RCU dentry lookups can go full speed.

    Signed-off-by: Eric Dumazet
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Dumazet
     
  • Semaphore to mutex conversion.

    The conversion was generated via scripts, and the result was validated
    automatically via a script as well.

    Signed-off-by: Ingo Molnar
    Cc: Eric Van Hensbergen
    Cc: Robert Love
    Cc: Thomas Gleixner
    Cc: David Woodhouse
    Cc: Neil Brown
    Cc: Trond Myklebust
    Cc: Dave Kleikamp
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     

12 Jan, 2006

1 commit


08 Jul, 2005

1 commit

  • Dcookies shouldn't play with the internals of dentry and vfsmnt
    refcounting. It defeats grepping, and is prone to break if implementation
    details change.

    In addition the function doesn't even seem to be performance critical: it
    calls kmem_cache_alloc().

    Signed-off-by: Miklos Szeredi
    Acked-by: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Miklos Szeredi
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds