[MODERATED] Re: [PATCH v5 00/27] MDSv5 19

On Thu, Feb 14, 2019 at 10:33:59AM -0800, speck for Andi Kleen wrote:
> > > everyone understands these implications.
> > 
> > No, we don't (or at least I do not), understand any of the implications
> > here because the questions I asked were never answered.  So far you have
> 
> The original patches flushed on every kernel exit.
> This was rejected as default because it has some overhead
> (we saw ~6% for a micro benchmark, RH saw more in a very unrealistic
> micro) 
> 
> The second (actually third) version didn't flush on every
> kernel exit, but only on asynchronous events like non whitelisted
> interrupts/timers/tasklets
> 
> The vast majority of the performance improvement came
> from not flushing for process context system calls and exceptions.
> At least in our benchmarks there was very little overhead
> with that solution, with most kernel exits not flushing
> anymore, and any penalties near the noise level.
> 
> But it relied on asynchronous events white listing
> to avoid having to patch most of the tree.
> 
> The feedback, including from you, was that this would 
> be still unacceptable to slow down any interrupt handlers or timers
> that don't touch user data.

Of course that's not ok.

I also asked, as did Thomas, what is "user data" in this type of
situation?  Without having that definition, it's been impossible for me
to propose anything here.

> > just "told us what you are going to do" and then never even backed that
> > up with reasons for why you are doing that.
> 
> !?!? I wrote long document with a full security model.
> 
> Did you read it? I don't remember any comments on that from you.

Thomas beat me to it, please go back and look at his questions.  Most of
those have yet to be answered, including my "simple" one above.

> > Why would anyone want to take
> > that?
> 
> Are you asking about the mds=full variant, (like v2 of the patch series)
> 
> It's really simple, straight forward, and has a very strictly defined
> easy security model that can be explained in a few sentences.

And it's a non-viable solution.  Please stop pushing this.

> It's also very similar to what will be eventually in tree
> as the code path for mds=full, there haven't been any changes
> to this at all.
> 
> Its only drawback is some performance penalty. Everything else
> is vastly superior over any other solutions.

"only" is not ok.  I'm still getting yelled at for the spectre fixes and
how it slowed down people's workloads.  It's also easy to just run in UP
mode to solve all of these, right?  :)

greg k-h