From owner-freebsd-current Tue May 13 09:16:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA27128 for current-outgoing; Tue, 13 May 1997 09:16:05 -0700 (PDT) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.202]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA27080 for ; Tue, 13 May 1997 09:15:55 -0700 (PDT) Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.203]) by innocence.interface-business.de (8.6.11/8.6.9) with SMTP id SAA09184 for ; Tue, 13 May 1997 18:14:41 +0200 Received: (from j@localhost) by ida.interface-business.de (8.8.5/8.7.3) id SAA12618; Tue, 13 May 1997 18:15:25 +0200 (MET DST) Message-ID: <19970513181525.ZO49600@ida.interface-business.de> Date: Tue, 13 May 1997 18:15:25 +0200 From: j@ida.interface-business.de (J Wunsch) To: freebsd-current@freebsd.org (FreeBSD-current users) Subject: Re: Big problem with b_blkno References: <19970513135901.QU53254@ida.interface-business.de> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface business GmbH, Dresden Reply-To: joerg_wunsch@interface-business.de (Joerg Wunsch) In-Reply-To: ; from Doug Rabson on May 13, 1997 15:37:32 +0100 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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 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. -- J"org Wunsch Unix support engineer joerg_wunsch@interface-business.de http://www.interface-business.de/~j