On Thu, Jul 09, 2020 at 05:50:11PM +0200, Aurélien Aptel wrote: > Hi, > > I was thinking the same mechanism for lock checks (lock() has matching > unlock()) could be used for detecting refcount leaks (get() has matching > put()). > > This could be used to catch bugs like that: > > https://lore.kernel.org/linux-cifs/CAH2r5mtJg0OONLuAYmcggj=M3euDDxRa3Y5-_W1=qxwbeZypqA@xxxxxxxxxxxxxx/T/#mf0e0397aa0b63043d7b3bb0981f0b7323713bfdc You might be better off copying the Smatch's locking test instead of Sparse's. Smatch does cross function flow analysis which can help. In this CIFS case, the leak is on the success path (as well as the failure path) so my theory would be that it would be caught in testing and will only cause false positives for static analysis. I can't see any automated way to know which success paths should take a reference and which should not. regards, dan carpenter
