> > Next time, when/if you send patch series, send patches in one thread, i.e.
> > patches should be replies to the cover letter.
> > Your patches are not linked together, which makes them harder to track.
Thanks for the tip; but doesn't this conflict with the advice in
https://www.kernel.org/doc/
> > 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 serializing access to KASAN object metadata.
> > New functions kasan_meta_lock() and kasan_meta_unlock() are provid
> > + int cpu, cnt = num_online_cpus();
> > + cpumask_t mask = { CPU_BITS_NONE };
> > + size_t size = 4097; /* must be <= KMALLOC_MAX_CACHE_SIZE/2 */
> Can you please explicitly calculate |size| from KMALLOC_MAX_CACHE_SIZE?
> > +
> > + if (cnt == 1)
> > + r
> >> > +/* flags shadow for object header if it has been overwritten. */
> >> > +void kasan_mark_bad_meta(struct kasan_alloc_meta *alloc_info,
> >> > + struct kasan_access_info *info)
> >> > +{
> >> > + u8 *datap = (u8 *)&alloc_info->data;
> >> > +
> >> > + if u8 *)inf
> > +/* flags shadow for object header if it has been overwritten. */
> > +void kasan_mark_bad_meta(struct kasan_alloc_meta *alloc_info,
> > + struct kasan_access_info *info)
> > +{
> > + u8 *datap = (u8 *)&alloc_info->data;
> > +
> > + if u8 *)info->access_addr + info
> > 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 serializing access to KASAN object metadata.
> > New functions kasan_meta_lock() and kasan_meta_unlock() are provid
> >> Thank you for the review!
> >>
> >> > > + switch (alloc_data.state) {
> >> > > + case KASAN_STATE_QUARANTINE:
> >> > > + case KASAN_STATE_FREE:
> >> > > + kasan_report((unsigned long)object, 0, false,
> >> > > + (unsigned long)__builtin_return_address(1));
> >>
Thank you for the review!
> > +
> > +/* acquire per-object lock for access to KASAN metadata. */
>
> I believe there's strong reason not to use standard spin_lock() or
> similar. I think it's proper place to explain it.
>
will do.
> > +void kasan_meta_lock(struct kasan_alloc_meta *alloc_info)
> >> 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,
> >> >> 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
> >> 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
>
> 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
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
16 matches
Mail list logo
