lkml.org 
[lkml]   [2020]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH smp 2/2] kernel/smp: Provide CSD lock timeout diagnostics
On Thu, Jul 23, 2020 at 03:50:57PM -0700, Paul E. McKenney wrote:
> On Thu, Jul 23, 2020 at 03:55:56PM +0200, Peter Zijlstra wrote:

[ . . . ]

> > > + ts2 = sched_clock();
> > > + ts_delta = ts2 - *ts1;
> > > + if (likely(ts_delta <= CSD_LOCK_TIMEOUT)) {
> > > + cpu_relax();
> > > + return false;
> > > + }
> > > +
> > > + firsttime = !*bug_id;
> > > + if (firsttime)
> > > + *bug_id = atomic_inc_return(&csd_bug_count);
> > > + cpu = csd_lock_wait_getcpu(csd);
> > > + smp_mb(); // No stale cur_csd values!
> >
> > > + if (WARN_ONCE(cpu < 0 || cpu >= nr_cpu_ids, "%s: cpu = %d\n", __func__, cpu))
> > > + cpu_cur_csd = READ_ONCE(per_cpu(cur_csd, 0));
> > > + else
> > > + cpu_cur_csd = READ_ONCE(per_cpu(cur_csd, cpu));
> >
> > This is a potential user-after-free, func() may free the csd when async.
> > Although I don't believe anybody does so.
>
> Huh. This will require some thought. The one that the CPU is currently
> executing is available, so this is a problem only when they stack up.

Bah. This is exactly why the cur_csd_func and cur_csd_info per-CPU
variables exist, and so I just need to actually use them. :-/

Thanx, Paul

\
 
 \ /
  Last update: 2020-07-24 20:20    [W:0.113 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site