Re: Robust mutexes implementation

On Mon, May 09, 2016 at 05:51:07AM +0300, Konstantin Belousov wrote:
> On Sun, May 08, 2016 at 02:52:22PM +0200, Jilles Tjoelker wrote:
> > OK. The patch still initializes umtx_shm_vnobj_persistent to 1 though.
> > There is also a leak if umtx_shm_vnobj_persistent is toggled from 1 to 0
> > while an unmapped object with an off-page is active.

> [snip]

> > All this is POSIX-compliant since POSIX specifies that the state of
> > synchronization objects becomes undefined on last unmap, and our
> > implementation fundamentally depends on that possibility. Unfortunately,

> Could you, please, point me to the exact place in the standard where
> this is allowed ?

The mmap() page in POSIX.1-2008tc1 XSH 3 has:

] The state of synchronization objects such as mutexes, semaphores,
] barriers, and conditional variables placed in shared memory mapped
] with MAP_SHARED becomes undefined when the last region in any process
] containing the synchronization object is unmapped.

This is new in issue 7 (SUSv4):

] Austin Group Interpretations 1003.1-2001 #078 and #079 are applied,
] clarifying page alignment requirements and adding a note about the
] state of synchronization objects becoming undefined when a shared
] region is unmapped.

> > Linux and Solaris do not need the possibility. The automatic
> > re-initialization and umtx_vnode_persistent are just hacks that make
> > certain applications almost always work (but not always, and in such
> > cases it will be hard to debug).

> > Another issue with umtx_vnode_persistent is that it can hide high memory
> > usage. Filling up a page with pthread_mutex_t will create many pages
> > full of actual mutexes. This memory usage is only visible as long as it
> > is still mapped somewhere.

> There is already a resource limit for the number of pshared locks per
> uid, RLIMIT_UMTXP. When exceeded, user would get somewhat obscure
> failure mode, but excessive memory consumption is not allowed. And I
> think that vmstat -o would give enough info to diagnose, except that
> users must know about it and be quialified enough to interpret the
> output.

Hmm, OK.

> > Apart from that, umtx_vnode_persistent can (at least conceptually) work
> > fully reliably for shared memory objects and tmpfs files, which do not
> > have persistent storage.

> I changed defaults for the umtx_vnode_persistent to 0 in the published
> patch.

OK.

> > Hmm, libthr2 or non-standard synchronization primitive implementations
> > seem a good reason to not check for umtx shm page.

> > However, the existing checks can be made stricter. The umtx_handle_rb()
> > from robust.3.patch will use m_rb_lnk with no validation at all except
> > that it is a valid pointer. However, if the UMUTEX_ROBUST flag is not
> > set, the mutex should not have been in this list at all and it is
> > probably safer to ignore m_rb_lnk.

> Ok, I changed the code to consider lack of UMUTEX_ROBUST as a stopper
> for the list walk.  Also, I stop the walk if mutex is not owned by
> the current thread, except when the mutex was stored in inact slot.
> The same piece of changes hopefully fixes list walk for COMPAT32 on
> big-endian machines.

OK.

> > There is a difference between chunked allocations and the current
> > m_rb_lnk in that the list would reside in local memory, not vulnerable
> > to other processes scribbling over it. This is probably not a major
> > issue since sharing a mutex already allows threads to block each other
> > indefinitely.

> I would easily deletegate the chunked array to some future reimplementation
> if not the ABI issue.  Still, I do not like it.

An array only works well for this if you know beforehand how long it
needs to be, and I don't think we can do this since Linux's limit is so
high that an array would waste a lot of memory.

The existence of some limit is, however, unavoidable and it could be
considered a bug that pthread_mutex_lock() for a robust mutex returns
success even if it will not fulfill its promise to do the EOWNERDEAD
thing.

> Current updates to the patch https://kib.kiev.ua/kib/pshared/robust.4.patch

-- 
Jilles Tjoelker
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-threads
To unsubscribe, send any mail to "[email protected]"