Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 117682 - "echo 'force_on:1' > /proc/acpi/toshiba/fan" causes kernel OOPS
Summary: "echo 'force_on:1' > /proc/acpi/toshiba/fan" causes kernel OOPS
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: FC2Blocker
TreeView+ depends on / blocked
 
Reported: 2004-03-07 02:59 UTC by Barry K. Nathan
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-03-25 09:06:45 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description Barry K. Nathan 2004-03-07 02:59:21 UTC 
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):
kernel-2.6.3-2.1.242

How reproducible:
Always

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:
2183a028
*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
2183a84c
       13ec6f74 2183b078 2183b078 2076f334 2183a249 021a4cc7 2183b078
02312dc0
       113bae4c 02168b2b 113bae6c f6e91000 113bae4c fffffff7 f6e91000
13ec6000
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 14:56:29 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).
Comment 2 Barry K. Nathan 2004-03-12 21:06:59 UTC 
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 21:28:44 UTC 
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 08:52:19 UTC 
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 05:38:52 UTC 
Here's the patch:
http://marc.theaimsgroup.com/?l=linux-kernel&m=107924235630434&w=2
Comment 6 Len Brown 2004-03-24 08:01:56 UTC 
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
Comment 7 Arjan van de Ven 2004-03-25 09:06:45 UTC 
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.