On Sat, 2018-01-06 at 20:36 -0500, David Miller wrote: > From: Willy Tarreau <w@xxxxxx> > Date: Sat, 6 Jan 2018 21:42:29 +0100 > > > On Sat, Jan 06, 2018 at 06:38:59PM +0000, Alan Cox wrote: > >> Normally people who propose security fixes don't have to argue > about the > >> fact they added 30 clocks to avoid your box being 0wned. > > > > In fact it depends, because if a fix makes the system unusable for > its > > initial purpose, this fix will simply not be deployed at all, which > is > > the worst that can happen. > > +1 > > I completely agree with Willy and Alexei. > > And the scale isn't even accurate, we're talking about at least > hundreds upon hundreds of clocks, not 30, if we add an operation > whose side effect is to wait for all pending loads to complete. So > yeah this is going to be heavily scrutinized. Plus this is the standard kernel code review MO: we've never blindly accepted code just because *security* (otherwise we'd have grsec in by now). We use the pushback to get better and more performant code. What often happens is it turns out that the "either security or performance" position was a false dichotomy and there is a way of fixing stuff that's acceptable (although not usually perfect) for everyone. I'm not saying this always happens, but it is reasonable to let the iterative pushback see if we can get to better code in this case rather than trying to cut it of with the "because *security*" argument. James
