svn commit: r254703 - in head: share/man/man9 sys/sys

[Davide Italiano]

[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?

Thanks,

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare