On Sat, May 31, 2025 at 11:20:50AM +0200, Borislav Petkov wrote: > On Fri, May 30, 2025 at 01:52:39PM -0700, Luck, Tony wrote: > > Use case to inject to one device would be: > > > > # echo 1 > nr_components > > What does that do? EINJ V2 allows the user to perform multiple injections together. The component_idN/component_syndromeN pairs of files direct the "where" and the "what" of each injection. But the kernel needs to know how many of these pairs to use for an injection (to fill in a field in the structure passed to the BIOS). With EINJ V2 the user might want to inject to 2 locations with one injection, and then just to 1 location on the next. Zaid Alali's version took the approach of zeroing the input after each injection so the user had to start from scratch for each injection. I wasn't fond of that because the existing Linux EINJ interface saves all the paramters allowing the user to repeat the same injection by just runniing "echo 1 > error_inject: over and over (e.g. to force a soft offline by injecting multiple corrected errors to the same address). User interface options: 1) User can zero out the component_idN/component_syndromeN pairs that they don't need and have the kernel count how many injections are requested by looping to find the zero terminator. 2) Kernel could zero all pairs after an injection to make the user explicitly set the list of targets each time. 3) User provides the count vis the nr_components file (perhaps needs a better name?) 4) Something else? > > The interface probably needs a little refinement, but... > > > # echo 4 > component_id0 > > # echo A5A5A5A5 > component_syndrome0 > > ... set other files and finish with usual > > # echo 1 > error_inject > > > > There isn't a fancy "debugfs_create_x128_le()" helper to manage these > > 128-bit little endian numbers. So I've coded with the basic building > > blocks (though using copy_from_user() and copy_to_user() feels like > > back in the stone age). If there some helpers that I missed I'd be > > happy to see that part simplified. > > > > Patch is on top of the existing v7 set. Obviously it needs to be folded > > back into the earlier patches to make a clean history that doesn't add > > functions and then replace them with different code. > > ... yes, definitely much better. > > Thanks! You are welcome. > > -- > Regards/Gruss, > Boris. -Tony
