On 1/3/2018 5:10 PM, Byungchul Park wrote:
On 1/3/2018 4:05 PM, Theodore Ts'o wrote:
On Wed, Jan 03, 2018 at 11:10:37AM +0900, Byungchul Park wrote:
The point I was trying to drive home is that "all we have to do is
just classify everything well or just invalidate the right lock
Just to be sure, we don't have to invalidate lock objects at all but
a problematic waiter only.
So essentially you are proposing that we have to play "whack-a-mole"
as we find false positives, and where we may have to put in ad-hoc
plumbing to only invalidate "a problematic waiter" when it's
problematic --- or to entirely suppress the problematic waiter
If we have too many problematic completions(waiters) to handle it,
then I agree with you. But so far, only one exits and it seems able
to be handled even in the future on my own.
Or if you believe that we have a lot of those kind of completions
making trouble so we cannot handle it, the (4) by Amir would work,
no? I'm asking because I'm really curious about your opinion..
altogether. And in that case, a file system developer might be forced
to invalidate a lock/"waiter"/"completion" in another subsystem.
As I said, with regard to the invalidation, we don't have to
consider locks at all. It's enough to invalidate the waiter only.
I will also remind you that doing this will trigger a checkpatch.pl
*error*:
This is what we decided. And I think the decision is reasonable for
original lockdep. But I wonder if we should apply the same decision
on waiters. I don't insist but just wonder.
What if we adopt the (4) in which waiters are validated one by one
and no explicit invalidation is involved?
ERROR("LOCKDEP", "lockdep_no_validate class is reserved for
device->mutex.\n" . $herecurr);
- Ted
--
Thanks,
Byungchul
