From owner-freebsd-current Tue May 13 10:07:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA29726 for current-outgoing; Tue, 13 May 1997 10:07:42 -0700 (PDT) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA29720 for ; Tue, 13 May 1997 10:07:39 -0700 (PDT) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.5/8.8.5) with SMTP id SAA01122; Tue, 13 May 1997 18:06:09 +0100 (BST) Date: Tue, 13 May 1997 18:06:09 +0100 (BST) From: Doug Rabson To: Joerg Wunsch cc: FreeBSD-current users Subject: Re: Big problem with b_blkno In-Reply-To: <19970513181525.ZO49600@ida.interface-business.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 13 May 1997, J Wunsch wrote: > As Doug Rabson wrote: > > > I don't know about any solutions but I think changing btodb would break > > NFS since it plays silly games with the block numbers to support caching > > of NFS files. > > A quick scan of all the NFS files for the usage of b_blkno seems to > yield no occuarance where it isn't multiplied with DEV_BSIZE when used > on the right hand side, or divided by DEV_BSIZE (of course, not using > btodb()) when used on the right hand side. My suggestion was to avoid > the shifting (division, in the top layers), and this mulitiplication > (in the bottom layers). > > This however probably means b_blkno needs to become a 64-bit entity. > It's probably time for this step anyway, since most drivers don't > handle the potential overflow after the multiplication. NFS, for > example: > > > if (((bp->b_blkno * DEV_BSIZE) + bp->b_dirtyend) > np->n_size) > > The multiplication on the left side is done in terms of 32-bit > entities, and can easily overflow if bp->b_blkno was larger than 2^30. > This is just a randomly picked example. I am sure there are plenty more examples where that came from. Bear in mind that the protocol only supported files larger than 32bit with version 3, so perhaps it is understandable that the code doesn't cope well with it. > > I don't think this is an easily solvable problem, but we should think > about solving it. Since it's not actually a block number after this > suggested transition, we should probably rename it into b_boffset, in > order to easily catch possible remaining bogus usage. NFS' use of b_blkno is about as bogus as it gets. Have a look at nfs_bmap for instance. Actually, I think vfs_bio.c's habit of comparing b_blkno to b_lblkno to decide whether it has called VOP_BMAP yet should rank pretty highly on the bogus usage stakes. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891