24 Mar, 2011

1 commit

  • printk()s without a priority level default to KERN_WARNING. To reduce
    noise at KERN_WARNING, this patch set the priority level appriopriately
    for unleveled printks()s. This should be useful to folks that look at
    dmesg warnings closely.

    Signed-off-by: Mandeep Singh Baines
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mandeep Singh Baines
     

14 Jan, 2011

1 commit

  • Commit 4be2c95d ("taskstats: pad taskstats netlink response for aligment
    issues on ia64") added a null field to align the taskstats structure but
    the discussion centered around ia64. The issue exists on other platforms
    with inefficient unaligned access and adding them piecemeal would be an
    unmaintainable mess.

    This patch uses Dave Miller's suggestion of using a combination of
    CONFIG_64BIT && !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to determine
    whether alignment is needed.

    Note that this will cause breakage on those platforms with applications
    like iotop which had hard-coded offsets into the packet to access the
    taskstats structure.

    The message seen on systems without the alignment fixes looks like: kernel
    unaligned access to 0xe000023879dca9bc, ip=0xa000000100133d10

    The addresses may vary but resolve to locations inside __delayacct_add_tsk.

    iotop makes what I'd call unreasonable assumptions about the contents of a
    netlink genetlink packet containing generic attributes. They're typed and
    have headers that specify value lengths, so the client can (should)
    identify and skip the ones the client doesn't understand.

    The kernel, as of version 2.6.36, presented a packet like so:
    +--------------------------------+
    | genlmsghdr - 4 bytes |
    +--------------------------------+
    | NLA header - 4 bytes | /* Aggregate header */
    +-+------------------------------+
    | | NLA header - 4 bytes | /* PID header */
    | +------------------------------+
    | | pid/tgid - 4 bytes |
    | +------------------------------+
    | | NLA header - 4 bytes | /* stats header */
    | + -----------------------------+
    Reported-by: David S. Miller
    Acked-by: David S. Miller
    Cc: Dan Carpenter
    Cc: Balbir Singh
    Cc: Florian Mickler
    Cc: Guillaume Chazarain
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Mahoney
     

08 Jan, 2011

1 commit

  • * 'for-2.6.38' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu: (30 commits)
    gameport: use this_cpu_read instead of lookup
    x86: udelay: Use this_cpu_read to avoid address calculation
    x86: Use this_cpu_inc_return for nmi counter
    x86: Replace uses of current_cpu_data with this_cpu ops
    x86: Use this_cpu_ops to optimize code
    vmstat: User per cpu atomics to avoid interrupt disable / enable
    irq_work: Use per cpu atomics instead of regular atomics
    cpuops: Use cmpxchg for xchg to avoid lock semantics
    x86: this_cpu_cmpxchg and this_cpu_xchg operations
    percpu: Generic this_cpu_cmpxchg() and this_cpu_xchg support
    percpu,x86: relocate this_cpu_add_return() and friends
    connector: Use this_cpu operations
    xen: Use this_cpu_inc_return
    taskstats: Use this_cpu_ops
    random: Use this_cpu_inc_return
    fs: Use this_cpu_inc_return in buffer.c
    highmem: Use this_cpu_xx_return() operations
    vmstat: Use this_cpu_inc_return for vm statistics
    x86: Support for this_cpu_add, sub, dec, inc_return
    percpu: Generic support for this_cpu_add, sub, dec, inc_return
    ...

    Fixed up conflicts: in arch/x86/kernel/{apic/nmi.c, apic/x2apic_uv_x.c, process.c}
    as per Tejun.

    Linus Torvalds
     

23 Dec, 2010

1 commit

  • The taskstats structure is internally aligned on 8 byte boundaries but the
    layout of the aggregrate reply, with two NLA headers and the pid (each 4
    bytes), actually force the entire structure to be unaligned. This causes
    the kernel to issue unaligned access warnings on some architectures like
    ia64. Unfortunately, some software out there doesn't properly unroll the
    NLA packet and assumes that the start of the taskstats structure will
    always be 20 bytes from the start of the netlink payload. Aligning the
    start of the taskstats structure breaks this software, which we don't
    want. So, for now the alignment only happens on architectures that
    require it and those users will have to update to fixed versions of those
    packages. Space is reserved in the packet only when needed. This ifdef
    should be removed in several years e.g. 2012 once we can be confident
    that fixed versions are installed on most systems. We add the padding
    before the aggregate since the aggregate is already a defined type.

    Commit 85893120 ("delayacct: align to 8 byte boundary on 64-bit systems")
    previously addressed the alignment issues by padding out the pid field.
    This was supposed to be a compatible change but the circumstances
    described above mean that it wasn't. This patch backs out that change,
    since it was a hack, and introduces a new NULL attribute type to provide
    the padding. Padding the response with 4 bytes avoids allocating an
    aligned taskstats structure and copying it back. Since the structure
    weighs in at 328 bytes, it's too big to do it on the stack.

    Signed-off-by: Jeff Mahoney
    Reported-by: Brian Rogers
    Cc: Jeff Mahoney
    Cc: Guillaume Chazarain
    Cc: Balbir Singh
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Mahoney
     

17 Dec, 2010

1 commit

  • Use this_cpu_inc_return in one place and avoid ugly __raw_get_cpu in
    another.

    V3->V4:
    - Fix off by one.

    V4-V4f:
    - Use &listener_array

    Cc: Michael Holzheu
    Acked-by: H. Peter Anvin
    Signed-off-by: Christoph Lameter
    Signed-off-by: Tejun Heo

    Christoph Lameter
     

28 Oct, 2010

3 commits

  • Separate the finding of a task_struct by pid or tgid from filling the
    taskstats data. This makes the code more readable.

    Signed-off-by: Michael Holzheu
    Acked-by: Balbir Singh
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Holzheu
     
  • Move each taskstats command into a single function. This makes the code
    more readable and makes it easier to add new commands.

    Signed-off-by: Michael Holzheu
    Acked-by: Balbir Singh
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Holzheu
     
  • prepare_reply() sets up an skb for the response. The payload contains:

    +--------------------------------+
    | genlmsghdr - 4 bytes |
    +--------------------------------+
    | NLA header - 4 bytes | /* Aggregate header */
    +-+------------------------------+
    | | NLA header - 4 bytes | /* PID header */
    | +------------------------------+
    | | pid/tgid - 4 bytes |
    | +------------------------------+
    | | NLA header - 4 bytes | /* stats header */
    | + -----------------------------+
    Cc: Balbir Singh
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Mahoney
     

30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

19 Feb, 2010

1 commit


13 Jul, 2009

1 commit

  • This makes generic netlink network namespace aware. No
    generic netlink families except for the controller family
    are made namespace aware, they need to be checked one by
    one and then set the family->netnsok member to true.

    A new function genlmsg_multicast_netns() is introduced to
    allow sending a multicast message in a given namespace,
    for example when it applies to an object that lives in
    that namespace, a new function genlmsg_multicast_allns()
    to send a message to all network namespaces (for objects
    that do not have an associated netns).

    The function genlmsg_multicast() is changed to multicast
    the message in just init_net, which is currently correct
    for all generic netlink families since they only work in
    init_net right now. Some will later want to work in all
    net namespaces because they do not care about the netns
    at all -- those will have to be converted to use one of
    the new functions genlmsg_multicast_allns() or
    genlmsg_multicast_netns() whenever they are made netns
    aware in some way.

    After this patch families can easily decide whether or
    not they should be available in all net namespaces. Many
    genl families us it for objects not related to networking
    and should therefore be available in all namespaces, but
    that will have to be done on a per family basis.

    Note that this doesn't touch on the checkpoint/restart
    problem where network namespaces could be used, genl
    families and multicast groups are numbered globally and
    I see no easy way of changing that, especially since it
    must be possible to multicast to all network namespaces
    for those families that do not care about netns.

    Signed-off-by: Johannes Berg
    Signed-off-by: David S. Miller

    Johannes Berg
     

01 Jan, 2009

1 commit

  • Impact: Reduce stack usage, use new cpumask API.

    Mainly changing cpumask_t to 'struct cpumask' and similar simple API
    conversion. Two conversions worth mentioning:

    1) we use cpumask_any_but to avoid a temporary in kernel/softlockup.c,
    2) Use cpumask_var_t in taskstats_user_cmd().

    Signed-off-by: Rusty Russell
    Signed-off-by: Mike Travis
    Cc: Balbir Singh
    Cc: Ingo Molnar

    Rusty Russell
     

13 Dec, 2008

1 commit

  • …t_scnprintf to take pointers.

    Impact: change calling convention of existing cpumask APIs

    Most cpumask functions started with cpus_: these have been replaced by
    cpumask_ ones which take struct cpumask pointers as expected.

    These four functions don't have good replacement names; fortunately
    they're rarely used, so we just change them over.

    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Mike Travis <travis@sgi.com>
    Acked-by: Ingo Molnar <mingo@elte.hu>
    Cc: paulus@samba.org
    Cc: mingo@redhat.com
    Cc: tony.luck@intel.com
    Cc: ralf@linux-mips.org
    Cc: Greg Kroah-Hartman <gregkh@suse.de>
    Cc: cl@linux-foundation.org
    Cc: srostedt@redhat.com

    Rusty Russell