On Thu, Aug 1, 2019 at 10:15 AM Andrea Righi <email address hidden>
wrote:
> Thanks Ryan, this is very interesting:
>
> [ 259.411486] bcache: register_bcache() error /dev/vdg: device already
> registered (emitting change event)
> [ 259.537070] bcache: register_bcache() error /dev/vdg: device already
> registered (emitting change event)
> [ 259.797830] bcache: register_bcache() error /dev/vdg: device already
> registered (emitting change event)
> [ 259.900392] bcache: register_bcache() error /dev/vdg: device already
> registered (emitting change event)
>
> It looks that we're trying to register /dev/vdg multiple times as a
> backing device (make-bcache -B). I'm not getting this message during my
> tests, so that might be required to reproduce that particular deadlock.
>
We carry a specific sauce patch to ensure that if the cacheset is already
online, and a backing device
shows up later, that the kernel emits the change event to trigger the udev
rules to generate the
symlink for /dev/bcache/by-uuid. I don't think the patch we carry is at
issue since we are just detecting
the re-register scenario and emitting a change uevent;
On Thu, Aug 1, 2019 at 10:15 AM Andrea Righi <email address hidden>
wrote:
> Thanks Ryan, this is very interesting:
>
> [ 259.411486] bcache: register_bcache() error /dev/vdg: device already
> registered (emitting change event)
> [ 259.537070] bcache: register_bcache() error /dev/vdg: device already
> registered (emitting change event)
> [ 259.797830] bcache: register_bcache() error /dev/vdg: device already
> registered (emitting change event)
> [ 259.900392] bcache: register_bcache() error /dev/vdg: device already
> registered (emitting change event)
>
> It looks that we're trying to register /dev/vdg multiple times as a
> backing device (make-bcache -B). I'm not getting this message during my
> tests, so that might be required to reproduce that particular deadlock.
>
We carry a specific sauce patch to ensure that if the cacheset is already by-uuid. I don't think the patch we carry is at
online, and a backing device
shows up later, that the kernel emits the change event to trigger the udev
rules to generate the
symlink for /dev/bcache/
issue since we are just detecting
the re-register scenario and emitting a change uevent;
https:/ /www.spinics. net/lists/ linux-bcache/ msg05833. html
We may want to resubmit that now to see if they'll take that or even want
to deal with the scenario
in a cleaner way;
>
> I'll modify my test case to trigger these errors and see if I can
> reproduce the hung task timeout issue.
>
I can provide you a setup to reproduce this. I'll put together a doc.
> -- /bugs.launchpad .net/bugs/ 1796292 /bugs.launchpad .net/curtin/ +bug/1796292/ +subscriptions
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> Tight timeout for bcache removal causes spurious failures
>
> To manage notifications about this bug go to:
> https:/
>