On Tue, Feb 13, 2024 at 07:46:02PM +0200, Leon Romanovsky wrote: > On Tue, Feb 13, 2024 at 09:59:54AM -0600, Bjorn Helgaas wrote: > ... > > I guess that means that if we apply this revert, the problem Pierre > > reported will return. Obviously the deadlock is more important than > > the inconsistency Pierre observed, but from the user's point of view > > this will look like a regression. > > > > Maybe listening to netlink and then looking at sysfs isn't the > > "correct" way to do this, but I don't want to just casually break > > existing user code. If we do contemplate doing the revert, at the > > very least we should include specific details about what the user code > > *should* do instead, at the level of the actual commands to use > > instead of "ip monitor dev; cat ${path}/device/sriov_numvfs". > > udevadm monitor will do the trick. > > Another possible solution is to refactor the code to make sure that > .probe on VFs happens only after sriov_numvfs is updated. I like the idea of refactoring it so as to preserve the existing ordering while also fixing the deadlock. If, in addition, we want to update the sriov_numvfs documentation to recommend "udevadm monitor" + /sys/.../sriov_numvfs, that's fine, too, but I don't really like the idea of merging a patch and forcing users to update their code. So I'll table the v2 series for now and watch for a v3 with the refactoring. Bjorn