Bug 117682
Summary: | "echo 'force_on:1' > /proc/acpi/toshiba/fan" causes kernel OOPS | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Barry K. Nathan <barryn> |
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
Status: | CLOSED RAWHIDE | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | barryn, len.brown |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-03-25 09:06:45 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 114961 |
Description
Barry K. Nathan
2004-03-07 02:59:21 UTC
I'm not absolutely 100% sure of this (i.e. I haven't thoroughly ruled out weird freak scenarios, I suppose) but AFAICT so far, the problem happens with the kernel RPMS (still happens with 2.6.4-1.257) but not with mainline kernel source (at least, not with 2.6.4-rc2-bk1; I'm about to try 2.6.4 final). IOW, I think it's probably a patch being added by Red Hat. As I said, though, I'm not 100% sure of this. I'm trying to find time to test this hypothesis conclusively (and, if the hypothesis is correct, narrow it down to the patch in question). Ok, I can now 100% confirm that: (a) the oops does not happen with 2.6.4 mainline source (b) once I apply the patches that are applied by the 2.6.4-1.257 SPEC file, in the order that the SPEC file applies them, the resulting kernel has the oopsing problem I am now working on seeing which patch causes the problem. it's most likely the 4g/4g patch. Without that patch a driver can violate the driver API on x86 and do direct userspace access, which works most of the time. Unless the page in question is swapped out or if a bad address is passed in. With the 4g4g patch, use of the correct API's is basically a requirement. It looks to me like the write_fan() function is accessing the *userspace* pointer directly without copying it to a kernel space buffer with copy_from_user. Yes, indeed, that was exactly it. I've written a patch to fix it; I'll send it to lkml and to the toshiba_acpi maintainer. It's late so I may have to get some sleep before I send the patch, however. Here's the patch: http://marc.theaimsgroup.com/?l=linux-kernel&m=107924235630434&w=2 Thanks guys, for finding and diagnosing this bug. The upstream patch from John is here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2 .6.4/20040323011750-toshiba.patch cheers, -Len and the latest kernel on my people dir has this fixed. Time to close this bug ;) |