Re: [linux-safety] [PATCH] mm: vmscan: provide a change to the development-process group

On Thu, 17 Sep 2020, Sudip Mukherjee wrote:

> 
> 
> On 17/09/2020 09:44, Lukas Bulwahn wrote:
> > I think this change is needed for safety, whatever that might mean to you.
> > 
> > I am unqualified to really make a change here, as I have no clue what this
> > code does, nor what my change does, but sure, the testing and verification
> > reference process can now point out the required next steps in the
> > reference process to test this code and code change.
> > 
> > Good luck :)
> > 
> > Not intended for distribution to the general kernel mailing lists.
> > 
> > Signed-off-by: Lukas Bulwahn <[email protected]>
> > ---
> > I would like to submit such a patch, what do I need to do according to
> > the expected testing and verification recommendations for safety-related
> > systems?
> > 
> > Please help me. What do I need to compile, what test do I need to run,
> > which verification tool do I need to employ for this change?
> 
> The change looks valid, 'reclaim_order' has not been used anywhere after
> READ_ONCE(), and its  So, it looks like a harmless change, you will only
> need a good commit message detailing why its harmless.
> 

Thanks, Sudip. Yes, I also conclude it is harmless but I really cannot say 
as I did not even compile it :) and I guess you did not either :)

I would actually want to argue that I compiled it for all available (and 
relevant) kernel configurations and the binary is identical before and 
after the change.

It is a Dead Store, so I expect the compiler to detect that and just 
optimize that away...

> So, from a safety pov, is it a requirement that every submitted patch
> will need to be tested based on the safety tests and all the other
> defined tests?
>

Well, I do not know what Roberto thinks his reference process is good for, 
but I would like to know if Roberto thinks it can guide anyone on such a 
question or not?

It is really just some fun for the discussion in this group... there are 
thousands of commits travelling into the kernel... if we cannot provide 
an answer for a single one, how to do it for thousands?


Lukas