2013/4/25 Martin K. Petersen <[email protected]>:
>>>>>> "Akinobu" == Akinobu Mita <[email protected]> writes:
>
> Akinobu> kmap_atomic() is now using stack based implementation and
> Akinobu> doesn't take the KM_type argument anymore. So nesting
> Akinobu> kmap_atomic() calls must be properly stacked.
>
> Akinobu> This fixes nesting kmap_atomic() calls for scsi_sglist and
> Akinobu> scsi_prot_sglist in prot_verify_write().
>
> I don't see how the prog_sglist is incorrectly nested? Also, with your
> code you also end up mapping and unmapping the protection page for every
> data segment. The two scatterlists have different cadence.
I meant that the unmapped address by kunmap_atomic() should be the
address returned by the last kmap_atomic() call which is not yet unmapped.
Because kmap_atomic was changed to stack based implementation.
Specifically,
/* For each data page */
scsi_for_each_sg(SCpnt, dsgl, scsi_sg_count(SCpnt), i) {
daddr = kmap_atomic(sg_page(dsgl)) + dsgl->offset;
This kmapped address 'daddr' will not unmapped during the next for-loop.
/* For each sector-sized chunk in data page */
for (j = 0 ; j < dsgl->length ; j += scsi_debug_sector_size) {
/* If we're at the end of the current
* protection page advance to the next one
*/
if (ppage_offset >= psgl->length) {
kunmap_atomic(paddr);
...
But this kunmap_atomic() for the first time in this loop is called.
The last two kmap_atomic() and kunmap_atomic() do not correspond and
it breaks kmap_atomic/kunmap_atomic stack.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
