From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [git patches] two warning fixes Date: Mon, 23 Jul 2007 07:29:20 +1000 Message-ID: <1185139760.5439.52.camel@localhost.localdomain> References: <20070718235504.GA9601@havoc.gtf.org> <469ECD29.2010909@garzik.org> <1184977973.5439.45.camel@localhost.localdomain> <46A2D6F7.9080309@garzik.org> Reply-To: linux-fbdev-devel@lists.sourceforge.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1ICizk-0004tg-FJ for linux-fbdev-devel@lists.sourceforge.net; Sun, 22 Jul 2007 14:29:40 -0700 Received: from gate.crashing.org ([63.228.1.57] ident=[U2FsdGVkX18ZU7ey2PHIiDuQFoE8r96ZAeleYYs4V68=]) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1ICizj-0008Ho-1H for linux-fbdev-devel@lists.sourceforge.net; Sun, 22 Jul 2007 14:29:40 -0700 In-Reply-To: <46A2D6F7.9080309@garzik.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-fbdev-devel-bounces@lists.sourceforge.net Errors-To: linux-fbdev-devel-bounces@lists.sourceforge.net To: Jeff Garzik Cc: linux-fbdev-devel@lists.sourceforge.net, adaplas@gmail.com, ak@suse.de, LKML , Andrew Morton , Linus Torvalds , Krzysztof Halasa > Not necessarily as simple as that -- you need to make sure you don't > pass something bogus to a sysfs_remove_blah() function at > unregister/unload time, if sysfs_create_blah() failed. > > Certainly sysfs_foo() failure is often ignorable in the sense that you > want the driver to keep loading... but that does not imply that it is > strictly ignorable, if you also consider the associated cleanup code. It should be trivial enough to have sysfs_create_blah() do enough initializations before it can fail so that sysfs_remove_blah() do the right thing regardless. It's actually a major PITA for a driver that creates a whole bunch of sysfs files to have to track precisely which ones were created successfully for the error path. If it's a single function, goto does the trick but if for some reason it's not, it's really annoying. Ben. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762358AbXGVVaB (ORCPT ); Sun, 22 Jul 2007 17:30:01 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753294AbXGVV3x (ORCPT ); Sun, 22 Jul 2007 17:29:53 -0400 Received: from gate.crashing.org ([63.228.1.57]:33294 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753383AbXGVV3w (ORCPT ); Sun, 22 Jul 2007 17:29:52 -0400 Subject: Re: [git patches] two warning fixes From: Benjamin Herrenschmidt To: Jeff Garzik Cc: Krzysztof Halasa , Linus Torvalds , Andrew Morton , LKML , ak@suse.de, adaplas@gmail.com, linux-fbdev-devel@lists.sourceforge.net In-Reply-To: <46A2D6F7.9080309@garzik.org> References: <20070718235504.GA9601@havoc.gtf.org> <469ECD29.2010909@garzik.org> <1184977973.5439.45.camel@localhost.localdomain> <46A2D6F7.9080309@garzik.org> Content-Type: text/plain Date: Mon, 23 Jul 2007 07:29:20 +1000 Message-Id: <1185139760.5439.52.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > Not necessarily as simple as that -- you need to make sure you don't > pass something bogus to a sysfs_remove_blah() function at > unregister/unload time, if sysfs_create_blah() failed. > > Certainly sysfs_foo() failure is often ignorable in the sense that you > want the driver to keep loading... but that does not imply that it is > strictly ignorable, if you also consider the associated cleanup code. It should be trivial enough to have sysfs_create_blah() do enough initializations before it can fail so that sysfs_remove_blah() do the right thing regardless. It's actually a major PITA for a driver that creates a whole bunch of sysfs files to have to track precisely which ones were created successfully for the error path. If it's a single function, goto does the trick but if for some reason it's not, it's really annoying. Ben.