Created attachment 1004406 [details] Test program Description of problem: Using 'poll' with /sys/.../md/sync_action to wait for changes doesn't ever block. Doing the same with /sys/.../md/degraded works as expected. Version-Release number of selected component (if applicable): kernel-4.0.0-0.rc4.git0.1.fc22.x86_64 How reproducible: Always Steps to Reproduce: 1. Create a "md" device, maybe so: # mdadm --create /dev/md127 --run --level 5 --name ARR --raid-devices 3 /dev/vda /dev/vdb /dev/vdc 2. Optionally start udisks2 and see it use 100% CPU 3. Run the attached program like so: # ./t 1 /sys/devices/virtual/block/md127/md/sync_action Or so: # ./t 2 /sys/devices/virtual/block/md127/md/sync_action Actual results: Both invocations spin as fast as they can and continuously output "idle" (or whatever the sync_action is). Expected results: The program blocks in "poll" until the content of the file actually changes. Additional info: These invocations work as expected: # ./t 1 /sys/devices/virtual/block/md127/md/degraded # ./t 2 /sys/devices/virtual/block/md127/md/degraded UDisks uses variant 2 and gets into a tight loop as well. This is what prompted this bug report. I am not sure what the proper way to use poll with sysfs files is. (Is it documented somewhere?) I have found hints about both variant 1 and variant 2, and they both work as expected on kernel-3.18.8-201.fc21.x86_64 on Fedora 21.
This is probably a duplicate of 1202362. Can you test 4.0.0-0.rc4.git1.3 in koji?
(In reply to Josh Boyer from comment #1) > This is probably a duplicate of 1202362. Can you test 4.0.0-0.rc4.git1.3 in > koji? Works beautifully, thanks! *** This bug has been marked as a duplicate of bug 1202362 ***