Marcos-David Dione/NCE/AMADEUS wrote on 24/11/2014 11:10:42:
Seen like that I'm not sure if there's a defined behaviourfor that. I'll ask in the glibc and/or kernel MLs and I'll come back with the answer.
and here's the answer:
On 11/24/2014 03:34 PM, Marcos Dione wrote:
We found a situation where a robust mutex cannot be recoveredfrom a stale lock and we're wondering if it's simply an undefined situation or a bug in the kernel. Attached you will find the sample code, which is loosely based on a glibc's test case.The gist of it is
as
follows:
- we open a file.
- we mmap it and use that mem to store a robust mutex.
- we lock the mutex.
- we munmap the file.
- we close the file.
Undefined behaviour.
This results in undefined behaviour since the allocated storage for the mutex object has been lost. You need to keep that storage around for the robust algorithms to work with. Without any data you can't do anything.
Full answer:
https://sourceware.org/ml/libc-help/2014-11/msg00035.html
-- Marcos Dione Astek Sud-Est R&D-SSP-DTA-TAE-TDS for Amadeus SAS T: +33 (4)4 9704 1727 marcos-david.dione@amadeus.com
Marcos-David Dione wrote:
Marcos-David Dione/NCE/AMADEUS wrote on 24/11/2014 11:10:42:
Seen like that I'm not sure if there's a defined behaviourfor that. I'll ask in the glibc and/or kernel MLs and I'll come back with the answer.
and here's the answer:On 11/24/2014 03:34 PM, Marcos Dione wrote:
We found a situation where a robust mutex cannot be recoveredfrom a stale lock and we're wondering if it's simply an undefined situation or a bug in the kernel. Attached you will find the sample code, which is loosely based on a glibc's test case.The gist of it
is as
follows:
- we open a file.
- we mmap it and use that mem to store a robust mutex.
- we lock the mutex.
- we munmap the file.
- we close the file.
Undefined behaviour.
This results in undefined behaviour since the allocated storage for the mutex object has been lost. You need to keep that storage around for the robust algorithms to work with. Without any data you can't do anything.
Full answer:
Fyi, this would not have been a bug in Solaris:
https://docs.oracle.com/cd/E19253-01/816-5168/pthread-mutexattr-setrobust-np...
"openldap-devel" openldap-devel-bounces@openldap.org wrote on 25/11/2014
16:19:40:
Fyi, this would not have been a bug in Solaris:
https://docs.oracle.com/cd/E19253-01/816-5168/pthread-mutexattr- setrobust-np-3c/index.html
you mean, because of the phrase «When the owner of a mutex with the PTHREAD_MUTEX_ROBUST_NP robustness attribute dies, or when the process containing such a locked mutex unmaps the memory containing the mutex or performs one of the exec(2) functions, the mutex is unlocked.»? I'm not sure that when it says 'unmap' it means 'munmap()s'.
-- Marcos Dione Astek Sud-Est R&D-SSP-DTA-TAE-TDS for Amadeus SAS T: +33 (4)4 9704 1727 marcos-david.dione@amadeus.com
Marcos-David Dione wrote:
"openldap-devel" openldap-devel-bounces@openldap.org wrote on 25/11/2014 16:19:40:
Fyi, this would not have been a bug in Solaris:
https://docs.oracle.com/cd/E19253-01/816-5168/pthread-mutexattr- setrobust-np-3c/index.html
you mean, because of the phrase «When the owner of a mutex withthe PTHREAD_MUTEX_ROBUST_NP /robustness/ attribute dies, or when the process containing such a locked mutex unmaps the memory containing the mutex or performs one of the _exec(2)_ https://docs.oracle.com/docs/cd/E19253-01/816-5167/exec-2/index.htmlfunctions, the mutex is unlocked.»? I'm not sure that when it says 'unmap' it means 'munmap()s'.
There is no other meaning of the word. A process-shared mutex must reside in shared memory. When a process detaches from that shared memory, it is unmapped.
-
Howard Chu -
Marcos-David Dione