Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933912AbZJMKiZ (ORCPT ); Tue, 13 Oct 2009 06:38:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933886AbZJMKiY (ORCPT ); Tue, 13 Oct 2009 06:38:24 -0400 Received: from cantor2.suse.de ([195.135.220.15]:56748 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933648AbZJMKiX (ORCPT ); Tue, 13 Oct 2009 06:38:23 -0400 Date: Tue, 13 Oct 2009 12:37:46 +0200 Message-ID: From: Takashi Iwai To: Rusty Russell Cc: linux-kernel@vger.kernel.org Subject: Problems with string (charp) module parameters User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.7 Emacs/23.1 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2438 Lines: 67 Hi Rusty, While I tried to add some debug option to a driver, I found that a module parameter taking a string (charp) gives Oops when set via sysfs: BUG: unable to handle kernel paging request at ffffffff814c8d8a IP: [] param_set_charp+0x89/0xd0 PGD 1003067 PUD 1007063 PMD 11c10d063 PTE 80000000014c8161 Oops: 0003 [#1] SMP ... Call Trace: [] param_attr_store+0x31/0x56 [] module_attr_store+0x34/0x4c [] sysfs_write_file+0x101/0x151 [] vfs_write+0xbc/0x195 [] ? do_page_fault+0x2e5/0x345 [] sys_write+0x54/0x8f [] system_call_fastpath+0x16/0x1b This seems happening only with a built-in driver, not with a module. The Oops appears at line 227 in kernel/params.c (as of 2.6.32-rc4), if (slab_is_available()) { ==> kp->flags |= KPARAM_KMALLOCED; *(char **)kp->arg = kstrdup(val, GFP_KERNEL); if (!kp->arg) return -ENOMEM; Puzzling. So I looked into the relevant code, and found some deeper problems. * Each struct kernel_param instance is defined as const, and is put into __param section, which is read-only. I guess this causes the page fault above. And... * The above NULL check is invalid. It should be if (!*(char **)kp->arg) return -ENOMEM This is easy, however... * The handling of parameter array is pretty buggy now. kp->perm and kp->flags aren't properly initialized in param_array(). Thus, you might call kfree() with invalid pointers, or pass a wrong type for bool. The first item was overlooked because there was no writable field before the kmalloc'ed string was introduced. And, the current code still works somehow for charp with param_array() just because a struct kernel_param on stack is used there. But, this is also a buggy implementation due to the third point. We didn't hint a bug because the charp array contain usually NULL. So, the situation looks messy right now, not only about the section issue. If we allow kmalloc of each parameter array element, the flag must be associated to each element, not a global one to the array. Thoughts? thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/