On 6/4/21 12:34 AM, Changheun Lee wrote:
>> On 2021/06/04 14:22, Changheun Lee wrote:
>>> +unsigned int bio_max_bytes(struct bio *bio)
>>> +{
>>> + struct block_device *bdev = bio->bi_bdev;
>>> +
>>> + return bdev ? bdev->bd_disk->queue->limits.max_bio_bytes : UINT_MAX;
>>> +}
>>
>> unsigned int bio_max_bytes(struct bio *bio)
>> {
>> struct block_device *bdev = bio->bi_bdev;
>>
>> if (!bdev)
>> return UINT_MAX;
>> return bdev->bd_disk->queue->limits.max_bio_bytes;
>> }
>>
>> is a lot more readable...
>> Also, I remember there was some problems with bd_disk possibly being null. Was
>> that fixed ?
>
> Thank you for review. But I'd like current style, and it's readable enough
> now I think. Null of bd_disk was just suspicion. bd_disk is not null if bdev
> is not null.
Damien is right. bd_disk can be NULL. From
https://lore.kernel.org/linux-block/20210425043020.30065-1-bvanassche@xxxxxxx/:
"bio_max_size() may get called before device_add_disk() and hence needs to
check whether or not the block device pointer is NULL. [ ... ]
This patch prevents that bio_max_size() triggers the following kernel
crash during a SCSI LUN scan:\
BUG: KASAN: null-ptr-deref in bio_add_hw_page+0xa6/0x310
Read of size 8 at addr 00000000000005a8 by task kworker/u16:0/7
Workqueue: events_unbound async_run_entry_fn
Call Trace:
show_stack+0x52/0x58
dump_stack+0x9d/0xcf
kasan_report.cold+0x4b/0x50
__asan_load8+0x69/0x90
bio_add_hw_page+0xa6/0x310
bio_add_pc_page+0xaa/0xe0
bio_map_kern+0xdc/0x1a0
blk_rq_map_kern+0xcd/0x2d0
__scsi_execute+0x9a/0x290 [scsi_mod]
scsi_probe_lun.constprop.0+0x17c/0x660 [scsi_mod]
scsi_probe_and_add_lun+0x178/0x750 [scsi_mod]
__scsi_add_device+0x18c/0x1a0 [scsi_mod]
ata_scsi_scan_host+0xe5/0x260 [libata]
async_port_probe+0x94/0xb0 [libata]
async_run_entry_fn+0x7d/0x2d0
process_one_work+0x582/0xac0
worker_thread+0x8f/0x5a0
kthread+0x222/0x250
ret_from_fork+0x1f/0x30"
Bart.
