On Fri, 2008-02-29 at 00:46 +0900, Tejun Heo wrote: > Jens Axboe wrote: > >> This problem was reported and diagnosed by Mike Galbraith. > > > > Tejun, this patch isn't much cleaner at all. It really shows the pain of > > these two seperate, yet related, variables. > > Not much cleaner compared to what? I think padding stuff is bound to be > somewhat complex. It's a nasty thing in nature. I think ->extra_len is > better than ->raw_data_len because ->extra_len only needs to be updated > where the dirty jobs are done and extra buffer areas are added. Any > better suggestions? Well, I just investigated a bug report in the SCSI transport class. Our SMP handler is broken in exactly the same way. We rely on the incoming reported request lengths to size our request data, and they've blown up from the true length to 512 bytes (the size of our alignment). With the original patch, I have to run through the whole of libsas and scsi_transport_sas doing s/data_len/raw_data_len/ With your update it looks like I have to run through them all doing s/data_len/data_len - extra_len/ which is even worse. Can't we put things back to a point where data_len means exactly that and extra_len means how much we have spare on the end, so you know you can DMA up to data_len + extra_len if need be? That way we don't have to sweep through every block driver altering the way it uses data_len. James -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
