07 Jan, 2009

2 commits

  • …l/git/tip/linux-2.6-tip

    * 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    sched: fix section mismatch
    sched: fix double kfree in failure path
    sched: clean up arch_reinit_sched_domains()
    sched: mark sched_create_sysfs_power_savings_entries() as __init
    getrusage: RUSAGE_THREAD should return ru_utime and ru_stime
    sched: fix sched_slice()
    sched_clock: prevent scd->clock from moving backwards, take #2
    sched: sched.c declare variables before they get used

    Linus Torvalds
     
  • At the moment, the times() system call will appear to fail for a period
    shortly after boot, while the value it want to return is between -4095 and
    -1. The same thing will also happen for the time() system call on 32-bit
    platforms some time in 2106 or so.

    On some platforms, such as x86, this is unavoidable because of the system
    call ABI, but other platforms such as powerpc have a separate error
    indication from the return value, so system calls can in fact return small
    negative values without indicating an error. On those platforms,
    force_successful_syscall_return() provides a way to indicate that the
    system call return value should not be treated as an error even if it is
    in the range which would normally be taken as a negative error number.

    This adds a force_successful_syscall_return() call to the time() and
    times() system calls plus their 32-bit compat versions, so that they don't
    erroneously indicate an error on those platforms whose system call ABI has
    a separate error indication. This will not affect anything on other
    platforms.

    Joakim Tjernlund added the fix for time() and the compat versions of
    time() and times(), after I did the fix for times().

    Signed-off-by: Joakim Tjernlund
    Signed-off-by: Paul Mackerras
    Acked-by: David S. Miller
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Mackerras
     

04 Jan, 2009

1 commit


31 Dec, 2008

1 commit

  • * 'core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (63 commits)
    stacktrace: provide save_stack_trace_tsk() weak alias
    rcu: provide RCU options on non-preempt architectures too
    printk: fix discarding message when recursion_bug
    futex: clean up futex_(un)lock_pi fault handling
    "Tree RCU": scalable classic RCU implementation
    futex: rename field in futex_q to clarify single waiter semantics
    x86/swiotlb: add default swiotlb_arch_range_needs_mapping
    x86/swiotlb: add default physbus conversion
    x86: unify pci iommu setup and allow swiotlb to compile for 32 bit
    x86: add swiotlb allocation functions
    swiotlb: consolidate swiotlb info message printing
    swiotlb: support bouncing of HighMem pages
    swiotlb: factor out copy to/from device
    swiotlb: add arch hook to force mapping
    swiotlb: allow architectures to override physbusphys conversions
    swiotlb: add comment where we handle the overflow of a dma mask on 32 bit
    rcu: fix rcutorture behavior during reboot
    resources: skip sanity check of busy resources
    swiotlb: move some definitions to header
    swiotlb: allow architectures to override swiotlb pool allocation
    ...

    Fix up trivial conflicts in
    arch/x86/kernel/Makefile
    arch/x86/mm/init_32.c
    include/linux/hardirq.h
    as per Ingo's suggestions.

    Linus Torvalds
     

25 Nov, 2008

1 commit

  • The user_ns is moved from nsproxy to user_struct, so that a struct
    cred by itself is sufficient to determine access (which it otherwise
    would not be). Corresponding ecryptfs fixes (by David Howells) are
    here as well.

    Fix refcounting. The following rules now apply:
    1. The task pins the user struct.
    2. The user struct pins its user namespace.
    3. The user namespace pins the struct user which created it.

    User namespaces are cloned during copy_creds(). Unsharing a new user_ns
    is no longer possible. (We could re-add that, but it'll cause code
    duplication and doesn't seem useful if PAM doesn't need to clone user
    namespaces).

    When a user namespace is created, its first user (uid 0) gets empty
    keyrings and a clean group_info.

    This incorporates a previous patch by David Howells. Here
    is his original patch description:

    >I suggest adding the attached incremental patch. It makes the following
    >changes:
    >
    > (1) Provides a current_user_ns() macro to wrap accesses to current's user
    > namespace.
    >
    > (2) Fixes eCryptFS.
    >
    > (3) Renames create_new_userns() to create_user_ns() to be more consistent
    > with the other associated functions and because the 'new' in the name is
    > superfluous.
    >
    > (4) Moves the argument and permission checks made for CLONE_NEWUSER to the
    > beginning of do_fork() so that they're done prior to making any attempts
    > at allocation.
    >
    > (5) Calls create_user_ns() after prepare_creds(), and gives it the new creds
    > to fill in rather than have it return the new root user. I don't imagine
    > the new root user being used for anything other than filling in a cred
    > struct.
    >
    > This also permits me to get rid of a get_uid() and a free_uid(), as the
    > reference the creds were holding on the old user_struct can just be
    > transferred to the new namespace's creator pointer.
    >
    > (6) Makes create_user_ns() reset the UIDs and GIDs of the creds under
    > preparation rather than doing it in copy_creds().
    >
    >David

    >Signed-off-by: David Howells

    Changelog:
    Oct 20: integrate dhowells comments
    1. leave thread_keyring alone
    2. use current_user_ns() in set_user()

    Signed-off-by: Serge Hallyn

    Serge Hallyn
     

17 Nov, 2008

1 commit


14 Nov, 2008

5 commits

  • Inaugurate copy-on-write credentials management. This uses RCU to manage the
    credentials pointer in the task_struct with respect to accesses by other tasks.
    A process may only modify its own credentials, and so does not need locking to
    access or modify its own credentials.

    A mutex (cred_replace_mutex) is added to the task_struct to control the effect
    of PTRACE_ATTACHED on credential calculations, particularly with respect to
    execve().

    With this patch, the contents of an active credentials struct may not be
    changed directly; rather a new set of credentials must be prepared, modified
    and committed using something like the following sequence of events:

    struct cred *new = prepare_creds();
    int ret = blah(new);
    if (ret < 0) {
    abort_creds(new);
    return ret;
    }
    return commit_creds(new);

    There are some exceptions to this rule: the keyrings pointed to by the active
    credentials may be instantiated - keyrings violate the COW rule as managing
    COW keyrings is tricky, given that it is possible for a task to directly alter
    the keys in a keyring in use by another task.

    To help enforce this, various pointers to sets of credentials, such as those in
    the task_struct, are declared const. The purpose of this is compile-time
    discouragement of altering credentials through those pointers. Once a set of
    credentials has been made public through one of these pointers, it may not be
    modified, except under special circumstances:

    (1) Its reference count may incremented and decremented.

    (2) The keyrings to which it points may be modified, but not replaced.

    The only safe way to modify anything else is to create a replacement and commit
    using the functions described in Documentation/credentials.txt (which will be
    added by a later patch).

    This patch and the preceding patches have been tested with the LTP SELinux
    testsuite.

    This patch makes several logical sets of alteration:

    (1) execve().

    This now prepares and commits credentials in various places in the
    security code rather than altering the current creds directly.

    (2) Temporary credential overrides.

    do_coredump() and sys_faccessat() now prepare their own credentials and
    temporarily override the ones currently on the acting thread, whilst
    preventing interference from other threads by holding cred_replace_mutex
    on the thread being dumped.

    This will be replaced in a future patch by something that hands down the
    credentials directly to the functions being called, rather than altering
    the task's objective credentials.

    (3) LSM interface.

    A number of functions have been changed, added or removed:

    (*) security_capset_check(), ->capset_check()
    (*) security_capset_set(), ->capset_set()

    Removed in favour of security_capset().

    (*) security_capset(), ->capset()

    New. This is passed a pointer to the new creds, a pointer to the old
    creds and the proposed capability sets. It should fill in the new
    creds or return an error. All pointers, barring the pointer to the
    new creds, are now const.

    (*) security_bprm_apply_creds(), ->bprm_apply_creds()

    Changed; now returns a value, which will cause the process to be
    killed if it's an error.

    (*) security_task_alloc(), ->task_alloc_security()

    Removed in favour of security_prepare_creds().

    (*) security_cred_free(), ->cred_free()

    New. Free security data attached to cred->security.

    (*) security_prepare_creds(), ->cred_prepare()

    New. Duplicate any security data attached to cred->security.

    (*) security_commit_creds(), ->cred_commit()

    New. Apply any security effects for the upcoming installation of new
    security by commit_creds().

    (*) security_task_post_setuid(), ->task_post_setuid()

    Removed in favour of security_task_fix_setuid().

    (*) security_task_fix_setuid(), ->task_fix_setuid()

    Fix up the proposed new credentials for setuid(). This is used by
    cap_set_fix_setuid() to implicitly adjust capabilities in line with
    setuid() changes. Changes are made to the new credentials, rather
    than the task itself as in security_task_post_setuid().

    (*) security_task_reparent_to_init(), ->task_reparent_to_init()

    Removed. Instead the task being reparented to init is referred
    directly to init's credentials.

    NOTE! This results in the loss of some state: SELinux's osid no
    longer records the sid of the thread that forked it.

    (*) security_key_alloc(), ->key_alloc()
    (*) security_key_permission(), ->key_permission()

    Changed. These now take cred pointers rather than task pointers to
    refer to the security context.

    (4) sys_capset().

    This has been simplified and uses less locking. The LSM functions it
    calls have been merged.

    (5) reparent_to_kthreadd().

    This gives the current thread the same credentials as init by simply using
    commit_thread() to point that way.

    (6) __sigqueue_alloc() and switch_uid()

    __sigqueue_alloc() can't stop the target task from changing its creds
    beneath it, so this function gets a reference to the currently applicable
    user_struct which it then passes into the sigqueue struct it returns if
    successful.

    switch_uid() is now called from commit_creds(), and possibly should be
    folded into that. commit_creds() should take care of protecting
    __sigqueue_alloc().

    (7) [sg]et[ug]id() and co and [sg]et_current_groups.

    The set functions now all use prepare_creds(), commit_creds() and
    abort_creds() to build and check a new set of credentials before applying
    it.

    security_task_set[ug]id() is called inside the prepared section. This
    guarantees that nothing else will affect the creds until we've finished.

    The calling of set_dumpable() has been moved into commit_creds().

    Much of the functionality of set_user() has been moved into
    commit_creds().

    The get functions all simply access the data directly.

    (8) security_task_prctl() and cap_task_prctl().

    security_task_prctl() has been modified to return -ENOSYS if it doesn't
    want to handle a function, or otherwise return the return value directly
    rather than through an argument.

    Additionally, cap_task_prctl() now prepares a new set of credentials, even
    if it doesn't end up using it.

    (9) Keyrings.

    A number of changes have been made to the keyrings code:

    (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
    all been dropped and built in to the credentials functions directly.
    They may want separating out again later.

    (b) key_alloc() and search_process_keyrings() now take a cred pointer
    rather than a task pointer to specify the security context.

    (c) copy_creds() gives a new thread within the same thread group a new
    thread keyring if its parent had one, otherwise it discards the thread
    keyring.

    (d) The authorisation key now points directly to the credentials to extend
    the search into rather pointing to the task that carries them.

    (e) Installing thread, process or session keyrings causes a new set of
    credentials to be created, even though it's not strictly necessary for
    process or session keyrings (they're shared).

    (10) Usermode helper.

    The usermode helper code now carries a cred struct pointer in its
    subprocess_info struct instead of a new session keyring pointer. This set
    of credentials is derived from init_cred and installed on the new process
    after it has been cloned.

    call_usermodehelper_setup() allocates the new credentials and
    call_usermodehelper_freeinfo() discards them if they haven't been used. A
    special cred function (prepare_usermodeinfo_creds()) is provided
    specifically for call_usermodehelper_setup() to call.

    call_usermodehelper_setkeys() adjusts the credentials to sport the
    supplied keyring as the new session keyring.

    (11) SELinux.

    SELinux has a number of changes, in addition to those to support the LSM
    interface changes mentioned above:

    (a) selinux_setprocattr() no longer does its check for whether the
    current ptracer can access processes with the new SID inside the lock
    that covers getting the ptracer's SID. Whilst this lock ensures that
    the check is done with the ptracer pinned, the result is only valid
    until the lock is released, so there's no point doing it inside the
    lock.

    (12) is_single_threaded().

    This function has been extracted from selinux_setprocattr() and put into
    a file of its own in the lib/ directory as join_session_keyring() now
    wants to use it too.

    The code in SELinux just checked to see whether a task shared mm_structs
    with other tasks (CLONE_VM), but that isn't good enough. We really want
    to know if they're part of the same thread group (CLONE_THREAD).

    (13) nfsd.

    The NFS server daemon now has to use the COW credentials to set the
    credentials it is going to use. It really needs to pass the credentials
    down to the functions it calls, but it can't do that until other patches
    in this series have been applied.

    Signed-off-by: David Howells
    Acked-by: James Morris
    Signed-off-by: James Morris

    David Howells
     
  • Use RCU to access another task's creds and to release a task's own creds.
    This means that it will be possible for the credentials of a task to be
    replaced without another task (a) requiring a full lock to read them, and (b)
    seeing deallocated memory.

    Signed-off-by: David Howells
    Acked-by: James Morris
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    David Howells
     
  • Wrap current->cred and a few other accessors to hide their actual
    implementation.

    Signed-off-by: David Howells
    Acked-by: James Morris
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    David Howells
     
  • Separate the task security context from task_struct. At this point, the
    security data is temporarily embedded in the task_struct with two pointers
    pointing to it.

    Note that the Alpha arch is altered as it refers to (E)UID and (E)GID in
    entry.S via asm-offsets.

    With comment fixes Signed-off-by: Marc Dionne

    Signed-off-by: David Howells
    Acked-by: James Morris
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    David Howells
     
  • Wrap access to task credentials so that they can be separated more easily from
    the task_struct during the introduction of COW creds.

    Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id().

    Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more
    sense to use RCU directly rather than a convenient wrapper; these will be
    addressed by later patches.

    Signed-off-by: David Howells
    Reviewed-by: James Morris
    Acked-by: Serge Hallyn
    Cc: Al Viro
    Cc: linux-audit@redhat.com
    Cc: containers@lists.linux-foundation.org
    Cc: linux-mm@kvack.org
    Signed-off-by: James Morris

    David Howells
     

22 Oct, 2008

1 commit


20 Oct, 2008

1 commit


18 Oct, 2008

1 commit


17 Oct, 2008

3 commits

  • utsname() is quite expensive to calculate. Cache it in a local.

    text data bss dec hex filename
    before: 11136 720 16 11872 2e60 kernel/sys.o
    after: 11096 720 16 11832 2e38 kernel/sys.o

    Acked-by: Vegard Nossum
    Cc: "Eric W. Biederman"
    Acked-by: "Serge E. Hallyn"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • On sethostname() and setdomainname(), previous information may be retained
    if it was longer than than the new hostname/domainname.

    This can be demonstrated trivially by calling sethostname() first with a
    long name, then with a short name, and then calling uname() to retrieve
    the full buffer that contains the hostname (and possibly parts of the old
    hostname), one just has to look past the terminating zero.

    I don't know if we should really care that much (hence the RFC); the only
    scenarios I can possibly think of is administrator putting something
    sensitive in the hostname (or domain name) by accident, and changing it
    back will not undo the mistake entirely, though it's not like we can
    recover gracefully from "rm -rf /" either... The other scenario is
    namespaces (CLONE_NEWUTS) where some information may be unintentionally
    "inherited" from the previous namespace (a program wants to hide the
    original name and does clone + sethostname, but some information is still
    left).

    I think the patch may be defended on grounds of the principle of least
    surprise. But I am not adamant :-)

    (I guess the question now is whether userspace should be able to
    write embedded NULs into the buffer or not...)

    At least the observation has been made and the patch has been presented.

    Signed-off-by: Vegard Nossum
    Cc: "Eric W. Biederman"
    Cc: "Serge E. Hallyn"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vegard Nossum
     
  • When a process wants to set the limit of open files to RLIM_INFINITY it
    gets EPERM even if it has CAP_SYS_RESOURCE capability.

    For example, BIND does:

    ...
    #elif defined(NR_OPEN) && defined(__linux__)
    /*
    * Some Linux kernels don't accept RLIM_INFINIT; the maximum
    * possible value is the NR_OPEN defined in linux/fs.h.
    */
    if (resource == isc_resource_openfiles && rlim_value == RLIM_INFINITY) {
    rl.rlim_cur = rl.rlim_max = NR_OPEN;
    unixresult = setrlimit(unixresource, &rl);
    if (unixresult == 0)
    return (ISC_R_SUCCESS);
    }
    #elif ...

    If we allow setting RLIMIT_NOFILE to RLIM_INFINITY we increase portability
    - you don't have to check if OS is linux and then use different schema for
    limits.

    The spec says "Specifying RLIM_INFINITY as any resource limit value on a
    successful call to setrlimit() shall inhibit enforcement of that resource
    limit." and we're presently not doing that.

    Cc: Michael Kerrisk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adam Tkac
     

14 Oct, 2008

1 commit

  • Introduce a kref to the tty structure and use it to protect the tty->signal
    tty references. For now we don't introduce it for anything else.

    Signed-off-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Alan Cox
     

14 Sep, 2008

1 commit

  • Overview

    This patch reworks the handling of POSIX CPU timers, including the
    ITIMER_PROF, ITIMER_VIRT timers and rlimit handling. It was put together
    with the help of Roland McGrath, the owner and original writer of this code.

    The problem we ran into, and the reason for this rework, has to do with using
    a profiling timer in a process with a large number of threads. It appears
    that the performance of the old implementation of run_posix_cpu_timers() was
    at least O(n*3) (where "n" is the number of threads in a process) or worse.
    Everything is fine with an increasing number of threads until the time taken
    for that routine to run becomes the same as or greater than the tick time, at
    which point things degrade rather quickly.

    This patch fixes bug 9906, "Weird hang with NPTL and SIGPROF."

    Code Changes

    This rework corrects the implementation of run_posix_cpu_timers() to make it
    run in constant time for a particular machine. (Performance may vary between
    one machine and another depending upon whether the kernel is built as single-
    or multiprocessor and, in the latter case, depending upon the number of
    running processors.) To do this, at each tick we now update fields in
    signal_struct as well as task_struct. The run_posix_cpu_timers() function
    uses those fields to make its decisions.

    We define a new structure, "task_cputime," to contain user, system and
    scheduler times and use these in appropriate places:

    struct task_cputime {
    cputime_t utime;
    cputime_t stime;
    unsigned long long sum_exec_runtime;
    };

    This is included in the structure "thread_group_cputime," which is a new
    substructure of signal_struct and which varies for uniprocessor versus
    multiprocessor kernels. For uniprocessor kernels, it uses "task_cputime" as
    a simple substructure, while for multiprocessor kernels it is a pointer:

    struct thread_group_cputime {
    struct task_cputime totals;
    };

    struct thread_group_cputime {
    struct task_cputime *totals;
    };

    We also add a new task_cputime substructure directly to signal_struct, to
    cache the earliest expiration of process-wide timers, and task_cputime also
    replaces the it_*_expires fields of task_struct (used for earliest expiration
    of thread timers). The "thread_group_cputime" structure contains process-wide
    timers that are updated via account_user_time() and friends. In the non-SMP
    case the structure is a simple aggregator; unfortunately in the SMP case that
    simplicity was not achievable due to cache-line contention between CPUs (in
    one measured case performance was actually _worse_ on a 16-cpu system than
    the same test on a 4-cpu system, due to this contention). For SMP, the
    thread_group_cputime counters are maintained as a per-cpu structure allocated
    using alloc_percpu(). The timer functions update only the timer field in
    the structure corresponding to the running CPU, obtained using per_cpu_ptr().

    We define a set of inline functions in sched.h that we use to maintain the
    thread_group_cputime structure and hide the differences between UP and SMP
    implementations from the rest of the kernel. The thread_group_cputime_init()
    function initializes the thread_group_cputime structure for the given task.
    The thread_group_cputime_alloc() is a no-op for UP; for SMP it calls the
    out-of-line function thread_group_cputime_alloc_smp() to allocate and fill
    in the per-cpu structures and fields. The thread_group_cputime_free()
    function, also a no-op for UP, in SMP frees the per-cpu structures. The
    thread_group_cputime_clone_thread() function (also a UP no-op) for SMP calls
    thread_group_cputime_alloc() if the per-cpu structures haven't yet been
    allocated. The thread_group_cputime() function fills the task_cputime
    structure it is passed with the contents of the thread_group_cputime fields;
    in UP it's that simple but in SMP it must also safely check that tsk->signal
    is non-NULL (if it is it just uses the appropriate fields of task_struct) and,
    if so, sums the per-cpu values for each online CPU. Finally, the three
    functions account_group_user_time(), account_group_system_time() and
    account_group_exec_runtime() are used by timer functions to update the
    respective fields of the thread_group_cputime structure.

    Non-SMP operation is trivial and will not be mentioned further.

    The per-cpu structure is always allocated when a task creates its first new
    thread, via a call to thread_group_cputime_clone_thread() from copy_signal().
    It is freed at process exit via a call to thread_group_cputime_free() from
    cleanup_signal().

    All functions that formerly summed utime/stime/sum_sched_runtime values from
    from all threads in the thread group now use thread_group_cputime() to
    snapshot the values in the thread_group_cputime structure or the values in
    the task structure itself if the per-cpu structure hasn't been allocated.

    Finally, the code in kernel/posix-cpu-timers.c has changed quite a bit.
    The run_posix_cpu_timers() function has been split into a fast path and a
    slow path; the former safely checks whether there are any expired thread
    timers and, if not, just returns, while the slow path does the heavy lifting.
    With the dedicated thread group fields, timers are no longer "rebalanced" and
    the process_timer_rebalance() function and related code has gone away. All
    summing loops are gone and all code that used them now uses the
    thread_group_cputime() inline. When process-wide timers are set, the new
    task_cputime structure in signal_struct is used to cache the earliest
    expiration; this is checked in the fast path.

    Performance

    The fix appears not to add significant overhead to existing operations. It
    generally performs the same as the current code except in two cases, one in
    which it performs slightly worse (Case 5 below) and one in which it performs
    very significantly better (Case 2 below). Overall it's a wash except in those
    two cases.

    I've since done somewhat more involved testing on a dual-core Opteron system.

    Case 1: With no itimer running, for a test with 100,000 threads, the fixed
    kernel took 1428.5 seconds, 513 seconds more than the unfixed system,
    all of which was spent in the system. There were twice as many
    voluntary context switches with the fix as without it.

    Case 2: With an itimer running at .01 second ticks and 4000 threads (the most
    an unmodified kernel can handle), the fixed kernel ran the test in
    eight percent of the time (5.8 seconds as opposed to 70 seconds) and
    had better tick accuracy (.012 seconds per tick as opposed to .023
    seconds per tick).

    Case 3: A 4000-thread test with an initial timer tick of .01 second and an
    interval of 10,000 seconds (i.e. a timer that ticks only once) had
    very nearly the same performance in both cases: 6.3 seconds elapsed
    for the fixed kernel versus 5.5 seconds for the unfixed kernel.

    With fewer threads (eight in these tests), the Case 1 test ran in essentially
    the same time on both the modified and unmodified kernels (5.2 seconds versus
    5.8 seconds). The Case 2 test ran in about the same time as well, 5.9 seconds
    versus 5.4 seconds but again with much better tick accuracy, .013 seconds per
    tick versus .025 seconds per tick for the unmodified kernel.

    Since the fix affected the rlimit code, I also tested soft and hard CPU limits.

    Case 4: With a hard CPU limit of 20 seconds and eight threads (and an itimer
    running), the modified kernel was very slightly favored in that while
    it killed the process in 19.997 seconds of CPU time (5.002 seconds of
    wall time), only .003 seconds of that was system time, the rest was
    user time. The unmodified kernel killed the process in 20.001 seconds
    of CPU (5.014 seconds of wall time) of which .016 seconds was system
    time. Really, though, the results were too close to call. The results
    were essentially the same with no itimer running.

    Case 5: With a soft limit of 20 seconds and a hard limit of 2000 seconds
    (where the hard limit would never be reached) and an itimer running,
    the modified kernel exhibited worse tick accuracy than the unmodified
    kernel: .050 seconds/tick versus .028 seconds/tick. Otherwise,
    performance was almost indistinguishable. With no itimer running this
    test exhibited virtually identical behavior and times in both cases.

    In times past I did some limited performance testing. those results are below.

    On a four-cpu Opteron system without this fix, a sixteen-thread test executed
    in 3569.991 seconds, of which user was 3568.435s and system was 1.556s. On
    the same system with the fix, user and elapsed time were about the same, but
    system time dropped to 0.007 seconds. Performance with eight, four and one
    thread were comparable. Interestingly, the timer ticks with the fix seemed
    more accurate: The sixteen-thread test with the fix received 149543 ticks
    for 0.024 seconds per tick, while the same test without the fix received 58720
    for 0.061 seconds per tick. Both cases were configured for an interval of
    0.01 seconds. Again, the other tests were comparable. Each thread in this
    test computed the primes up to 25,000,000.

    I also did a test with a large number of threads, 100,000 threads, which is
    impossible without the fix. In this case each thread computed the primes only
    up to 10,000 (to make the runtime manageable). System time dominated, at
    1546.968 seconds out of a total 2176.906 seconds (giving a user time of
    629.938s). It received 147651 ticks for 0.015 seconds per tick, still quite
    accurate. There is obviously no comparable test without the fix.

    Signed-off-by: Frank Mayhar
    Cc: Roland McGrath
    Cc: Alexey Dobriyan
    Cc: Andrew Morton
    Signed-off-by: Ingo Molnar

    Frank Mayhar
     

06 Sep, 2008

1 commit

  • We want to be able to control the default "rounding" that is used by
    select() and poll() and friends. This is a per process property
    (so that we can have a "nice" like program to start certain programs with
    a looser or stricter rounding) that can be set/get via a prctl().

    For this purpose, a field called "timer_slack_ns" is added to the task
    struct. In addition, a field called "default_timer_slack"ns" is added
    so that tasks easily can temporarily to a more/less accurate slack and then
    back to the default.

    The default value of the slack is set to 50 usec; this is significantly less
    than 2.6.27's average select() and poll() timing error but still allows
    the kernel to group timers somewhat to preserve power behavior. Applications
    and admins can override this via the prctl()

    Signed-off-by: Arjan van de Ven

    Arjan van de Ven
     

21 Aug, 2008

1 commit

  • When user calls sys_setpriority(PRIO_PGRP ...) on a NPTL style multi-LWP
    process, only the task leader of the process is affected, all other
    sibling LWP threads didn't receive the setting. The problem was that the
    iterator used in sys_setpriority() only iteartes over one task for each
    process, ignoring all other sibling thread.

    Introduce a new macro do_each_pid_thread / while_each_pid_thread to walk
    each thread of a process. Convert 4 call sites in {set/get}priority and
    ioprio_{set/get}.

    Signed-off-by: Ken Chen
    Cc: Oleg Nesterov
    Cc: Roland McGrath
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Jens Axboe
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ken Chen
     

15 Aug, 2008

1 commit

  • Call kernel_restart_prepare() in kernel_kexec() instead of duplicating the
    code.

    Signed-off-by: Huang Ying
    Acked-by: Pavel Machek
    Acked-by: Vivek Goyal
    Cc: Pavel Machek
    Cc: "Rafael J. Wysocki"
    Cc: "Eric W. Biederman"
    Cc: Vivek Goyal
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Huang Ying
     

27 Jul, 2008

1 commit

  • This patch provides an enhancement to kexec/kdump. It implements the
    following features:

    - Backup/restore memory used by the original kernel before/after
    kexec.

    - Save/restore CPU state before/after kexec.

    The features of this patch can be used as a general method to call program in
    physical mode (paging turning off). This can be used to call BIOS code under
    Linux.

    kexec-tools needs to be patched to support kexec jump. The patches and
    the precompiled kexec can be download from the following URL:

    source: http://khibernation.sourceforge.net/download/release_v10/kexec-tools/kexec-tools-src_git_kh10.tar.bz2
    patches: http://khibernation.sourceforge.net/download/release_v10/kexec-tools/kexec-tools-patches_git_kh10.tar.bz2
    binary: http://khibernation.sourceforge.net/download/release_v10/kexec-tools/kexec_git_kh10

    Usage example of calling some physical mode code and return:

    1. Compile and install patched kernel with following options selected:

    CONFIG_X86_32=y
    CONFIG_KEXEC=y
    CONFIG_PM=y
    CONFIG_KEXEC_JUMP=y

    2. Build patched kexec-tool or download the pre-built one.

    3. Build some physical mode executable named such as "phy_mode"

    4. Boot kernel compiled in step 1.

    5. Load physical mode executable with /sbin/kexec. The shell command
    line can be as follow:

    /sbin/kexec --load-preserve-context --args-none phy_mode

    6. Call physical mode executable with following shell command line:

    /sbin/kexec -e

    Implementation point:

    To support jumping without reserving memory. One shadow backup page (source
    page) is allocated for each page used by kexeced code image (destination
    page). When do kexec_load, the image of kexeced code is loaded into source
    pages, and before executing, the destination pages and the source pages are
    swapped, so the contents of destination pages are backupped. Before jumping
    to the kexeced code image and after jumping back to the original kernel, the
    destination pages and the source pages are swapped too.

    C ABI (calling convention) is used as communication protocol between
    kernel and called code.

    A flag named KEXEC_PRESERVE_CONTEXT for sys_kexec_load is added to
    indicate that the loaded kernel image is used for jumping back.

    Now, only the i386 architecture is supported.

    Signed-off-by: Huang Ying
    Acked-by: Vivek Goyal
    Cc: "Eric W. Biederman"
    Cc: Pavel Machek
    Cc: Nigel Cunningham
    Cc: "Rafael J. Wysocki"
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Huang Ying
     

26 Jul, 2008

2 commits

  • With the removal of the Solaris binary emulation the export of
    uts_sem became unused.

    Signed-off-by: Adrian Bunk
    Acked-by: David S. Miller
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     
  • Presently call_usermodehelper_setup() uses GFP_ATOMIC. but it can return
    NULL _very_ easily.

    GFP_ATOMIC is needed only when we can't sleep. and, GFP_KERNEL is robust
    and better.

    thus, I add gfp_mask argument to call_usermodehelper_setup().

    So, its callers pass the gfp_t as below:

    call_usermodehelper() and call_usermodehelper_keys():
    depend on 'wait' argument.
    call_usermodehelper_pipe():
    always GFP_KERNEL because always run under process context.
    orderly_poweroff():
    pass to GFP_ATOMIC because may run under interrupt context.

    Signed-off-by: KOSAKI Motohiro
    Cc: "Paul Menage"
    Reviewed-by: Li Zefan
    Acked-by: Jeremy Fitzhardinge
    Cc: Rusty Russell
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KOSAKI Motohiro
     

25 May, 2008

1 commit

  • If none of the switch cases match, the PR_SET_PDEATHSIG and
    PR_SET_DUMPABLE cases of the switch statement will never write to local
    variable `error'.

    Signed-off-by: Shi Weihua
    Cc: Andrew G. Morgan
    Acked-by: "Serge E. Hallyn"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Shi Weihua
     

30 Apr, 2008

4 commits

  • 1. sys_getpgid() needs rcu_read_lock() to derive the pgrp _nr, even if
    the task is current, otherwise we can race with another thread which
    does sys_setpgid().

    2. Use rcu_read_lock() instead of tasklist_lock when pid != 0, make sure
    that we don't use the NULL pid if the task exits right after successful
    find_task_by_vpid().

    Signed-off-by: Oleg Nesterov
    Cc: Roland McGrath
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oleg Nesterov
     
  • 1. sys_getsid() needs rcu_read_lock() to derive the session _nr, even if
    the task is current, otherwise we can race with another thread which
    does sys_setsid().

    2. The task can exit between find_task_by_vpid() and task_session_vnr(),
    in that unlikely case sys_getsid() returns 0 instead of -ESRCH.

    Signed-off-by: Oleg Nesterov
    Cc: Roland McGrath
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oleg Nesterov
     
  • Use change_pid() instead of detach_pid() + attach_pid() in sys_setpgid().

    This way task_pgrp() is not NULL in between.

    Signed-off-by: Oleg Nesterov
    Cc: "Eric W. Biederman"
    Cc: Pavel Emelyanov
    Cc: Roland McGrath
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oleg Nesterov
     
  • Just a trivial example, more to come.

    k_getrusage() holds rcu_read_lock() because it was previously required by
    lock_task_sighand(). Unneeded now.

    Signed-off-by: Oleg Nesterov
    Cc: "Eric W. Biederman"
    Cc: "Paul E. McKenney"
    Cc: Roland McGrath
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oleg Nesterov
     

29 Apr, 2008

1 commit

  • Add the RUSAGE_THREAD option for the getrusage system call. This is
    essentially Roland's patch from http://lkml.org/lkml/2008/1/18/589, but the
    line about RUSAGE_LWP line has been removed, as suggested by Ulrich and
    Christoph.

    Signed-off-by: Roland McGrath
    Signed-off-by: Sripathi Kodi
    Cc: Ingo Molnar
    Cc: Michael Kerrisk
    Cc: Ulrich Drepper
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sripathi Kodi
     

28 Apr, 2008

1 commit

  • Filesystem capability support makes it possible to do away with (set)uid-0
    based privilege and use capabilities instead. That is, with filesystem
    support for capabilities but without this present patch, it is (conceptually)
    possible to manage a system with capabilities alone and never need to obtain
    privilege via (set)uid-0.

    Of course, conceptually isn't quite the same as currently possible since few
    user applications, certainly not enough to run a viable system, are currently
    prepared to leverage capabilities to exercise privilege. Further, many
    applications exist that may never get upgraded in this way, and the kernel
    will continue to want to support their setuid-0 base privilege needs.

    Where pure-capability applications evolve and replace setuid-0 binaries, it is
    desirable that there be a mechanisms by which they can contain their
    privilege. In addition to leveraging the per-process bounding and inheritable
    sets, this should include suppressing the privilege of the uid-0 superuser
    from the process' tree of children.

    The feature added by this patch can be leveraged to suppress the privilege
    associated with (set)uid-0. This suppression requires CAP_SETPCAP to
    initiate, and only immediately affects the 'current' process (it is inherited
    through fork()/exec()). This reimplementation differs significantly from the
    historical support for securebits which was system-wide, unwieldy and which
    has ultimately withered to a dead relic in the source of the modern kernel.

    With this patch applied a process, that is capable(CAP_SETPCAP), can now drop
    all legacy privilege (through uid=0) for itself and all subsequently
    fork()'d/exec()'d children with:

    prctl(PR_SET_SECUREBITS, 0x2f);

    This patch represents a no-op unless CONFIG_SECURITY_FILE_CAPABILITIES is
    enabled at configure time.

    [akpm@linux-foundation.org: fix uninitialised var warning]
    [serue@us.ibm.com: capabilities: use cap_task_prctl when !CONFIG_SECURITY]
    Signed-off-by: Andrew G. Morgan
    Acked-by: Serge Hallyn
    Reviewed-by: James Morris
    Cc: Stephen Smalley
    Cc: Paul Moore
    Signed-off-by: Serge E. Hallyn
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew G. Morgan
     

20 Apr, 2008

1 commit


09 Feb, 2008

7 commits

  • Some time ago the xxx_vnr() calls (e.g. pid_vnr or find_task_by_vpid) were
    _all_ converted to operate on the current pid namespace. After this each call
    like xxx_nr_ns(foo, current->nsproxy->pid_ns) is nothing but a xxx_vnr(foo)
    one.

    Switch all the xxx_nr_ns() callers to use the xxx_vnr() calls where
    appropriate.

    Signed-off-by: Pavel Emelyanov
    Reviewed-by: Oleg Nesterov
    Cc: "Eric W. Biederman"
    Cc: Balbir Singh
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Emelyanov
     
  • With the new semantics of find_vpid() we don't need to play with ->nsproxy
    explicitely, _vxx() do the right things.

    Also s/tasklist/rcu/.

    Signed-off-by: Oleg Nesterov
    Cc: "Eric W. Biederman"
    Cc: Pavel Emelyanov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oleg Nesterov
     
  • Eric's "fix clone(CLONE_NEWPID)" eliminated the last reason for this hack.

    Signed-off-by: Oleg Nesterov
    Cc: "Eric W. Biederman"
    Cc: Roland McGrath
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oleg Nesterov
     
  • As Eric pointed out, there is no problem with init starting with sid == pgid
    == 0, and this was historical linux behavior changed in 2.6.18.

    Remove kernel_init()->__set_special_pids(), this is unneeded and complicates
    the rules for sys_setsid().

    This change and the previous change in daemonize() mean that /sbin/init does
    not need the special "session != 1" hack in sys_setsid() any longer. We can't
    remove this check yet, we should cleanup copy_process(CLONE_NEWPID) first, so
    update the comment only.

    Signed-off-by: Oleg Nesterov
    Acked-by: "Eric W. Biederman"
    Cc: Pavel Emelyanov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oleg Nesterov
     
  • Change set_special_pids() to work with struct pid, not pid_t from global name
    space. This again speedups and imho cleanups the code, also a preparation for
    the next patch.

    Signed-off-by: Oleg Nesterov
    Acked-by: "Eric W. Biederman"
    Acked-by: Pavel Emelyanov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oleg Nesterov
     
  • sys_setsid() still deals with pid_t's from the global namespace. This means
    that the "session > 1" check can't help for sub-namespace init, setsid() can't
    succeed because copy_process(CLONE_NEWPID) populates PIDTYPE_PGID/SID links.

    Remove the usage of task_struct->pid and convert the code to use "struct pid".
    This also simplifies and speedups the code, saves one find_pid().

    Signed-off-by: Oleg Nesterov
    Cc: "Eric W. Biederman"
    Acked-by: Pavel Emelyanov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oleg Nesterov
     
  • sys_setpgid() does unneeded conversions from pid_t to "struct pid" and vice
    versa. Use "struct pid" more consistently. Saves one find_vpid() and
    eliminates the explicit usage of ->nsproxy->pid_ns. Imho, cleanups the
    code.

    Also use the same_thread_group() helper.

    Signed-off-by: Oleg Nesterov
    Acked-by: Pavel Emelyanov
    Acked-by: "Eric W. Biederman"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oleg Nesterov