udev cookie on DM_DEVICE_RELOAD

[Peter Rajnoha <prajnoha@redhat.com>]

On 06/29/2015 04:56 PM, Hannes Reinecke wrote:
> On 06/29/2015 04:49 PM, Peter Rajnoha wrote:
> [ .. ]
>>
>> Actually, we don't check proper combination of dm_task_set_cookie with
>> dm task type. So currently, if someone sets cookie on a task that does
>> not produce uevents, it can hang if dm_udev_wait is called for such cookie.
>>
>> I've noticed we have a FIXME in the code for this already, but clearly
>> nobody has run into this issue yet. I'll add the check!
>>
>> As for the DM_DEVICE_RELOAD - yes, it needs DM_DEVICE_RESUME to be called
>> right after the reload for the new table to be used (and hence the uevent
>> with the cookie generated as well). If you call RELOAD, the inactive
>> table is loaded which is then switched to active with the RESUME.
>>
>> The task that is transparently translated into 3 tasks internally is the
>> DM_DEVICE_CREATE (with table) which translates into CREATE + LOAD + RESUME.
>>
>> Anyway, yes, the check whether cookie is not misused is not there yet, so
>> that's why you hit this.
>>
> So how to circumvent this?
> Should I do an explicit
> SUSPEND/RELOAD/RESUME call sequence and add a cookie on the final
> resume?
> Or is it sufficient to call RESUME after RELOAD without suspending
> first? Or another magic trick?

suspend -> reload -> dm_task_set_cookie -> resume -> dm_udev_wait
should be the proper sequence.

The reload never translates internally into more tasks...
Can you point me to the exact code you're trying to edit?

-- 
Peter