On Tue, May 14, 2019 at 09:31:48AM +0800, Yuyang Du wrote: > Thanks for review. > > On Mon, 13 May 2019 at 19:45, Peter Zijlstra <[email protected]> wrote: > > > > On Mon, May 13, 2019 at 05:11:47PM +0800, Yuyang Du wrote: > > > + * Note that we have an assumption that a lock class cannot ever be both > > > + * read and recursive-read. > > > > We have such locks in the kernel... see: > > > > kernel/qrwlock.c:queued_read_lock_slowpath() > > > > And yes, that is somewhat unfortunate, but hard to get rid of due to > > hysterical raisins. > > That is ok, then LOCK_TYPE_RECURSIVE has to be 3 such that > LOCK_TYPE_RECURSIVE & LOCK_TYPE_READ != 0. I thought to do this in the > first place without assuming. Anyway, it is better to know. > > And I guess in a task: > > (1) read(X); > recursive_read(x); /* this is ok ? */
Correct, that is the use-case for that 'funny' construct. > (2) recursive_read(x); > read(x) /* not ok ? */ Indeed, read can block due to a pending writer, while recurise_read will not suffer like that. > Either way, very small change may need to be made. OK, excellent.
