Messages in this thread | | | Subject | Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1 | From | Waiman Long <> | Date | Fri, 3 Apr 2020 19:16:03 -0400 |
| |
On 4/3/20 4:59 PM, Linus Torvalds wrote: > On Fri, Apr 3, 2020 at 1:41 PM Waiman Long <longman@redhat.com> wrote: >> Another alternative is to add new functions like down_read_unfair() that >> perform unfair read locking for its callers. That will require less code >> change, but the calling functions have to make the right choice. > I'd prefer the static choice model - and I'd hide this in some > "task_cred_read_lock()" function anyway rather than have the users do > "mutex_lock_killable(&task->signal->cred_guard_mutex)" like they do > now. > > How nasty would it be to add the "upgrade" op? I took a quick look, > but that just made me go "Waiman would know" ;) > > Linus > With static choice, you mean defined at init time. Right? In that case, you don't really need a special encapsulation function.
With upgrade, if there is only one reader, it is pretty straight forward. With more than one readers, it gets more complicated as we have to wait for other readers to unlock. We can spin for a certain period of time. After that, that reader can use the handoff mechanism by queuing itself in front the wait queue before releasing the read lock and go to sleep. That will make sure that it will get the lock once all the other readers exits. For an unfair rwsem, the writer cannot assert the handoff bit and so it shouldn't interfere with this upgrade process.
If there are multiple upgrade readers, only one can win the race. The others have to release the read lock and queue themselves as writers. Will that be acceptable?
Cheers, Longman
Cheers, Longman
| |