lkml.org 
[lkml]   [2016]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] kasan: improve double-free detection
Date
> >> 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).
> >>
> >
> > Available CAS primitives/compiler do not support CAS with bitfield. I propose
> > to change kasan_alloc_meta to:
> >
> > struct kasan_alloc_meta {
> > struct kasan_track track;
> > u16 size_delta; /* object_size - alloc size */
> > u8 state; /* enum kasan_state */
> > u8 reserved1;
> > u32 reserved2;
> > }
> >
> > This shrinks _used_ meta object by 1 byte wrt the original. (btw, patch v1 does
> > not increase overall alloc meta object size). "Alloc size", where needed, is
> > easily calculated as a delta from cache->object_size.
>
>
> What is the maximum size that slab can allocate?
> I remember seeing slabs as large as 4MB some time ago (or did I
> confuse it with something else?). If there are such large objects,
> that 2 bytes won't be able to hold even delta.
> However, now on my desktop I don't see slabs larger than 16KB in
> /proc/slabinfo.

max size for SLAB's slab is 32MB; default is 4MB. I must have gotten confused by
SLUB's 8KB limit. Anyway, new kasan_alloc_meta in patch V2:

struct kasan_alloc_meta {
struct kasan_track track;
union {
u8 lock;
struct {
u32 dummy : 8;
u32 size_delta : 24; /* object_size - alloc size */
};
};
u32 state : 2; /* enum kasan_alloc_state */
u32 unused : 30;
};

This uses 2 more bits than current, but given the constraints I think this is
close to optimal.

Kuthonuzo
\
 
 \ /
  Last update: 2016-05-04 22:41    [W:0.090 / U:4.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site