All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>,
	libc-alpha <libc-alpha@sourceware.org>,
	Carlos O'Donell <carlos@redhat.com>,
	Rich Felker <dalias@libc.org>,
	linux-api <linux-api@vger.kernel.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Will Deacon <will.deacon@arm.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ben Maurer <bmaurer@fb.com>, Dave Watson <davejwatson@fb.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Paul <paulmck@linux.vnet.ibm.com>, Paul Turner <pjt@google.com>,
	Joseph Myers <joseph@codesourcery.com>,
	Szabolcs Nagy <szabolcs.nagy@arm.com>
Subject: Re: [PATCH glibc 5/9] glibc: Perform rseq(2) registration at C startup and thread creation (v17)
Date: Mon, 27 Apr 2020 16:27:37 -0400 (EDT)	[thread overview]
Message-ID: <122741024.71528.1588019257574.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <2102127737.70791.1588008377292.JavaMail.zimbra@efficios.com>

----- On Apr 27, 2020, at 1:26 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:
[...]
>>> We don't mind that user-space uses that pointer, but we never want the kernel
>>> to touch that pointer rather than the 32/64-bit-aware fields. One possibility
>>> would be to do:
>>>
>>>     union
>>>       {
>>>         uint64_t ptr64;
>>> #ifdef __LP64__
>>>         uint64_t ptr;
>>> #else
>>>         struct
>>>           {
>>> #if (defined (__BYTE_ORDER) && (__BYTE_ORDER == __BIG_ENDIAN)) || defined
>>> (__BIG_ENDIAN)
>>>             uint32_t padding; /* Initialized to zero.  */
>>>             uint32_t ptr32;
>>> #else /* LITTLE */
>>>             uint32_t ptr32;
>>>             uint32_t padding; /* Initialized to zero.  */
>>> #endif /* ENDIAN */
>>>           } ptr;
>>> #endif
>>>
>>> #ifndef __KERNEL__
>>>      const struct rseq_cs *uptr;
>>> #endif
>>>       } rseq_cs;
>>>
>>> in the union, so only user-space can see that field. Thoughts ?
>> 
>> I think this depends on where the x32 question lands.
> 
> x32 should not be an issue as explained above, so I'm very open to
> add this "uptr" for user-space only.

Actually, the snippet above is broken on 32-bit. It needs to be:

    union
      {
        uint64_t ptr64;
#ifdef __LP64__
        uint64_t ptr;
# ifndef __KERNEL__
        const struct rseq_cs *uptr;
# endif
#else   
        struct
          {
#if (defined (__BYTE_ORDER) && (__BYTE_ORDER == __BIG_ENDIAN)) || defined (__BIG_ENDIAN)
            uint32_t padding; /* Initialized to zero.  */
            uint32_t ptr32;
#else /* LITTLE */
            uint32_t ptr32;
            uint32_t padding; /* Initialized to zero.  */
#endif /* ENDIAN */
          } ptr;
# ifndef __KERNEL__
        struct
          {
#  if (defined (__BYTE_ORDER) && (__BYTE_ORDER == __BIG_ENDIAN)) || defined (__BIG_ENDIAN)
            uint32_t padding; /* Initialized to zero.  */
            const struct rseq_cs *uptr32;
#  else /* LITTLE */
            const struct rseq_cs *uptr32;
            uint32_t padding; /* Initialized to zero.  */
#  endif /* ENDIAN */
          } uptr;
# endif
#endif
      } rseq_cs;

I'll leave this out of the patchset for now as we'd need more feedback on its
usefulness.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

  reply	other threads:[~2020-04-27 20:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200326155633.18236-1-mathieu.desnoyers@efficios.com>
2020-03-26 15:56 ` [PATCH glibc 5/9] glibc: Perform rseq(2) registration at C startup and thread creation (v17) Mathieu Desnoyers
2020-04-27  9:11   ` Florian Weimer
2020-04-27 16:40     ` Mathieu Desnoyers
2020-04-27 16:54       ` Florian Weimer
2020-04-27 17:26         ` Mathieu Desnoyers
2020-04-27 20:27           ` Mathieu Desnoyers [this message]
2020-04-28 12:02           ` Florian Weimer
2020-04-28 12:33             ` Mathieu Desnoyers
2020-04-28 12:35               ` Florian Weimer
2020-04-28 12:43                 ` Mathieu Desnoyers
2020-04-28 12:54                   ` Florian Weimer
2020-04-28 14:58                     ` Mathieu Desnoyers
2020-04-29  8:16                       ` Szabolcs Nagy
2020-04-29  8:18                         ` Florian Weimer
2020-04-29  8:52                           ` Szabolcs Nagy
2020-04-28 12:56               ` Mathieu Desnoyers
2020-04-29 12:19                 ` Florian Weimer
2020-04-27 11:59   ` Florian Weimer
2020-04-27 16:47     ` Mathieu Desnoyers
2020-04-27 16:59       ` Florian Weimer
2020-03-26 15:56 ` [PATCH glibc 6/9] glibc: sched_getcpu(): use rseq cpu_id TLS on Linux (v7) Mathieu Desnoyers
2020-04-27  9:13   ` Florian Weimer

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=122741024.71528.1588019257574.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=bmaurer@fb.com \
    --cc=boqun.feng@gmail.com \
    --cc=carlos@redhat.com \
    --cc=dalias@libc.org \
    --cc=davejwatson@fb.com \
    --cc=fw@deneb.enyo.de \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=szabolcs.nagy@arm.com \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.com \
    /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.