kernel/linux.git, branch v2.6.27.1

Linux 2.6.27.1

2008-10-15T23:02:53+00:00

disable CONFIG_DYNAMIC_FTRACE due to possible memory corruption on module unload

2008-10-15T23:02:33+00:00

While debugging the e1000e corruption bug with Intel, we discovered today that the dynamic ftrace code in mainline is the likely source of this bug. For the stable kernel we are providing the only viable fix patch: labeling CONFIG_DYNAMIC_FTRACE as broken. (see the patch below) We will follow up with a backport patch that contains the fixes. But since the fixes are not a one liner, the safest approach for now is to disable the code in question. The cause of the bug is due to the way the current code in mainline handles dynamic ftrace. When dynamic ftrace is turned on, it also turns on CONFIG_FTRACE which enables the -pg config in gcc that places a call to mcount at every function call. With just CONFIG_FTRACE this causes a noticeable overhead. CONFIG_DYNAMIC_FTRACE works to ease this overhead by dynamically updating the mcount call sites into nops. The problem arises when we trace functions and modules are unloaded. The first time a function is called, it will call mcount and the mcount call will call ftrace_record_ip. This records the calling site and stores it in a preallocated hash table. Later on a daemon will wake up and call kstop_machine and convert any mcount callers into nops. The evolution of this code first tried to do this without the kstop_machine and used cmpxchg to update the callers as they were called. But I was informed that this is dangerous to do on SMP machines if another CPU is running that same code. The solution was to do this with kstop_machine. We still used cmpxchg to test if the code that we are modifying is indeed code that we expect to be before updating it - as a final line of defense. But on 32bit machines, ioremapped memory and modules share the same address space. When a module would load its code into memory and execute some code, that would register the function. On module unload, ftrace incorrectly did not zap these functions from its hash (this was the bug). The cmpxchg could have saved us in most cases (via luck) - but with ioremap-ed memory that was exactly the wrong thing to do - the results of cmpxchg on device memory are undefined. (and will likely result in a write) The pending .28 ftrace tree does not have this bug anymore, as a general push towards more robustness of code patching, this is done differently: we do not use cmpxchg and we do a WARN_ON and turn the tracer off if anything deviates from its expected state. Furthermore, patch sites are statically identified during build time so there's no runtime discovery of dynamic code areas anymore, and no room for code unmaps to cause the hash to become out of date. We believe the fragility of dynamic patching has been sufficiently addressed in the development code via the static patching method, but further suggestions to make it more robust are welcome. Signed-off-by: Steven Rostedt Acked-by: Ingo Molnar Acked-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

Linux 2.6.27

2008-10-09T22:13:53+00:00

Don't allow splice() to files opened with O_APPEND

2008-10-09T21:26:38+00:00

This is debatable, but while we're debating it, let's disallow the combination of splice and an O_APPEND destination. It's not entirely clear what the semantics of O_APPEND should be, and POSIX apparently expects pwrite() to ignore O_APPEND, for example. So we could make up any semantics we want, including the old ones. But Miklos convinced me that we should at least give it some thought, and that accepting writes at arbitrary offsets is wrong at least for IS_APPEND() files (which always have O_APPEND set, even if the reverse isn't true: you can obviously have O_APPEND set on a regular file). So disallow O_APPEND entirely for now. I doubt anybody cares, and this way we have one less gray area to worry about. Reported-and-argued-for-by: Miklos Szeredi Acked-by: Jens Axboe Signed-off-by: Linus Torvalds

Merge branch 'hwmon-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6

2008-10-09T19:23:54+00:00

* 'hwmon-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6: hwmon: (abituguru3) Enable DMI probing feature on Abit AT8 32X hwmon: (abituguru3) Enable reading from AUX3 fan on Abit AT8 32X hwmon: (adt7473) Fix some bogosity in documentation file hwmon: Define sysfs interface for energy consumption register hwmon: (it87) Prevent power-off on Shuttle SN68PT eeepc-laptop: Fix hwmon interface

Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq

2008-10-09T19:23:35+00:00

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq: [CPUFREQ] correct broken links and email addresses

SLOB: fix bogus ksize calculation fix

2008-10-09T19:18:27+00:00

This fixes the previous fix, which was completely wrong on closer inspection. This version has been manually tested with a user-space test harness and generates sane values. A nearly identical patch has been boot-tested. The problem arose from changing how kmalloc/kfree handled alignment padding without updating ksize to match. This brings it in sync. Signed-off-by: Matt Mackall Signed-off-by: Linus Torvalds

[CPUFREQ] correct broken links and email addresses

2008-10-09T17:52:40+00:00

Replace the no longer working links and email address in the documentation and in source code. Signed-off-by: Márton Németh Signed-off-by: Dave Jones

hwmon: (abituguru3) Enable DMI probing feature on Abit AT8 32X

2008-10-09T13:33:59+00:00

Enable driver checking of the DMI product name (when enabled) on an Abit AT8 32X, instead of falling back to a manual probe. This eliminates false negatives and eventually will help avoid unnecessary bus probes on unsupported mainboards. Signed-off-by: Alistair John Strachan Tested-by: Daniel Exner Acked-by: Hans de Goede Signed-off-by: Jean Delvare

hwmon: (abituguru3) Enable reading from AUX3 fan on Abit AT8 32X

2008-10-09T13:33:59+00:00

The table for the Abit AT8 32X was incorrectly missing an entry for the sixth ("AUX3") fan. Add this entry, exporting the fan reading to userspace. Closes lm-sensors.org ticket #2339. Signed-off-by: Alistair John Strachan Tested-by: Daniel Exner Acked-by: Hans de Goede Signed-off-by: Jean Delvare