12 Jan, 2010

30 commits

  • Remove comments about function short descriptions not allowed to be on
    multiple lines (that was fixed/changed recently).

    Add comments that function "section header:" names need to be unique per
    function/struct/union/typedef/enum.

    Signed-off-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     
  • Signed-off-by: Michael Hennerich
    Signed-off-by: Mike Frysinger
    Cc: Jean Delvare
    Cc: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Hennerich
     
  • menu: use proper 64 bit math

    The new menu governor is incorrectly doing a 64 bit divide. Compile
    tested only

    Signed-off-by: Stephen Hemminger
    Cc: Arjan van de Ven
    Cc: Len Brown
    Cc: Venkatesh Pallipadi
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Stephen Hemminger
     
  • Fix typos, grammos, spellos, hyphenation.

    Signed-off-by: Randy Dunlap
    Acked-by: Steven Rostedt
    Cc: Mel Gorman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     
  • sz is in bytes, MAX_ORDER_NR_PAGES is in pages.

    Signed-off-by: Andrea Arcangeli
    Acked-by: David Gibson
    Cc: Mel Gorman
    Cc: David Rientjes
    Cc: Lee Schermerhorn
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrea Arcangeli
     
  • Signed-off-by:
    Cc: Jean Delvare
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tomaz Mertelj
     
  • Previously enabled poll(2) support on one edge was never reconfigured when
    sysfs polarity change was triggered from kernel, because 'struct device
    *dev' shadowed an earlier definition.

    Found by sparse, which I should've run much earlier.

    Signed-off-by: Jani Nikula
    Cc: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jani Nikula
     
  • Signed-off-by: Uwe Kleine-König
    Reported-by: Josip Rodin
    Cc: Joe Perches
    Cc: David S. Miller
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Uwe Kleine-König
     
  • JEDEC eMMC specification version 4.4 (MMCA 4.4) defines Extended CSD
    structure versions up to 5.

    Signed-off-by: Adrian Hunter
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Hunter
     
  • The main bug was that 'blk_cleanup_queue()' was called while the block
    device could still be in use, for example, because the card was removed
    while files were still open.

    In addition, to be sure that 'mmc_request()' will get called for all new
    requests (so it can error them out), the queue is emptied during cleanup.
    This is done after the worker thread is stopped to avoid racing with it.

    Finally, it is not a device error for this to be happening, so quiet the
    (sometimes very many) error messages.

    Signed-off-by: Adrian Hunter
    Cc:
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Hunter
     
  • If mmc_blk_set_blksize() fails mmc_blk_probe() the request queue and its
    thread have been set up and they need to be shut down properly before
    putting the disk.

    Signed-off-by: Jarkko Lavinen
    Signed-off-by: Adrian Hunter
    Cc:
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jarkko Lavinen
     
  • When a card is removed before mmc_blk_probe() has called add_disk(), then
    the minor field is uninitialized and has value 0. This caused
    mmc_blk_put() to always release devidx 0 even if 0 was still in use. Then
    the next mmc_blk_probe() used the first free idx of 0, which oopses in
    sysfs, since it is used by another card.

    Signed-off-by: Anna Lemehova
    Signed-off-by: Adrian Hunter
    Cc:
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Anna Lemehova
     
  • Warning(drivers/base/power/main.c:453): No description found for parameter 'dev'
    Warning(drivers/base/power/main.c:453): No description found for parameter 'cb'
    Warning(drivers/base/power/main.c:719): No description found for parameter 'dev'
    Warning(drivers/base/power/main.c:719): No description found for parameter 'state'
    Warning(drivers/base/power/main.c:719): No description found for parameter 'cb'

    Signed-off-by: Randy Dunlap
    Cc: Rafael J. Wysocki
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     
  • Commit d899bf7b (procfs: provide stack information for threads) introduced
    to show stack information in /proc/{pid}/status. But it cause large
    performance regression. Unfortunately /proc/{pid}/status is used ps
    command too and ps is one of most important component. Because both to
    take mmap_sem and page table walk are heavily operation.

    If many process run, the ps performance is,

    [before d899bf7b]

    % perf stat ps >/dev/null

    Performance counter stats for 'ps':

    4090.435806 task-clock-msecs # 0.032 CPUs
    229 context-switches # 0.000 M/sec
    0 CPU-migrations # 0.000 M/sec
    234 page-faults # 0.000 M/sec
    8587565207 cycles # 2099.425 M/sec
    9866662403 instructions # 1.149 IPC
    3789415411 cache-references # 926.409 M/sec
    30419509 cache-misses # 7.437 M/sec

    128.859521955 seconds time elapsed

    [after d899bf7b]

    % perf stat ps > /dev/null

    Performance counter stats for 'ps':

    4305.081146 task-clock-msecs # 0.028 CPUs
    480 context-switches # 0.000 M/sec
    2 CPU-migrations # 0.000 M/sec
    237 page-faults # 0.000 M/sec
    9021211334 cycles # 2095.480 M/sec
    10605887536 instructions # 1.176 IPC
    3612650999 cache-references # 839.160 M/sec
    23917502 cache-misses # 5.556 M/sec

    152.277819582 seconds time elapsed

    Thus, this patch revert it. Fortunately /proc/{pid}/task/{tid}/smaps
    provide almost same information. we can use it.

    Commit d899bf7b introduced two features:

    1) Add the annotattion of [thread stack: xxxx] mark to
    /proc/{pid}/task/{tid}/maps.
    2) Add StackUsage field to /proc/{pid}/status.

    I only revert (2), because I haven't seen (1) cause regression.

    Signed-off-by: KOSAKI Motohiro
    Cc: Stefani Seibold
    Cc: Ingo Molnar
    Cc: Peter Zijlstra
    Cc: Alexey Dobriyan
    Cc: "Eric W. Biederman"
    Cc: Randy Dunlap
    Cc: Andrew Morton
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KOSAKI Motohiro
     
  • MIPS compressed kernels output a vmlinuz file in the top-level directory
    (maybe others do). Add vmlinuz to the list of files to ignore by git.

    Signed-off-by: Florian Fainelli
    Cc: Ralf Baechle
    Cc: Maxime Bizon
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Florian Fainelli
     
  • When print-fatal-signals is enabled it's possible to dump any memory
    reachable by the kernel to the log by simply jumping to that address from
    user space.

    Or crash the system if there's some hardware with read side effects.

    The fatal signals handler will dump 16 bytes at the execution address,
    which is fully controlled by ring 3.

    In addition when something jumps to a unmapped address there will be up to
    16 additional useless page faults, which might be potentially slow (and at
    least is not very efficient)

    Fortunately this option is off by default and only there on i386.

    But fix it by checking for kernel addresses and also stopping when there's
    a page fault.

    Signed-off-by: Andi Kleen
    Cc: Ingo Molnar
    Cc: Oleg Nesterov
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     
  • The LTP cgroup test suite generates a "kernel BUG at kernel/cgroup.c:790!"
    here in cgroup_diput():

    /*
    * if we're getting rid of the cgroup, refcount should ensure
    * that there are no pidlists left.
    */
    BUG_ON(!list_empty(&cgrp->pidlists));

    The cgroup pidlist rework in 2.6.32 generates the BUG_ON, which is caused
    when pidlist_array_load() calls cgroup_pidlist_find():

    (1) if a matching cgroup_pidlist is found, it down_write's the mutex of the
    pre-existing cgroup_pidlist, and increments its use_count.
    (2) if no matching cgroup_pidlist is found, then a new one is allocated, it
    down_write's its mutex, and the use_count is set to 0.
    (3) the matching, or new, cgroup_pidlist gets returned back to pidlist_array_load(),
    which increments its use_count -- regardless whether new or pre-existing --
    and up_write's the mutex.

    So if a matching list is ever encountered by cgroup_pidlist_find() during
    the life of a cgroup directory, it results in an inflated use_count value,
    preventing it from ever getting released by cgroup_release_pid_array().
    Then if the directory is subsequently removed, cgroup_diput() hits the
    BUG_ON() when it finds that the directory's cgroup is still populated with
    a pidlist.

    The patch simply removes the use_count increment when a matching pidlist
    is found by cgroup_pidlist_find(), because it gets bumped by the calling
    pidlist_array_load() function while still protected by the list's mutex.

    Signed-off-by: Dave Anderson
    Reviewed-by: Li Zefan
    Acked-by: Ben Blum
    Cc: Paul Menage
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Anderson
     
  • The following command doesn't generate any output.
    `./scripts/get_maintainer.pl --no-git -f drivers/net/wireless/wl12xx/wl1271_acx.c`

    An excluded "X:" pattern match in any section would cause a file not to
    match any other section.

    Signed-off-by: Joe Perches
    Reported-by: Dan Carpenter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Joe Perches
     
  • lib/rational.c:62: warning: data definition has no type or storage class
    lib/rational.c:62: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
    lib/rational.c:62: warning: parameter names (without types) in function declaration

    Signed-off-by: Sascha Hauer
    Signed-off-by: Uwe Kleine-König
    Acked-by: WANG Cong
    Cc: Oskar Schirmer
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sascha Hauer
     
  • Signed-off-by: Albin Tonnerre
    Tested-by: Wu Zhangjin
    Acked-by: "H. Peter Anvin"
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Tested-by: Russell King
    Acked-by: Russell King
    Cc: Ralf Baechle
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Albin Tonnerre
     
  • The necessary changes to the x86 Kconfig and boot/compressed to allow the
    use of this new compression method

    Signed-off-by: Albin Tonnerre
    Acked-by: H. Peter Anvin
    Tested-by: Wu Zhangjin
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Tested-by: Russell King
    Acked-by: Russell King
    Cc: Ralf Baechle
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Albin Tonnerre
     
  • - changes to ach/arch/boot/Makefile to make it easier to add new
    compression types
    - new piggy.lzo.S necessary for lzo compression
    - changes in arch/arm/boot/compressed/misc.c to allow the use of lzo or
    gzip, depending on the config
    - Kconfig support

    Signed-off-by: Albin Tonnerre
    Tested-by: Wu Zhangjin
    Acked-by: "H. Peter Anvin"
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Tested-by: Russell King
    Acked-by: Russell King
    Cc: Ralf Baechle
    Cc: Martin Michlmayr
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Albin Tonnerre
     
  • This patch series adds generic support for creating and extracting
    LZO-compressed kernel images, as well as support for using such images on
    the x86 and ARM architectures, and support for creating and using
    LZO-compressed initrd and initramfs images.

    Russell King said:

    : Testing on a Cortex A9 model:
    : - lzo decompressor is 65% of the time gzip takes to decompress a kernel
    : - lzo kernel is 9% larger than a gzip kernel
    :
    : which I'm happy to say confirms your figures when comparing the two.
    :
    : However, when comparing your new gzip code to the old gzip code:
    : - new is 99% of the size of the old code
    : - new takes 42% of the time to decompress than the old code
    :
    : What this means is that for a proper comparison, the results get even better:
    : - lzo is 7.5% larger than the old gzip'd kernel image
    : - lzo takes 28% of the time that the old gzip code took
    :
    : So the expense seems definitely worth the effort. The only reason I
    : can think of ever using gzip would be if you needed the additional
    : compression (eg, because you have limited flash to store the image.)
    :
    : I would argue that the default for ARM should therefore be LZO.

    This patch:

    The lzo compressor is worse than gzip at compression, but faster at
    extraction. Here are some figures for an ARM board I'm working on:

    Uncompressed size: 3.24Mo
    gzip 1.61Mo 0.72s
    lzo 1.75Mo 0.48s

    So for a compression ratio that is still relatively close to gzip, it's
    much faster to extract, at least in that case.

    This part contains:
    - Makefile routine to support lzo compression
    - Fixes to the existing lzo compressor so that it can be used in
    compressed kernels
    - wrapper around the existing lzo1x_decompress, as it only extracts one
    block at a time, while we need to extract a whole file here
    - config dialog for kernel compression

    [akpm@linux-foundation.org: coding-style fixes]
    [akpm@linux-foundation.org: cleanup]
    Signed-off-by: Albin Tonnerre
    Tested-by: Wu Zhangjin
    Acked-by: "H. Peter Anvin"
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Tested-by: Russell King
    Acked-by: Russell King
    Cc: Ralf Baechle
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Albin Tonnerre
     
  • JFFS2 uses lesser compression ratio and inflate always ends up in "copy
    direct from output" case.

    This patch tries to optimize the direct copy procedure. Uses
    get_unaligned() but only in one place.

    The copy loop just above this one can also use this optimization, but I
    havn't done so as I have not tested if it is a win there too.

    On my MPC8321 this is about 17% faster on my JFFS2 root FS than the
    original.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Joakim Tjernlund
    Cc: Roel Kluin
    Cc: Richard Purdie
    Cc: David Woodhouse
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Joakim Tjernlund
     
  • __pcpu_ptr_to_addr() can be overridden by the architecture and might not
    behave well if passed a NULL pointer. So avoid calling it until we have
    verified that its arg is not NULL.

    Cc: Rusty Russell
    Cc: Kamalesh Babulal
    Acked-by: Tejun Heo
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • Fix resource (write-pipe file) leak in call_usermodehelper_pipe().

    When call_usermodehelper_exec() fails, write-pipe file is opened and
    call_usermodehelper_pipe() just returns an error. Since it is hard for
    caller to determine whether the error occured when opening the pipe or
    executing the helper, the caller cannot close the pipe by themselves.

    I've found this resoruce leak when testing coredump. You can check how
    the resource leaks as below;

    $ echo "|nocommand" > /proc/sys/kernel/core_pattern
    $ ulimit -c unlimited
    $ while [ 1 ]; do ./segv; done &> /dev/null &
    $ cat /proc/meminfo (
    Cc: Rusty Russell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Masami Hiramatsu
     
  • There is no need to perform full BIDIR sync (copying the buffers in case
    of swiotlb and similar schemes) if we know that the owner (CPU or device)
    hasn't altered the data.

    Addresses the false-positive reported at
    http://bugzilla.kernel.org/show_bug.cgi?id=14169

    Signed-off-by: Krzysztof Halasa
    Cc: David Miller
    Cc: Joerg Roedel
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Krzysztof Halasa
     
  • It turns out that even zero-sized struct members (int foo[0];) will affect
    the struct layout, causing us in particular to lose 4 bytes in struct
    sock.

    This patch fixes the regression in CONFIG_KMEMCHECK=n case.

    Reported-by: Eric Dumazet
    Signed-off-by: Vegard Nossum
    Acked-by: Pekka Enberg
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vegard Nossum
     
  • Add many ioctl definitions to ioctl-number.txt.
    Fix some whitespace/formatting.
    Correct some filenames/paths.

    Signed-off-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     
  • Makes it consistent with the extern declaration, used when CONFIG_HIGHMEM
    is set Removes redundant casts in printout messages

    Signed-off-by: Andreas Fenkart
    Acked-by: Russell King
    Cc: Ralf Baechle
    Cc: David Howells
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: "H. Peter Anvin"
    Cc: Chen Liqin
    Cc: Lennox Wu
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andreas Fenkart
     

09 Jan, 2010

10 commits