Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S265427AbUAFW7T (ORCPT ); Tue, 6 Jan 2004 17:59:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265401AbUAFW7S (ORCPT ); Tue, 6 Jan 2004 17:59:18 -0500 Received: from mta4.rcsntx.swbell.net ([151.164.30.28]:31412 "EHLO mta4.rcsntx.swbell.net") by vger.kernel.org with ESMTP id S265427AbUAFW7Q (ORCPT ); Tue, 6 Jan 2004 17:59:16 -0500 Date: Tue, 6 Jan 2004 14:58:55 -0800 From: Mike Fedyk To: Jesper Juhl Cc: Hans Reiser , "Tigran A. Aivazian" , Hans Reiser , Daniel Pirkl , Russell King , Will Dyson , linux-kernel@vger.kernel.org, nikita@namesys.com Subject: Re: Suspected bug infilesystems (UFS,ADFS,BEFS,BFS,ReiserFS) related to sector_t being unsigned, advice requested Message-ID: <20040106225855.GH1882@matchmail.com> Mail-Followup-To: Jesper Juhl , Hans Reiser , "Tigran A. Aivazian" , Hans Reiser , Daniel Pirkl , Russell King , Will Dyson , linux-kernel@vger.kernel.org, nikita@namesys.com References: <3FFA7717.7080808@namesys.com> <20040106174650.GD1882@matchmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1853 Lines: 39 On Tue, Jan 06, 2004 at 11:43:40PM +0100, Jesper Juhl wrote: > reiserfs_write_unlock(inode->i_sb); is called at the beginning of the > function, and as far as I can tell it's matched by a call to > reiserfs_write_unlock(inode->i_sb); at every potential return point in the > function, and I see no other locks being taken. OK, good. > Besides, since if (block < 0) will never be true and > reiserfs_write_unlock(inode->i_sb); > return -EIO; > will never execute in any case, locking should behave identical to what it > did before removing the code. > Locking /seems/ OK to me in this function. > > Also, I did a build of fs/reiserfs/ both with and without the above patch, > and then did a disassemble of inode.o (objdump -d) and compared the > generated code for reiserfs_get_block , and the generated code is > byte-for-byte identical in both cases, which means that gcc realizes that > the if() statement will never execute and optimizes it away in any case. I'm not talking about before and afte your patch, I'm talking about before and after the sector_t patch (presumably for the large block device (gt 2TB) support). > I'm not familliar with those "sector_t merges" you are refering to, but I > found some mention of a 64bit sector_t merge in the 2.5.x kernel > Changelogs, so I downloaded the 2.5.10 kernel source (first reference to > sector_t I found was in the 2.5.11 changelog) and took a look at how > sector_t used to be defined. It seems that it was an unsigned value even > back then. > Has sector_t ever been signed? Really? Interesting. Then maybe this is from ported 2.2 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/