From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sam Ravnborg Subject: Re: [PATCH 01/14] ide-tape: fix potential fs requests bug Date: Sat, 9 May 2009 12:25:14 +0200 Message-ID: <20090509102514.GA23517@uranus.ravnborg.org> References: <1241855134-4984-1-git-send-email-petkovbb@gmail.com> <1241855134-4984-2-git-send-email-petkovbb@gmail.com> <20090509080245.GB22617@uranus.ravnborg.org> <20090509085008.GA5261@liondog.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from pfepb.post.tele.dk ([195.41.46.236]:39287 "EHLO pfepb.post.tele.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751370AbZEIKXD (ORCPT ); Sat, 9 May 2009 06:23:03 -0400 Content-Disposition: inline In-Reply-To: <20090509085008.GA5261@liondog.tnic> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: petkovbb@gmail.com, Borislav Petkov , bzolnier@gmail.com, linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org On Sat, May 09, 2009 at 10:50:08AM +0200, Borislav Petkov wrote: > On Sat, May 09, 2009 at 10:02:45AM +0200, Sam Ravnborg wrote: > > On Sat, May 09, 2009 at 09:45:21AM +0200, Borislav Petkov wrote: > > > ide-tape had a potential bug for fs requests when preparing the command > > > packet: it was writing the transfer length as a number of fixed blocks. > > > However, the block layer implies 512 byte blocks and ide-tape can have > > > other block sizes so account for that too. > > > > > > ide-floppy does this calculation properly with the block size factor > > > (floppy->bs_factor). > > > > > > Signed-off-by: Borislav Petkov > > > --- > > > drivers/ide/ide-tape.c | 2 +- > > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > > diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c > > > index e166045..fc79cf4 100644 > > > --- a/drivers/ide/ide-tape.c > > > +++ b/drivers/ide/ide-tape.c > > > @@ -586,7 +586,7 @@ static void ide_tape_create_rw_cmd(idetape_tape_t *tape, > > > struct ide_atapi_pc *pc, struct request *rq, > > > u8 opcode) > > > { > > > - unsigned int length = blk_rq_sectors(rq); > > > + unsigned int length = blk_rq_sectors(rq) / (tape->blk_size >> 9); > > > > If tape->blk_size equals 256 or less then we get a divide-by-zero. > > Yes, there is a far-fetched, potential possibility for that but here's > what the QIC 157D (http://www.qic.org/html/standards/15x.x/qic157d.pdf) > spec for streaming tapes says on block sizes: > > "The Block Length specifies the current length in bytes of each logical > block described by the block descriptor for the current medium. For QIC > Streaming Tape Devices, two block sizes supported may be of either 512 > or 1024 bytes per block." > > Also, the driver catches invalid block sizes in > idetape_get_mode_sense_results() so I guess we should be fine. OK - but If I am wondering maybe the next reader will think the same A small comment: /* idetape_get_mode_sense_results() prevent sizes less than 1 << 9 */ Seems to be reasonable. Sam