Hotplug

Hotplug

[Jens Axboe]

Hi,

Been running some tests and I keep running into issues with hotplug.
This looks similar to what Bart posted the other day, but it looks
more deeply rooted than just having to protect the queue in
generic_make_request_checks(). The test run is blktests,
block/001. Current -git doesn't survive it. I've seen at least two
different oopses, pasted below.

[  102.163442] NULL pointer dereference at 0000000000000010
[  102.163444] PGD 0 P4D 0 
[  102.163447] Oops: 0000 [#1] PREEMPT SMP
[  102.163449] Modules linked in:
[  102.175540] sr 12:0:0:0: [sr2] scsi-1 drive
[  102.180112]  scsi_debug crc_t10dif crct10dif_generic crct10dif_common nvme nvme_core sb_edac xl
[  102.186934] sr 12:0:0:0: Attached scsi CD-ROM sr2
[  102.191896]  sr_mod cdrom btrfs xor zstd_decompress zstd_compress xxhash lzo_compress zlib_defc
[  102.197169] sr 12:0:0:0: Attached scsi generic sg7 type 5
[  102.203475]  igb ahci libahci i2c_algo_bit libata dca [last unloaded: crc_t10dif]
[  102.203484] CPU: 43 PID: 4629 Comm: systemd-udevd Not tainted 4.16.0+ #650
[  102.203487] Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016
[  102.350882] RIP: 0010:sr_block_revalidate_disk+0x23/0x190 [sr_mod]
[  102.358299] RSP: 0018:ffff883ff357bb58 EFLAGS: 00010292
[  102.364734] RAX: ffffffffa00b07d0 RBX: ffff883ff3058000 RCX: ffff883ff357bb66
[  102.373220] RDX: 0000000000000003 RSI: 0000000000007530 RDI: ffff881fea631000
[  102.381705] RBP: 0000000000000000 R08: ffff881fe4d38400 R09: 0000000000000000
[  102.390185] R10: 0000000000000000 R11: 00000000000001b6 R12: 000000000800005d
[  102.398671] R13: 000000000800005d R14: ffff883ffd9b3790 R15: 0000000000000000
[  102.407156] FS:  00007f7dc8e6d8c0(0000) GS:ffff883fff340000(0000) knlGS:0000000000000000
[  102.417138] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  102.424066] CR2: 0000000000000010 CR3: 0000003ffda98005 CR4: 00000000003606e0
[  102.432545] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  102.441024] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  102.449502] Call Trace:
[  102.452744]  ? __invalidate_device+0x48/0x60
[  102.458022]  check_disk_change+0x4c/0x60
[  102.462900]  sr_block_open+0x16/0xd0 [sr_mod]
[  102.468270]  __blkdev_get+0xb9/0x450
[  102.472774]  ? iget5_locked+0x1c0/0x1e0
[  102.477568]  blkdev_get+0x11e/0x320
[  102.481969]  ? bdget+0x11d/0x150
[  102.486083]  ? _raw_spin_unlock+0xa/0x20
[  102.490968]  ? bd_acquire+0xc0/0xc0
[  102.495368]  do_dentry_open+0x1b0/0x320
[  102.500159]  ? inode_permission+0x24/0xc0
[  102.505140]  path_openat+0x4e6/0x1420
[  102.509741]  ? cpumask_any_but+0x1f/0x40
[  102.514630]  ? flush_tlb_mm_range+0xa0/0x120
[  102.519903]  do_filp_open+0x8c/0xf0
[  102.524305]  ? __seccomp_filter+0x28/0x230
[  102.529389]  ? _raw_spin_unlock+0xa/0x20
[  102.534283]  ? __handle_mm_fault+0x7d6/0x9b0
[  102.539559]  ? list_lru_add+0xa8/0xc0
[  102.544157]  ? _raw_spin_unlock+0xa/0x20
[  102.549047]  ? __alloc_fd+0xaf/0x160
[  102.553549]  ? do_sys_open+0x1a6/0x230
[  102.558244]  do_sys_open+0x1a6/0x230
[  102.562742]  do_syscall_64+0x5a/0x100
[  102.567336]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2

and this one, similar to Barts:

[ 4676.738069] NULL pointer dereference at 0000000000000154
[ 4676.738071] PGD 0 P4D 0 
[ 4676.738073] Oops: 0000 [#1] PREEMPT SMP
[ 4676.738075] Modules linked in: scsi_debug crc_t10dif nvme nvme_core loop configfs crct10dif_ge]
[ 4676.859272] CPU: 10 PID: 16598 Comm: systemd-udevd Not tainted 4.16.0+ #651
[ 4676.867525] Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016
[ 4676.876765] RIP: 0010:blk_throtl_bio+0x45/0x9b0
[ 4676.882296] RSP: 0018:ffff881ff0c8bb38 EFLAGS: 00010246
[ 4676.888610] RAX: 0000000000000000 RBX: ffff881ffa273a40 RCX: 0000000000000000
[ 4676.897059] RDX: ffff881ffa273a40 RSI: 0000000000000000 RDI: 0000000000000000
[ 4676.905507] RBP: 0000000000000000 R08: ffff881ffa273ac0 R09: ffff881ff123f458
[ 4676.913955] R10: ffff881ff0c8bc70 R11: 0000000000001000 R12: 0000000000000000
[ 4676.922402] R13: ffffffff82600980 R14: ffff882081130000 R15: 0000000000000000
[ 4676.930856] FS:  00007fe63e5228c0(0000) GS:ffff881fff740000(0000) knlGS:0000000000000000
[ 4676.940773] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4676.947667] CR2: 0000000000000154 CR3: 0000001fed2a0003 CR4: 00000000003606e0
[ 4676.956116] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4676.964568] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 4676.973021] Call Trace:
[ 4676.976229]  generic_make_request_checks+0x640/0x660
[ 4676.982245]  ? kmem_cache_alloc+0x37/0x190
[ 4676.987295]  generic_make_request+0x29/0x2f0
[ 4676.992534]  ? submit_bio+0x5c/0x110
[ 4676.996998]  ? bio_alloc_bioset+0x99/0x1c0
[ 4677.002050]  submit_bio+0x5c/0x110
[ 4677.006317]  ? guard_bio_eod+0x42/0x120
[ 4677.011074]  submit_bh_wbc.isra.49+0x132/0x160
[ 4677.016517]  ? bh_uptodate_or_lock+0x90/0x90
[ 4677.021757]  block_read_full_page+0x216/0x330
[ 4677.027095]  ? check_disk_change+0x60/0x60
[ 4677.032144]  ? __atime_needs_update+0x7f/0x190
[ 4677.037576]  ? find_get_entry+0x98/0xf0
[ 4677.042329]  ? pagecache_get_page+0x30/0x220
[ 4677.047567]  ? touch_atime+0x27/0xb0
[ 4677.052029]  generic_file_read_iter+0x60b/0x970
[ 4677.057561]  ? _copy_to_user+0x56/0x70
[ 4677.062221]  ? __seccomp_filter+0x28/0x230
[ 4677.067269]  __vfs_read+0xd1/0x120
[ 4677.071539]  vfs_read+0x9b/0x140
[ 4677.075614]  ksys_read+0x45/0xa0
[ 4677.079686]  do_syscall_64+0x5a/0x100
[ 4677.084241]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 4677.090345] RIP: 0033:0x7fe63d6741f0
[ 4677.094808] RSP: 002b:00007ffcb901f918 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[ 4677.104143] RAX: ffffffffffffffda RBX: 000055b1645c33c0 RCX: 00007fe63d6741f0
[ 4677.112584] RDX: 0000000000000400 RSI: 000055b1645c33e8 RDI: 000000000000000f
[ 4677.121037] RBP: 000055b1645c32b0 R08: 00007fe63d65f008 R09: 0000000000000430
[ 4677.129489] R10: 000055b1645c33d8 R11: 0000000000000246 R12: 0000000000000000
[ 4677.137934] R13: 0000000000000400 R14: 000055b1645c3300 R15: 0000000000000400
[ 4677.146385] Code: 85 f6 74 4e 48 63 05 ab 33 d6 00 4c 8b bc c6 c8 02 00 00 0f b7 43 14 f6 c4 0 
[ 4677.168785] RIP: blk_throtl_bio+0x45/0x9b0 RSP: ffff881ff0c8bb38


-- 
Jens Axboe

Re: Hotplug

[Jan Kara]

Hi,

On Tue 10-04-18 11:17:46, Jens Axboe wrote:
> Been running some tests and I keep running into issues with hotplug.
> This looks similar to what Bart posted the other day, but it looks
> more deeply rooted than just having to protect the queue in
> generic_make_request_checks(). The test run is blktests,
> block/001. Current -git doesn't survive it. I've seen at least two
> different oopses, pasted below.
> 
> [  102.163442] NULL pointer dereference at 0000000000000010
> [  102.163444] PGD 0 P4D 0 
> [  102.163447] Oops: 0000 [#1] PREEMPT SMP
> [  102.163449] Modules linked in:
> [  102.175540] sr 12:0:0:0: [sr2] scsi-1 drive
> [  102.180112]  scsi_debug crc_t10dif crct10dif_generic crct10dif_common nvme nvme_core sb_edac xl
> [  102.186934] sr 12:0:0:0: Attached scsi CD-ROM sr2
> [  102.191896]  sr_mod cdrom btrfs xor zstd_decompress zstd_compress xxhash lzo_compress zlib_defc
> [  102.197169] sr 12:0:0:0: Attached scsi generic sg7 type 5
> [  102.203475]  igb ahci libahci i2c_algo_bit libata dca [last unloaded: crc_t10dif]
> [  102.203484] CPU: 43 PID: 4629 Comm: systemd-udevd Not tainted 4.16.0+ #650
> [  102.203487] Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016
> [  102.350882] RIP: 0010:sr_block_revalidate_disk+0x23/0x190 [sr_mod]
> [  102.358299] RSP: 0018:ffff883ff357bb58 EFLAGS: 00010292
> [  102.364734] RAX: ffffffffa00b07d0 RBX: ffff883ff3058000 RCX: ffff883ff357bb66
> [  102.373220] RDX: 0000000000000003 RSI: 0000000000007530 RDI: ffff881fea631000
> [  102.381705] RBP: 0000000000000000 R08: ffff881fe4d38400 R09: 0000000000000000
> [  102.390185] R10: 0000000000000000 R11: 00000000000001b6 R12: 000000000800005d
> [  102.398671] R13: 000000000800005d R14: ffff883ffd9b3790 R15: 0000000000000000
> [  102.407156] FS:  00007f7dc8e6d8c0(0000) GS:ffff883fff340000(0000) knlGS:0000000000000000
> [  102.417138] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [  102.424066] CR2: 0000000000000010 CR3: 0000003ffda98005 CR4: 00000000003606e0
> [  102.432545] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  102.441024] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [  102.449502] Call Trace:
> [  102.452744]  ? __invalidate_device+0x48/0x60
> [  102.458022]  check_disk_change+0x4c/0x60
> [  102.462900]  sr_block_open+0x16/0xd0 [sr_mod]
> [  102.468270]  __blkdev_get+0xb9/0x450
> [  102.472774]  ? iget5_locked+0x1c0/0x1e0
> [  102.477568]  blkdev_get+0x11e/0x320
> [  102.481969]  ? bdget+0x11d/0x150
> [  102.486083]  ? _raw_spin_unlock+0xa/0x20
> [  102.490968]  ? bd_acquire+0xc0/0xc0
> [  102.495368]  do_dentry_open+0x1b0/0x320
> [  102.500159]  ? inode_permission+0x24/0xc0
> [  102.505140]  path_openat+0x4e6/0x1420
> [  102.509741]  ? cpumask_any_but+0x1f/0x40
> [  102.514630]  ? flush_tlb_mm_range+0xa0/0x120
> [  102.519903]  do_filp_open+0x8c/0xf0
> [  102.524305]  ? __seccomp_filter+0x28/0x230
> [  102.529389]  ? _raw_spin_unlock+0xa/0x20
> [  102.534283]  ? __handle_mm_fault+0x7d6/0x9b0
> [  102.539559]  ? list_lru_add+0xa8/0xc0
> [  102.544157]  ? _raw_spin_unlock+0xa/0x20
> [  102.549047]  ? __alloc_fd+0xaf/0x160
> [  102.553549]  ? do_sys_open+0x1a6/0x230
> [  102.558244]  do_sys_open+0x1a6/0x230
> [  102.562742]  do_syscall_64+0x5a/0x100
> [  102.567336]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2

Interesting. Thinking out loud: This is cd->device dereference I guess
which means disk->private_data was NULL. That gets set in sr_probe()
together with disk->fops which are certainly set as they must have led us
to the crashing function sr_block_revalidate_disk(). So likely
disk->private_data got already cleared. That happens in sr_kref_release()
and the fact that that function got called means struct scsi_cd went away -
so sr_remove() must have been called as well. That all seems possible like:

CPU1		CPU2
sr_probe()
		__blkdev_get()
		  disk = bdev_get_gendisk();
<device removed>
sr_remove()
  del_gendisk()
  ...
  kref_put(&cd->kref, sr_kref_release);
    disk->private_data = NULL;
    put_disk(disk);
    kfree(cd);
		  if (disk->fops->open) {
		    ret = disk->fops->open(bdev, mode); => sr_block_open
		      check_disk_change(bdev);
		        sr_block_revalidate_disk()
			  CRASH

And I think the problem is in sr_block_revalidate_disk() itself as the
scsi_cd() call is not guaranteed that the caller holds reference to 'cd'
and thus that 'cd' does not disappear under it. IMHO it needs to use
scsi_cd_get() to get struct scsi_cd from gendisk. Am I missing something?

> and this one, similar to Barts:
> 
> [ 4676.738069] NULL pointer dereference at 0000000000000154
> [ 4676.738071] PGD 0 P4D 0 
> [ 4676.738073] Oops: 0000 [#1] PREEMPT SMP
> [ 4676.738075] Modules linked in: scsi_debug crc_t10dif nvme nvme_core loop configfs crct10dif_ge]
> [ 4676.859272] CPU: 10 PID: 16598 Comm: systemd-udevd Not tainted 4.16.0+ #651
> [ 4676.867525] Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016
> [ 4676.876765] RIP: 0010:blk_throtl_bio+0x45/0x9b0
> [ 4676.882296] RSP: 0018:ffff881ff0c8bb38 EFLAGS: 00010246
> [ 4676.888610] RAX: 0000000000000000 RBX: ffff881ffa273a40 RCX: 0000000000000000
> [ 4676.897059] RDX: ffff881ffa273a40 RSI: 0000000000000000 RDI: 0000000000000000
> [ 4676.905507] RBP: 0000000000000000 R08: ffff881ffa273ac0 R09: ffff881ff123f458
> [ 4676.913955] R10: ffff881ff0c8bc70 R11: 0000000000001000 R12: 0000000000000000
> [ 4676.922402] R13: ffffffff82600980 R14: ffff882081130000 R15: 0000000000000000
> [ 4676.930856] FS:  00007fe63e5228c0(0000) GS:ffff881fff740000(0000) knlGS:0000000000000000
> [ 4676.940773] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 4676.947667] CR2: 0000000000000154 CR3: 0000001fed2a0003 CR4: 00000000003606e0
> [ 4676.956116] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 4676.964568] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 4676.973021] Call Trace:
> [ 4676.976229]  generic_make_request_checks+0x640/0x660
> [ 4676.982245]  ? kmem_cache_alloc+0x37/0x190
> [ 4676.987295]  generic_make_request+0x29/0x2f0
> [ 4676.992534]  ? submit_bio+0x5c/0x110
> [ 4676.996998]  ? bio_alloc_bioset+0x99/0x1c0
> [ 4677.002050]  submit_bio+0x5c/0x110
> [ 4677.006317]  ? guard_bio_eod+0x42/0x120
> [ 4677.011074]  submit_bh_wbc.isra.49+0x132/0x160
> [ 4677.016517]  ? bh_uptodate_or_lock+0x90/0x90
> [ 4677.021757]  block_read_full_page+0x216/0x330
> [ 4677.027095]  ? check_disk_change+0x60/0x60
> [ 4677.032144]  ? __atime_needs_update+0x7f/0x190
> [ 4677.037576]  ? find_get_entry+0x98/0xf0
> [ 4677.042329]  ? pagecache_get_page+0x30/0x220
> [ 4677.047567]  ? touch_atime+0x27/0xb0
> [ 4677.052029]  generic_file_read_iter+0x60b/0x970
> [ 4677.057561]  ? _copy_to_user+0x56/0x70
> [ 4677.062221]  ? __seccomp_filter+0x28/0x230
> [ 4677.067269]  __vfs_read+0xd1/0x120
> [ 4677.071539]  vfs_read+0x9b/0x140
> [ 4677.075614]  ksys_read+0x45/0xa0
> [ 4677.079686]  do_syscall_64+0x5a/0x100
> [ 4677.084241]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> [ 4677.090345] RIP: 0033:0x7fe63d6741f0
> [ 4677.094808] RSP: 002b:00007ffcb901f918 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
> [ 4677.104143] RAX: ffffffffffffffda RBX: 000055b1645c33c0 RCX: 00007fe63d6741f0
> [ 4677.112584] RDX: 0000000000000400 RSI: 000055b1645c33e8 RDI: 000000000000000f
> [ 4677.121037] RBP: 000055b1645c32b0 R08: 00007fe63d65f008 R09: 0000000000000430
> [ 4677.129489] R10: 000055b1645c33d8 R11: 0000000000000246 R12: 0000000000000000
> [ 4677.137934] R13: 0000000000000400 R14: 000055b1645c3300 R15: 0000000000000400
> [ 4677.146385] Code: 85 f6 74 4e 48 63 05 ab 33 d6 00 4c 8b bc c6 c8 02 00 00 0f b7 43 14 f6 c4 0 
> [ 4677.168785] RIP: blk_throtl_bio+0x45/0x9b0 RSP: ffff881ff0c8bb38

I'm not really sure where this is crashing and 'Code' line is incomplete to
tell me.

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: Hotplug

[Bart Van Assche]

T24gV2VkLCAyMDE4LTA0LTExIGF0IDE1OjU4ICswMjAwLCBKYW4gS2FyYSB3cm90ZToNCj4gSSdt
IG5vdCByZWFsbHkgc3VyZSB3aGVyZSB0aGlzIGlzIGNyYXNoaW5nIGFuZCAnQ29kZScgbGluZSBp
cyBpbmNvbXBsZXRlIHRvDQo+IHRlbGwgbWUuDQoNCkhlbGxvIEphbiwNCg0KVGhlIGZvbGxvd2lu
ZyBwYXRjaCBzaG91bGQgZml4IHRoaXMgY3Jhc2g6DQpodHRwczovL3d3dy5tYWlsLWFyY2hpdmUu
Y29tL2xpbnV4LWJsb2NrQHZnZXIua2VybmVsLm9yZy9tc2cyMDIwOS5odG1sLg0KDQpUaGFua3Ms
DQoNCkJhcnQuDQoNCg0K

Re: Hotplug

[Jens Axboe]

On 4/11/18 7:58 AM, Jan Kara wrote:
> Hi,
> 
> On Tue 10-04-18 11:17:46, Jens Axboe wrote:
>> Been running some tests and I keep running into issues with hotplug.
>> This looks similar to what Bart posted the other day, but it looks
>> more deeply rooted than just having to protect the queue in
>> generic_make_request_checks(). The test run is blktests,
>> block/001. Current -git doesn't survive it. I've seen at least two
>> different oopses, pasted below.
>>
>> [  102.163442] NULL pointer dereference at 0000000000000010
>> [  102.163444] PGD 0 P4D 0 
>> [  102.163447] Oops: 0000 [#1] PREEMPT SMP
>> [  102.163449] Modules linked in:
>> [  102.175540] sr 12:0:0:0: [sr2] scsi-1 drive
>> [  102.180112]  scsi_debug crc_t10dif crct10dif_generic crct10dif_common nvme nvme_core sb_edac xl
>> [  102.186934] sr 12:0:0:0: Attached scsi CD-ROM sr2
>> [  102.191896]  sr_mod cdrom btrfs xor zstd_decompress zstd_compress xxhash lzo_compress zlib_defc
>> [  102.197169] sr 12:0:0:0: Attached scsi generic sg7 type 5
>> [  102.203475]  igb ahci libahci i2c_algo_bit libata dca [last unloaded: crc_t10dif]
>> [  102.203484] CPU: 43 PID: 4629 Comm: systemd-udevd Not tainted 4.16.0+ #650
>> [  102.203487] Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016
>> [  102.350882] RIP: 0010:sr_block_revalidate_disk+0x23/0x190 [sr_mod]
>> [  102.358299] RSP: 0018:ffff883ff357bb58 EFLAGS: 00010292
>> [  102.364734] RAX: ffffffffa00b07d0 RBX: ffff883ff3058000 RCX: ffff883ff357bb66
>> [  102.373220] RDX: 0000000000000003 RSI: 0000000000007530 RDI: ffff881fea631000
>> [  102.381705] RBP: 0000000000000000 R08: ffff881fe4d38400 R09: 0000000000000000
>> [  102.390185] R10: 0000000000000000 R11: 00000000000001b6 R12: 000000000800005d
>> [  102.398671] R13: 000000000800005d R14: ffff883ffd9b3790 R15: 0000000000000000
>> [  102.407156] FS:  00007f7dc8e6d8c0(0000) GS:ffff883fff340000(0000) knlGS:0000000000000000
>> [  102.417138] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [  102.424066] CR2: 0000000000000010 CR3: 0000003ffda98005 CR4: 00000000003606e0
>> [  102.432545] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  102.441024] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> [  102.449502] Call Trace:
>> [  102.452744]  ? __invalidate_device+0x48/0x60
>> [  102.458022]  check_disk_change+0x4c/0x60
>> [  102.462900]  sr_block_open+0x16/0xd0 [sr_mod]
>> [  102.468270]  __blkdev_get+0xb9/0x450
>> [  102.472774]  ? iget5_locked+0x1c0/0x1e0
>> [  102.477568]  blkdev_get+0x11e/0x320
>> [  102.481969]  ? bdget+0x11d/0x150
>> [  102.486083]  ? _raw_spin_unlock+0xa/0x20
>> [  102.490968]  ? bd_acquire+0xc0/0xc0
>> [  102.495368]  do_dentry_open+0x1b0/0x320
>> [  102.500159]  ? inode_permission+0x24/0xc0
>> [  102.505140]  path_openat+0x4e6/0x1420
>> [  102.509741]  ? cpumask_any_but+0x1f/0x40
>> [  102.514630]  ? flush_tlb_mm_range+0xa0/0x120
>> [  102.519903]  do_filp_open+0x8c/0xf0
>> [  102.524305]  ? __seccomp_filter+0x28/0x230
>> [  102.529389]  ? _raw_spin_unlock+0xa/0x20
>> [  102.534283]  ? __handle_mm_fault+0x7d6/0x9b0
>> [  102.539559]  ? list_lru_add+0xa8/0xc0
>> [  102.544157]  ? _raw_spin_unlock+0xa/0x20
>> [  102.549047]  ? __alloc_fd+0xaf/0x160
>> [  102.553549]  ? do_sys_open+0x1a6/0x230
>> [  102.558244]  do_sys_open+0x1a6/0x230
>> [  102.562742]  do_syscall_64+0x5a/0x100
>> [  102.567336]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> 
> Interesting. Thinking out loud: This is cd->device dereference I guess
> which means disk->private_data was NULL. That gets set in sr_probe()
> together with disk->fops which are certainly set as they must have led us
> to the crashing function sr_block_revalidate_disk(). So likely
> disk->private_data got already cleared. That happens in sr_kref_release()
> and the fact that that function got called means struct scsi_cd went away -
> so sr_remove() must have been called as well. That all seems possible like:
> 
> CPU1		CPU2
> sr_probe()
> 		__blkdev_get()
> 		  disk = bdev_get_gendisk();
> <device removed>
> sr_remove()
>   del_gendisk()
>   ...
>   kref_put(&cd->kref, sr_kref_release);
>     disk->private_data = NULL;
>     put_disk(disk);
>     kfree(cd);
> 		  if (disk->fops->open) {
> 		    ret = disk->fops->open(bdev, mode); => sr_block_open
> 		      check_disk_change(bdev);
> 		        sr_block_revalidate_disk()
> 			  CRASH
> 
> And I think the problem is in sr_block_revalidate_disk() itself as the
> scsi_cd() call is not guaranteed that the caller holds reference to 'cd'
> and thus that 'cd' does not disappear under it. IMHO it needs to use
> scsi_cd_get() to get struct scsi_cd from gendisk. Am I missing something?

No I think you are correct, from the revalidate path it should grab/release
a reference. Looks like sr_block_check_events() needs the same treatment.
How about the below?

>> [ 4677.146385] Code: 85 f6 74 4e 48 63 05 ab 33 d6 00 4c 8b bc c6 c8 02 00 00 0f b7 43 14 f6 c4 0 
>> [ 4677.168785] RIP: blk_throtl_bio+0x45/0x9b0 RSP: ffff881ff0c8bb38
> 
> I'm not really sure where this is crashing and 'Code' line is incomplete to
> tell me.

This one was already in progress, different fix there.


diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 0cf25d789d05..3f3cb72e0c0c 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -587,18 +587,28 @@ static int sr_block_ioctl(struct block_device *bdev, fmode_t mode, unsigned cmd,
 static unsigned int sr_block_check_events(struct gendisk *disk,
 					  unsigned int clearing)
 {
-	struct scsi_cd *cd = scsi_cd(disk);
+	unsigned int ret = 0;
+	struct scsi_cd *cd;
 
-	if (atomic_read(&cd->device->disk_events_disable_depth))
+	cd = scsi_cd_get(disk);
+	if (!cd)
 		return 0;
 
-	return cdrom_check_events(&cd->cdi, clearing);
+	if (!atomic_read(&cd->device->disk_events_disable_depth))
+		ret = cdrom_check_events(&cd->cdi, clearing);
+
+	scsi_cd_put(cd);
+	return ret;
 }
 
 static int sr_block_revalidate_disk(struct gendisk *disk)
 {
-	struct scsi_cd *cd = scsi_cd(disk);
 	struct scsi_sense_hdr sshdr;
+	struct scsi_cd *cd;
+
+	cd = scsi_cd_get(disk);
+	if (!cd)
+		return -ENXIO;
 
 	/* if the unit is not ready, nothing more to do */
 	if (scsi_test_unit_ready(cd->device, SR_TIMEOUT, MAX_RETRIES, &sshdr))
@@ -607,6 +617,7 @@ static int sr_block_revalidate_disk(struct gendisk *disk)
 	sr_cd_check(&cd->cdi);
 	get_sectorsize(cd);
 out:
+	scsi_cd_put(cd);
 	return 0;
 }
 

-- 
Jens Axboe

Re: Hotplug

[Jens Axboe]

On 4/11/18 8:06 AM, Bart Van Assche wrote:
> On Wed, 2018-04-11 at 15:58 +0200, Jan Kara wrote:
>> I'm not really sure where this is crashing and 'Code' line is incomplete to
>> tell me.
> 
> Hello Jan,
> 
> The following patch should fix this crash:
> https://www.mail-archive.com/linux-block@vger.kernel.org/msg20209.html.

Yeah, I forgot the link in my reply, thanks.

-- 
Jens Axboe

Re: Hotplug

[Jan Kara]

Hello,

On Wed 11-04-18 08:11:13, Jens Axboe wrote:
> On 4/11/18 7:58 AM, Jan Kara wrote:
> > On Tue 10-04-18 11:17:46, Jens Axboe wrote:
> >> Been running some tests and I keep running into issues with hotplug.
> >> This looks similar to what Bart posted the other day, but it looks
> >> more deeply rooted than just having to protect the queue in
> >> generic_make_request_checks(). The test run is blktests,
> >> block/001. Current -git doesn't survive it. I've seen at least two
> >> different oopses, pasted below.
> >>
> >> [  102.163442] NULL pointer dereference at 0000000000000010
> >> [  102.163444] PGD 0 P4D 0 
> >> [  102.163447] Oops: 0000 [#1] PREEMPT SMP
> >> [  102.163449] Modules linked in:
> >> [  102.175540] sr 12:0:0:0: [sr2] scsi-1 drive
> >> [  102.180112]  scsi_debug crc_t10dif crct10dif_generic crct10dif_common nvme nvme_core sb_edac xl
> >> [  102.186934] sr 12:0:0:0: Attached scsi CD-ROM sr2
> >> [  102.191896]  sr_mod cdrom btrfs xor zstd_decompress zstd_compress xxhash lzo_compress zlib_defc
> >> [  102.197169] sr 12:0:0:0: Attached scsi generic sg7 type 5
> >> [  102.203475]  igb ahci libahci i2c_algo_bit libata dca [last unloaded: crc_t10dif]
> >> [  102.203484] CPU: 43 PID: 4629 Comm: systemd-udevd Not tainted 4.16.0+ #650
> >> [  102.203487] Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016
> >> [  102.350882] RIP: 0010:sr_block_revalidate_disk+0x23/0x190 [sr_mod]
> >> [  102.358299] RSP: 0018:ffff883ff357bb58 EFLAGS: 00010292
> >> [  102.364734] RAX: ffffffffa00b07d0 RBX: ffff883ff3058000 RCX: ffff883ff357bb66
> >> [  102.373220] RDX: 0000000000000003 RSI: 0000000000007530 RDI: ffff881fea631000
> >> [  102.381705] RBP: 0000000000000000 R08: ffff881fe4d38400 R09: 0000000000000000
> >> [  102.390185] R10: 0000000000000000 R11: 00000000000001b6 R12: 000000000800005d
> >> [  102.398671] R13: 000000000800005d R14: ffff883ffd9b3790 R15: 0000000000000000
> >> [  102.407156] FS:  00007f7dc8e6d8c0(0000) GS:ffff883fff340000(0000) knlGS:0000000000000000
> >> [  102.417138] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >> [  102.424066] CR2: 0000000000000010 CR3: 0000003ffda98005 CR4: 00000000003606e0
> >> [  102.432545] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> [  102.441024] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> >> [  102.449502] Call Trace:
> >> [  102.452744]  ? __invalidate_device+0x48/0x60
> >> [  102.458022]  check_disk_change+0x4c/0x60
> >> [  102.462900]  sr_block_open+0x16/0xd0 [sr_mod]
> >> [  102.468270]  __blkdev_get+0xb9/0x450
> >> [  102.472774]  ? iget5_locked+0x1c0/0x1e0
> >> [  102.477568]  blkdev_get+0x11e/0x320
> >> [  102.481969]  ? bdget+0x11d/0x150
> >> [  102.486083]  ? _raw_spin_unlock+0xa/0x20
> >> [  102.490968]  ? bd_acquire+0xc0/0xc0
> >> [  102.495368]  do_dentry_open+0x1b0/0x320
> >> [  102.500159]  ? inode_permission+0x24/0xc0
> >> [  102.505140]  path_openat+0x4e6/0x1420
> >> [  102.509741]  ? cpumask_any_but+0x1f/0x40
> >> [  102.514630]  ? flush_tlb_mm_range+0xa0/0x120
> >> [  102.519903]  do_filp_open+0x8c/0xf0
> >> [  102.524305]  ? __seccomp_filter+0x28/0x230
> >> [  102.529389]  ? _raw_spin_unlock+0xa/0x20
> >> [  102.534283]  ? __handle_mm_fault+0x7d6/0x9b0
> >> [  102.539559]  ? list_lru_add+0xa8/0xc0
> >> [  102.544157]  ? _raw_spin_unlock+0xa/0x20
> >> [  102.549047]  ? __alloc_fd+0xaf/0x160
> >> [  102.553549]  ? do_sys_open+0x1a6/0x230
> >> [  102.558244]  do_sys_open+0x1a6/0x230
> >> [  102.562742]  do_syscall_64+0x5a/0x100
> >> [  102.567336]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> > 
> > Interesting. Thinking out loud: This is cd->device dereference I guess
> > which means disk->private_data was NULL. That gets set in sr_probe()
> > together with disk->fops which are certainly set as they must have led us
> > to the crashing function sr_block_revalidate_disk(). So likely
> > disk->private_data got already cleared. That happens in sr_kref_release()
> > and the fact that that function got called means struct scsi_cd went away -
> > so sr_remove() must have been called as well. That all seems possible like:
> > 
> > CPU1		CPU2
> > sr_probe()
> > 		__blkdev_get()
> > 		  disk = bdev_get_gendisk();
> > <device removed>
> > sr_remove()
> >   del_gendisk()
> >   ...
> >   kref_put(&cd->kref, sr_kref_release);
> >     disk->private_data = NULL;
> >     put_disk(disk);
> >     kfree(cd);
> > 		  if (disk->fops->open) {
> > 		    ret = disk->fops->open(bdev, mode); => sr_block_open
> > 		      check_disk_change(bdev);
> > 		        sr_block_revalidate_disk()
> > 			  CRASH
> > 
> > And I think the problem is in sr_block_revalidate_disk() itself as the
> > scsi_cd() call is not guaranteed that the caller holds reference to 'cd'
> > and thus that 'cd' does not disappear under it. IMHO it needs to use
> > scsi_cd_get() to get struct scsi_cd from gendisk. Am I missing something?
> 
> No I think you are correct, from the revalidate path it should grab/release
> a reference. Looks like sr_block_check_events() needs the same treatment.
> How about the below?
 
Yeah, that looks good to me except one thing:

> diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
> index 0cf25d789d05..3f3cb72e0c0c 100644
> --- a/drivers/scsi/sr.c
> +++ b/drivers/scsi/sr.c
>  static int sr_block_revalidate_disk(struct gendisk *disk)
>  {
> -	struct scsi_cd *cd = scsi_cd(disk);
>  	struct scsi_sense_hdr sshdr;
> +	struct scsi_cd *cd;
> +
> +	cd = scsi_cd_get(disk);
> +	if (!cd)
> +		return -ENXIO;

So if this returns -ENXIO I somewhat wonder about the code in
fs/block_dev.c: revalidate_disk(). Why do we do all the work there and then
return -ENXIO?

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: Hotplug

[Jens Axboe]

On 4/11/18 10:14 AM, Jan Kara wrote:
> Hello,
> 
> On Wed 11-04-18 08:11:13, Jens Axboe wrote:
>> On 4/11/18 7:58 AM, Jan Kara wrote:
>>> On Tue 10-04-18 11:17:46, Jens Axboe wrote:
>>>> Been running some tests and I keep running into issues with hotplug.
>>>> This looks similar to what Bart posted the other day, but it looks
>>>> more deeply rooted than just having to protect the queue in
>>>> generic_make_request_checks(). The test run is blktests,
>>>> block/001. Current -git doesn't survive it. I've seen at least two
>>>> different oopses, pasted below.
>>>>
>>>> [  102.163442] NULL pointer dereference at 0000000000000010
>>>> [  102.163444] PGD 0 P4D 0 
>>>> [  102.163447] Oops: 0000 [#1] PREEMPT SMP
>>>> [  102.163449] Modules linked in:
>>>> [  102.175540] sr 12:0:0:0: [sr2] scsi-1 drive
>>>> [  102.180112]  scsi_debug crc_t10dif crct10dif_generic crct10dif_common nvme nvme_core sb_edac xl
>>>> [  102.186934] sr 12:0:0:0: Attached scsi CD-ROM sr2
>>>> [  102.191896]  sr_mod cdrom btrfs xor zstd_decompress zstd_compress xxhash lzo_compress zlib_defc
>>>> [  102.197169] sr 12:0:0:0: Attached scsi generic sg7 type 5
>>>> [  102.203475]  igb ahci libahci i2c_algo_bit libata dca [last unloaded: crc_t10dif]
>>>> [  102.203484] CPU: 43 PID: 4629 Comm: systemd-udevd Not tainted 4.16.0+ #650
>>>> [  102.203487] Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016
>>>> [  102.350882] RIP: 0010:sr_block_revalidate_disk+0x23/0x190 [sr_mod]
>>>> [  102.358299] RSP: 0018:ffff883ff357bb58 EFLAGS: 00010292
>>>> [  102.364734] RAX: ffffffffa00b07d0 RBX: ffff883ff3058000 RCX: ffff883ff357bb66
>>>> [  102.373220] RDX: 0000000000000003 RSI: 0000000000007530 RDI: ffff881fea631000
>>>> [  102.381705] RBP: 0000000000000000 R08: ffff881fe4d38400 R09: 0000000000000000
>>>> [  102.390185] R10: 0000000000000000 R11: 00000000000001b6 R12: 000000000800005d
>>>> [  102.398671] R13: 000000000800005d R14: ffff883ffd9b3790 R15: 0000000000000000
>>>> [  102.407156] FS:  00007f7dc8e6d8c0(0000) GS:ffff883fff340000(0000) knlGS:0000000000000000
>>>> [  102.417138] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>> [  102.424066] CR2: 0000000000000010 CR3: 0000003ffda98005 CR4: 00000000003606e0
>>>> [  102.432545] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>>> [  102.441024] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>>>> [  102.449502] Call Trace:
>>>> [  102.452744]  ? __invalidate_device+0x48/0x60
>>>> [  102.458022]  check_disk_change+0x4c/0x60
>>>> [  102.462900]  sr_block_open+0x16/0xd0 [sr_mod]
>>>> [  102.468270]  __blkdev_get+0xb9/0x450
>>>> [  102.472774]  ? iget5_locked+0x1c0/0x1e0
>>>> [  102.477568]  blkdev_get+0x11e/0x320
>>>> [  102.481969]  ? bdget+0x11d/0x150
>>>> [  102.486083]  ? _raw_spin_unlock+0xa/0x20
>>>> [  102.490968]  ? bd_acquire+0xc0/0xc0
>>>> [  102.495368]  do_dentry_open+0x1b0/0x320
>>>> [  102.500159]  ? inode_permission+0x24/0xc0
>>>> [  102.505140]  path_openat+0x4e6/0x1420
>>>> [  102.509741]  ? cpumask_any_but+0x1f/0x40
>>>> [  102.514630]  ? flush_tlb_mm_range+0xa0/0x120
>>>> [  102.519903]  do_filp_open+0x8c/0xf0
>>>> [  102.524305]  ? __seccomp_filter+0x28/0x230
>>>> [  102.529389]  ? _raw_spin_unlock+0xa/0x20
>>>> [  102.534283]  ? __handle_mm_fault+0x7d6/0x9b0
>>>> [  102.539559]  ? list_lru_add+0xa8/0xc0
>>>> [  102.544157]  ? _raw_spin_unlock+0xa/0x20
>>>> [  102.549047]  ? __alloc_fd+0xaf/0x160
>>>> [  102.553549]  ? do_sys_open+0x1a6/0x230
>>>> [  102.558244]  do_sys_open+0x1a6/0x230
>>>> [  102.562742]  do_syscall_64+0x5a/0x100
>>>> [  102.567336]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>>>
>>> Interesting. Thinking out loud: This is cd->device dereference I guess
>>> which means disk->private_data was NULL. That gets set in sr_probe()
>>> together with disk->fops which are certainly set as they must have led us
>>> to the crashing function sr_block_revalidate_disk(). So likely
>>> disk->private_data got already cleared. That happens in sr_kref_release()
>>> and the fact that that function got called means struct scsi_cd went away -
>>> so sr_remove() must have been called as well. That all seems possible like:
>>>
>>> CPU1		CPU2
>>> sr_probe()
>>> 		__blkdev_get()
>>> 		  disk = bdev_get_gendisk();
>>> <device removed>
>>> sr_remove()
>>>   del_gendisk()
>>>   ...
>>>   kref_put(&cd->kref, sr_kref_release);
>>>     disk->private_data = NULL;
>>>     put_disk(disk);
>>>     kfree(cd);
>>> 		  if (disk->fops->open) {
>>> 		    ret = disk->fops->open(bdev, mode); => sr_block_open
>>> 		      check_disk_change(bdev);
>>> 		        sr_block_revalidate_disk()
>>> 			  CRASH
>>>
>>> And I think the problem is in sr_block_revalidate_disk() itself as the
>>> scsi_cd() call is not guaranteed that the caller holds reference to 'cd'
>>> and thus that 'cd' does not disappear under it. IMHO it needs to use
>>> scsi_cd_get() to get struct scsi_cd from gendisk. Am I missing something?
>>
>> No I think you are correct, from the revalidate path it should grab/release
>> a reference. Looks like sr_block_check_events() needs the same treatment.
>> How about the below?
>  
> Yeah, that looks good to me except one thing:
> 
>> diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
>> index 0cf25d789d05..3f3cb72e0c0c 100644
>> --- a/drivers/scsi/sr.c
>> +++ b/drivers/scsi/sr.c
>>  static int sr_block_revalidate_disk(struct gendisk *disk)
>>  {
>> -	struct scsi_cd *cd = scsi_cd(disk);
>>  	struct scsi_sense_hdr sshdr;
>> +	struct scsi_cd *cd;
>> +
>> +	cd = scsi_cd_get(disk);
>> +	if (!cd)
>> +		return -ENXIO;
> 
> So if this returns -ENXIO I somewhat wonder about the code in
> fs/block_dev.c: revalidate_disk(). Why do we do all the work there and then
> return -ENXIO?

That's a good (but separate) question. I'd have to look deeper, but
it's entirely possible that revalidate could fail for other reasons
and we still want to ensure we reset the size of the device, for
instance.

-- 
Jens Axboe

Re: Hotplug

[Srikanth Akula]

Hi Tetsuya ,

Thank you for your inputs .

I have thought about this API , but looks like it takes interface name as
argument ( which is a unique name from the rte_pci_dev instance) . But i am
looking to check if the device is attached based on the PCI address .

But ,I am going to test this too

Regards,
Srikanth

On Wed, Oct 7, 2015 at 4:45 PM, Tetsuya Mukawa <mukawa@igel.co.jp> wrote:

> On 2015/10/07 22:16, Srikanth Akula wrote:
> > Thank you for the inputs .
> >
> > I was able to solve the problem of device notification from my control
> > plane.
> >
> > I would like to know if we have any way to know if the PCI device is
> > already attached before we try to attach it ( if the device is already
> > attached pci probe will result an error ) .
> > But i want to know before hand to verify if the device is already
> attached
> > or not .
>
> Hi  Srikanth,
>
> I guess below API may help you.
> (Unfortunately, I am out of office now, so I haven't checked it, but I
> guess it works.)
>
>  - struct rte_eth_dev *rte_eth_dev_allocated(const char *name)
>
> If none NULL value is returned, a device has been already attached.
> If you want to check a physical NIC, above 'name' parameter will be like
> below.
>
>     snprintf(name, size, "%d:%d.%d",
>                         pci_dev->addr.bus, pci_dev->addr.devid,
>                         pci_dev->addr.function);
>
> Thanks,
> Tetsuya
>
> >
> > I came with small API which can be used to check if the pci device is
> > already bound to any driver .
> >
> > +int
> > +rte_eal_pci_is_attached(const char *devargs)
> > +{
> > +        struct rte_pci_device *dev = NULL;
> > +        struct rte_pci_addr addr;
> > +        memset(&addr,0,sizeof(struct rte_pci_addr));
> > +
> > +        if (eal_parse_pci_DomBDF(devargs, &addr) == 0)
> > +          {
> > +            TAILQ_FOREACH(dev, &pci_device_list, next) {
> > +            if (!rte_eal_compare_pci_addr(&dev->addr, &addr))
> > +              {
> > +                if (dev->driver)
> > +                  {
> > +                    /*pci_dump_one_device(stdout,dev);*/
> > +                    RTE_LOG(WARNING, EAL, "Requested device "
> PCI_PRI_FMT
> > +                      " cannot be used\n", dev->addr.domain,
> dev->addr.bus,
> > +                    dev->addr.devid, dev->addr.function);
> > +                   return -1;
> > +                 }
> > +              }
> > +           }
> > +         }
> > +   return 0;
> > +}
> > +
> >
> > Could you please let me know if it is good to have such APIs
> >
> > Regards,
> > _Srikanth_
> >
> >
> > On Mon, Sep 28, 2015 at 9:44 PM, Stephen Hemminger <
> > stephen@networkplumber.org> wrote:
> >
> >> On Mon, 28 Sep 2015 21:12:50 -0700
> >> Srikanth Akula <srikanth044@gmail.com> wrote:
> >>
> >>> Hello ,
> >>>
> >>> I am trying to write an application based on DPDK port hotplug feature
> .
> >> My
> >>> requirement is to get an event when a new PCI devices gets added to the
> >>> system on the go.
> >>>
> >>> Do we have any in-built mechanism in DPDK (UIO/e1000/vfio drivers )
> that
> >> i
> >>> can use to get notifications when a new device gets added . I know the
> >>> alternatives such as inotify etc .
> >>>
> >>> But i am more interested to get equivalent support in dpdk drivers .
> >>>
> >>> Please let me know .
> >>>
> >>> Srikanth
> >> Implementing hotplug requires integration with the OS more than any
> >> additional
> >> DPDK support. What the Brocade vRouter does is leverage the existing
> Linux
> >> udev infrastructure to send a message to the router application which
> then
> >> initializes and sets up the new hardware. Most of the DPDK changes are
> >> upstream
> >> already and involve being able to dynamically add ports on the fly.
> >>
> >>
>
>

Re: Hotplug

[Tetsuya Mukawa]

On 2015/10/07 22:16, Srikanth Akula wrote:
> Thank you for the inputs .
>
> I was able to solve the problem of device notification from my control
> plane.
>
> I would like to know if we have any way to know if the PCI device is
> already attached before we try to attach it ( if the device is already
> attached pci probe will result an error ) .
> But i want to know before hand to verify if the device is already attached
> or not .

Hi  Srikanth,

I guess below API may help you.
(Unfortunately, I am out of office now, so I haven't checked it, but I
guess it works.)

 - struct rte_eth_dev *rte_eth_dev_allocated(const char *name)

If none NULL value is returned, a device has been already attached.
If you want to check a physical NIC, above 'name' parameter will be like
below.

    snprintf(name, size, "%d:%d.%d",
                        pci_dev->addr.bus, pci_dev->addr.devid,
                        pci_dev->addr.function);

Thanks,
Tetsuya

>
> I came with small API which can be used to check if the pci device is
> already bound to any driver .
>
> +int
> +rte_eal_pci_is_attached(const char *devargs)
> +{
> +        struct rte_pci_device *dev = NULL;
> +        struct rte_pci_addr addr;
> +        memset(&addr,0,sizeof(struct rte_pci_addr));
> +
> +        if (eal_parse_pci_DomBDF(devargs, &addr) == 0)
> +          {
> +            TAILQ_FOREACH(dev, &pci_device_list, next) {
> +            if (!rte_eal_compare_pci_addr(&dev->addr, &addr))
> +              {
> +                if (dev->driver)
> +                  {
> +                    /*pci_dump_one_device(stdout,dev);*/
> +                    RTE_LOG(WARNING, EAL, "Requested device " PCI_PRI_FMT
> +                      " cannot be used\n", dev->addr.domain, dev->addr.bus,
> +                    dev->addr.devid, dev->addr.function);
> +                   return -1;
> +                 }
> +              }
> +           }
> +         }
> +   return 0;
> +}
> +
>
> Could you please let me know if it is good to have such APIs
>
> Regards,
> _Srikanth_
>
>
> On Mon, Sep 28, 2015 at 9:44 PM, Stephen Hemminger <
> stephen@networkplumber.org> wrote:
>
>> On Mon, 28 Sep 2015 21:12:50 -0700
>> Srikanth Akula <srikanth044@gmail.com> wrote:
>>
>>> Hello ,
>>>
>>> I am trying to write an application based on DPDK port hotplug feature .
>> My
>>> requirement is to get an event when a new PCI devices gets added to the
>>> system on the go.
>>>
>>> Do we have any in-built mechanism in DPDK (UIO/e1000/vfio drivers ) that
>> i
>>> can use to get notifications when a new device gets added . I know the
>>> alternatives such as inotify etc .
>>>
>>> But i am more interested to get equivalent support in dpdk drivers .
>>>
>>> Please let me know .
>>>
>>> Srikanth
>> Implementing hotplug requires integration with the OS more than any
>> additional
>> DPDK support. What the Brocade vRouter does is leverage the existing Linux
>> udev infrastructure to send a message to the router application which then
>> initializes and sets up the new hardware. Most of the DPDK changes are
>> upstream
>> already and involve being able to dynamically add ports on the fly.
>>
>>

Re: Hotplug

[Srikanth Akula]

Thank you for the inputs .

I was able to solve the problem of device notification from my control
plane.

I would like to know if we have any way to know if the PCI device is
already attached before we try to attach it ( if the device is already
attached pci probe will result an error ) .
But i want to know before hand to verify if the device is already attached
or not .

I came with small API which can be used to check if the pci device is
already bound to any driver .

+int
+rte_eal_pci_is_attached(const char *devargs)
+{
+        struct rte_pci_device *dev = NULL;
+        struct rte_pci_addr addr;
+        memset(&addr,0,sizeof(struct rte_pci_addr));
+
+        if (eal_parse_pci_DomBDF(devargs, &addr) == 0)
+          {
+            TAILQ_FOREACH(dev, &pci_device_list, next) {
+            if (!rte_eal_compare_pci_addr(&dev->addr, &addr))
+              {
+                if (dev->driver)
+                  {
+                    /*pci_dump_one_device(stdout,dev);*/
+                    RTE_LOG(WARNING, EAL, "Requested device " PCI_PRI_FMT
+                      " cannot be used\n", dev->addr.domain, dev->addr.bus,
+                    dev->addr.devid, dev->addr.function);
+                   return -1;
+                 }
+              }
+           }
+         }
+   return 0;
+}
+

Could you please let me know if it is good to have such APIs

Regards,
_Srikanth_


On Mon, Sep 28, 2015 at 9:44 PM, Stephen Hemminger <
stephen@networkplumber.org> wrote:

> On Mon, 28 Sep 2015 21:12:50 -0700
> Srikanth Akula <srikanth044@gmail.com> wrote:
>
> > Hello ,
> >
> > I am trying to write an application based on DPDK port hotplug feature .
> My
> > requirement is to get an event when a new PCI devices gets added to the
> > system on the go.
> >
> > Do we have any in-built mechanism in DPDK (UIO/e1000/vfio drivers ) that
> i
> > can use to get notifications when a new device gets added . I know the
> > alternatives such as inotify etc .
> >
> > But i am more interested to get equivalent support in dpdk drivers .
> >
> > Please let me know .
> >
> > Srikanth
>
> Implementing hotplug requires integration with the OS more than any
> additional
> DPDK support. What the Brocade vRouter does is leverage the existing Linux
> udev infrastructure to send a message to the router application which then
> initializes and sets up the new hardware. Most of the DPDK changes are
> upstream
> already and involve being able to dynamically add ports on the fly.
>
>

Hotplug

[Stephen Hemminger]

On Mon, 28 Sep 2015 21:12:50 -0700
Srikanth Akula <srikanth044@gmail.com> wrote:

> Hello ,
> 
> I am trying to write an application based on DPDK port hotplug feature . My
> requirement is to get an event when a new PCI devices gets added to the
> system on the go.
> 
> Do we have any in-built mechanism in DPDK (UIO/e1000/vfio drivers ) that i
> can use to get notifications when a new device gets added . I know the
> alternatives such as inotify etc .
> 
> But i am more interested to get equivalent support in dpdk drivers .
> 
> Please let me know .
> 
> Srikanth

Implementing hotplug requires integration with the OS more than any additional
DPDK support. What the Brocade vRouter does is leverage the existing Linux
udev infrastructure to send a message to the router application which then
initializes and sets up the new hardware. Most of the DPDK changes are upstream
already and involve being able to dynamically add ports on the fly.

Re: Hotplug

[Mark Nelson]

On Thu, Sep 4, 2008 at 8:35 PM, Tejun Heo <tj@kernel.org> wrote:
> Hello,
>
> Mark Nelson wrote:
>> Can you check these too (I'm testing hotplug on the PDC42819 with
>> ahci driver)?
>>
>> after powering up eSATA connected drive:
>>
>>  ata7: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0xe frozen
>>  ata7: irq_stat 0x00000040, connection status changed
>>  ata7: SError: { PHYRdyChg CommWake DevExch }
>>  ata7: hard resetting link
>>  ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>  ata7.00: ATA-7: HTS721060G9SA00, MC3IC10H, max UDMA/100
>>  ata7.00: 117210240 sectors, multi 0: LBA48
>>  ata7.00: configured for UDMA/100
>>  ata7: EH complete
>>  scsi 6:0:0:0: Direct-Access     ATA      HTS721060G9SA00  MC3I PQ: 0 ANSI: 5
>>  sd 6:0:0:0: [sdb] 117210240 512-byte hardware sectors (60012 MB)
>>  sd 6:0:0:0: [sdb] Write Protect is off
>>  sd 6:0:0:0: [sdb] Mode Sense: 00 3a 00 00
>>  sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
>> support DPO or FUA
>>  sd 6:0:0:0: [sdb] 117210240 512-byte hardware sectors (60012 MB)
>>  sd 6:0:0:0: [sdb] Write Protect is off
>>  sd 6:0:0:0: [sdb] Mode Sense: 00 3a 00 00
>>  sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
>> support DPO or FUA
>>   sdb: sdb1
>>  sd 6:0:0:0: [sdb] Attached SCSI disk
>>  sd 6:0:0:0: Attached scsi generic sg1 type 0
>>  kjournald starting.  Commit interval 5 seconds
>>  EXT3 FS on sdb1, internal journal
>>  EXT3-fs: recovery complete.
>>  EXT3-fs: mounted filesystem with ordered data mode.
>
> Yeap, looks fine.
>
>> after unmounting and executing
>> echo 1 > /sys/class/scsi_device/6\:0\:0\:0/device/delete:
>>
>>  sd 6:0:0:0: [sdb] Synchronizing SCSI cache
>>  sd 6:0:0:0: [sdb] Stopping disk
>>  ata7.00: disabled
>
> Heh.. I usually just pull the power plug doing delete is a good idea.

Well truth be told I just learnt it from Jason's post (prior to that I took
hotplug more literally :) )

>
>> and after removing power from eSATA device:
>>
>>  ata7: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0xe frozen
>>  ata7: irq_stat 0x00400000, PHY RDY changed
>>  ata7: SError: { PHYRdyChg }
>>  ata7: hard resetting link
>>  ata7: SATA link down (SStatus 0 SControl 300)
>>  ata7: EH complete
>
> This looks fine too.

Excellent.

Thanks!

Mark

Re: Hotplug

[Tejun Heo]

Hello,

Mark Nelson wrote:
> Can you check these too (I'm testing hotplug on the PDC42819 with
> ahci driver)?
> 
> after powering up eSATA connected drive:
> 
>  ata7: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0xe frozen
>  ata7: irq_stat 0x00000040, connection status changed
>  ata7: SError: { PHYRdyChg CommWake DevExch }
>  ata7: hard resetting link
>  ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>  ata7.00: ATA-7: HTS721060G9SA00, MC3IC10H, max UDMA/100
>  ata7.00: 117210240 sectors, multi 0: LBA48
>  ata7.00: configured for UDMA/100
>  ata7: EH complete
>  scsi 6:0:0:0: Direct-Access     ATA      HTS721060G9SA00  MC3I PQ: 0 ANSI: 5
>  sd 6:0:0:0: [sdb] 117210240 512-byte hardware sectors (60012 MB)
>  sd 6:0:0:0: [sdb] Write Protect is off
>  sd 6:0:0:0: [sdb] Mode Sense: 00 3a 00 00
>  sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA
>  sd 6:0:0:0: [sdb] 117210240 512-byte hardware sectors (60012 MB)
>  sd 6:0:0:0: [sdb] Write Protect is off
>  sd 6:0:0:0: [sdb] Mode Sense: 00 3a 00 00
>  sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA
>   sdb: sdb1
>  sd 6:0:0:0: [sdb] Attached SCSI disk
>  sd 6:0:0:0: Attached scsi generic sg1 type 0
>  kjournald starting.  Commit interval 5 seconds
>  EXT3 FS on sdb1, internal journal
>  EXT3-fs: recovery complete.
>  EXT3-fs: mounted filesystem with ordered data mode.

Yeap, looks fine.

> after unmounting and executing
> echo 1 > /sys/class/scsi_device/6\:0\:0\:0/device/delete:
> 
>  sd 6:0:0:0: [sdb] Synchronizing SCSI cache
>  sd 6:0:0:0: [sdb] Stopping disk
>  ata7.00: disabled

Heh.. I usually just pull the power plug doing delete is a good idea.

> and after removing power from eSATA device:
> 
>  ata7: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0xe frozen
>  ata7: irq_stat 0x00400000, PHY RDY changed
>  ata7: SError: { PHYRdyChg }
>  ata7: hard resetting link
>  ata7: SATA link down (SStatus 0 SControl 300)
>  ata7: EH complete

This looks fine too.

-- 
tejun

Re: Hotplug

[Mark Nelson]

On Wed, Sep 3, 2008 at 5:01 PM, Tejun Heo <tj@kernel.org> wrote:
> Jason Davis wrote:
>> Hello,
>>  I'm trying to confirm hot/warm plugging is working on my system. When
>> I plug in the drive shows up as expected. I just want to make sure the
>> stuff I see in the logs is ok.
>
> Yeah, those are as okay as they get.  :-)

Hi Tejun,

Can you check these too (I'm testing hotplug on the PDC42819 with ahci driver)?

after powering up eSATA connected drive:

 ata7: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0xe frozen
 ata7: irq_stat 0x00000040, connection status changed
 ata7: SError: { PHYRdyChg CommWake DevExch }
 ata7: hard resetting link
 ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
 ata7.00: ATA-7: HTS721060G9SA00, MC3IC10H, max UDMA/100
 ata7.00: 117210240 sectors, multi 0: LBA48
 ata7.00: configured for UDMA/100
 ata7: EH complete
 scsi 6:0:0:0: Direct-Access     ATA      HTS721060G9SA00  MC3I PQ: 0 ANSI: 5
 sd 6:0:0:0: [sdb] 117210240 512-byte hardware sectors (60012 MB)
 sd 6:0:0:0: [sdb] Write Protect is off
 sd 6:0:0:0: [sdb] Mode Sense: 00 3a 00 00
 sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
 sd 6:0:0:0: [sdb] 117210240 512-byte hardware sectors (60012 MB)
 sd 6:0:0:0: [sdb] Write Protect is off
 sd 6:0:0:0: [sdb] Mode Sense: 00 3a 00 00
 sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
  sdb: sdb1
 sd 6:0:0:0: [sdb] Attached SCSI disk
 sd 6:0:0:0: Attached scsi generic sg1 type 0
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS on sdb1, internal journal
 EXT3-fs: recovery complete.
 EXT3-fs: mounted filesystem with ordered data mode.


after unmounting and executing
echo 1 > /sys/class/scsi_device/6\:0\:0\:0/device/delete:

 sd 6:0:0:0: [sdb] Synchronizing SCSI cache
 sd 6:0:0:0: [sdb] Stopping disk
 ata7.00: disabled


and after removing power from eSATA device:

 ata7: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0xe frozen
 ata7: irq_stat 0x00400000, PHY RDY changed
 ata7: SError: { PHYRdyChg }
 ata7: hard resetting link
 ata7: SATA link down (SStatus 0 SControl 300)
 ata7: EH complete


Thanks!

Mark

Re: Hotplug

[Tejun Heo]

Jason Davis wrote:
> Hello,
>  I'm trying to confirm hot/warm plugging is working on my system. When
> I plug in the drive shows up as expected. I just want to make sure the
> stuff I see in the logs is ok.

Yeah, those are as okay as they get.  :-)

-- 
tejun

Hotplug

[Jason Davis]

Hello,
 I'm trying to confirm hot/warm plugging is working on my system. When
I plug in the drive shows up as expected. I just want to make sure the
stuff I see in the logs is ok.

Thanks,
jason

jd@linux:~$ uname -a
Linux linux 2.6.18-6-686 #1 SMP Mon Aug 18 08:42:39 UTC 2008 i686 GNU/Linux

from kern.log when I plug in:

Sep  2 15:24:04 linux kernel: ata6: exception Emask 0x10 SAct 0x0 SErr
0x0 action 0x2 frozen
Sep  2 15:24:04 linux kernel: ata6: (irq_stat 0x00b00090, PHY RDY changed)
Sep  2 15:24:05 linux kernel: ata6: waiting for device to spin up (8 secs)
Sep  2 15:24:13 linux kernel: ata6: soft resetting port
Sep  2 15:24:17 linux kernel: ata6: SATA link up 3.0 Gbps (SStatus 123
SControl 300)
Sep  2 15:24:17 linux kernel: ata6.00: ATA-8, max UDMA/133, 1953525168
sectors: LBA48 NCQ (depth 31/32)
Sep  2 15:24:17 linux kernel: ata6.00: ata6: dev 0 multi count 0
Sep  2 15:24:17 linux kernel: ata6.00: configured for UDMA/100
Sep  2 15:24:17 linux kernel: ata6: EH complete
Sep  2 15:24:17 linux kernel:   Vendor: ATA       Model: WDC
WD10EACS-00D  Rev: 01.0
Sep  2 15:24:17 linux kernel:   Type:   Direct-Access
    ANSI SCSI revision: 05
Sep  2 15:24:17 linux kernel: SCSI device sdc: 1953525168 512-byte
hdwr sectors (1000205 MB)
Sep  2 15:24:17 linux kernel: sdc: Write Protect is off
Sep  2 15:24:17 linux kernel: sdc: Mode Sense: 00 3a 00 00
Sep  2 15:24:17 linux kernel: SCSI device sdc: drive cache: write back
Sep  2 15:24:17 linux kernel: SCSI device sdc: 1953525168 512-byte
hdwr sectors (1000205 MB)
Sep  2 15:24:17 linux kernel: sdc: Write Protect is off
Sep  2 15:24:17 linux kernel: sdc: Mode Sense: 00 3a 00 00
Sep  2 15:24:17 linux kernel: SCSI device sdc: drive cache: write back
Sep  2 15:24:17 linux kernel:  sdc: sdc1
Sep  2 15:24:17 linux kernel: sd 5:0:0:0: Attached scsi disk sdc
Sep  2 15:24:47 linux kernel: kjournald starting.  Commit interval 5 seconds
Sep  2 15:24:47 linux kernel: EXT3 FS on sdc1, internal journal
Sep  2 15:24:47 linux kernel: EXT3-fs: mounted filesystem with ordered
data mode.




When I unplug:
root@linux:~# umount /mnt/other
root@linux:~# echo 1 > /sys/class/scsi_device/5\:0\:0\:0/device/delete


Sep  2 15:26:01 linux kernel: ata6.00: disabled
Sep  2 15:26:13 linux kernel: ata6: exception Emask 0x10 SAct 0x0 SErr
0x80000 action 0x2 frozen
Sep  2 15:26:13 linux kernel: ata6: (irq_stat 0x01140010, PHY RDY changed)
Sep  2 15:26:14 linux kernel: ata6: soft resetting port
Sep  2 15:26:14 linux kernel: ata6: SATA link down (SStatus 0 SControl 300)
Sep  2 15:26:14 linux kernel: ata6: EH complete

Re: Hotplug

[Philip MacIver]

 --- MALET JL <malet.jean-luc@laposte.net> wrote: > 
> I remember having such trouble but this was because
> the udev script was 
> run twice...... but I can't remember exactly what
> was the causes and how 
> they disapeard.....
> 
> what I remember is that : I loged into the box,
> noticed that /dev wasn't 
> the right one (a fixed dev tree) so tried to rerun
> the script and only 
> get a partial /dev structure.... looking what was
> mounted told me that 
> /dev was mounted twice with ramfs..... maybe it can
> help :/
> 

Thanks, I have to explore this possibility more when I
get home (they make me use Wind**s at work) :)
 

==Philip MacIver
--
e: pmaciver@arishi.com
e: philipmaciver@yahoo.co.uk


	
	
		
___________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Hotplug

[MALET JL]

[-- Attachment #1: Type: text/plain, Size: 2891 bytes --]

Philip MacIver a écrit :

> --- MALET JL <malet.jean-luc@laposte.net> wrote: >
>Philip MacIver a écrit :
>  
>
>>>I've just read something that may be causing my
>>>problem with udev, and I would just like to confirm
>>>this before I actually go ahead and do any changes.
>>>      
>>>
>>>Running "/proc/sys/kernel/hotplug" on my system
>>>      
>>>
>>prints
>>    
>>
>>>out "/bin/true", I've read that to change this you
>>>      
>>>
>>do
>>    
>>
>>>echo "/sbin/hotplug" > /proc/sys/kernel/hotplug. 
>>>
>>>But what I want to know is, is this the reason that
>>>      
>>>
>>my
>>    
>>
>>>linux system won't boot up when I try and use udev
>>>with /dev as the udev_root. The reason that I ask
>>>      
>>>
>>is
>>    
>>
>>>because when I tested out udev using /udev as the
>>>udev_root and my system started up, the hotplug
>>>      
>>>
>>demon
>>    
>>
>>>started up after the hard disks are mounted. And
>>>      
>>>
>>the
>>    
>>
>>>problem was that the /dev/hda device nodes (and
>>>others) were not being created. 
>>>
>>>Thanks in advanced for any help. 
>>>
>>>=====
>>>Philip MacIver
>>>--
>>>e: pmaciver@arishi.com
>>>e: philipmaciver@yahoo.co.uk
>>> 
>>>
>>>      
>>>
>>what script do you use to start udev?  is this the
>>start_udev one?
>>    
>>
>
>Yes.
>
>  
>
>>when you use /udev : the entries are created? (do an
>>ls don't assume 
>>that they are created because no errors occurs)
>>    
>>
>
>Yes all the enteries are created, I've learnt never to
>assume
>  
>
>>are you mounting a /dev in fstab? (i know someone
>>that did that...)
>>
>>    
>>
>
>Nope I've checked my fstab many times and I don't
>mount a dev.
>
>When I do set the udev_root to /dev some devices get
>created, like fd0 and a few others that I can't
>remember. 
>
>But i'm wondering if where i'm starting udev in my
>rc.sysinit is the problem. Just for your reference I
>start it (and also mount sysfs) right after /proc gets
>mounted (and yes I do mmount sysfs before I run
>start_udev :) )
>
>
> 
>
>=====
>Philip MacIver
>--
>e: pmaciver@arishi.com
>e: philipmaciver@yahoo.co.uk
>
>
>	
>	
>		
>___________________________________________________________
>Yahoo! Messenger - Communicate instantly..."Ping" 
>your friends today! Download Messenger Now 
>http://uk.messenger.yahoo.com/download/index.html
>  
>
I remember having such trouble but this was because the udev script was 
run twice...... but I can't remember exactly what was the causes and how 
they disapeard.....

what I remember is that : I loged into the box, noticed that /dev wasn't 
the right one (a fixed dev tree) so tried to rerun the script and only 
get a partial /dev structure.... looking what was mounted told me that 
/dev was mounted twice with ramfs..... maybe it can help :/

[-- Attachment #2: Type: application/pgp-signature, Size: 250 bytes --]

Re: Hotplug

[Philip MacIver]

 --- MALET JL <malet.jean-luc@laposte.net> wrote: >
Philip MacIver a écrit :
> 
> >I've just read something that may be causing my
> >problem with udev, and I would just like to confirm
> >this before I actually go ahead and do any changes.
> 
> >
> >Running "/proc/sys/kernel/hotplug" on my system
> prints
> >out "/bin/true", I've read that to change this you
> do
> >echo "/sbin/hotplug" > /proc/sys/kernel/hotplug. 
> >
> >But what I want to know is, is this the reason that
> my
> >linux system won't boot up when I try and use udev
> >with /dev as the udev_root. The reason that I ask
> is
> >because when I tested out udev using /udev as the
> >udev_root and my system started up, the hotplug
> demon
> >started up after the hard disks are mounted. And
> the
> >problem was that the /dev/hda device nodes (and
> >others) were not being created. 
> >
> >Thanks in advanced for any help. 
> >
> >==> >Philip MacIver
> >--
> >e: pmaciver@arishi.com
> >e: philipmaciver@yahoo.co.uk
> >  
> >
> what script do you use to start udev?  is this the
> start_udev one?

Yes.

> when you use /udev : the entries are created? (do an
> ls don't assume 
> that they are created because no errors occurs)

Yes all the enteries are created, I've learnt never to
assume
> are you mounting a /dev in fstab? (i know someone
> that did that...)
> 

Nope I've checked my fstab many times and I don't
mount a dev.

When I do set the udev_root to /dev some devices get
created, like fd0 and a few others that I can't
remember. 

But i'm wondering if where i'm starting udev in my
rc.sysinit is the problem. Just for your reference I
start it (and also mount sysfs) right after /proc gets
mounted (and yes I do mmount sysfs before I run
start_udev :) )


 

==Philip MacIver
--
e: pmaciver@arishi.com
e: philipmaciver@yahoo.co.uk


	
	
		
___________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Hotplug

[MALET JL]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

Philip MacIver a écrit :

>I've just read something that may be causing my
>problem with udev, and I would just like to confirm
>this before I actually go ahead and do any changes. 
>
>Running "/proc/sys/kernel/hotplug" on my system prints
>out "/bin/true", I've read that to change this you do
>echo "/sbin/hotplug" > /proc/sys/kernel/hotplug. 
>
>But what I want to know is, is this the reason that my
>linux system won't boot up when I try and use udev
>with /dev as the udev_root. The reason that I ask is
>because when I tested out udev using /udev as the
>udev_root and my system started up, the hotplug demon
>started up after the hard disks are mounted. And the
>problem was that the /dev/hda device nodes (and
>others) were not being created. 
>
>Thanks in advanced for any help. 
>
>=====
>Philip MacIver
>--
>e: pmaciver@arishi.com
>e: philipmaciver@yahoo.co.uk
>  
>
what script do you use to start udev?  is this the start_udev one?
when you use /udev : the entries are created? (do an ls don't assume 
that they are created because no errors occurs)
are you mounting a /dev in fstab? (i know someone that did that...)

[-- Attachment #2: Type: application/pgp-signature, Size: 250 bytes --]

Hotplug

[Philip MacIver]

I've just read something that may be causing my
problem with udev, and I would just like to confirm
this before I actually go ahead and do any changes. 

Running "/proc/sys/kernel/hotplug" on my system prints
out "/bin/true", I've read that to change this you do
echo "/sbin/hotplug" > /proc/sys/kernel/hotplug. 

But what I want to know is, is this the reason that my
linux system won't boot up when I try and use udev
with /dev as the udev_root. The reason that I ask is
because when I tested out udev using /udev as the
udev_root and my system started up, the hotplug demon
started up after the hard disks are mounted. And the
problem was that the /dev/hda device nodes (and
others) were not being created. 

Thanks in advanced for any help. 

==Philip MacIver
--
e: pmaciver@arishi.com
e: philipmaciver@yahoo.co.uk


	
	
		
___________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

hotplug

[raja sekhar kottapalli]

what are the required rpm's for creating a dynamic
icon on the desktop when an usb is pluged in


________________________________________________________________________
Yahoo! India Mobile: Download the latest polyphonic ringtones.
Go to http://in.mobile.yahoo.com


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel