On Wednesday, September 11, 2013 2:10:11 pm Davide Italiano wrote:
> [snip]
>
> > Well, I've thought about changing lc_lock/unlock to return a uintptr_t or
> > void * instead of an int and then I could make rm_sleep work fine.
However,
> > that still doesn't solve the callout case. The callout case can't be
fixed
> > easily without explicitly allocating storage in the softclock thread
itself.
> >
> > Also, I don't think you want a pointer in a lock_object. Imagine if two
> > threads both locked and then slept on the same rm lock in succession while
> > waiting for a wakeup. You would have two trackers to keep track of, but
only
> > one pointer in the lock_object.
> >
> > I'm not sure you need to revert your commit. It should pretty much panic
> > instantly if someone tries to use it with a read lock instead of a write
> > lock, even without INVARIANTS.
> >
> > --
> > John Baldwin
>
> Hi John,
> I've finally gotten around to dedicate some time to this.
> The following patch :
> http://people.freebsd.org/~davide/review/callout_sharedrm.diff is a
> proposed fix the problem for the callout_rm shared case, based on your
> suggestions.
> I've overloaded the lc_lock/lc_unlock functions so that they take an
> additional void *arg argument which in the callout rm shared case is a
> pointer to priotracker structure (I used a void * so that it could be
> used for some other purposes in the future, if any).
> I've also added a MPASS in the lc_lock()/lc_unlock() functions for all
> the primitives but rmlock so that is ensured that arg passed is NULL.
> I'm not completely sure this is required but I put that there as
> safety belt.
> The KPI is highly disturbed by this change, but unfortunately I wasn't
> able to find out a way to workaround the problem without this
> breakage. While we're breaking things, I guess we can fix the
> rm_sleep() case as well instead of causing a double breakage.
> My only doubt is what exactly we should return from lc_unlock/lc_lock,
> as long as in the, e.g. rwlock case we need to return a boolean that
> contains lock state (shared/exclusive) whilst in the rmlock case we
> need to return both the lock state and a pointer to struct
> rm_priotracker. My best guess is that of introducing a 'struct
> lockstate' (sorry for the poor name choice, just to give you the idea)
> which contains these two informations, but probably we can
> alternatively use a single pointer and store the information about
> lock state in the low order bits.
> What's your opinion about?
Hmm, I think I had envisioned something a bit simpler. Namely, I would
change lc_lock/lc_unlock to return a uintptr_t instead of an int, and
I would then change lc_unlock for an rm lock to return a pointer to the
current thread's tracker as the 'how' and 0 for a write lock. Note
that you have to use the existing tracker to make this work correctly
for the sleep case where you unlock/lock.
For the callout case I figured you would just hack it explicitly like
this:
if (flags & CALLOUT_SHAREDRM)
rm_rlock(...)
else
lock->lc_lock();
However, if you make my suggested change to make the 'how' a uintptr_t
that passes the tracker you can actually do this in the callout case:
struct rm_priotracker tracker;
uintptr_t how;
how = 0;
if (flags & CALLOUT_SHAREDLOCK)
how = 1;
else if (flags & CALLOUT_SHAREDRM)
how = (uintptr_t)&tracker;
...
class->lc_lock(lock, how);
Now, it would be even nicer to make prevent footshooting perhaps by
checking the lock class directly:
how = 0;
if (flags & CALLOUT_SHAREDLOCK) {
if (class == &lock_class_rm || class ==
&lock_class_rm_sleepable)
how = (uintptr_t)&tracker;
else
how = 1;
}
--
John Baldwin
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
