All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.