Doug / smarc-fsl-linux-kernel

01 Mar, 2012

1 commit

18 Aug, 2010

1 commit

  • d7627467b   Make do_execve() take a const filename pointer ... Browse Code »

    Make do_execve() take a const filename pointer so that kernel_execve() compiles
    correctly on ARM:

    arch/arm/kernel/sys_arm.c:88: warning: passing argument 1 of 'do_execve' discards qualifiers from pointer target type

    This also requires the argv and envp arguments to be consted twice, once for
    the pointer array and once for the strings the array points to. This is
    because do_execve() passes a pointer to the filename (now const) to
    copy_strings_kernel(). A simpler alternative would be to cast the filename
    pointer in do_execve() when it's passed to copy_strings_kernel().

    do_execve() may not change any of the strings it is passed as part of the argv
    or envp lists as they are some of them in .rodata, so marking these strings as
    const should be fine.

    Further kernel_execve() and sys_execve() need to be changed to match.

    This has been test built on x86_64, frv, arm and mips.

    Signed-off-by: David Howells
    Tested-by: Ralf Baechle
    Acked-by: Russell King
    Signed-off-by: Linus Torvalds

    David Howells
     

14 Aug, 2010

1 commit

  • c78873252   Mark arguments to certain syscalls as being const ... Browse Code »

    Mark arguments to certain system calls as being const where they should be but
    aren't. The list includes:

    (*) The filename arguments of various stat syscalls, execve(), various utimes
    syscalls and some mount syscalls.

    (*) The filename arguments of some syscall helpers relating to the above.

    (*) The buffer argument of various write syscalls.

    Signed-off-by: David Howells
    Acked-by: David S. Miller
    Signed-off-by: Linus Torvalds

    David Howells
     

30 Mar, 2010

1 commit

  • 5a0e3ad6a   include cleanup: Update gfp.h and slab.h includes to prepare for breaking implic… ... Browse Code »

    …it slab.h inclusion from percpu.h

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

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

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

    The script does the followings.

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

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

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

    The conversion was done in the following steps.

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

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

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

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

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

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

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

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

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

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

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

    Tejun Heo
     

19 Jun, 2009

1 commit

03 Apr, 2009

1 commit

17 Oct, 2008

1 commit

27 Sep, 2008

1 commit

  • 81e480730   m32r/kernel/: cleanups ... Browse Code »

    This patch contains the following cleanups:
    - make the following needlessly global code static:
    - entry.S: resume_userspace
    - process.c: pm_idle
    - process.c: default_idle()
    - smp.c: send_IPI_allbutself()
    - time.c: timer_interrupt()
    - time.c: struct irq0
    - traps.c: set_eit_vector_entries()
    - traps.c: kstack_depth_to_print
    - traps.c: show_trace()
    - traps.c: die_lock
    - remove the following unused code:
    - head.S: startup_32
    - process.c: hlt_counter
    - process.c: disable_hlt()
    - process.c: enable_hlt()
    - process.c: dump_task_regs()
    - remove the following variables and their usages since they were
    always 0:
    - irq.c: irq_err_count
    - irq.c: irq_mis_count

    Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Hirokazu Takata

    Adrian Bunk
     

12 Feb, 2007

1 commit

01 Jul, 2006

1 commit

20 Apr, 2006

1 commit

13 Jan, 2006

1 commit

11 Jan, 2006

1 commit

  • df2e71fb9   [PATCH] dump_thread() cleanup ... Browse Code »

    )

    From: Adrian Bunk

    - create one common dump_thread() prototype in kernel.h

    - dump_thread() is only used in fs/binfmt_aout.c and can therefore be
    removed on all architectures where CONFIG_BINFMT_AOUT is not
    available

    Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    akpm@osdl.org
     

09 Jan, 2006

1 commit

  • 5e38291d8   [PATCH] Don't attempt to power off if power off is not implemented ... Browse Code »

    The problem. It is expected that /sbin/halt -p works exactly like
    /sbin/halt, when the kernel does not implement power off functionality.

    The kernel can do a lot of work in the reboot notifiers and in
    device_shutdown before we even get to machine_power_off. Some of that
    shutdown is not safe if you are leaving the power on, and it definitely
    gets in the way of using sysrq or pressing ctrl-alt-del. Since the
    shutdown happens in generic code there is no way to fix this in
    architecture specific code :(

    Some machines are kernel oopsing today because of this.

    The simple solution is to turn LINUX_REBOOT_CMD_POWER_OFF into
    LINUX_REBOOT_CMD_HALT if power_off functionality is not implemented.

    This has the unfortunate side effect of disabling the power off
    functionality on architectures that leave pm_power_off to null and still
    implement something in machine_power_off. And it will break the build on
    some architectures that don't have a pm_power_off variable at all.

    On both counts I say tough.

    For architectures like alpha that don't implement the pm_power_off variable
    pm_power_off is declared in linux/pm.h and it is a generic part of our
    power management code, and all architectures should implement it.

    For architectures like parisc that have a default power off method in
    machine_power_off if pm_power_off is not implemented or fails. It is easy
    enough to set the pm_power_off variable. And nothing bad happens there,
    the machines just stop powering off.

    The current semantics are impossible without a flag at the top level so we
    can avoid the problem code if a power off is not implemented. pm_power_off
    is as good a flag as any with the bonus that it works without modification
    on at least x86, x86_64, powerpc, and ppc today.

    Andrew can you pick this up and put this in the mm tree. Kernels that
    don't compile or don't power off seem saner than kernels that oops or
    panic. Until we get the arch specific patches for the problem
    architectures this probably isn't smart to push into the stable kernel.
    Unfortunately I don't have the time at the moment to walk through every
    architecture and make them work. And even if I did I couldn't test it :(

    From: Hirokazu Takata

    Add pm_power_off() for build fix of arch/m32r/kernel/process.c.

    From: Miklos Szeredi

    UML build fix

    Signed-off-by: Eric W. Biederman
    Signed-off-by: Hayato Fujiwara
    Signed-off-by: Hirokazu Takata
    Signed-off-by: Miklos Szeredi
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric W. Biederman
     

09 Nov, 2005

1 commit

  • 5bfb5d690   [PATCH] sched: disable preempt in idle tasks ... Browse Code »

    Run idle threads with preempt disabled.

    Also corrected a bugs in arm26's cpu_idle (make it actually call schedule()).
    How did it ever work before?

    Might fix the CPU hotplugging hang which Nigel Cunningham noted.

    We think the bug hits if the idle thread is preempted after checking
    need_resched() and before going to sleep, then the CPU offlined.

    After calling stop_machine_run, the CPU eventually returns from preemption and
    into the idle thread and goes to sleep. The CPU will continue executing
    previous idle and have no chance to call play_dead.

    By disabling preemption until we are ready to explicitly schedule, this bug is
    fixed and the idle threads generally become more robust.

    From: alexs

    PPC build fix

    From: Yoichi Yuasa

    MIPS build fix

    Signed-off-by: Nick Piggin
    Signed-off-by: Yoichi Yuasa
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nick Piggin
     

27 Jul, 2005

1 commit

  • 59586e5a2   [PATCH] Don't export machine_restart, machine_halt, or machine_power_off. ... Browse Code »

    machine_restart, machine_halt and machine_power_off are machine
    specific hooks deep into the reboot logic, that modules
    have no business messing with. Usually code should be calling
    kernel_restart, kernel_halt, kernel_power_off, or
    emergency_restart. So don't export machine_restart,
    machine_halt, and machine_power_off so we can catch buggy users.

    Signed-off-by: Eric W. Biederman
    Signed-off-by: Linus Torvalds

    Eric W. Biederman
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds