Re: Potential data race in __scsi_init_queue/ata_sg_setup

From: Dmitry Vyukov
Date: Mon Sep 21 2015 - 06:09:14 EST

Next message: Jisheng Zhang: "[PATCH v2 5/6] arm64: dts: berlin4ct: add the pinctrl node"
Previous message: Jisheng Zhang: "[PATCH v2 4/6] pinctrl: dt-binding: document berlin4ct SoC pinctrl"
In reply to: Dmitry Vyukov: "Potential data race in __scsi_init_queue/ata_sg_setup"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Here is another data race in add_disk, maybe it is related.

ThreadSanitizer: data-race in sysfs_create_dir_ns

Write at 0xffff88048374eca8 of size 8 by thread 829 on CPU 4:
[<ffffffff813292eb>] sysfs_create_dir_ns+0x7b/0xd0 fs/sysfs/dir.c:63
[< inline >] create_dir lib/kobject.c:71
[<ffffffff8154cb75>] kobject_add_internal+0x165/0x4a0 lib/kobject.c:229
[< inline >] kobject_add_varg lib/kobject.c:352
[<ffffffff8154cf31>] kobject_add+0x81/0xe0 lib/kobject.c:397
[<ffffffff8151879c>] blk_register_queue+0xac/0x1a0 block/blk-sysfs.c:570
[<ffffffff8152f6a8>] add_disk+0x348/0x760 block/genhd.c:620
[<ffffffff818b72c8>] sd_probe_async+0x298/0x370 drivers/scsi/sd.c:2896
[<ffffffff810c038d>] async_run_entry_fn+0x7d/0x1e0 kernel/async.c:123
[<ffffffff810b1d6e>] process_one_work+0x47e/0x930 kernel/workqueue.c:2036
[<ffffffff810b22d0>] worker_thread+0xb0/0x900 kernel/workqueue.c:2170
[<ffffffff810bba40>] kthread+0x150/0x170 kernel/kthread.c:209
[<ffffffff81ee420f>] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:529

Previous read at 0xffff88048374eca8 of size 8 by thread 6 on CPU 7:
[<ffffffff81539d08>] bsg_register_queue+0x1a8/0x2a0 block/bsg.c:1021
[<ffffffff818a5ef4>] scsi_sysfs_add_sdev+0x164/0x340
drivers/scsi/scsi_sysfs.c:1044
[< inline >] scsi_add_lun drivers/scsi/scsi_scan.c:995
[<ffffffff818a1e5b>] scsi_probe_and_add_lun+0x116b/0x1180
drivers/scsi/scsi_scan.c:1157
[<ffffffff818a271d>] __scsi_add_device+0x13d/0x150
drivers/scsi/scsi_scan.c:1487
[<ffffffff818daf96>] ata_scsi_scan_host+0xf6/0x270
drivers/ata/libata-scsi.c:3736
[<ffffffff818d2f1e>] async_port_probe+0x6e/0x90 drivers/ata/libata-core.c:6096
[<ffffffff810c038d>] async_run_entry_fn+0x7d/0x1e0 kernel/async.c:123
[<ffffffff810b1d6e>] process_one_work+0x47e/0x930 kernel/workqueue.c:2036
[<ffffffff810b22d0>] worker_thread+0xb0/0x900 kernel/workqueue.c:2170
[<ffffffff810bba40>] kthread+0x150/0x170 kernel/kthread.c:209
[<ffffffff81ee420f>] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:529

The race is between:
if (q->kobj.sd) {
and:
kobj->sd = kn;

On Mon, Sep 21, 2015 at 11:58 AM, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
> Hello,
>
> We are working on a data race detector for kernel, KernelThreadSanitizer (KTSAN.
> I am getting the following reports (on 4.2 rc2) between
> __scsi_init_queue and ata_sg_setup. The reports suggest that
> dev->dma_parms->max_segment_size is being used before it is
> initialized. I would expect that request_queue somehow becomes
> accessible to other threads before all the associated data structures
> are completely initialized. I've tried to verify that hypothesis but
> got lost along the way.
> Can somebody familiar with this code please take a look? I will
> appreciate if you either confirm that this is a bug, or explain why
> this is not a bug (how the accesses are synchronized with each other).
> Thank you in advance.
>
>
> ThreadSanitizer: data-race in __scsi_init_queue
>
> Write at 0xffff880484c87070 of size 8 by thread 6 on CPU 0:
> [< inline >] dma_set_seg_boundary include/linux/dma-mapping.h:170
> [<ffffffff81899e81>] __scsi_init_queue+0x151/0x290 drivers/scsi/scsi_lib.c:2119
> [<ffffffff81899ff3>] __scsi_alloc_queue+0x33/0x40 drivers/scsi/scsi_lib.c:2142
> [<ffffffff8189f43c>] scsi_alloc_queue+0x2c/0x90 drivers/scsi/scsi_lib.c:2151
> [<ffffffff818a098f>] scsi_alloc_sdev+0x3cf/0x600 drivers/scsi/scsi_scan.c:266
> [<ffffffff818a1a24>] scsi_probe_and_add_lun+0xd34/0x1180
> drivers/scsi/scsi_scan.c:1079
> [<ffffffff818a271d>] __scsi_add_device+0x13d/0x150
> drivers/scsi/scsi_scan.c:1487
> [<ffffffff818daf96>] ata_scsi_scan_host+0xf6/0x270
> drivers/ata/libata-scsi.c:3736
> [<ffffffff818d2f1e>] async_port_probe+0x6e/0x90 drivers/ata/libata-core.c:6096
> [<ffffffff810c038d>] async_run_entry_fn+0x7d/0x1e0 kernel/async.c:123
> [<ffffffff810b1d6e>] process_one_work+0x47e/0x930 kernel/workqueue.c:2036
> [<ffffffff810b22d0>] worker_thread+0xb0/0x900 kernel/workqueue.c:2170
> [<ffffffff810bba40>] kthread+0x150/0x170 kernel/kthread.c:209
> [<ffffffff81ee420f>] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:529
>
> Previous read at 0xffff880484c87070 of size 8 by thread 763 on CPU 4:
> [< inline >] dma_get_seg_boundary include/linux/dma-mapping.h:164
> [<ffffffff815843c0>] swiotlb_tbl_map_single+0x70/0x410 lib/swiotlb.c:441
> [< inline >] map_single lib/swiotlb.c:546
> [<ffffffff81585972>] swiotlb_map_sg_attrs+0x172/0x240 lib/swiotlb.c:893
> [< inline >] dma_map_sg_attrs
> include/asm-generic/dma-mapping-common.h:57
> [< inline >] ata_sg_setup drivers/ata/libata-core.c:4719
> [<ffffffff818cb5e3>] ata_qc_issue+0x533/0x750 drivers/ata/libata-core.c:5078
> [<ffffffff818d5999>] ata_scsi_translate+0x189/0x2c0
> drivers/ata/libata-scsi.c:1864
> [< inline >] __ata_scsi_queuecmd drivers/ata/libata-scsi.c:3481
> [<ffffffff818da62e>] ata_scsi_queuecmd+0x11e/0x370
> drivers/ata/libata-scsi.c:3530
> [<ffffffff8189a1d3>] scsi_dispatch_cmd+0x183/0x2f0 drivers/scsi/scsi_lib.c:1718
> [<ffffffff8189e823>] scsi_request_fn+0x903/0xb20 drivers/scsi/scsi_lib.c:1853
> [< inline >] __blk_run_queue_uncond block/blk-core.c:310
> [<ffffffff8150c06f>] __blk_run_queue+0x6f/0xa0 block/blk-core.c:328
> [<ffffffff815099b1>] __elv_add_request+0x191/0x4e0 block/elevator.c:633
> [< inline >] add_acct_request block/blk-core.c:1336
> [<ffffffff81516911>] blk_queue_bio+0x511/0x520 block/blk-core.c:1710
> [<ffffffff8150e30b>] generic_make_request+0x17b/0x1f0 block/blk-core.c:1970
> [<ffffffff8150e432>] submit_bio+0xb2/0x250 block/blk-core.c:2022
> [<ffffffff812ba1fa>] submit_bh_wbc.isra.34+0x23a/0x270 fs/buffer.c:3068
> [< inline >] submit_bh fs/buffer.c:3080
> [<ffffffff812ba7ad>] block_read_full_page+0x3ad/0x440 fs/buffer.c:2262
> [<ffffffff812be784>] blkdev_readpage+0x24/0x40 fs/block_dev.c:294
> [< inline >] __read_cache_page mm/filemap.c:2188
> [<ffffffff811cd3a1>] do_read_cache_page+0x81/0x1d0 mm/filemap.c:2210
> [<ffffffff811cd535>] read_cache_page+0x45/0x60 mm/filemap.c:2257
> [< inline >] read_mapping_page include/linux/pagemap.h:381
> [<ffffffff81532798>] read_dev_sector+0x68/0xf0 block/partition-generic.c:557
> [< inline >] read_part_sector block/partitions/check.h:37
> [<ffffffff815344f0>] amiga_partition+0xa0/0x6a0 block/partitions/amiga.c:42
> [<ffffffff81534225>] check_partition+0x1b5/0x300 block/partitions/check.c:166
> [<ffffffff81533377>] rescan_partitions+0x127/0x400
> block/partition-generic.c:433 (discriminator 1)
> [<ffffffff812c0758>] __blkdev_get+0x418/0x650 fs/block_dev.c:1220
> [<ffffffff812c0e18>] blkdev_get+0x1c8/0x5f0 fs/block_dev.c:1324
> [< inline >] register_disk block/genhd.c:557
> [<ffffffff8152f9e8>] add_disk+0x688/0x760 block/genhd.c:619
> [<ffffffff818b72c8>] sd_probe_async+0x298/0x370 drivers/scsi/sd.c:2896
> [<ffffffff810c038d>] async_run_entry_fn+0x7d/0x1e0 kernel/async.c:123
> [<ffffffff810b1d6e>] process_one_work+0x47e/0x930 kernel/workqueue.c:2036
> [<ffffffff810b22d0>] worker_thread+0xb0/0x900 kernel/workqueue.c:2170
> [<ffffffff810bba40>] kthread+0x150/0x170 kernel/kthread.c:209
> [<ffffffff81ee420f>] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:529
>
> Mutexes locked by thread 6:
> Mutex 98677 is locked here:
> [<ffffffff81ee0407>] mutex_lock+0x57/0x70 kernel/locking/mutex.c:108
> [<ffffffff818a268c>] __scsi_add_device+0xac/0x150 drivers/scsi/scsi_scan.c:1482
> [<ffffffff818daf96>] ata_scsi_scan_host+0xf6/0x270
> drivers/ata/libata-scsi.c:3736
> [<ffffffff818d2f1e>] async_port_probe+0x6e/0x90 drivers/ata/libata-core.c:6096
> [<ffffffff810c038d>] async_run_entry_fn+0x7d/0x1e0 kernel/async.c:123
> [<ffffffff810b1d6e>] process_one_work+0x47e/0x930 kernel/workqueue.c:2036
> [<ffffffff810b22d0>] worker_thread+0xb0/0x900 kernel/workqueue.c:2170
> [<ffffffff810bba40>] kthread+0x150/0x170 kernel/kthread.c:209
> [<ffffffff81ee420f>] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:529
>
> Mutexes locked by thread 763:
> Mutex 106894 is locked here:
> [<ffffffff81ee0407>] mutex_lock+0x57/0x70 kernel/locking/mutex.c:108
> [<ffffffff812c03c7>] __blkdev_get+0x87/0x650 fs/block_dev.c:1177
> [<ffffffff812c0e18>] blkdev_get+0x1c8/0x5f0 fs/block_dev.c:1324
> [< inline >] register_disk block/genhd.c:557
> [<ffffffff8152f9e8>] add_disk+0x688/0x760 block/genhd.c:619
> [<ffffffff818b72c8>] sd_probe_async+0x298/0x370 drivers/scsi/sd.c:2896
> [<ffffffff810c038d>] async_run_entry_fn+0x7d/0x1e0 kernel/async.c:123
> [<ffffffff810b1d6e>] process_one_work+0x47e/0x930 kernel/workqueue.c:2036
> [<ffffffff810b22d0>] worker_thread+0xb0/0x900 kernel/workqueue.c:2170
> [<ffffffff810bba40>] kthread+0x150/0x170 kernel/kthread.c:209
> [<ffffffff81ee420f>] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:529
>
> Mutex 103680 is locked here:
> [< inline >] __raw_spin_lock_irqsave
> include/linux/spinlock_api_smp.h:129
> [<ffffffff81ee3b84>] _raw_spin_lock_irqsave+0x64/0x80
> kernel/locking/spinlock.c:159
> [<ffffffff818da567>] ata_scsi_queuecmd+0x57/0x370
> drivers/ata/libata-scsi.c:3524
> [<ffffffff8189a1d3>] scsi_dispatch_cmd+0x183/0x2f0 drivers/scsi/scsi_lib.c:1718
> [<ffffffff8189e823>] scsi_request_fn+0x903/0xb20 drivers/scsi/scsi_lib.c:1853
> [< inline >] __blk_run_queue_uncond block/blk-core.c:310
> [<ffffffff8150c06f>] __blk_run_queue+0x6f/0xa0 block/blk-core.c:328
> [<ffffffff815099b1>] __elv_add_request+0x191/0x4e0 block/elevator.c:633
> [< inline >] add_acct_request block/blk-core.c:1336
> [<ffffffff81516911>] blk_queue_bio+0x511/0x520 block/blk-core.c:1710
> [<ffffffff8150e30b>] generic_make_request+0x17b/0x1f0 block/blk-core.c:1970
> [<ffffffff8150e432>] submit_bio+0xb2/0x250 block/blk-core.c:2022
> [<ffffffff812ba1fa>] submit_bh_wbc.isra.34+0x23a/0x270 fs/buffer.c:3068
> [< inline >] submit_bh fs/buffer.c:3080
> [<ffffffff812ba7ad>] block_read_full_page+0x3ad/0x440 fs/buffer.c:2262
> [<ffffffff812be784>] blkdev_readpage+0x24/0x40 fs/block_dev.c:294
> [< inline >] __read_cache_page mm/filemap.c:2188
> [<ffffffff811cd3a1>] do_read_cache_page+0x81/0x1d0 mm/filemap.c:2210
> [<ffffffff811cd535>] read_cache_page+0x45/0x60 mm/filemap.c:2257
> [< inline >] read_mapping_page include/linux/pagemap.h:381
> [<ffffffff81532798>] read_dev_sector+0x68/0xf0 block/partition-generic.c:557
> [< inline >] read_part_sector block/partitions/check.h:37
> [<ffffffff815344f0>] amiga_partition+0xa0/0x6a0 block/partitions/amiga.c:42
> [<ffffffff81534225>] check_partition+0x1b5/0x300 block/partitions/check.c:166
> [<ffffffff81533377>] rescan_partitions+0x127/0x400
> block/partition-generic.c:433 (discriminator 1)
> [<ffffffff812c0758>] __blkdev_get+0x418/0x650 fs/block_dev.c:1220
> [<ffffffff812c0e18>] blkdev_get+0x1c8/0x5f0 fs/block_dev.c:1324
> [< inline >] register_disk block/genhd.c:557
> [<ffffffff8152f9e8>] add_disk+0x688/0x760 block/genhd.c:619
> [<ffffffff818b72c8>] sd_probe_async+0x298/0x370 drivers/scsi/sd.c:2896
> [<ffffffff810c038d>] async_run_entry_fn+0x7d/0x1e0 kernel/async.c:123
> [<ffffffff810b1d6e>] process_one_work+0x47e/0x930 kernel/workqueue.c:2036
> [<ffffffff810b22d0>] worker_thread+0xb0/0x900 kernel/workqueue.c:2170
> [<ffffffff810bba40>] kthread+0x150/0x170 kernel/kthread.c:209
> [<ffffffff81ee420f>] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:529
>
>
> --
> Dmitry Vyukov, Software Engineer, dvyukov@xxxxxxxxxx
> Google Germany GmbH, DienerstraÃe 12, 80331, MÃnchen
> GeschÃftsfÃhrer: Graham Law, Christine Elizabeth Flores
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat
> sind, leiten Sie diese bitte nicht weiter, informieren Sie den
> Absender und lÃschen Sie die E-Mail und alle AnhÃnge. Vielen Dank.
> This e-mail is confidential. If you are not the right addressee please
> do not forward it, please inform the sender, and please erase this
> e-mail including any attachments. Thanks.

--
Dmitry Vyukov, Software Engineer, dvyukov@xxxxxxxxxx
Google Germany GmbH, DienerstraÃe 12, 80331, MÃnchen
GeschÃftsfÃhrer: Graham Law, Christine Elizabeth Flores
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat
sind, leiten Sie diese bitte nicht weiter, informieren Sie den
Absender und lÃschen Sie die E-Mail und alle AnhÃnge. Vielen Dank.
This e-mail is confidential. If you are not the right addressee please
do not forward it, please inform the sender, and please erase this
e-mail including any attachments. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Next message: Jisheng Zhang: "[PATCH v2 5/6] arm64: dts: berlin4ct: add the pinctrl node"
Previous message: Jisheng Zhang: "[PATCH v2 4/6] pinctrl: dt-binding: document berlin4ct SoC pinctrl"
In reply to: Dmitry Vyukov: "Potential data race in __scsi_init_queue/ata_sg_setup"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]