Re: Thread Safety Analysis and the Linux kernel
"Paul E. McKenney" <[email protected]>
| Newsgroups | org.kernel.vger.linux-toolchains,dev.linux.lists.llvm |
|---|---|
| Message-ID | <c48fcf0e-ec41-41b1-8c25-53b09170771f@paulmck-laptop> |
On Fri, Mar 07, 2025 at 05:59:49PM +0000, Puchert, Aaron wrote: > > From: Paul E. McKenney <[email protected]> > > Until such time as the analysis is carried out after inlining. ;-) > > The idea behind requiring the attributes is that we'll never have to do that. We let the programmer specify interface preconditions/postconditions so that we don't have to inspect the function body. > > Inlining has enough disadvantages that it will probably never work here: > * Since we're looking at individual translation units and not the whole program, we might not see function definitions. So the analysis would behave differently based on whether a function is defined in a header or source file, which is undesirable. Some definitions might be in external libraries and never be available. > * Even if we could see all definitions, there are complexity issues with inlining. We'd have to draw a line somewhere, which would make the analysis unpredictable as well. > > But these are just the reasons for the design decision. What matters is the decision itself to consider bodies of other functions as black boxes and only work with the attributes on their declaration. I guess we could also more clearly document this. As good a design decision as any, so fair enough! Thanx, Paul