linux-toradex.git/init, branch v2.6.20-rc4

[PATCH] start_kernel: test if irq's got enabled early, barf, and disable them again

2007-01-06T07:55:21+00:00

The calls made by parse_parms to other initialization code might enable
interrupts again way too early.

Having interrupts on this early can make systems PANIC when they initialize
the IRQ controllers (which happens later in the code).  This patch detects
that irq's are enabled again, barfs about it and disables them again as a
safety net.

[akpm@osdl.org: cleanups]
Signed-off-by: Ard van Breemen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] build compile.h earlier

2006-12-22T16:55:51+00:00

compile.h is created super-late in the build.  But proc_misc.c want to include
it, and it's generally not sane to have a header file in include/linux be
created at the end of the build: it's either not present or, worse, wrong for
most of the build.

So the patch arranges for compile.h to be built at the start of the build
process.  It also consolidates the compile.h rules with those for version.h
and utsname.h, so they all get built together.

I hope.  My chances of having got this right are about 2%.

Cc: Sam Ravnborg 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] handle SLOB with sparsemen

2006-12-22T16:55:49+00:00

This is to disallow to make SLOB with SMP or SPARSEMEM.  This avoids latent
troubles of SLOB with SLAB_DESTROY_BY_RCU.  And fix compile error.

Signed-off-by: Yasunori Goto 
Acked-by: Randy Dunlap 
Acked-by: Hugh Dickins 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] CONFIG_VM_EVENT_COUNTER comment decrustify

2006-12-22T16:55:46+00:00

The VM event counters, enabled by CONFIG_VM_EVENT_COUNTERS, which provides
VM event counters in /proc/vmstat, has become more essential to
non-EMBEDDED kernel configurations than they were in the past.  Comments in
the code and the Kconfig configuration explanation were stale, downplaying
their role excessively.

Refresh those comments to correctly reflect the current role of VM event
counters.

Signed-off-by: Paul Jackson 
Acked-by: Christoph Lameter 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Driver core: proper prototype for drivers/base/init.c:driver_init()

2006-12-20T18:56:45+00:00

Add a prototype for driver_init() in include/linux/device.h.

Also remove a static function of the same name in drivers/acpi/ibm_acpi.c to
ibm_acpi_driver_init() to fix the namespace collision.

Signed-off-by: Adrian Bunk 
Acked-by: Henrique de Moraes Holschuh 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

Kconfig: fix spelling error in config KALLSYMS help text

2006-12-12T18:25:11+00:00

Signed-off-by: Jesper Juhl 
Acked-By: Randy Dunlap 
Signed-off-by: Adrian Bunk

Make sure we populate the initroot filesystem late enough

2006-12-11T20:12:04+00:00

We should not initialize rootfs before all the core initializers have
run.  So do it as a separate stage just before starting the regular
driver initializers.

Signed-off-by: Linus Torvalds

Make SLES9 "get_kernel_version" work on the kernel binary again

2006-12-11T19:34:11+00:00

As reported by Andy Whitcroft, at least the SLES9 initrd build process
depends on getting the kernel version from the kernel binary.  It does
that by simply trawling the binary and looking for the signature of the
"linux_banner" string (the string "Linux version " to be exact. Which
is really broken in itself, but whatever..)

That got broken when the string was changed to allow /proc/version to
change the UTS release information dynamically, and "get_kernel_version"
thus returned "%s" (see commit a2ee8649ba6d71416712e798276bf7c40b64e6e5:
"[PATCH] Fix linux banner utsname information").

This just restores "linux_banner" as a static string, which should fix
the version finding.  And /proc/version simply uses a different string.

To avoid wasting even that miniscule amount of memory, the early boot
string should really be marked __initdata, but that just causes the same
bug in SLES9 to re-appear, since it will then find other occurrences of
"Linux version " first.

Cc: Andy Whitcroft 
Acked-by: Herbert Poetzl 
Cc: Andi Kleen 
Cc: Andrew Morton 
Cc: Steve Fox 
Acked-by: Olaf Hering 
Signed-off-by: Linus Torvalds

[PATCH] io-accounting: core statistics

2006-12-10T17:55:41+00:00

The present per-task IO accounting isn't very useful.  It simply counts the
number of bytes passed into read() and write().  So if a process reads 1MB
from an already-cached file, it is accused of having performed 1MB of I/O,
which is wrong.

(David Wright had some comments on the applicability of the present logical IO accounting:

  For billing purposes it is useless but for workload analysis it is very
  useful

  read_bytes/read_calls  average read request size
  write_bytes/write_calls average write request size

  read_bytes/read_blocks ie logical/physical can indicate hit rate or thrashing
  write_bytes/write_blocks  ie logical/physical  guess since pdflush writes can
                                                be missed

  I often look for logical larger than physical to see filesystem cache
  problems.  And the bytes/cpusec can help find applications that are
  dominating the cache and causing slow interactive response from page cache
  contention.

  I want to find the IO intensive applications and make sure they are doing
  efficient IO.  Thus the acctcms(sysV) or csacms command would give the high
  IO commands).

This patchset adds new accounting which tries to be more accurate.  We account
for three things:

reads:

  attempt to count the number of bytes which this process really did cause
  to be fetched from the storage layer.  Done at the submit_bio() level, so it
  is accurate for block-backed filesystems.  I also attempt to wire up NFS and
  CIFS.

writes:

  attempt to count the number of bytes which this process caused to be sent
  to the storage layer.  This is done at page-dirtying time.

  The big inaccuracy here is truncate.  If a process writes 1MB to a file
  and then deletes the file, it will in fact perform no writeout.  But it will
  have been accounted as having caused 1MB of write.

  So...

cancelled_writes:

  account the number of bytes which this process caused to not happen, by
  truncating pagecache.

  We _could_ just subtract this from the process's `write' accounting.  But
  that means that some processes would be reported to have done negative
  amounts of write IO, which is silly.

  So we just report the raw number and punt this decision up to userspace.

Now, we _could_ account for writes at the physical I/O level.  But

- This would require that we track memory-dirtying tasks at the per-page
  level (would require a new pointer in struct page).

- It would mean that IO statistics for a process are usually only available
  long after that process has exitted.  Which means that we probably cannot
  communicate this info via taskstats.

This patch:

Wire up the kernel-private data structures and the accessor functions to
manipulate them.

Cc: Jay Lan 
Cc: Shailabh Nagar 
Cc: Balbir Singh 
Cc: Chris Sturtivant 
Cc: Tony Ernst 
Cc: Guillaume Thouvenin 
Cc: David Wright 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] add child reaper to pid_namespace

2006-12-08T16:28:52+00:00

Add a per pid_namespace child-reaper.  This is needed so processes are reaped
within the same pid space and do not spill over to the parent pid space.  Its
also needed so containers preserve existing semantic that pid == 1 would reap
orphaned children.

This is based on Eric Biederman's patch: http://lkml.org/lkml/2006/2/6/285

Signed-off-by: Sukadev Bhattiprolu 
Signed-off-by: Cedric Le Goater 
Cc: Kirill Korotaev 
Cc: Eric W. Biederman 
Cc: Herbert Poetzl 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds