> >> We can use per-header lock by setting status to KASAN_STATE_LOCKED. A
> >> thread can CAS any status to KASAN_STATE_LOCKED which means that it
> >> locked the header. If any thread tried to modify/read the status and
> >> the status is KASAN_STATE_LOCKED, then the thread waits.
> >
> > Thanks
> >> >> >> I missed that Alexander already landed patches that reduce header
> >> >> >> size
> >> >> >> to 16 bytes.
> >> >> >> It is not OK to increase them again. Please leave state as bitfield
> >> >> >> and update it with CAS (if we introduce helper functions for state
> >> >> >> manipulation,
On Thu, May 5, 2016 at 8:23 AM, Luruo, Kuthonuzo
wrote:
>> >> >> I missed that Alexander already landed patches that reduce header size
>> >> >> to 16 bytes.
>> >> >> It is not OK to increase them again. Please leave state as bitfield
>> >> >> and update it with CAS (if we introduce helper functio
> >> >> I missed that Alexander already landed patches that reduce header size
> >> >> to 16 bytes.
> >> >> It is not OK to increase them again. Please leave state as bitfield
> >> >> and update it with CAS (if we introduce helper functions for state
> >> >> manipulation, they will hide the CAS loo
On Wed, May 4, 2016 at 10:13 PM, Luruo, Kuthonuzo
wrote:
>> >> I missed that Alexander already landed patches that reduce header size
>> >> to 16 bytes.
>> >> It is not OK to increase them again. Please leave state as bitfield
>> >> and update it with CAS (if we introduce helper functions for stat
> >> I missed that Alexander already landed patches that reduce header size
> >> to 16 bytes.
> >> It is not OK to increase them again. Please leave state as bitfield
> >> and update it with CAS (if we introduce helper functions for state
> >> manipulation, they will hide the CAS loop, which is nic
On Tue, May 3, 2016 at 11:24 AM, Luruo, Kuthonuzo
wrote:
>>
>> We can use per-header lock by setting status to KASAN_STATE_LOCKED. A
>> thread can CAS any status to KASAN_STATE_LOCKED which means that it
>> locked the header. If any thread tried to modify/read the status and
>> the status is KASA
On Tue, May 3, 2016 at 9:53 AM, Luruo, Kuthonuzo
wrote:
>> I missed that Alexander already landed patches that reduce header size
>> to 16 bytes.
>> It is not OK to increase them again. Please leave state as bitfield
>> and update it with CAS (if we introduce helper functions for state
>> manipula
>
> We can use per-header lock by setting status to KASAN_STATE_LOCKED. A
> thread can CAS any status to KASAN_STATE_LOCKED which means that it
> locked the header. If any thread tried to modify/read the status and
> the status is KASAN_STATE_LOCKED, then the thread waits.
Thanks, Dmitry. I've s
> >
> > I missed that Alexander already landed patches that reduce header size
> > to 16 bytes.
> > It is not OK to increase them again. Please leave state as bitfield
> > and update it with CAS (if we introduce helper functions for state
> > manipulation, they will hide the CAS loop, which is nice
> I missed that Alexander already landed patches that reduce header size
> to 16 bytes.
> It is not OK to increase them again. Please leave state as bitfield
> and update it with CAS (if we introduce helper functions for state
> manipulation, they will hide the CAS loop, which is nice).
>
Availab
On Mon, May 2, 2016 at 1:41 PM, Dmitry Vyukov wrote:
> On Mon, May 2, 2016 at 12:09 PM, Dmitry Vyukov wrote:
>> On Mon, May 2, 2016 at 11:49 AM, Kuthonuzo Luruo
>> wrote:
>>> Hi Alexander/Andrey/Dmitry,
>>>
>>> For your consideration/review. Thanks!
>>>
>>> Kuthonuzo Luruo
>>>
>>> Currently, KAS
On Mon, May 2, 2016 at 12:09 PM, Dmitry Vyukov wrote:
> On Mon, May 2, 2016 at 11:49 AM, Kuthonuzo Luruo
> wrote:
>> Hi Alexander/Andrey/Dmitry,
>>
>> For your consideration/review. Thanks!
>>
>> Kuthonuzo Luruo
>>
>> Currently, KASAN may fail to detect concurrent deallocations of the same
>> obj
On Mon, May 2, 2016 at 1:30 PM, Luruo, Kuthonuzo
wrote:
> Hi Dmitry,
>
> Thanks very much for your response/review.
>
>> I agree that it's something we need to fix (user-space ASAN does
>> something along these lines). My only concern is increase of
>> kasan_alloc_meta size. It's unnecessary large
Hi Dmitry,
Thanks very much for your response/review.
> I agree that it's something we need to fix (user-space ASAN does
> something along these lines). My only concern is increase of
> kasan_alloc_meta size. It's unnecessary large already and we have a
> plan to reduce both alloc and free into t
On Mon, May 2, 2016 at 11:49 AM, Kuthonuzo Luruo
wrote:
> Hi Alexander/Andrey/Dmitry,
>
> For your consideration/review. Thanks!
>
> Kuthonuzo Luruo
>
> Currently, KASAN may fail to detect concurrent deallocations of the same
> object due to a race in kasan_slab_free(). This patch makes double-fre
Hi Alexander/Andrey/Dmitry,
For your consideration/review. Thanks!
Kuthonuzo Luruo
Currently, KASAN may fail to detect concurrent deallocations of the same
object due to a race in kasan_slab_free(). This patch makes double-free
detection more reliable by atomically setting allocation state for
17 matches
Mail list logo
