On Fri, 2017-04-21 at 14:30 -0700, Kees Cook wrote:
> On Fri, Apr 21, 2017 at 2:27 PM, James Bottomley
> wrote:
> > On Fri, 2017-04-21 at 13:22 -0700, Kees Cook wrote:
> > > On Fri, Apr 21, 2017 at 12:55 PM, Eric Biggers <
> > > ebigge...@gmail.com>
> > > wrote:
> > > > > > Of course, having extra
On Fri, Apr 21, 2017 at 2:27 PM, James Bottomley
wrote:
> On Fri, 2017-04-21 at 13:22 -0700, Kees Cook wrote:
>> On Fri, Apr 21, 2017 at 12:55 PM, Eric Biggers
>> wrote:
>> > > > Of course, having extra checks behind a debug option is fine.
>> > > > But they should not be part of the base featur
On Fri, 2017-04-21 at 13:22 -0700, Kees Cook wrote:
> On Fri, Apr 21, 2017 at 12:55 PM, Eric Biggers
> wrote:
> > > > Of course, having extra checks behind a debug option is fine.
> > > > But they should not be part of the base feature; the base
> > > > feature should just be mitigation of ref
On Fri, Apr 21, 2017 at 12:55 PM, Eric Biggers wrote:
> Hi Elena,
>
> On Fri, Apr 21, 2017 at 10:55:29AM +, Reshetova, Elena wrote:
>> >
>> > At the very least, what is there now could probably be made about twice as
>> > fast
>> > by removing the checks that don't actually help mitigate refc
Hi Elena,
On Fri, Apr 21, 2017 at 10:55:29AM +, Reshetova, Elena wrote:
> >
> > At the very least, what is there now could probably be made about twice as
> > fast
> > by removing the checks that don't actually help mitigate refcount overflow
> > bugs,
> > specifically all the checks in ref
On Fri, Apr 21, 2017 at 3:55 AM, Reshetova, Elena
wrote:
> On Thu, Apr 20, 2017 at 11:33 AM, Eric Biggers wrote:
>> Of course, having extra checks behind a debug option is fine. But they
>> should
>> not be part of the base feature; the base feature should just be mitigation
>> of
>> reference
On Fri, Apr 21, 2017 at 08:03:13AM -0600, Jens Axboe wrote:
> You have it so easy - the code is completely standalone, building a
> small test framework around it and measuring performance in _user space_
> is trivial.
Something like this you mean:
https://lkml.kernel.org/r/20170322165144.dtid
On 04/21/2017 09:22 AM, Peter Zijlstra wrote:
> On Fri, Apr 21, 2017 at 08:03:13AM -0600, Jens Axboe wrote:
>> You have it so easy - the code is completely standalone, building a
>> small test framework around it and measuring performance in _user space_
>> is trivial.
>
> Something like this you
On 04/21/2017 04:55 AM, Reshetova, Elena wrote:
Please don't send any more conversions until those have been resolved.
>>
>> Like I suggested months ago, how about doing an efficient implementation of
>> refcount_t which doesn't use the bloated cmpxchg loop? Then there would be
>> no
>> need
On Thu, Apr 20, 2017 at 11:33:19AM -0700, Eric Biggers wrote:
> Like I suggested months ago, how about doing an efficient implementation of
> refcount_t which doesn't use the bloated cmpxchg loop? Then there would be no
> need for endless performance arguments. In fact, in PaX there are already
>
> Hi Elena,
>
> On Thu, Apr 20, 2017 at 04:10:16PM +, Reshetova, Elena wrote:
> >
> > > All the objections from DaveM on the amount of cycles spent on the
> > > new refcount_t apply to the block layer fast path operations as well.
> >
> > Ok, could you please indicate the correct way to measur
Hi Elena,
On Thu, Apr 20, 2017 at 04:10:16PM +, Reshetova, Elena wrote:
>
> > All the objections from DaveM on the amount of cycles spent on the
> > new refcount_t apply to the block layer fast path operations as well.
>
> Ok, could you please indicate the correct way to measure the impact f
> All the objections from DaveM on the amount of cycles spent on the
> new refcount_t apply to the block layer fast path operations as well.
Ok, could you please indicate the correct way to measure the impact for the
block layer?
We can do the measurements.
Best Regards,
Elena.
>
> Please d
All the objections from DaveM on the amount of cycles spent on the
new refcount_t apply to the block layer fast path operations as well.
Please don't send any more conversions until those have been resolved.
14 matches
Mail list logo