On Thu, Jul 20, 2017 at 5:34 AM, Eric W. Biederman
wrote:
> Ingo Molnar writes:
>
>> * Andrew Morton wrote:
>>
>>> On Wed, 19 Jul 2017 15:54:27 -0700 Davidlohr Bueso
>>> wrote:
>>>
>>> > On Wed, 19 Jul 2017, Andrew Morton wrote:
>>> >
>>> > >I do rather dislike these conversions from the point
Ingo Molnar writes:
> * Andrew Morton wrote:
>
>> On Wed, 19 Jul 2017 15:54:27 -0700 Davidlohr Bueso wrote:
>>
>> > On Wed, 19 Jul 2017, Andrew Morton wrote:
>> >
>> > >I do rather dislike these conversions from the point of view of
>> > >performance overhead and general code bloat. But I se
* Andrew Morton wrote:
> On Wed, 19 Jul 2017 15:54:27 -0700 Davidlohr Bueso wrote:
>
> > On Wed, 19 Jul 2017, Andrew Morton wrote:
> >
> > >I do rather dislike these conversions from the point of view of
> > >performance overhead and general code bloat. But I seem to have lost
> > >that stru
On Wed, Jul 19, 2017 at 4:20 PM, Kees Cook wrote:
> On Wed, Jul 19, 2017 at 4:11 PM, Davidlohr Bueso wrote:
>> May I suggest using mmtests with the following config file:
>>
>> https://github.com/gormanm/mmtests/blob/7e070a810bc0af92e592e5121d0ea75fada51aeb/configs/config-global-dhp__workload-ipc
On Wed, Jul 19, 2017 at 4:11 PM, Davidlohr Bueso wrote:
> On Wed, 19 Jul 2017, Andrew Morton wrote:
>
>> On Wed, 19 Jul 2017 15:54:27 -0700 Davidlohr Bueso
>> wrote:
>>
>>> On Wed, 19 Jul 2017, Andrew Morton wrote:
>>>
>>> >I do rather dislike these conversions from the point of view of
>>> >perf
On Wed, 19 Jul 2017, Andrew Morton wrote:
On Wed, 19 Jul 2017 15:54:27 -0700 Davidlohr Bueso wrote:
On Wed, 19 Jul 2017, Andrew Morton wrote:
>I do rather dislike these conversions from the point of view of
>performance overhead and general code bloat. But I seem to have lost
>that struggle
On Wed, 19 Jul 2017 15:54:27 -0700 Davidlohr Bueso wrote:
> On Wed, 19 Jul 2017, Andrew Morton wrote:
>
> >I do rather dislike these conversions from the point of view of
> >performance overhead and general code bloat. But I seem to have lost
> >that struggle and I don't think any of these are
On Wed, 19 Jul 2017, Andrew Morton wrote:
I do rather dislike these conversions from the point of view of
performance overhead and general code bloat. But I seem to have lost
that struggle and I don't think any of these are fastpath(?).
Well, since we now have fd25d19 (locking/refcount: Creat
On Sun, 09 Jul 2017 16:59:55 -0500 ebied...@xmission.com (Eric W. Biederman)
wrote:
> Elena Reshetova writes:
>
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter o
> "Reshetova, Elena" writes:
>
> >> "Reshetova, Elena" writes:
> >>
> >> >> "Reshetova, Elena" writes:
> >> >>
> >> >> 2>> Elena Reshetova writes:
> >> >> >>
> >> >> >> > refcount_t type and corresponding API should be
> >> >> >> > used instead of atomic_t when the variable is used as
> >>
"Reshetova, Elena" writes:
>> "Reshetova, Elena" writes:
>>
>> >> "Reshetova, Elena" writes:
>> >>
>> >> 2>> Elena Reshetova writes:
>> >> >>
>> >> >> > refcount_t type and corresponding API should be
>> >> >> > used instead of atomic_t when the variable is used as
>> >> >> > a reference coun
> "Reshetova, Elena" writes:
>
> >> "Reshetova, Elena" writes:
> >>
> >> 2>> Elena Reshetova writes:
> >> >>
> >> >> > refcount_t type and corresponding API should be
> >> >> > used instead of atomic_t when the variable is used as
> >> >> > a reference counter. This allows to avoid accidental
>
"Reshetova, Elena" writes:
>> "Reshetova, Elena" writes:
>>
>> 2>> Elena Reshetova writes:
>> >>
>> >> > refcount_t type and corresponding API should be
>> >> > used instead of atomic_t when the variable is used as
>> >> > a reference counter. This allows to avoid accidental
>> >> > refcounter
Alexey Dobriyan writes:
> On Mon, Jul 10, 2017 at 11:37 AM, Eric W. Biederman
> wrote:
>> "Reshetova, Elena" writes:
>>
>> 2>> Elena Reshetova writes:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference cou
> "Reshetova, Elena" writes:
>
> 2>> Elena Reshetova writes:
> >>
> >> > refcount_t type and corresponding API should be
> >> > used instead of atomic_t when the variable is used as
> >> > a reference counter. This allows to avoid accidental
> >> > refcounter overflows that might lead to use-aft
On Mon, Jul 10, 2017 at 11:37 AM, Eric W. Biederman
wrote:
> "Reshetova, Elena" writes:
>
> 2>> Elena Reshetova writes:
>>>
>>> > refcount_t type and corresponding API should be
>>> > used instead of atomic_t when the variable is used as
>>> > a reference counter. This allows to avoid accidental
"Reshetova, Elena" writes:
2>> Elena Reshetova writes:
>>
>> > refcount_t type and corresponding API should be
>> > used instead of atomic_t when the variable is used as
>> > a reference counter. This allows to avoid accidental
>> > refcounter overflows that might lead to use-after-free
>> > si
> Elena Reshetova writes:
>
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
>
> In this patch you can
Elena Reshetova writes:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
In this patch you can see all of the use
On 05/27/2017 09:41 PM, Kees Cook wrote:
On Mon, Feb 20, 2017 at 3:29 AM, Elena Reshetova
wrote:
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use
On Mon, Feb 20, 2017 at 3:29 AM, Elena Reshetova
wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
>
> Signed
21 matches
Mail list logo