Bug 117682 - "echo 'force_on:1' > /proc/acpi/toshiba/fan" causes kernel OOPS
"echo 'force_on:1' > /proc/acpi/toshiba/fan" causes kernel OOPS
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
Blocks: FC2Blocker
  Show dependency treegraph
Reported: 2004-03-06 21:59 EST by Barry K. Nathan
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-03-25 04:06:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Barry K. Nathan 2004-03-06 21:59:21 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040225 Firefox/0.8

Description of problem:
When I run the following command as root, my root shell dies and I get
a kernel oops:
echo 'force_on:1' > /proc/acpi/toshiba/fan

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Obtain a root shell.
2. Run the command: echo 'force_on:1' > /proc/acpi/toshiba/fan

Actual Results:  From 2.6.3-2.1.242:

Unable to handle kernel paging request at virtual address f6e91000
 printing eip:
*pde = 00000000
Debug: sleeping function called from invalid context at
include/linux/rwsem.h:43in_atomic():0, irqs_disabled():1
Call Trace:
 [<021250a3>] __might_sleep+0x80/0x8a
 [<02166287>] rw_vm+0x1b7/0x3aa
 [<0212842f>] __call_console_drivers+0x36/0x42
 [<2183a028>] snscanf+0x28/0x53 [toshiba_acpi]
 [<2183a028>] snscanf+0x28/0x53 [toshiba_acpi]
 [<021666d3>] get_user_size+0x30/0x57
 [<2183a028>] snscanf+0x28/0x53 [toshiba_acpi]
 [<0210e0cf>] handle_BUG+0x32/0xdf
 [<0212883a>] printk+0x26a/0x2e3
 [<0210e23d>] die+0xc1/0x1b1
 [<021203c7>] do_page_fault+0x2f8/0x447
 [<2183a028>] snscanf+0x28/0x53 [toshiba_acpi]
 [<02188d7d>] inode_setattr+0xe6/0xef
 [<02188fad>] notify_change+0x1d1/0x1dc
 [<02166ba8>] do_truncate+0x4f/0x6b
 [<021a0b96>] proc_read_inode+0xc/0x29
 [<021200cf>] do_page_fault+0x0/0x447
 [<0214007b>] load_module+0x4d0/0x75a
 [<2183a028>] snscanf+0x28/0x53 [toshiba_acpi]
 [<2183a4eb>] write_fan+0x16/0x58 [toshiba_acpi]
 [<2183a249>] dispatch_write+0xb/0xc [toshiba_acpi]
 [<021a4cc7>] proc_file_write+0x25/0x29
 [<02168b2b>] vfs_write+0xb8/0xe4
 [<02168bc5>] sys_write+0x2c/0x42
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<2183a028>]    Not tainted
EFLAGS: 00010206   (2.6.3-2.1.242)
EIP is at snscanf+0x28/0x53 [toshiba_acpi]
eax: 00000000   ebx: 0000000b   ecx: 0000000a   edx: 111aa7dc
esi: f6e91000   edi: 111aa7e0   ebp: 111aa7e0   esp: 13ec6f4c
ds: 007b   es: 007b   ss: 0068
Process bash (pid: 2369, threadinfo=13ec6000 task=11a846c0)
Stack: 0000000b 113bae4c 0000000b 113bae6c 2183a4eb f6e91000 0000000b
       13ec6f74 2183b078 2183b078 2076f334 2183a249 021a4cc7 2183b078
       113bae4c 02168b2b 113bae6c f6e91000 113bae4c fffffff7 f6e91000
Call Trace:
 [<2183a4eb>] write_fan+0x16/0x58 [toshiba_acpi]
 [<2183a249>] dispatch_write+0xb/0xc [toshiba_acpi]
 [<021a4cc7>] proc_file_write+0x25/0x29
 [<02168b2b>] vfs_write+0xb8/0xe4
 [<02168bc5>] sys_write+0x2c/0x42
Code: ac aa 84 c0 75 f7 f3 aa c6 04 2b 00 8d 4c 24 20 89 e8 8b 54

Expected Results:  no oops expected; fan expected to turn on (if it's
off) and stay on

Additional info:

This fails with 2.6.3-2.1.238. Last working kernel was 2.6.3-1.118.
Comment 1 Barry K. Nathan 2004-03-12 09:56:29 EST
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).
Comment 2 Barry K. Nathan 2004-03-12 16:06:59 EST
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.
Comment 3 Arjan van de Ven 2004-03-12 16:28:44 EST
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.
Comment 4 Barry K. Nathan 2004-03-13 03:52:19 EST
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.
Comment 5 Barry K. Nathan 2004-03-14 00:38:52 EST
Here's the patch:
Comment 6 Len Brown 2004-03-24 03:01:56 EST
Thanks guys, for finding and diagnosing this bug.

The upstream patch from John is here:


Comment 7 Arjan van de Ven 2004-03-25 04:06:45 EST
and the latest kernel on my people dir has this fixed.
Time to close this bug ;)

Note You need to log in before you can comment on or make changes to this bug.