[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A0FF5EA.3020805@gmail.com>
Date: Sun, 17 May 2009 20:32:58 +0900
From: Tejun Heo <htejun@...il.com>
To: Boaz Harrosh <bharrosh@...asas.com>
CC: Jens Axboe <jens.axboe@...cle.com>,
James Bottomley <James.Bottomley@...senPartnership.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
linux-scsi <linux-scsi@...r.kernel.org>,
IDE/ATA development list <linux-ide@...r.kernel.org>,
Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
Borislav Petkov <petkovbb@...glemail.com>,
Pete Zaitcev <zaitcev@...hat.com>,
Sergei Shtylyov <sshtylyov@...mvista.com>,
Eric Moore <Eric.Moore@....com>,
"Darrick J. Wong" <djwong@...ibm.com>
Subject: Re: [PATCH UPDATED block#for-2.6.31 2/3] block: set rq->resid_len
to blk_rq_bytes() on issue
Hello, Boaz.
Boaz Harrosh wrote:
> Surly this is not enough. This is not the only place rq->__data_len
> gets a value. Specifically it can be added to in blk_rq_append_bio.
> You must then update all places that set rq->__data_len to also set
> rq->resid_len.
Right, nice spotting, but I think those are the only two places. You
now see why I don't like that append thing. :-)
> Alternatively you could do a single:
> + rq->resid_len = blk_rq_bytes(rq);
>
> inside blk_fetch_request(q) or before the call to prep_fn, or even at
> __elv_add_request().
I think I'll just add resid_len adjustment there right after
__data_len manipulation. That code path should really go away
eventually.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists