linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Nicholas Miell <nmiell-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	libc-alpha-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org
Subject: Re: For review: nptl(7) man page
Date: Sun, 26 Jul 2015 22:24:53 +0200	[thread overview]
Message-ID: <55B54215.6070502@gmail.com> (raw)
In-Reply-To: <CAODz2cDq4o85NOzqCDg9cH8eCvqt3Tq5QXKMMJtXbik5h5bL+Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 07/24/2015 05:51 PM, Nicholas Miell wrote:
> PTHREAD_PROCESS_SHARED says any thread with access to the memory containing
> the mutex can operate on the mutex and POSIX basically ignores the idea
> that different processes could be running completely incompatible
> executables or whatever.
> 
> pthread_mutex_t has a bunch of #ifdefs in the middle of it that change the
> structure size and layout between i386 and x86_64.
> 
> Most importantly, the positions of the __nusers and __kind fields are
> swapped (this looks to be an oversight dating back to 2003 when __nusers
> was first introduced and carefully preserved when the separate i386 and
> x86_64 versions of pthreadtypes.h were merged into the single x86 version),
> which means that when the lock and unlock functions attempt to figure out
> what kind of mutex it is (recursive/adaptive/whatever), they'll look at the
> wrong field if the mutex is from the wrong architecture and then things
> will break.
> 
> And then there's the fact that the rest of the struct is a union in the
> 32-bit version and flat in the 64-bit version, but that could have been
> worked around if you put a flag in the __kind field that tells the 64-bit
> pthread library that it is looking at a 32-bit mutex.

Thanks for the additional detail, Nicholas. So, how about a paragraph such 
as the following for the manual page:

       POSIX says that any thread in any process with access to the mem‐
       ory containing a  process-shared  (PTHREAD_PROCESS_SHARED)  mutex
       can  operate  on that mutex.  However, on 64-bit x86 systems, the
       mutex definition for x86-64 is incompatible with the mutex  defi‐
       nition  for  i386,  meaning that 32-bit and 64-bit binaries can't
       share mutexes on x86-64 systems.
?

Cheers,

Michael


> On Fri, Jul 24, 2015 at 12:57 AM, Michael Kerrisk (man-pages) <
> mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
>> On 03/22/2015 10:38 PM, Nicholas Miell wrote:
>>> On 03/22/2015 07:38 AM, Michael Kerrisk (man-pages) wrote:
>>>> Hello all,
>>>>
>>>> I wrote a short man page documented some of the details of
>>>> NPTL that might affect application developers. Review comments
>>>> would be most welcome.
>>>>
>>>> Thanks,
>>>>
>>>> Michael
>>>
>>> POSIX specifies that process-shared pthread_mutex_t's can be manipulated
>>> by independent processes, however the AMD64 and i386 versions of the
>>> mutex structures are incompatible and cannot be shared.
>>>
>>> This might be true of the other supposedly sharable primitives, I never
>>> bothered to check the rest when I first noticed the problem with mutexes.
>>
>> Nicholas,
>>
>> Can you provide pointers to further information on this topic?
>>
>> Cheers,
>>
>> Michael
>>
>>
>> --
>> Michael Kerrisk
>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
>> Linux/UNIX System Programming Training: http://man7.org/training/
>>
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2015-07-26 20:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-22 14:38 For review: nptl(7) man page Michael Kerrisk (man-pages)
     [not found] ` <550ED3F4.1080403-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-03-22 15:51   ` Bert Wesarg
     [not found]     ` <CAKPyHN2VTcP3eOPA-er+iOs0VCRd4ALzuqPY4HJOVOmDH7Arug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-22 19:02       ` Michael Kerrisk (man-pages)
2015-03-22 19:56 ` Szabolcs Nagy
     [not found]   ` <20150322195632.GM16260-4P1ElwuDYu6sTnJN9+BGXg@public.gmane.org>
2015-07-24  7:56     ` Michael Kerrisk (man-pages)
2015-03-22 21:38 ` Nicholas Miell
     [not found]   ` <550F363B.801-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-07-24  7:57     ` Michael Kerrisk (man-pages)
     [not found]       ` <CAODz2cDq4o85NOzqCDg9cH8eCvqt3Tq5QXKMMJtXbik5h5bL+Q@mail.gmail.com>
     [not found]         ` <CAODz2cDq4o85NOzqCDg9cH8eCvqt3Tq5QXKMMJtXbik5h5bL+Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-07-26 20:24           ` Michael Kerrisk (man-pages) [this message]
2015-07-26 20:27             ` Nicholas Miell
     [not found]               ` <CAODz2cAmqVtkoNSwUA5p0_=pcFAdrS3ovohyjwnXMapgEhc4qg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-07-26 20:29                 ` Michael Kerrisk (man-pages)
     [not found]             ` <55B54215.6070502-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-08-03 15:45               ` Torvald Riegel
2015-08-03 20:08                 ` Rich Felker
2015-08-04 15:06                   ` Roland McGrath
     [not found]                     ` <20150804150648.9E9F42C3B01-j1d2VQoJOwwHfwO+Tb3JRVaTQe2KTcn/@public.gmane.org>
2015-08-04 18:50                       ` Nicholas Miell
     [not found]                         ` <3848244D-C3FE-4FD1-B137-AF7AD6252659-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-08-05  9:36                           ` Torvald Riegel
     [not found]                             ` <1438767393.20974.211.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2015-08-05 18:14                               ` Nicholas Miell
     [not found]                                 ` <BCB9D422-563C-4317-B0CB-B14001FE0EA3-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-08-05 18:23                                   ` Rich Felker
     [not found]                                     ` <20150805182327.GA14639-C3MtFaGISjmo6RMmaWD+6Sb1p8zYI1N1@public.gmane.org>
2015-08-05 18:59                                       ` Michael Kerrisk (man-pages)
     [not found]                                         ` <55C25D2B.4040905-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-08-05 19:46                                           ` Rich Felker
2015-08-06 10:06                                             ` Michael Kerrisk (man-pages)
     [not found]                                               ` <55C3319A.7020408-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-08-06 13:54                                                 ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55B54215.6070502@gmail.com \
    --to=mtk.manpages-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=libc-alpha-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org \
    --cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=nmiell-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).