On 08/05/2016 02:01 PM, Andrew Morton wrote:
Bah. What about WARN__ON_ONCE()? Or much heavier ratelimiting?
The problem w/ the WARN_ON_ONCE macro for this case is that it applies once per _function_ (because of its static variable), not per _device_. So, after the message happens for a particular device, it won't happen for any other devices. This would still conflict with the reasons the other patch (use dynamic debug) was rejected [1]. The other problem w/ WARN_ON_ONCE (even if it could be used per device) is that it masks/hides some events: if you reach it with requests that are OK to fail (i.e., retry), it will be silent for requests that are not OK to fail (e.g., the blk_integrity-related call on nvme) -- and it could be helpful for debugging. I believe that ratelimiting would fall into the same category as above (masks events since it hits the threshold with the OK-to-fail requests, and then misses the not-OK-to-fail requests). The other problem with ratelimiting would be, in case of continuously working on high loads with the devices (e.g., nvme drive) - which is acceptable - the messages would still eventually be printed, and since it will happen every time the threshold is OK to print it again, it's only a repetition with a greater period. ... the difficult point with the problem this patch addresses is not to be heavy handed; it's interesting to find some balance to still reach the message when it might be useful, and provide some form of control to the device driver (for when it knows it is OK for requests to fail). Given that the driver can have multiple callsites (with different or no failure handling), unfortunately I found it hard to make this arch-specific (but that is what I really aimed for first). If you see other approaches that could help with it, I'd be happy to write something simpler/more discreet. Thanks for the suggestions and discussions. [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-June/144196.html -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
