09 Dec, 2006

1 commit

  • This facility provides three entry points:

    ilog2() Log base 2 of unsigned long
    ilog2_u32() Log base 2 of u32
    ilog2_u64() Log base 2 of u64

    These facilities can either be used inside functions on dynamic data:

    int do_something(long q)
    {
    ...;
    y = ilog2(x)
    ...;
    }

    Or can be used to statically initialise global variables with constant values:

    unsigned n = ilog2(27);

    When performing static initialisation, the compiler will report "error:
    initializer element is not constant" if asked to take a log of zero or of
    something not reducible to a constant. They treat negative numbers as
    unsigned.

    When not dealing with a constant, they fall back to using fls() which permits
    them to use arch-specific log calculation instructions - such as BSR on
    x86/x86_64 or SCAN on FRV - if available.

    [akpm@osdl.org: MMC fix]
    Signed-off-by: David Howells
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Herbert Xu
    Cc: David Howells
    Cc: Wojtek Kaniewski
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

30 Nov, 2006

1 commit


27 Nov, 2006

1 commit

  • You wouldn't think that doing an ALIGN() macro that aligns something up
    to a power-of-two boundary would be likely to have bugs, would you?

    But hey, in the wonderful world of mixing integer types, you have to be
    careful. This just makes sure that the alignment is interpreted in the
    same type as the thing to be aligned.

    Thanks to Roland Dreier, who noticed that the amso1100 driver got broken
    by the previous fix (that just extended the mask to "unsigned long", but
    was still broken in "unsigned long long" - it just happened to be the
    same on 64-bit architectures).

    See commit 4c8bd7eeee4c8f157fb61fb64b57500990b42e0e for the history of
    bugs here...

    Acked-by: Roland Dreier
    Cc: Andrew Morton
    Cc: David Miller
    Cc: Al Viro
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

04 Nov, 2006

1 commit

  • printk_ratelimit() has global state which makes it not useful for callers
    which wish to perform ratelimiting at a particular frequency.

    Add a printk_timed_ratelimit() which utilises caller-provided state storage to
    permit more flexibility.

    This function can in fact be used for things other than printk ratelimiting
    and is perhaps poorly named.

    Cc: Ulrich Drepper
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Rusty Russell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

03 Oct, 2006

1 commit

  • check pr_debug() arguments

    When DEBUG isn't defined pr_debug() is defined away as an empty macro. By
    throwing away the arguments we allow completely incorrect code to build.

    Instead let's make it an empty inline which checks arguments and mark it so gcc
    can check the format specification.

    This results in a seemingly insignificant code size increase. A x86-64
    allyesconfig:

    text data bss dec hex filename
    25354768 7191098 4854720 37400586 23ab00a vmlinux.before
    25354945 7191138 4854720 37400803 23ab0e3 vmlinux

    Signed-off-by: Zach Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Zach Brown
     

27 Sep, 2006

2 commits

  • The NUMA_BUILD constant is always available and will be set to 1 on
    NUMA_BUILDs. That way checks valid only under CONFIG_NUMA can easily be done
    without #ifdef CONFIG_NUMA

    F.e.

    if (NUMA_BUILD && ) {
    ...
    }

    [akpm: not a thing we'd normally do, but CONFIG_NUMA is special: it is
    causing ifdef explosion in core kernel, so let's see if this is a comfortable
    way in whcih to control that]

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

    Christoph Lameter
     
  • * 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6: (225 commits)
    [PATCH] Don't set calgary iommu as default y
    [PATCH] i386/x86-64: New Intel feature flags
    [PATCH] x86: Add a cumulative thermal throttle event counter.
    [PATCH] i386: Make the jiffies compares use the 64bit safe macros.
    [PATCH] x86: Refactor thermal throttle processing
    [PATCH] Add 64bit jiffies compares (for use with get_jiffies_64)
    [PATCH] Fix unwinder warning in traps.c
    [PATCH] x86: Allow disabling early pci scans with pci=noearly or disallowing conf1
    [PATCH] x86: Move direct PCI scanning functions out of line
    [PATCH] i386/x86-64: Make all early PCI scans dependent on CONFIG_PCI
    [PATCH] Don't leak NT bit into next task
    [PATCH] i386/x86-64: Work around gcc bug with noreturn functions in unwinder
    [PATCH] Fix some broken white space in ia32_signal.c
    [PATCH] Initialize argument registers for 32bit signal handlers.
    [PATCH] Remove all traces of signal number conversion
    [PATCH] Don't synchronize time reading on single core AMD systems
    [PATCH] Remove outdated comment in x86-64 mmconfig code
    [PATCH] Use string instructions for Core2 copy/clear
    [PATCH] x86: - restore i8259A eoi status on resume
    [PATCH] i386: Split multi-line printk in oops output.
    ...

    Linus Torvalds
     

26 Sep, 2006

2 commits

  • Add the DIV_ROUND_UP() helper macro: divide `n' by `d', rounding up.

    Stolen from the gfs2 tree(!) because the swsusp patches need it.

    Signed-off-by: Steven Whitehouse
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Steven Whitehouse
     
  • To quote Alan Cox:

    The default Linux behaviour on an NMI of either memory or unknown is to
    continue operation. For many environments such as scientific computing
    it is preferable that the box is taken out and the error dealt with than
    an uncorrected parity/ECC error get propogated.

    A small number of systems do generate NMI's for bizarre random reasons
    such as power management so the default is unchanged. In other respects
    the new proc/sys entry works like the existing panic controls already in
    that directory.

    This is separate to the edac support - EDAC allows supported chipsets to
    handle ECC errors well, this change allows unsupported cases to at least
    panic rather than cause problems further down the line.

    Signed-off-by: Don Zickus
    Signed-off-by: Andi Kleen

    Don Zickus
     

24 Sep, 2006

1 commit


12 Aug, 2006

1 commit


11 Jul, 2006

1 commit


27 Jun, 2006

1 commit

  • These are the generic bits needed to enable reliable stack traces based
    on Dwarf2-like (.eh_frame) unwind information. Subsequent patches will
    enable x86-64 and i386 to make use of this.

    Thanks to Andi Kleen and Ingo Molnar, who pointed out several possibilities
    for improvement.

    Signed-off-by: Jan Beulich
    Signed-off-by: Andi Kleen
    Signed-off-by: Linus Torvalds

    Jan Beulich
     

26 Jun, 2006

1 commit

  • Implement kasprintf, a kernel version of asprintf. This allocates the
    memory required for the formatted string, including the trailing '\0'.
    Returns NULL on allocation failure.

    Signed-off-by: Jeremy Fitzhardinge
    Signed-off-by: Chris Wright
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeremy Fitzhardinge
     

23 Jun, 2006

2 commits

  • The likely() profiling tools show that __alloc_page() causes a lot of misses:

    ! 132 119193 __alloc_pages():mm/page_alloc.c@937

    Because most __alloc_page() calls are not atomic.

    Signed-off-by: Hua Zhong
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hua Zhong
     
  • When a writeback_control's `start' and `end' fields are used to
    indicate a one-byte-range starting at file offset zero, the required
    values of .start=0,.end=0 mean that the ->writepages() implementation
    has no way of telling that it is being asked to perform a range
    request. Because we're currently overloading (start == 0 && end == 0)
    to mean "this is not a write-a-range request".

    To make all this sane, the patch changes range of writeback_control.

    So caller does: If it is calling ->writepages() to write pages, it
    sets range (range_start/end or range_cyclic) always.

    And if range_cyclic is true, ->writepages() thinks the range is
    cyclic, otherwise it just uses range_start and range_end.

    This patch does,

    - Add LLONG_MAX, LLONG_MIN, ULLONG_MAX to include/linux/kernel.h
    -1 is usually ok for range_end (type is long long). But, if someone did,

    range_end += val; range_end is "val - 1"
    u64val = range_end >> bits; u64val is "~(0ULL)"

    or something, they are wrong. So, this adds LLONG_MAX to avoid nasty
    things, and uses LLONG_MAX for range_end.

    - All callers of ->writepages() sets range_start/end or range_cyclic.

    - Fix updates of ->writeback_index. It seems already bit strange.
    If it starts at 0 and ended by check of nr_to_write, this last
    index may reduce chance to scan end of file. So, this updates
    ->writeback_index only if range_cyclic is true or whole-file is
    scanned.

    Signed-off-by: OGAWA Hirofumi
    Cc: Nathan Scott
    Cc: Anton Altaparmakov
    Cc: Steven French
    Cc: "Vladimir V. Saveliev"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    OGAWA Hirofumi
     

16 May, 2006

1 commit

  • Even since a previous patch:

    Fix race between CONFIG_DEBUG_SLABALLOC and modules
    Sun, 27 Jun 2004 17:55:19 +0000 (17:55 +0000)
    http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commit;h=92b3db26d31cf21b70e3c1eadc56c179506d8fbe

    The function symbol_put_addr() will deadlock the kernel.

    symbol_put_addr() would acquire modlist_lock, then while holding the lock call
    two functions kernel_text_address() and module_text_address() which also try
    to acquire the same lock. This deadlocks the kernel of course.

    This patch changes symbol_put_addr() to not acquire the modlist_lock, it
    doesn't need it since it never looks at the module list directly. Also, it
    now uses core_kernel_text() instead of kernel_text_address(). The latter has
    an additional check for addr inside a module, but we don't need to do that
    since we call module_text_address() (the same function kernel_text_address
    uses) ourselves.

    Signed-off-by: Trent Piepho
    Cc: Zwane Mwaikambo
    Acked-by: Rusty Russell
    Cc: Johannes Stezenbach
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Trent Piepho
     

11 Apr, 2006

1 commit


28 Mar, 2006

1 commit

  • The kernel's implementation of notifier chains is unsafe. There is no
    protection against entries being added to or removed from a chain while the
    chain is in use. The issues were discussed in this thread:

    http://marc.theaimsgroup.com/?l=linux-kernel&m=113018709002036&w=2

    We noticed that notifier chains in the kernel fall into two basic usage
    classes:

    "Blocking" chains are always called from a process context
    and the callout routines are allowed to sleep;

    "Atomic" chains can be called from an atomic context and
    the callout routines are not allowed to sleep.

    We decided to codify this distinction and make it part of the API. Therefore
    this set of patches introduces three new, parallel APIs: one for blocking
    notifiers, one for atomic notifiers, and one for "raw" notifiers (which is
    really just the old API under a new name). New kinds of data structures are
    used for the heads of the chains, and new routines are defined for
    registration, unregistration, and calling a chain. The three APIs are
    explained in include/linux/notifier.h and their implementation is in
    kernel/sys.c.

    With atomic and blocking chains, the implementation guarantees that the chain
    links will not be corrupted and that chain callers will not get messed up by
    entries being added or removed. For raw chains the implementation provides no
    guarantees at all; users of this API must provide their own protections. (The
    idea was that situations may come up where the assumptions of the atomic and
    blocking APIs are not appropriate, so it should be possible for users to
    handle these things in their own way.)

    There are some limitations, which should not be too hard to live with. For
    atomic/blocking chains, registration and unregistration must always be done in
    a process context since the chain is protected by a mutex/rwsem. Also, a
    callout routine for a non-raw chain must not try to register or unregister
    entries on its own chain. (This did happen in a couple of places and the code
    had to be changed to avoid it.)

    Since atomic chains may be called from within an NMI handler, they cannot use
    spinlocks for synchronization. Instead we use RCU. The overhead falls almost
    entirely in the unregister routine, which is okay since unregistration is much
    less frequent that calling a chain.

    Here is the list of chains that we adjusted and their classifications. None
    of them use the raw API, so for the moment it is only a placeholder.

    ATOMIC CHAINS
    -------------
    arch/i386/kernel/traps.c: i386die_chain
    arch/ia64/kernel/traps.c: ia64die_chain
    arch/powerpc/kernel/traps.c: powerpc_die_chain
    arch/sparc64/kernel/traps.c: sparc64die_chain
    arch/x86_64/kernel/traps.c: die_chain
    drivers/char/ipmi/ipmi_si_intf.c: xaction_notifier_list
    kernel/panic.c: panic_notifier_list
    kernel/profile.c: task_free_notifier
    net/bluetooth/hci_core.c: hci_notifier
    net/ipv4/netfilter/ip_conntrack_core.c: ip_conntrack_chain
    net/ipv4/netfilter/ip_conntrack_core.c: ip_conntrack_expect_chain
    net/ipv6/addrconf.c: inet6addr_chain
    net/netfilter/nf_conntrack_core.c: nf_conntrack_chain
    net/netfilter/nf_conntrack_core.c: nf_conntrack_expect_chain
    net/netlink/af_netlink.c: netlink_chain

    BLOCKING CHAINS
    ---------------
    arch/powerpc/platforms/pseries/reconfig.c: pSeries_reconfig_chain
    arch/s390/kernel/process.c: idle_chain
    arch/x86_64/kernel/process.c idle_notifier
    drivers/base/memory.c: memory_chain
    drivers/cpufreq/cpufreq.c cpufreq_policy_notifier_list
    drivers/cpufreq/cpufreq.c cpufreq_transition_notifier_list
    drivers/macintosh/adb.c: adb_client_list
    drivers/macintosh/via-pmu.c sleep_notifier_list
    drivers/macintosh/via-pmu68k.c sleep_notifier_list
    drivers/macintosh/windfarm_core.c wf_client_list
    drivers/usb/core/notify.c usb_notifier_list
    drivers/video/fbmem.c fb_notifier_list
    kernel/cpu.c cpu_chain
    kernel/module.c module_notify_list
    kernel/profile.c munmap_notifier
    kernel/profile.c task_exit_notifier
    kernel/sys.c reboot_notifier_list
    net/core/dev.c netdev_chain
    net/decnet/dn_dev.c: dnaddr_chain
    net/ipv4/devinet.c: inetaddr_chain

    It's possible that some of these classifications are wrong. If they are,
    please let us know or submit a patch to fix them. Note that any chain that
    gets called very frequently should be atomic, because the rwsem read-locking
    used for blocking chains is very likely to incur cache misses on SMP systems.
    (However, if the chain's callout routines may sleep then the chain cannot be
    atomic.)

    The patch set was written by Alan Stern and Chandra Seetharaman, incorporating
    material written by Keith Owens and suggestions from Paul McKenney and Andrew
    Morton.

    [jes@sgi.com: restructure the notifier chain initialization macros]
    Signed-off-by: Alan Stern
    Signed-off-by: Chandra Seetharaman
    Signed-off-by: Jes Sorensen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alan Stern
     

26 Mar, 2006

1 commit

  • fls() takes an integer, so roundup_pow_of_two() is busted for ulongs larger
    than 2^32-1.

    Fix this by implementing and using fls_long().

    (Why does roundup_pow_of_two() return a long?)

    (Why is roundup_pow_of_two() __attribute_const__ whereas long_log2() is
    __attribute_pure__?)

    (Why does long_log2() suck so much? Because we were missing fls_long()?)

    Cc: Roland Dreier
    Cc: "Chen, Kenneth W"
    Cc: John Hawkes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

23 Mar, 2006

1 commit

  • Attempt to fix the problem wherein people's oops reports scroll off the screen
    due to repeated oopsing or to oopses on other CPUs.

    If this happens the user can reboot with the `pause_on_oops=' option.
    It will allow the first oopsing CPU to print an oops record just a single
    time. Second oopsing attempts, or oopses on other CPUs will cause those CPUs
    to enter a tight loop until the specified number of seconds have elapsed.

    The patch implements the infrastructure generically in the expectation that
    architectures other than x86 will find it useful.

    Cc: Dave Jones
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

18 Feb, 2006

1 commit


25 Jan, 2006

1 commit


17 Jan, 2006

1 commit


14 Jan, 2006

1 commit

  • There are errors and inconsistency in the display of NIP6 strings.
    ie: net/ipv6/ip6_flowlabel.c

    There are errors and inconsistency in the display of NIPQUAD strings too.
    ie: net/netfilter/nf_conntrack_ftp.c

    This patch:
    adds NIP6_FMT to kernel.h
    changes all code to use NIP6_FMT
    fixes net/ipv6/ip6_flowlabel.c
    adds NIPQUAD_FMT to kernel.h
    fixes net/netfilter/nf_conntrack_ftp.c
    changes a few uses of "%u.%u.%u.%u" to NIPQUAD_FMT for symmetry to NIP6_FMT

    Signed-off-by: Joe Perches
    Signed-off-by: David S. Miller

    Joe Perches
     

11 Jan, 2006

1 commit

  • )

    From: Adrian Bunk

    - create one common dump_thread() prototype in kernel.h

    - dump_thread() is only used in fs/binfmt_aout.c and can therefore be
    removed on all architectures where CONFIG_BINFMT_AOUT is not
    available

    Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    akpm@osdl.org
     

10 Jan, 2006

1 commit


09 Jan, 2006

1 commit

  • Remove various things which were checking for gcc-1.x and gcc-2.x compilers.

    From: Adrian Bunk

    Some documentation updates and removes some code paths for gcc < 3.2.

    Acked-by: Russell King
    Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

16 Dec, 2005

1 commit


07 Nov, 2005

2 commits

  • This looks like something which out-of-tree code could possibly be using.
    Give panic_timeout the twelve-month treatment.

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

    Adrian Bunk
     
  • Convert to proper kernel-doc format.

    Some have extra blank lines (not allowed immed. after the function name)
    or need blank lines (after all parameters). Function summary must be only
    one line.

    Colon (":") in a function description does weird things (causes kernel-doc
    to think that it's a new section head sadly).

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

    Randy Dunlap
     

31 Oct, 2005

1 commit


13 Sep, 2005

1 commit

  • Force a compiler error instead of a link error, because they are easier to
    track down. Idea stolen from code by Jan Beulich

    If the argument to BUILD_BUG_ON evaluates to non-zero the compiler will do:

    t.c:6: error: size of array `type name' is negative

    (surprised that gcc doesn't have an extension for this)

    Signed-off-by: "Andi Kleen"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     

26 Jun, 2005

1 commit

  • This patch adds a new preemption model: 'Voluntary Kernel Preemption'. The
    3 models can be selected from a new menu:

    (X) No Forced Preemption (Server)
    ( ) Voluntary Kernel Preemption (Desktop)
    ( ) Preemptible Kernel (Low-Latency Desktop)

    we still default to the stock (Server) preemption model.

    Voluntary preemption works by adding a cond_resched()
    (reschedule-if-needed) call to every might_sleep() check. It is lighter
    than CONFIG_PREEMPT - at the cost of not having as tight latencies. It
    represents a different latency/complexity/overhead tradeoff.

    It has no runtime impact at all if disabled. Here are size stats that show
    how the various preemption models impact the kernel's size:

    text data bss dec hex filename
    3618774 547184 179896 4345854 424ffe vmlinux.stock
    3626406 547184 179896 4353486 426dce vmlinux.voluntary +0.2%
    3748414 548640 179896 4476950 445016 vmlinux.preempt +3.5%

    voluntary-preempt is +0.2% of .text, preempt is +3.5%.

    This feature has been tested for many months by lots of people (and it's
    also included in the RHEL4 distribution and earlier variants were in Fedora
    as well), and it's intended for users and distributions who dont want to
    use full-blown CONFIG_PREEMPT for one reason or another.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     

01 May, 2005

1 commit

  • Arrange for all kernel printks to be no-ops. Only available if
    CONFIG_EMBEDDED.

    This patch saves about 375k on my laptop config and nearly 100k on minimal
    configs.

    Signed-off-by: Matt Mackall
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matt Mackall
     

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