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.
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 ;)