Hi guys, I'm trying to understand the intended semantics behind se_dev_attrib.max_sectors and it seems that two different things are being conflated. On the one hand, we have the following code for VPD page B0h (block limits) handling: /* * Set MAXIMUM TRANSFER LENGTH */ put_unaligned_be32(dev->se_sub_dev->se_dev_attrib.max_sectors, &buf[8]); IOW we advertise max_sectors as the biggest IO an initiator should send us. OTOH iblock initializes max_sectors with: limits->max_hw_sectors = queue_max_hw_sectors(q); limits->max_sectors = queue_max_sectors(q); so max_sectors is limited to what the backend device handles. Now, there is various code that seems to be confused about what max_sectors means, eg in target_core_transport.c: dev_max_sectors = dev->se_sub_dev->se_dev_attrib.max_sectors; sector_size = dev->se_sub_dev->se_dev_attrib.block_size; WARN_ON(cmd->data_length % sector_size); lba = cmd->t_task_lba; sectors = DIV_ROUND_UP(cmd->data_length, sector_size); task_count = DIV_ROUND_UP_SECTOR_T(sectors, dev_max_sectors); that will allocate multiple tasks if an incoming command is bigger than max_sectors -- except we advertise our maximum transfer length as being max_sectors so anything bigger than max_sectors is illegal! And eg there is lonely transport_limit_task_sectors() with no callers... And then in target_core_iblock.c: bio = bio_alloc_bioset(GFP_NOIO, sg_num, ib_dev->ibd_bio_set); where sg_num is task->task_sg_nents. But that bio_alloc will always fail if sg_num > BIO_MAX_PAGES, ie 256. So my conclusion is that we really need a distinction between the backend max_sectors (ie what we use to decide how many tasks to allocate) and the frontend max_sectors (ie what we advertise to the initiator). Does it make sense split out the fields in se_dev_attrib for the two usages? And then independent of that we need to fix the bio allocation in iblock so that it is limited by BIO_MAX_PAGES. Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
