Skip to content

L
linux-davinci
Switch branch/tag
  1. 04 Aug, 2009 2 commits
    • Albin Tonnerre's avatar
      This is the first part of the lzo patch The lzo compressor is worse than · 605dd428
      Albin Tonnerre authored 
      gzip at compression, but faster at extraction.  Here are some figures for
an ARM board I'm working on:

Uncompressed size: 3.24Mo
gzip  1.61Mo 0.72s
lzo   1.75Mo 0.48s

So for a compression ratio that is still relatively close to gzip, it's
much faster to extract, at least in that case.

This version applies to kernel 2.6.31-rc3

This part contains:
 - Makefile routine to support lzo compression
 - Fixes to the existing lzo compressor so that it can be used in
   compressed kernels
 - wrapper around the existing lzo1x_decompress, as it only extracts one
   block at a time, while we need to extract a whole file here
 - config dialog for kernel compression
Signed-off-by: default avatarAlbin Tonnerre <albin.tonnerre@free-electrons.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Phillip Lougher <phillip@lougher.demon.co.uk>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      605dd428
    • Albin Tonnerre's avatar
      When unaligned accesses are required for uncompressing a kernel (such as · cb340f3a
      Albin Tonnerre authored 
      for LZO decompression on ARM in a patch that follows), including
<linux/kernel.h> causes issues as it brings in a lot of things that are
not available in the decompression environment.

However, those files apparently use nothing from <linux/kernel.h>, all
they need is the declaration of types such as u32 or u64, so
<linux/types.h> should be enough
Signed-off-by: default avatarAlbin Tonnerre <albin.tonnerre@free-electrons.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Phillip Lougher <phillip@lougher.demon.co.uk>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      cb340f3a
  3. 25 Jun, 2009 1 commit
  5. 20 Jul, 2009 1 commit
  7. 03 Aug, 2009 1 commit
  9. 13 Jul, 2009 1 commit
  11. 25 Jun, 2009 1 commit
  13. 11 Aug, 2009 2 commits
  15. 15 Jul, 2009 3 commits
  17. 23 Jul, 2009 1 commit
  19. 30 Jul, 2009 2 commits
  21. 11 Aug, 2009 1 commit
  23. 17 Aug, 2009 1 commit
  25. 12 Aug, 2009 1 commit
    • Nils Carlson's avatar
      The periodic interrupt from drivers/char/hpet.c does not work correctly, · 749c5af1
      Nils Carlson authored 
      both when using the periodic capability of the hardware and while
emulating the periodic interrupt (when hardware does not support periodic
mode).

With timers capable of periodic interrupts, the comparator field is first
set with the period value followed by set of hidden accumulator, which has
the side effect of overwriting the comparator value.  This results in
wrong periodicity for the interrupts.  For, periodic interrupts to work,
following steps are necessary, in that order.

* Set config with Tn_VAL_SET_CNF bit

* Write to hidden accumulator, the value written is the time when the
  first interrupt should be generated

* Write compartor with period interval for subsequent interrupts
  (http://www.intel.com/hardwaredesign/hpetspec_1.pdf )

When emulating periodic timer with timers not capable of periodic
interrupt, driver is adding the period to counter value instead of
comparator value, which causes slow drift when using this emulation.

Also, driver seems to add hpetp->hp_delta both while setting up periodic
interrupt and while emulating periodic interrupts with timers not capable
of doing periodic interrupts.  This hp_delta will result in slower than
expected interrupt rate and should not be used while setting the interval.
Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: default avatarNils Carlson <nils.carlson@ericsson.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      749c5af1
  27. 04 Aug, 2009 1 commit
  29. 30 Jul, 2009 1 commit
  31. 10 Aug, 2009 1 commit
  33. 18 Aug, 2009 1 commit
    • Renzo Davoli's avatar
      There are two useless lines in fs/char_dev.c. · 0061edb0
      Renzo Davoli authored 
      In register_chrdev there is a loop to change all '/' into '!' in the
kernel object name.
This code is useless as the same substitution is in kobject_set_name_vargs in
lib/kobject.c:
228         /* ewww... some of these buggers have '/' in the name ... */
229         while ((s = strchr(kobj->name, '/')))
230                 s[0] = '!';

kobject_set_name_vargs is called by kobject_set_name.
kobject_set_name is called just above the useless loop.
Signed-off-by: default avatarRenzo Davoli <renzo@cs.unibo.it>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      0061edb0
  35. 21 Jul, 2009 1 commit
  37. 02 Jul, 2009 1 commit
  39. 20 Jul, 2009 1 commit
  41. 01 Jul, 2009 2 commits
  43. 23 Jul, 2009 1 commit
    • Lai Jiangshan's avatar
      _cpu_down() changes the current task's affinity and then recovers it at · ce8acbd2
      Lai Jiangshan authored 
      the end.

It has two problems:

1) The recovery of the current tasks's cpus_allowed will fail under
   some conditions.

   # grep Cpus_allowed_list /proc/$$/status
   Cpus_allowed_list:      0-3

   # taskset -pc 2 $$
   pid 29075's current affinity list: 0-3
   pid 29075's new affinity list: 2

   # grep Cpus_allowed_list /proc/$$/status
   Cpus_allowed_list:      2

   # echo 0 > /sys/devices/system/cpu/cpu2/online

   # grep Cpus_allowed_list /proc/$$/status
   Cpus_allowed_list:      0

   Here, the Cpus_allowed_list was originally "2" and has become
   "0-1,3" after cpu #2 is offlined.

   This "Cpus_allowed_list:      0" is incorrect.

2) If the current task is a userspace task, the user may change its
   cpu-affinity during the CPU hot-unplugging.  This change can be
   overwritten when _cpu_down() changes the current task's affinity.


Fix all this by not changing the current tasks's affinity.  Instead we
create a kernel thread to do the work.
Signed-off-by: default avatarLai Jiangshan <laijs@cn.fujitsu.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      ce8acbd2
  45. 28 Jul, 2009 1 commit
    • Oleg Nesterov's avatar
      sys_delete_module() can set MODULE_STATE_GOING after · 1504e6b5
      Oleg Nesterov authored 
      search_binary_handler() does try_module_get().  In this case
set_binfmt()->try_module_get() fails but since none of the callers
check the returned error, the task will run with the wrong old
->binfmt.

The proper fix should change all ->load_binary() methods, but we can
rely on fact that the caller must hold a reference to binfmt->module
and use __module_get() which never fails.
Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
Cc: Roland McGrath <roland@redhat.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      1504e6b5
  47. 22 Jul, 2009 5 commits
    • Neil Horman's avatar
      Allow core_pattern pipes to wait for user space to complete · aa200e2c
      Neil Horman authored 
      One of the things that user space processes like to do is look at metadata
for a crashing process in their /proc/<pid> directory.  this is racy
however, since do_coredump in the kernel doesn't wait for the user space
process to complete before it reaps the crashing process.  This patch
corrects that.  Allowing the kernel to wait for the user space process to
complete before cleaning up the crashing process.  This is a bit tricky to
do for a few reasons:

1) The user space process isn't our child, so we can't sys_wait4 on it
2) We need to close the pipe before waiting for the user process to complete,
since the user process may rely on an EOF condition

I've discussed several solutions with Oleg Nesterov off-list about this,
and this is the one we've come up with.  We add ourselves as a pipe reader
(to prevent premature cleanup of the pipe_inode_info), and remove
ourselves as a writer (to provide an EOF condition to the writer in user
space), then we iterate until the user space process exits (which we
detect by pipe->readers == 1, hence the > 1 check in the loop).  When we
exit the loop, we restore the proper reader/writer values, then we return
and let filp_close in do_coredump clean up the pipe data properly.
Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
Reported-by: default avatarEarl Chew <earl_chew@agilent.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      aa200e2c
    • Andrew Morton's avatar
      ERROR: code indent should use tabs where possible · 6c98b6d9
      Andrew Morton authored 
      #115: FILE: fs/exec.c:1838:
+ ^I^Iif (call_usermodehelper_pipe(helper_argv[0], helper_argv, NULL,$

ERROR: code indent should use tabs where possible
#120: FILE: fs/exec.c:1842:
+ ^I^I^Igoto fail_dropcount;$

WARNING: externs should be avoided in .c files
#149: FILE: kernel/sysctl.c:80:
+extern unsigned int core_pipe_limit;

total: 2 errors, 1 warnings, 120 lines checked

./patches/exec-let-do_coredump-limit-the-number-of-concurrent-dumps-to-pipes-v9.patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      6c98b6d9
    • Neil Horman's avatar
      Introduce core pipe limiting sysctl. · 21340ee9
      Neil Horman authored 
      Since we can dump cores to pipe, rather than directly to the filesystem,
we create a condition in which a user can create a very high load on the
system simply by running bad applications.

If the pipe reader specified in core_pattern is poorly written, we can
have lots of ourstandig resources and processes in the system.

This sysctl introduces an ability to limit that resource consumption. 
core_pipe_limit defines how many in-flight dumps may be run in parallel,
dumps beyond this value are skipped and a note is made in the kernel log. 
A special value of 0 in core_pipe_limit denotes unlimited core dumps may
be handled (this is the default value).
Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
Reported-by: default avatarEarl Chew <earl_chew@agilent.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      21340ee9
    • Andrew Morton's avatar
      WARNING: suspect code indent for conditional statements (16, 25) · 04de93c2
      Andrew Morton authored 
      #48: FILE: fs/exec.c:1796:
+		if (core_limit == 0) {
+			 /*

WARNING: line over 80 characters
#57: FILE: fs/exec.c:1805:
+			  * but it runs as root, and can do lots of stupid things

WARNING: line over 80 characters
#58: FILE: fs/exec.c:1806:
+			  * Note that we use task_tgid_vnr here to grab the pid of the

WARNING: line over 80 characters
#59: FILE: fs/exec.c:1807:
+			  * process group leader.  That way we get the right pid if a thread

total: 0 errors, 4 warnings, 59 lines checked

./patches/exec-make-do_coredump-more-resilient-to-recursive-crashes-v9.patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      04de93c2
    • Neil Horman's avatar
      Change how we detect recursive dumps. · 9e09dd6d
      Neil Horman authored 
      Currently we have a mechanism by which we try to compare pathnames of the
crashing process to the core_pattern path.  This is broken for a dozen
reasons, and just doesn't work in any sort of robust way.

I'm replacing it with the use of a 0 RLIMIT_CORE value.  Since helper apps
set RLIMIT_CORE to zero, we don't write out core files for any process
with that particular limit set.  It the core_pattern is a pipe, any
non-zero limit is translated to RLIM_INFINITY.

This allows complete dumps to be captured, but prevents infinite recursion
in the event that the core_pattern process itself crashes.
Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
Reported-by: default avatarEarl Chew <earl_chew@agilent.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      9e09dd6d
  49. 16 Jul, 2009 1 commit
    • Roland McGrath's avatar
      This adds the utrace facility, a new modular interface in the kernel for · be6978b9
      Roland McGrath authored 
      implementing user thread tracing and debugging.  This fits on top of the
tracehook_* layer, so the new code is well-isolated.

The new interface is in <linux/utrace.h> and the DocBook utrace book
describes it.  It allows for multiple separate tracing engines to work in
parallel without interfering with each other.  Higher-level tracing
facilities can be implemented as loadable kernel modules using this layer.

The new facility is made optional under CONFIG_UTRACE.  When this is not
enabled, no new code is added.  It can only be enabled on machines that
have all the prerequisites and select CONFIG_HAVE_ARCH_TRACEHOOK.

In this initial version, utrace and ptrace do not play together at all. 
If ptrace is attached to a thread, the attach calls in the utrace kernel
API return -EBUSY.  If utrace is attached to a thread, the PTRACE_ATTACH
or PTRACE_TRACEME request will return EBUSY to userland.  The old ptrace
code is otherwise unchanged and nothing using ptrace should be affected by
this patch as long as utrace is not used at the same time.  In the future
we can clean up the ptrace implementation and rework it to use the utrace
API.

[oleg@redhat.com: kill exclude_xtrace logic]
Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      be6978b9
  51. 30 Jul, 2009 2 commits
  53. 13 Jul, 2009 1 commit
  55. 19 Aug, 2009 1 commit
  57. 17 Aug, 2009 1 commit
    • Peter Zijlstra's avatar
      In order to direct the SIGIO signal to a particular thread of a · 29e1ea2e
      Peter Zijlstra authored 
      multi-threaded application we cannot, like suggested by the manpage, put a
TID into the regular fcntl(F_SETOWN) call.  It will still be send to the
whole process of which that thread is part.

Since people do want to properly direct SIGIO we introduce F_SETOWN_EX.

The need to direct SIGIO comes from self-monitoring profiling such as with
perf-counters.  Perf-counters uses SIGIO to notify that new sample data is
available.  If the signal is delivered to the same task that generated the
new sample it can augment that data by inspecting the task's user-space
state right after it returns from the kernel.  This is esp.  convenient
for interpreted or virtual machine driven environments.

Both F_SETOWN_EX and F_GETOWN_EX take a pointer to a struct f_owner_ex
as argument:

struct f_owner_ex {
	int   type;
	pid_t pid;
};

Where type is one of F_OWNER_TID, F_OWNER_PID or F_OWNER_GID.
Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
Reviewed-by: default avatarOleg Nesterov <oleg@redhat.com>
Tested-by: default avatarstephane eranian <eranian@googlemail.com>
Cc: Michael Kerrisk <mtk.manpages@googlemail.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      29e1ea2e