Date: Tue, 13 May 1997 18:06:09 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Joerg Wunsch <joerg_wunsch@interface-business.de> Cc: FreeBSD-current users <freebsd-current@freebsd.org> Subject: Re: Big problem with b_blkno Message-ID: <Pine.BSF.3.95q.970513180105.947E-100000@herring.nlsystems.com> In-Reply-To: <19970513181525.ZO49600@ida.interface-business.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970513180105.947E-100000>