08 May, 2020

3 commits

  • There is and has been for a very long time been a lot more going on in
    flush_old_exec than just flushing the old state. After the movement
    of code from setup_new_exec there is a whole lot more going on than
    just flushing the old executables state.

    Rename flush_old_exec to begin_new_exec to more accurately reflect
    what this function does.

    Reviewed-by: Kees Cook
    Reviewed-by: Greg Ungerer
    Signed-off-by: "Eric W. Biederman"

    Eric W. Biederman
     
  • The two functions are now always called one right after the
    other so merge them together to make future maintenance easier.

    Reviewed-by: Kees Cook
    Reviewed-by: Greg Ungerer
    Signed-off-by: "Eric W. Biederman"

    Eric W. Biederman
     
  • In 2016 Linus moved install_exec_creds immediately after
    setup_new_exec, in binfmt_elf as a cleanup and as part of closing a
    potential information leak.

    Perform the same cleanup for the other binary formats.

    Different binary formats doing the same things the same way makes exec
    easier to reason about and easier to maintain.

    Greg Ungerer reports:
    > I tested the the whole series on non-MMU m68k and non-MMU arm
    > (exercising binfmt_flat) and it all tested out with no problems,
    > so for the binfmt_flat changes:
    Tested-by: Greg Ungerer

    Ref: 9f834ec18def ("binfmt_elf: switch to new creds when switching to new mm")
    Reviewed-by: Kees Cook
    Reviewed-by: Greg Ungerer
    Signed-off-by: "Eric W. Biederman"

    Eric W. Biederman
     

21 May, 2019

1 commit

  • Add SPDX license identifiers to all files which:

    - Have no license information of any form

    - Have MODULE_LICENCE("GPL*") inside which was used in the initial
    scan/conversion to ignore the file

    These files fall under the project license, GPL v2 only. The resulting SPDX
    license identifier is:

    GPL-2.0-only

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

06 Mar, 2019

1 commit

  • We're (finally) phasing out a.out support for good. As Borislav Petkov
    points out, we've supported ELF binaries for about 25 years by now, and
    coredumping in particular has bitrotted over the years.

    None of the tool chains even support generating a.out binaries any more,
    and the plan is to deprecate a.out support entirely for the kernel. But
    I want to start with just removing the core dumping code, because I can
    still imagine that somebody actually might want to support a.out as a
    simpler biinary format.

    Particularly if you generate some random binaries on the fly, ELF is a
    much more complicated format (admittedly ELF also does have a lot of
    toolchain support, mitigating that complexity a lot and you really
    should have moved over in the last 25 years).

    So it's at least somewhat possible that somebody out there has some
    workflow that still involves generating and running a.out executables.

    In contrast, it's very unlikely that anybody depends on debugging any
    legacy a.out core files. But regardless, I want this phase-out to be
    done in two steps, so that we can resurrect a.out support (if needed)
    without having to resurrect the core file dumping that is almost
    certainly not needed.

    Jann Horn pointed to the file that my first trivial
    cut at this had missed.

    And Alan Cox points out that the a.out binary loader _could_ be done in
    user space if somebody wants to, but we might keep just the loader in
    the kernel if somebody really wants it, since the loader isn't that big
    and has no really odd special cases like the core dumping does.

    Acked-by: Borislav Petkov
    Cc: Alan Cox
    Cc: Jann Horn
    Cc: Richard Weinberger
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

04 Jan, 2019

1 commit

  • Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
    of the user address range verification function since we got rid of the
    old racy i386-only code to walk page tables by hand.

    It existed because the original 80386 would not honor the write protect
    bit when in kernel mode, so you had to do COW by hand before doing any
    user access. But we haven't supported that in a long time, and these
    days the 'type' argument is a purely historical artifact.

    A discussion about extending 'user_access_begin()' to do the range
    checking resulted this patch, because there is no way we're going to
    move the old VERIFY_xyz interface to that model. And it's best done at
    the end of the merge window when I've done most of my merges, so let's
    just get this done once and for all.

    This patch was mostly done with a sed-script, with manual fix-ups for
    the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.

    There were a couple of notable cases:

    - csky still had the old "verify_area()" name as an alias.

    - the iter_iov code had magical hardcoded knowledge of the actual
    values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
    really used it)

    - microblaze used the type argument for a debug printout

    but other than those oddities this should be a total no-op patch.

    I tried to fix up all architectures, did fairly extensive grepping for
    access_ok() uses, and the changes are trivial, but I may have missed
    something. Any missed conversion should be trivially fixable, though.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

12 Apr, 2018

1 commit

  • Provide a final callback into fs/exec.c before start_thread() takes
    over, to handle any last-minute changes, like the coming restoration of
    the stack limit.

    Link: http://lkml.kernel.org/r/1518638796-20819-3-git-send-email-keescook@chromium.org
    Signed-off-by: Kees Cook
    Cc: Andy Lutomirski
    Cc: Ben Hutchings
    Cc: Ben Hutchings
    Cc: Brad Spengler
    Cc: Greg KH
    Cc: Hugh Dickins
    Cc: "Jason A. Donenfeld"
    Cc: Laura Abbott
    Cc: Michal Hocko
    Cc: Oleg Nesterov
    Cc: Rik van Riel
    Cc: Willy Tarreau
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kees Cook
     

05 Sep, 2017

1 commit

  • Use proper ssize_t and size_t types for the return value and count
    argument, move the offset last and make it an in/out argument like
    all other read/write helpers, and make the buf argument a void pointer
    to get rid of lots of casts in the callers.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Al Viro

    Christoph Hellwig
     

02 Mar, 2017

1 commit


25 Dec, 2016

1 commit


29 May, 2016

1 commit

  • Various builds (such as i386:allmodconfig) fail with

    fs/binfmt_aout.c:133:2: error: expected identifier or '(' before 'return'
    fs/binfmt_aout.c:134:1: error: expected identifier or '(' before '}' token

    [ Oops. My bad, I had stupidly thought that "allmodconfig" covered this
    on x86-64 too, but it obviously doesn't. Egg on my face. - Linus ]

    Fixes: 5d22fc25d4fc ("mm: remove more IS_ERR_VALUE abuses")
    Signed-off-by: Guenter Roeck
    Signed-off-by: Linus Torvalds

    Guenter Roeck
     

28 May, 2016

1 commit

  • The do_brk() and vm_brk() return value was "unsigned long" and returned
    the starting address on success, and an error value on failure. The
    reasons are entirely historical, and go back to it basically behaving
    like the mmap() interface does.

    However, nobody actually wanted that interface, and it causes totally
    pointless IS_ERR_VALUE() confusion.

    What every single caller actually wants is just the simpler integer
    return of zero for success and negative error number on failure.

    So just convert to that much clearer and more common calling convention,
    and get rid of all the IS_ERR_VALUE() uses wrt vm_brk().

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

24 May, 2016

1 commit

  • vm_brk is allowed to fail but load_aout_binary simply ignores the error
    and happily continues. I haven't noticed any problem from that in real
    life but later patches will make the failure more likely because vm_brk
    will become killable (resp. mmap_sem for write waiting will become
    killable) so we should be more careful now.

    The error handling should be quite straightforward because there are
    calls to vm_mmap which check the error properly already. The only
    notable exception is set_brk which is called after beyond_if label. But
    nothing indicates that we cannot move it above set_binfmt as the two do
    not depend on each other and fail before we do set_binfmt and alter
    reference counting.

    Signed-off-by: Michal Hocko
    Acked-by: Vlastimil Babka
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"
    Cc: Alexander Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michal Hocko
     

20 Nov, 2014

1 commit


09 Oct, 2014

1 commit


09 Nov, 2013

2 commits


25 Oct, 2013

1 commit


11 Jul, 2013

1 commit

  • Since all architectures have been converted to use vm_unmapped_area(),
    there is no remaining use for the free_area_cache.

    Signed-off-by: Michel Lespinasse
    Acked-by: Rik van Riel
    Cc: "James E.J. Bottomley"
    Cc: "Luck, Tony"
    Cc: Benjamin Herrenschmidt
    Cc: David Howells
    Cc: Helge Deller
    Cc: Ivan Kokshaysky
    Cc: Matt Turner
    Cc: Paul Mackerras
    Cc: Richard Henderson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michel Lespinasse
     

02 May, 2013

1 commit

  • Pull VFS updates from Al Viro,

    Misc cleanups all over the place, mainly wrt /proc interfaces (switch
    create_proc_entry to proc_create(), get rid of the deprecated
    create_proc_read_entry() in favor of using proc_create_data() and
    seq_file etc).

    7kloc removed.

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (204 commits)
    don't bother with deferred freeing of fdtables
    proc: Move non-public stuff from linux/proc_fs.h to fs/proc/internal.h
    proc: Make the PROC_I() and PDE() macros internal to procfs
    proc: Supply a function to remove a proc entry by PDE
    take cgroup_open() and cpuset_open() to fs/proc/base.c
    ppc: Clean up scanlog
    ppc: Clean up rtas_flash driver somewhat
    hostap: proc: Use remove_proc_subtree()
    drm: proc: Use remove_proc_subtree()
    drm: proc: Use minor->index to label things, not PDE->name
    drm: Constify drm_proc_list[]
    zoran: Don't print proc_dir_entry data in debug
    reiserfs: Don't access the proc_dir_entry in r_open(), r_start() r_show()
    proc: Supply an accessor for getting the data from a PDE's parent
    airo: Use remove_proc_subtree()
    rtl8192u: Don't need to save device proc dir PDE
    rtl8187se: Use a dir under /proc/net/r8180/
    proc: Add proc_mkdir_data()
    proc: Move some bits from linux/proc_fs.h to linux/{of.h,signal.h,tty.h}
    proc: Move PDE_NET() to fs/proc/proc_net.c
    ...

    Linus Torvalds
     

01 May, 2013

1 commit

  • Cleanup. Every linux_binfmt->core_dump() sets PF_DUMPCORE, move this into
    zap_threads() called by do_coredump().

    Signed-off-by: Oleg Nesterov
    Acked-by: Mandeep Singh Baines
    Cc: Neil Horman
    Cc: "Rafael J. Wysocki"
    Cc: Tejun Heo
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oleg Nesterov
     

30 Apr, 2013

1 commit

  • switch binfmts that use ->read() to that (and to kernel_read()
    in several cases in binfmt_flat - sure, it's nommu, but still,
    doing ->read() into kmalloc'ed buffer...)

    Signed-off-by: Al Viro

    Al Viro
     

23 Feb, 2013

1 commit


29 Nov, 2012

1 commit


06 Oct, 2012

2 commits

  • This is a preparatory patch for the introduction of NT_SIGINFO elf note.

    With this patch we pass "siginfo_t *siginfo" instead of "int signr" to
    do_coredump() and put it into coredump_params. It will be used by the
    next patch. Most changes are simple s/signr/siginfo->si_signo/.

    Signed-off-by: Denys Vlasenko
    Reviewed-by: Oleg Nesterov
    Cc: Amerigo Wang
    Cc: "Jonathan M. Foote"
    Cc: Roland McGrath
    Cc: Pedro Alves
    Cc: Fengguang Wu
    Cc: Stephen Rothwell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Denys Vlasenko
     
  • Adds an expert Kconfig option, CONFIG_COREDUMP, which allows disabling of
    core dump. This saves approximately 2.6k in the compiled kernel, and
    complements CONFIG_ELF_CORE, which now depends on it.

    CONFIG_COREDUMP also disables coredump-related sysctls, except for
    suid_dumpable and related functions, which are necessary for ptrace.

    [akpm@linux-foundation.org: fix binfmt_aout.c build]
    Signed-off-by: Alex Kelly
    Reviewed-by: Josh Triplett
    Acked-by: Serge Hallyn
    Acked-by: Kees Cook
    Cc: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alex Kelly
     

21 Apr, 2012

2 commits

  • This continues the theme started with vm_brk() and vm_munmap():
    vm_mmap() does the same thing as do_mmap(), but additionally does the
    required VM locking.

    This uninlines (and rewrites it to be clearer) do_mmap(), which sadly
    duplicates it in mm/mmap.c and mm/nommu.c. But that way we don't have
    to export our internal do_mmap_pgoff() function.

    Some day we hopefully don't have to export do_mmap() either, if all
    modular users can become the simpler vm_mmap() instead. We're actually
    very close to that already, with the notable exception of the (broken)
    use in i810, and a couple of stragglers in binfmt_elf.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • It does the same thing as "do_brk()", except it handles the VM locking
    too.

    It turns out that all external callers want that anyway, so we can make
    do_brk() static to just mm/mmap.c while at it.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

29 Mar, 2012

1 commit


21 Mar, 2012

2 commits


06 Mar, 2012

1 commit


15 Oct, 2010

1 commit

  • akiphie points out that a.out core-dumps have that odd task struct
    dumping that was never used and was never really a good idea (it goes
    back into the mists of history, probably the original core-dumping
    code). Just remove it.

    Also do the access_ok() check on dump_write(). It probably doesn't
    matter (since normal filesystems all seem to do it anyway), but he
    points out that it's normally done by the VFS layer, so ...

    [ I suspect that we should possibly do "vfs_write()" instead of
    calling ->write directly. That also does the whole fsnotify and write
    statistics thing, which may or may not be a good idea. ]

    And just to be anal, do this all for the x86-64 32-bit a.out emulation
    code too, even though it's not enabled (and won't currently even
    compile)

    Reported-by: akiphie
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

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
     

25 Mar, 2010

1 commit

  • fs/binfmt_aout.c: In function `aout_core_dump':
    fs/binfmt_aout.c:125: warning: passing argument 2 of `dump_write' makes pointer from integer without a cast
    include/linux/coredump.h:12: note: expected `const void *' but argument is of type `long unsigned int'
    fs/binfmt_aout.c:132: warning: passing argument 2 of `dump_write' makes pointer from integer without a cast
    include/linux/coredump.h:12: note: expected `const void *' but argument is of type `long unsigned int'

    due to dump_write() expecting a user void *. Fold casts into the
    START_DATA/START_STACK macros and shut up the warnings.

    Signed-off-by: Borislav Petkov
    Cc: Daisuke HATAYAMA
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Borislav Petkov
     

07 Mar, 2010

3 commits

  • My next patch will replace ELF_CORE_EXTRA_* macros by functions, putting
    them into other newly created *.c files. Then, each files will contain
    dump_write(), where each pair of binfmt_*.c and elfcore.c should be the
    same. So, this patch moves them into a header file with dump_seek().
    Also, the patch deletes confusing DUMP_WRITE macros in each files.

    Signed-off-by: Daisuke HATAYAMA
    Cc: "Luck, Tony"
    Cc: Jeff Dike
    Cc: David Howells
    Cc: Greg Ungerer
    Cc: Roland McGrath
    Cc: Oleg Nesterov
    Cc: Ingo Molnar
    Cc: Alexander Viro
    Cc: Andi Kleen
    Cc: Alan Cox
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Daisuke HATAYAMA
     
  • The current ELF dumper can produce broken corefiles if program headers
    exceed 65535. In particular, the program in 64-bit environment often
    demands more than 65535 mmaps. If you google max_map_count, then you can
    find many users facing this problem.

    Solaris has already dealt with this issue, and other OSes have also
    adopted the same method as in Solaris. Currently, Sun's document and AMD
    64 ABI include the description for the extension, where they call the
    extension Extended Numbering. See Reference for further information.

    I believe that linux kernel should adopt the same way as they did, so I've
    written this patch.

    I am also preparing for patches of GDB and binutils.

    How to fix
    ==========

    In new dumping process, there are two cases according to weather or
    not the number of program headers is equal to or more than 65535.

    - if less than 65535, the produced corefile format is exactly the same
    as the ordinary one.

    - if equal to or more than 65535, then e_phnum field is set to newly
    introduced constant PN_XNUM(0xffff) and the actual number of program
    headers is set to sh_info field of the section header at index 0.

    Compatibility Concern
    =====================

    * As already mentioned in Summary, Sun and AMD64 has already adopted
    this. See Reference.

    * There are four combinations according to whether kernel and userland
    tools are respectively modified or not. The next table summarizes
    shortly for each combination.

    ---------------------------------------------
    Original Kernel | Modified Kernel
    ---------------------------------------------
    < 65535 | >= 65535 | < 65535 | >= 65535
    -------------------------------------------------------------
    Original Tools | OK | broken | OK | broken (#)
    -------------------------------------------------------------
    Modified Tools | OK | broken | OK | OK
    -------------------------------------------------------------

    Note that there is no case that `OK' changes to `broken'.

    (#) Although this case remains broken, O-M behaves better than
    O-O. That is, while in O-O case e_phnum field would be extremely
    small due to integer overflow, in O-M case it is guaranteed to be at
    least 65535 by being set to PN_XNUM(0xFFFF), much closer to the
    actual correct value than the O-O case.

    Test Program
    ============

    Here is a test program mkmmaps.c that is useful to produce the
    corefile with many mmaps. To use this, please take the following
    steps:

    $ ulimit -c unlimited
    $ sysctl vm.max_map_count=70000 # default 65530 is too small
    $ sysctl fs.file-max=70000
    $ mkmmaps 65535

    Then, the program will abort and a corefile will be generated.

    If failed, there are two cases according to the error message
    displayed.

    * ``out of memory'' means vm.max_map_count is still smaller

    * ``too many open files'' means fs.file-max is still smaller

    So, please change it to a larger value, and then retry it.

    mkmmaps.c
    ==
    #include
    #include
    #include
    #include
    #include
    int main(int argc, char **argv)
    {
    int maps_num;
    if (argc < 2) {
    fprintf(stderr, "mkmmaps [number of maps to be created]\n");
    exit(1);
    }
    if (sscanf(argv[1], "%d", &maps_num) == EOF) {
    perror("sscanf");
    exit(2);
    }
    if (maps_num < 0) {
    fprintf(stderr, "%d is invalid\n", maps_num);
    exit(3);
    }
    for (; maps_num > 0; --maps_num) {
    if (MAP_FAILED == mmap((void *)NULL, (size_t) 1, PROT_READ,
    MAP_SHARED | MAP_ANONYMOUS, (int) -1,
    (off_t) NULL)) {
    perror("mmap");
    exit(4);
    }
    }
    abort();
    {
    char buffer[128];
    sprintf(buffer, "wc -l /proc/%u/maps", getpid());
    system(buffer);
    }
    return 0;
    }

    Tested on i386, ia64 and um/sys-i386.
    Built on sh4 (which covers fs/binfmt_elf_fdpic.c)

    References
    ==========

    - Sun microsystems: Linker and Libraries.
    Part No: 817-1984-17, September 2008.
    URL: http://docs.sun.com/app/docs/doc/817-1984

    - System V ABI AMD64 Architecture Processor Supplement
    Draft Version 0.99., May 11, 2009.
    URL: http://www.x86-64.org/

    This patch:

    There are three different definitions for dump_seek() functions in
    binfmt_aout.c, binfmt_elf.c and binfmt_elf_fdpic.c, respectively. The
    only for binfmt_elf.c.

    My next patch will move dump_seek() into a header file in order to share
    the same implementations for dump_write() and dump_seek(). As the first
    step, this patch unify these three definitions for dump_seek() by applying
    the past commits that have been applied only for binfmt_elf.c.

    Specifically, the modification made here is part of the following commits:

    * d025c9db7f31fc0554ce7fb2dfc78d35a77f3487
    * 7f14daa19ea36b200d237ad3ac5826ae25360461

    This patch does not change a shape of corefiles.

    Signed-off-by: Daisuke HATAYAMA
    Cc: "Luck, Tony"
    Cc: Jeff Dike
    Cc: David Howells
    Cc: Greg Ungerer
    Cc: Roland McGrath
    Cc: Oleg Nesterov
    Cc: Ingo Molnar
    Cc: Alexander Viro
    Cc: Andi Kleen
    Cc: Alan Cox
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Daisuke HATAYAMA
     
  • Make sure compiler won't do weird things with limits. E.g. fetching them
    twice may return 2 different values after writable limits are implemented.

    I.e. either use rlimit helpers added in commit 3e10e716abf3 ("resource:
    add helpers for fetching rlimits") or ACCESS_ONCE if not applicable.

    Signed-off-by: Jiri Slaby
    Cc: Alexander Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jiri Slaby
     

30 Jan, 2010

1 commit

  • 'flush_old_exec()' is the point of no return when doing an execve(), and
    it is pretty badly misnamed. It doesn't just flush the old executable
    environment, it also starts up the new one.

    Which is very inconvenient for things like setting up the new
    personality, because we want the new personality to affect the starting
    of the new environment, but at the same time we do _not_ want the new
    personality to take effect if flushing the old one fails.

    As a result, the x86-64 '32-bit' personality is actually done using this
    insane "I'm going to change the ABI, but I haven't done it yet" bit
    (TIF_ABI_PENDING), with SET_PERSONALITY() not actually setting the
    personality, but just the "pending" bit, so that "flush_thread()" can do
    the actual personality magic.

    This patch in no way changes any of that insanity, but it does split the
    'flush_old_exec()' function up into a preparatory part that can fail
    (still called flush_old_exec()), and a new part that will actually set
    up the new exec environment (setup_new_exec()). All callers are changed
    to trivially comply with the new world order.

    Signed-off-by: H. Peter Anvin
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

18 Dec, 2009

1 commit

  • Introduce coredump parameter data structure (struct coredump_params) to
    simplify binfmt->core_dump() arguments.

    Signed-off-by: Masami Hiramatsu
    Suggested-by: Ingo Molnar
    Cc: Hidehiro Kawai
    Cc: Oleg Nesterov
    Cc: Roland McGrath
    Cc: KOSAKI Motohiro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Masami Hiramatsu