Jan Beulich wrote: >>>> Boaz Harrosh <bharrosh@xxxxxxxxxxx> 22.07.08 15:28 >>> >> Jan Beulich wrote: >>> James, >>> >>> while reviewing code derived from that function I found this calculation >>> to be suspicious: I would think that it should get it wrong when both >>> start and end of the buffer area are misaligned (e.g. consider the case >>> where sgl->offset equals PAGE_SIZE-1 and bufflen equals 2 - the result >>> would be 1 when it should have been 2). >>> Is there something preventing this from happening? >>> >>> Thanks, Jan >>> >>> -- >> It has been discussed before for example look here: >> http://www.spinics.net/lists/linux-scsi/msg13454.html >> >> But for me the main reason it is not fixed is because >> this is only called from scsi_execute_async() which >> is a deprecated function. It is still used by old code >> which is supposed to be removed soon. Any new code will >> not be accepted if it uses scsi_execute_async(). > > No, that's a different issue: Even if the sg elements are all contiguous, > the count can be wrong, as described in the original mail. And as said, > I found this in code cloned from scsi_req_map_sg(), hence would be > interested in confirmation of that fact (or explanation why it's not an > issue) regardless of the function itself sitting in a to-be-removed code > path only. > > Thanks, Jan > lets write it like this: nr_pages = (bufflen + sgl[0].offset + PAGE_SIZE - 1) / PAGE_SIZE; now you say: nr_pages = (2 + (PAGE_SIZE-1) + PAGE_SIZE - 1) / PAGE_SIZE; which is (PAGE_SIZE + PAGE_SIZE) / PAGE_SIZE; No? What am I missing? Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
