On Sat, Dec 9, 2023 at 9:38 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Thu, Dec 7, 2023 at 1:58 PM Andrei Matei <andreimatei1@xxxxxxxxx> wrote: > > > > If Eduard's patch cannot be backported, I had a random thought that perhaps > > dead-code elimination could be partially disabled (perhaps only for loop > > callbacks, ignoring the functions that the callbacks call). > > imo the dead code elimination issue is a minor pain point compared to > the safety issue that patches addressed. Sounds like backports will happen; that's all I wanted, so I'm happy. Just to beat a dead-horse -- working around the issue might be doable once you know what the issue is. But I can say from personal experience that starting with a C program which appears buggy and *figuring out* that the verifier "mis-compiled" it, and then understanding *why* and what kind of work-around might help is not easy. > The barrier_var() and asm volatile can workaround "wrong dead code" issue. > Pls use it while the fixes are slowly getting into older kernels. Thanks for letting me know about barrier_var(), seems like a trick that will come in handy in the future. But I'm not entirely sure how it applies here. It seems like barrier_var() can be used to inhibit some *compiler* optimizations. But how does that translate to getting the *verifier* to forget a fixed value that it knows for a register or a set of stack slots or a C variable (which is what I think is what's needed in order to avoid the "wrong dead code elimination" issue)? Would you mind kindly spelling it out for my learning? > Eduard's patches are the only feasible path to backport. > We cannot support franken kernels with different verifier logic. > The patches were designed to be backportable. > We didn't start backport activities to make sure the fixes > are not causing regressions in bpf progs. > The backports don't have to be done in order either. > If there is a particular kernel version you care about please > prepare a backport and cc bpf list, Greg KH and Sasha Levin. > It could happen that your favorite kernel is not on their list though.
