On Tue, Jan 15, 2019 at 04:50:05PM +1200, Linus Torvalds wrote: > On Tue, Jan 15, 2019 at 12:49 PM Luc Van Oostenryck > <luc.vanoostenryck@xxxxxxxxx> wrote: > > > > The only simple temporary 'solution' is see for the moment would be > > to disable 'noderef' warnings while expanding ASM. > > No, I think the real fix is to consider memory arguments to asm's to > have an implicit "address_of" operation applied to them. > > Basically, the *compiler* never derefences the expression, it's just > given as an address to the asm. > > But note that this would require looking at the type of argument to > the asm. If it's a register that the compiler is supposed to fill in, > then the compiler obviously *does* dereference the expression. > > But if the asm constraint is "m", then the compiler basically passes > in just he address, and the asm is what *may* do the dereference. > > Note the *may*. It's entirely possible that we're passing a memory op > to the inline asm in order for the asm to generate not a dereference, > but something entirely different (like a cache flush, or in the case > of the kernel, maybe a special user access). > > Is this somewhat annoying? Yes. But a memory op to an asm really is > more like an address than an access. Yes, I agree. It's especially visible when looking at uaccess.h's macro __m() (it dereferences put_user/get_user()'s address argument just before for 'm' asm operands). But yes, it's certainly annoying because: *) the constraints are possibly arch specific *) the linearization needs to be special cased for asm memory op too (but I suppose it must currently be considered as wrong for asm memory ops) *) I've always considered __noderef as really meaning "must not be dereferenced except by some special purpose operation which effectively do the real deref". In the present case (percpu & uaccess (on x86)), it's clear that the special operation is the asm memory op but isn't this essentially incidental? Thinking a bit more about it and looking at some dumps I made: It seems that most of these these 'noderef in asm operand' warnings (99.5%) come from percpu operations (which have an API using an lvalue and not a pointer, unlike the uaccess API). I begin to suspect that the warnings occuring with an uaccess operation come from some other kind of error (possibly a missing call to degenerate()). Anyway, I'm looking at it. Thanks, -- Luc
