From mboxrd@z Thu Jan 1 00:00:00 1970 From: tytso@mit.edu Subject: Re: [Patch] fs: remove a useless BUG() Date: Tue, 1 Dec 2009 13:52:25 -0500 Message-ID: <20091201185225.GB6278@thunk.org> References: <20091201023714.3863.92566.sendpatchset@localhost.localdomain> <20091201165440.GA2688@joi.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Amerigo Wang , linux-kernel@vger.kernel.org, Alexander Viro , Jens Axboe , Nick Piggin , linux-fsdevel@vger.kernel.org, akpm@linux-foundation.org To: Marcin Slusarz Return-path: Content-Disposition: inline In-Reply-To: <20091201165440.GA2688@joi.lan> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, Dec 01, 2009 at 05:55:11PM +0100, Marcin Slusarz wrote: > On Mon, Nov 30, 2009 at 09:34:14PM -0500, Amerigo Wang wrote: > > This BUG() is suspicious, it makes its following statements > > unreachable, > only when CONFIG_BUG=y Which is true for all kernels except for the very rare embedded case. > > and it seems to be useless, since the caller > > of this function already handles the failure properly. > because this function can return NULL in other codepath > > > Remove it. > I don't know why this BUG() is there (and maybe it's not really > needed), but your rationale is wrong. Your reply is a bit snarky, IMHO. It might have been nicer and more courteous if you had bothered to take a closer look at the patch before firing off a reply. In fact, it's good to avoid BUG() if at all possible, especially if it can happen in the normally course of events --- such as running out of memory. Having code which triggers an BUG in an low memory situation is very bad form. Looks good to me. Signed-off-by: "Theodore Ts'o" - Ted