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
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
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
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
* 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
* 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
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:
>>
>>
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:
>>
>>
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
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
>>>
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
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
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
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:
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:
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
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
> "Reshetova, Elena" writes:
>
> >> "Reshetova, Elena" writes:
> >>
> >> >> "Reshetova, Elena" writes:
> >> >>
> >> >> 2>> Elena Reshetova writes:
> >> >> >>
> >> >> >> > refcount_t
> "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
"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
> "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
> "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
"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
>> >> >
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
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
> "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
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
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
"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
>> >
> 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
> >
> 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
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
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
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-off-by: Elena Reshetova
Signed-off-by:
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-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
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
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
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
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.
>
>
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-off-by: Elena Reshetova
Signed-off-by:
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-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
46 matches
Mail list logo