2015-04-13 13:59 GMT+09:00 Nicholas A. Bellinger <[email protected]>: > On Sat, 2015-04-11 at 13:17 +0900, Akinobu Mita wrote: >> The scatterlist for protection information which is passed to >> sbc_dif_verify_read() or sbc_dif_verify_write() requires that >> neighboring scatterlist entries are contiguous or chained so that they >> can be iterated by sg_next(). >> >> However, the protection information for RD-MCP backends could be located >> in the multiple scatterlist arrays when the ramdisk space is too large. >> So if the read/write request straddles this boundary, sbc_dif_verify_read() >> or sbc_dif_verify_write() can't iterate all scatterlist entries. >> >> This problem can be fixed by chaining protection information scatterlist >> at creation time. For the architectures which don't support sg chaining >> (i.e. !CONFIG_ARCH_HAS_SG_CHAIN), fix it by allocating temporary >> scatterlist if needed. >> >> Signed-off-by: Akinobu Mita <[email protected]> >> Cc: Nicholas Bellinger <[email protected]> >> Cc: Sagi Grimberg <[email protected]> >> Cc: "Martin K. Petersen" <[email protected]> >> Cc: Christoph Hellwig <[email protected]> >> Cc: "James E.J. Bottomley" <[email protected]> >> Cc: [email protected] >> Cc: [email protected] >> --- >> * v3 >> - Fix it by chaining protection information scatterlist at creation time >> if CONFIG_ARCH_HAS_SG_CHAIN is defined. >> >> drivers/target/target_core_rd.c | 67 >> +++++++++++++++++++++++++++++++++++++++-- >> 1 file changed, 64 insertions(+), 3 deletions(-) > > Applied to target-pending/for-next. > > Thanks for updating to use CONFIG_ARCH_HAS_SG_CHAIN for the common > case. :)
BTW, does anyone know why some architectures disable CONFIG_ARCH_HAS_SG_CHAIN? As far as I can see, there is no additional requirement to enable it for those that currently disable it. -- 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
