Bug#782390: udev: time between USB-stick connection and device notification takes up to a minute

[Michael Biebl]

Hi Bernd

On Wed, 27 May 2015 22:11:38 +0200
=?UTF-8?B?QmVybmhhcmQgw5xiZWxhY2tlcg==?= <bernhardu at vr-web.de> wrote:
> Hello Marco, hello Michael,
> sorry for the delay.
> This is just to add some points to the bug.
> 
> 
> On Sat, 11 Apr 2015 16:04:50 +0200 md at Linux.IT (Marco d'Itri) wrote:
> > Unless something is creating an events loop then this is an hardware 
> > issue or a kernel bug.
> > Considering that this only happens with a specific USB stick I will 
> > assume that it is broken.
> 
> To me it looks like the creators of this stick intentionally made a
> waiting time of 5 seconds between being recognized as USB stick and
> actually "inserting" the "media" into it, like a card reader.
> In this 5 seconds the kernel always tries to open the "media" and triggers
> new block-change events (possibly by being triggered by blkid runs triggered
> by udev triggered by the first block-change event).
> This accumulates to ~700 messages in this 5 seconds, which now taking nearly a
> minute for udev to process.
> If such a behaviour is allowed I cannot say.
> 
> 
> With attached printk-KOBJ_CHANGE.diff I isolated the two origins of
> these block-change events on the kernel side:
>   Mai 27 21:02:12.125582 rechner kernel: disk_check_events: kobject_uevent_env KOBJ_CHANGE nr_events=1 envp[0]=DISK_MEDIA_CHANGE=1 size=0
>     (405 times)
>   Mai 27 21:02:12.130620 rechner kernel: invalidate_partitions: kobject_uevent KOBJ_CHANGE (0/0)
>     (323 times)
> 
> 
> These are the origins of the function calls, as far as I could follow them:
>   blkdev_get
>       __blkdev_get (block_dev.c)
>           invalidate_partitions (partition-generic.c)
> 
>   check_disk_change (block_dev.c)
>       disk_clear_events (genhd.c)
>           disk_check_events (genhd.c)
> 
>   add_disk (genhd.c)
>       disk_alloc_events via INIT_DELAYED_WORK (genhd.c)
>           disk_events_workfn (genhd.c)
>               disk_check_events (genhd.c)
> 
> 
> I tried to find a way to avoid some of these events and possibly
> have found something for the invalidate_partitions path at least:
>   Does it make sense to send the block-change event in invalidate_partitions
>   when the disk had a size of 0 before and after checking its size?
>   (Or call invalidate_partitions in this case at all?)
> 
> 
> The second point is following question:
>   Does it make sense to insert an identically block-change event for this device
>   when we know that there are already some in the queue?
>   (See attached drop-block-change-events-already-in-queue.patch)

just wanted to ask, if you still run into this issue with a newer kernel
(from testing). If so, I think it would probably best to re-assign this.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20161221/cffa006c/attachment.sig>