Eric Lee / smarc-fsl-linux-kernel

10 Aug, 2018

1 commit

  • c3ad2c3b0   signal: Don't restart fork when signals come in. ... Browse Code »

    Wen Yang and majiang
    report that a periodic signal received during fork can cause fork to
    continually restart preventing an application from making progress.

    The code was being overly pessimistic. Fork needs to guarantee that a
    signal sent to multiple processes is logically delivered before the
    fork and just to the forking process or logically delivered after the
    fork to both the forking process and it's newly spawned child. For
    signals like periodic timers that are always delivered to a single
    process fork can safely complete and let them appear to logically
    delivered after the fork().

    While examining this issue I also discovered that fork today will miss
    signals delivered to multiple processes during the fork and handled by
    another thread. Similarly the current code will also miss blocked
    signals that are delivered to multiple process, as those signals will
    not appear pending during fork.

    Add a list of each thread that is currently forking, and keep on that
    list a signal set that records all of the signals sent to multiple
    processes. When fork completes initialize the new processes
    shared_pending signal set with it. The calculate_sigpending function
    will see those signals and set TIF_SIGPENDING causing the new task to
    take the slow path to userspace to handle those signals. Making it
    appear as if those signals were received immediately after the fork.

    It is not possible to send real time signals to multiple processes and
    exceptions don't go to multiple processes, which means that that are
    no signals sent to multiple processes that require siginfo. This
    means it is safe to not bother collecting siginfo on signals sent
    during fork.

    The sigaction of a child of fork is initially the same as the
    sigaction of the parent process. So a signal the parent ignores the
    child will also initially ignore. Therefore it is safe to ignore
    signals sent to multiple processes and ignored by the forking process.

    Signals sent to only a single process or only a single thread and delivered
    during fork are treated as if they are received after the fork, and generally
    not dealt with. They won't cause any problems.

    V2: Added removal from the multiprocess list on failure.
    V3: Use -ERESTARTNOINTR directly
    V4: - Don't queue both SIGCONT and SIGSTOP
    - Initialize signal_struct.multiprocess in init_task
    - Move setting of shared_pending to before the new task
    is visible to signals. This prevents signals from comming
    in before shared_pending.signal is set to delayed.signal
    and being lost.
    V5: - rework list add and delete to account for idle threads
    v6: - Use sigdelsetmask when removing stop signals

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200447
    Reported-by: Wen Yang and
    Reported-by: majiang
    Fixes: 4a2c7a7837da ("[PATCH] make fork() atomic wrt pgrp/session signals")
    Signed-off-by: "Eric W. Biederman"

    Eric W. Biederman
     

21 Jul, 2018

3 commits

  • 6883f81aa   pid: Implement PIDTYPE_TGID ... Browse Code »

    Everywhere except in the pid array we distinguish between a tasks pid and
    a tasks tgid (thread group id). Even in the enumeration we want that
    distinction sometimes so we have added __PIDTYPE_TGID. With leader_pid
    we almost have an implementation of PIDTYPE_TGID in struct signal_struct.

    Add PIDTYPE_TGID as a first class member of the pid_type enumeration and
    into the pids array. Then remove the __PIDTYPE_TGID special case and the
    leader_pid in signal_struct.

    The net size increase is just an extra pointer added to struct pid and
    an extra pair of pointers of an hlist_node added to task_struct.

    The effect on code maintenance is the removal of a number of special
    cases today and the potential to remove many more special cases as
    PIDTYPE_TGID gets used to it's fullest. The long term potential
    is allowing zombie thread group leaders to exit, which will remove
    a lot more special cases in the code.

    Signed-off-by: "Eric W. Biederman"

    Eric W. Biederman
     
  • 2c4704756   pids: Move the pgrp and session pid pointers from task_struct to signal_struct ... Browse Code »

    To access these fields the code always has to go to group leader so
    going to signal struct is no loss and is actually a fundamental simplification.

    This saves a little bit of memory by only allocating the pid pointer array
    once instead of once for every thread, and even better this removes a
    few potential races caused by the fact that group_leader can be changed
    by de_thread, while signal_struct can not.

    Signed-off-by: "Eric W. Biederman"

    Eric W. Biederman
     
  • 2896b0f09   pids: Initialize leader_pid in init_task ... Browse Code »

    This is cheap and no cost so we might as well.

    Signed-off-by: "Eric W. Biederman"

    Eric W. Biederman
     

15 May, 2018

1 commit

17 Jan, 2018

3 commits

10 Jan, 2018

1 commit

  • 0500871f2   Construct init thread stack in the linker script rather than by union ... Browse Code »

    Construct the init thread stack in the linker script rather than doing it
    by means of a union so that ia64's init_task.c can be got rid of.

    The following symbols are then made available from INIT_TASK_DATA() linker
    script macro:

    init_thread_union
    init_stack

    INIT_TASK_DATA() also expands the region to THREAD_SIZE to accommodate the
    size of the init stack. init_thread_union is given its own section so that
    it can be placed into the stack space in the right order. I'm assuming
    that the ia64 ordering is correct and that the task_struct is first and the
    thread_info second.

    Signed-off-by: David Howells
    Tested-by: Tony Luck
    Tested-by: Will Deacon (arm64)
    Tested-by: Palmer Dabbelt
    Acked-by: Thomas Gleixner

    David Howells
     

02 Nov, 2017

1 commit

  • b24413180   License cleanup: add SPDX GPL-2.0 license identifier to files with no license ... Browse Code »

    Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

02 Mar, 2017

1 commit

25 Dec, 2016

1 commit

15 Sep, 2016

1 commit

  • c65eacbe2   sched/core: Allow putting thread_info into task_struct ... Browse Code »

    If an arch opts in by setting CONFIG_THREAD_INFO_IN_TASK_STRUCT,
    then thread_info is defined as a single 'u32 flags' and is the first
    entry of task_struct. thread_info::task is removed (it serves no
    purpose if thread_info is embedded in task_struct), and
    thread_info::cpu gets its own slot in task_struct.

    This is heavily based on a patch written by Linus.

    Originally-from: Linus Torvalds
    Signed-off-by: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: Denys Vlasenko
    Cc: H. Peter Anvin
    Cc: Jann Horn
    Cc: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/a0898196f0476195ca02713691a5037a14f2aac5.1473801993.git.luto@kernel.org
    Signed-off-by: Ingo Molnar

    Andy Lutomirski
     

08 Feb, 2013

2 commits

  • 8bd75c77b   sched/rt: Move rt specific bits into new header file ... Browse Code »

    Move rt scheduler definitions out of include/linux/sched.h into
    new file include/linux/sched/rt.h

    Signed-off-by: Clark Williams
    Cc: Peter Zijlstra
    Cc: Steven Rostedt
    Link: http://lkml.kernel.org/r/20130207094707.7b9f825f@riff.lan
    Signed-off-by: Ingo Molnar

    Clark Williams
     
  • cf4aebc29   sched: Move sched.h sysctl bits into separate header ... Browse Code »

    Move the sysctl-related bits from include/linux/sched.h into
    a new file: include/linux/sched/sysctl.h. Then update source
    files requiring access to those bits by including the new
    header file.

    Signed-off-by: Clark Williams
    Cc: Peter Zijlstra
    Cc: Steven Rostedt
    Link: http://lkml.kernel.org/r/20130207094659.06dced96@riff.lan
    Signed-off-by: Ingo Molnar

    Clark Williams
     

05 May, 2012

1 commit

  • a4a2eb490   init_task: Create generic init_task instance ... Browse Code »

    All archs define init_task in the same way (except ia64, but there is
    no particular reason why ia64 cannot use the common version). Create a
    generic instance so all archs can be converted over.

    The config switch is temporary and will be removed when all archs are
    converted over.

    Signed-off-by: Thomas Gleixner
    Cc: Benjamin Herrenschmidt
    Cc: Chen Liqin
    Cc: Chris Metcalf
    Cc: Chris Zankel
    Cc: David Howells
    Cc: David S. Miller
    Cc: Geert Uytterhoeven
    Cc: Guan Xuetao
    Cc: Haavard Skinnemoen
    Cc: Hirokazu Takata
    Cc: James E.J. Bottomley
    Cc: Jesper Nilsson
    Cc: Jonas Bonn
    Cc: Mark Salter
    Cc: Martin Schwidefsky
    Cc: Heiko Carstens
    Cc: Matt Turner
    Cc: Michal Simek
    Cc: Mike Frysinger
    Cc: Paul Mundt
    Cc: Ralf Baechle
    Cc: Richard Kuo
    Cc: Richard Weinberger
    Cc: Russell King
    Cc: Yoshinori Sato
    Link: http://lkml.kernel.org/r/20120503085034.092585287@linutronix.de

    Thomas Gleixner