07 Nov, 2011

1 commit

  • * 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: (230 commits)
    Revert "tracing: Include module.h in define_trace.h"
    irq: don't put module.h into irq.h for tracking irqgen modules.
    bluetooth: macroize two small inlines to avoid module.h
    ip_vs.h: fix implicit use of module_get/module_put from module.h
    nf_conntrack.h: fix up fallout from implicit moduleparam.h presence
    include: replace linux/module.h with "struct module" wherever possible
    include: convert various register fcns to macros to avoid include chaining
    crypto.h: remove unused crypto_tfm_alg_modname() inline
    uwb.h: fix implicit use of asm/page.h for PAGE_SIZE
    pm_runtime.h: explicitly requires notifier.h
    linux/dmaengine.h: fix implicit use of bitmap.h and asm/page.h
    miscdevice.h: fix up implicit use of lists and types
    stop_machine.h: fix implicit use of smp.h for smp_processor_id
    of: fix implicit use of errno.h in include/linux/of.h
    of_platform.h: delete needless include
    acpi: remove module.h include from platform/aclinux.h
    miscdevice.h: delete unnecessary inclusion of module.h
    device_cgroup.h: delete needless include
    net: sch_generic remove redundant use of
    net: inet_timewait_sock doesnt need
    ...

    Fix up trivial conflicts (other header files, and removal of the ab3550 mfd driver) in
    - drivers/media/dvb/frontends/dibx000_common.c
    - drivers/media/video/{mt9m111.c,ov6650.c}
    - drivers/mfd/ab3550-core.c
    - include/linux/dmaengine.h

    Linus Torvalds
     

05 Nov, 2011

1 commit

  • …ASK_KILLABLE tasks too"

    Commit 27920651fe "PM / Freezer: Make fake_signal_wake_up() wake
    TASK_KILLABLE tasks too" updated fake_signal_wake_up() used by freezer
    to wake up KILLABLE tasks. Sending unsolicited wakeups to tasks in
    killable sleep is dangerous as there are code paths which depend on
    tasks not waking up spuriously from KILLABLE sleep.

    For example. sys_read() or page can sleep in TASK_KILLABLE assuming
    that wait/down/whatever _killable can only fail if we can not return
    to the usermode. TASK_TRACED is another obvious example.

    The previous patch updated wait_event_freezekillable() such that it
    doesn't depend on the spurious wakeup. This patch reverts the
    offending commit.

    Note that the spurious KILLABLE wakeup had other implicit effects in
    KILLABLE sleeps in nfs and cifs and those will need further updates to
    regain freezekillable behavior.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

    Tejun Heo
     

31 Oct, 2011

1 commit

  • The changed files were only including linux/module.h for the
    EXPORT_SYMBOL infrastructure, and nothing else. Revector them
    onto the isolated export header for faster compile times.

    Nothing to see here but a whole lot of instances of:

    -#include
    +#include

    This commit is only changing the kernel dir; next targets
    will probably be mm, fs, the arch dirs, etc.

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

17 Oct, 2011

1 commit

  • TASK_KILLABLE is often used to put tasks to sleep for quite some time.
    One of the most common uses is to put tasks to sleep while waiting for
    replies from a server on a networked filesystem (such as CIFS or NFS).

    Unfortunately, fake_signal_wake_up does not currently wake up tasks
    that are sleeping in TASK_KILLABLE state. This means that even if the
    code were in place to allow them to freeze while in this sleep, it
    wouldn't work anyway.

    This patch changes this function to wake tasks in this state as well.
    This should be harmless -- if the code doing the sleeping doesn't have
    handling to deal with freezer events, it should just go back to sleep.
    If it does, then this will allow that code to do the right thing.

    Signed-off-by: Jeff Layton
    Signed-off-by: Rafael J. Wysocki

    Jeff Layton
     

18 May, 2011

1 commit

  • The freezer processes are dealing with multiple threads running
    simultaneously, and on a UP system, the memory reads/writes do
    not need barriers to keep things in sync. These are only needed
    on SMP systems, so use SMP barriers instead.

    Signed-off-by: Mike Frysinger
    Acked-by: Pavel Machek
    Signed-off-by: Rafael J. Wysocki

    Mike Frysinger
     

24 Dec, 2010

1 commit

  • After calling freeze_task(), try_to_freeze_tasks() see whether the
    task is stopped or traced and if so, considers it to be frozen;
    however, nothing guarantees that either the task being frozen sees
    TIF_FREEZE or the freezer sees TASK_STOPPED -> TASK_RUNNING
    transition. The task being frozen may wake up and not see TIF_FREEZE
    while the freezer fails to notice the transition and believes the task
    is still stopped.

    This patch fixes the race by making freeze_task() always go through
    fake_signal_wake_up() for applicable tasks. The function goes through
    the target task's scheduler lock and thus guarantees that either the
    target sees TIF_FREEZE or try_to_freeze_task() sees TASK_RUNNING.

    Signed-off-by: Tejun Heo
    Signed-off-by: Rafael J. Wysocki

    Tejun Heo
     

18 Jul, 2009

1 commit

  • commit e3c8ca8336 (sched: do not count frozen tasks toward load) broke
    the nr_uninterruptible accounting on freeze/thaw. On freeze the task
    is excluded from accounting with a check for (task->flags &
    PF_FROZEN), but that flag is cleared before the task is thawed. So
    while we prevent that the task with state TASK_UNINTERRUPTIBLE
    is accounted to nr_uninterruptible on freeze we decrement
    nr_uninterruptible on thaw.

    Use a separate flag which is handled by the freezing task itself. Set
    it before calling the scheduler with TASK_UNINTERRUPTIBLE state and
    clear it after we return from frozen state.

    Cc:
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

31 Oct, 2008

1 commit


20 Oct, 2008

2 commits

  • This patch implements a new freezer subsystem in the control groups
    framework. It provides a way to stop and resume execution of all tasks in
    a cgroup by writing in the cgroup filesystem.

    The freezer subsystem in the container filesystem defines a file named
    freezer.state. Writing "FROZEN" to the state file will freeze all tasks
    in the cgroup. Subsequently writing "RUNNING" will unfreeze the tasks in
    the cgroup. Reading will return the current state.

    * Examples of usage :

    # mkdir /containers/freezer
    # mount -t cgroup -ofreezer freezer /containers
    # mkdir /containers/0
    # echo $some_pid > /containers/0/tasks

    to get status of the freezer subsystem :

    # cat /containers/0/freezer.state
    RUNNING

    to freeze all tasks in the container :

    # echo FROZEN > /containers/0/freezer.state
    # cat /containers/0/freezer.state
    FREEZING
    # cat /containers/0/freezer.state
    FROZEN

    to unfreeze all tasks in the container :

    # echo RUNNING > /containers/0/freezer.state
    # cat /containers/0/freezer.state
    RUNNING

    This is the basic mechanism which should do the right thing for user space
    task in a simple scenario.

    It's important to note that freezing can be incomplete. In that case we
    return EBUSY. This means that some tasks in the cgroup are busy doing
    something that prevents us from completely freezing the cgroup at this
    time. After EBUSY, the cgroup will remain partially frozen -- reflected
    by freezer.state reporting "FREEZING" when read. The state will remain
    "FREEZING" until one of these things happens:

    1) Userspace cancels the freezing operation by writing "RUNNING" to
    the freezer.state file
    2) Userspace retries the freezing operation by writing "FROZEN" to
    the freezer.state file (writing "FREEZING" is not legal
    and returns EIO)
    3) The tasks that blocked the cgroup from entering the "FROZEN"
    state disappear from the cgroup's set of tasks.

    [akpm@linux-foundation.org: coding-style fixes]
    [akpm@linux-foundation.org: export thaw_process]
    Signed-off-by: Cedric Le Goater
    Signed-off-by: Matt Helsley
    Acked-by: Serge E. Hallyn
    Tested-by: Matt Helsley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matt Helsley
     
  • Now that the TIF_FREEZE flag is available in all architectures, extract
    the refrigerator() and freeze_task() from kernel/power/process.c and make
    it available to all.

    The refrigerator() can now be used in a control group subsystem
    implementing a control group freezer.

    Signed-off-by: Cedric Le Goater
    Signed-off-by: Matt Helsley
    Acked-by: Serge E. Hallyn
    Tested-by: Matt Helsley
    Cc: "Rafael J. Wysocki"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matt Helsley