On Mon, Aug 23, 2021 at 05:18:12PM +0200, Andreas Gruenbacher wrote: > On Mon, Aug 23, 2021 at 10:14 AM Steven Whitehouse <swhiteho@xxxxxxxxxx> wrote: > > If the goal here is just to allow the glock to be held for a longer > > period of time, but with occasional interruptions to prevent > > starvation, then we have a potential model for this. There is > > cond_resched_lock() which does this for spin locks. > > This isn't an appropriate model for what I'm trying to achieve here. > In the cond_resched case, we know at the time of the cond_resched call > whether or not we want to schedule. If we do, we want to drop the spin > lock, schedule, and then re-acquire the spin lock. In the case we're > looking at here, we want to fault in user pages. There is no way of > knowing beforehand if the glock we're currently holding will have to > be dropped to achieve that. In fact, it will almost never have to be > dropped. But if it does, we need to drop it straight away to allow the > conflicting locking request to succeed. It occurs to me that this is similar to the wound/wait mutexes (include/linux/ww_mutex.h & Documentation/locking/ww-mutex-design.rst). You want to mark the glock as woundable before faulting, and then discover if it was wounded after faulting. Maybe sharing this terminology will aid in understanding?
