Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755070Ab0KEXH2 (ORCPT ); Fri, 5 Nov 2010 19:07:28 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]:31510 "EHLO rcsinet10.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753944Ab0KEXH0 (ORCPT ); Fri, 5 Nov 2010 19:07:26 -0400 Message-ID: <4CD48E04.2050709@oracle.com> Date: Fri, 05 Nov 2010 16:06:44 -0700 From: Randy Dunlap Organization: Oracle Linux Engineering User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-3.fc11 Thunderbird/3.0 MIME-Version: 1.0 To: Linus Torvalds CC: Pavel Roskin , "John W. Linville" , linux-wireless@vger.kernel.org, Linux Kernel Mailing List Subject: Re: Linux 2.6.37-rc1 (libipw remove_proc_entry warning) References: <20101103161837.fad11d79.randy.dunlap@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1541 Lines: 43 On 11/05/10 15:24, Linus Torvalds wrote: > This bug seems to be due to commit 27ae60f8f7aac ("ipw2x00: replace > "ieee80211" with "libipw" where appropriate"), where Pavel did this: > > - libipw_proc = proc_mkdir(DRV_NAME, init_net.proc_net); > + libipw_proc = proc_mkdir("ieee80211", init_net.proc_net); > > but then the cleanup was kept as > > remove_proc_entry(DRV_NAME, init_net.proc_net); > > in both places (both in the failure case and in the unload case). The > error string is also total crap, and says > > "Unable to create " DRV_NAME " proc directory\n"); > > Even though it doesn't actually create a proc directory named DRV_NAME at all. > > So that patch looks like total and utter crap to me. The commit message says > > "Keep /proc/net/ieee80211 under the original name to avoid breaking user > interface." > > but the thing is, it really didn't fix anything but that one create > thing. It needs to fix all the other cases too. > > Totally UNTESTED patch attached. It may or may not compile. And maybe > it doesn't catch all cases, but it should catch the obvious ones. That works for me. Tested-by: Randy Dunlap thanks, -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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/