[PATCH 2/4] S390: Use own tbegin macro instead of __builtin_tbegin.

Stefan Liebler stli@linux.vnet.ibm.com
Tue Jan 17 15:28:00 GMT 2017


On 01/10/2017 05:34 PM, Torvald Riegel wrote:
  > I'm not sure that this is always a good thing to do.  It is nicer for
  > programmers if they can get an instruction pointer that points to where
  > the faulty access happened.  However:
  >
  > (1) This can mask failures present in an application, because the
  > fallback path is not guaranteed to operate on the same data.  It may
  > never run into this problem.  Can inconsistencies arise due to that?
  > For example, is a masked segfault still visible through performance
  > counters or something like that?
No. If an interruption is filtered, those informations are not stored.
  >
  > (2) This introduces a facility to probe memory for being accessible or
  > not, considering that you say it masks segfaults.  It seems that this
  > probing may not be visible to the same extent as possible if a signal
  > handler were installed.  Is this relevant from a security perspective?
  > It may not be given that perhaps the user can do that anyway through
  > direct usage of transactions, or perhaps because the user would have to
  > be able to check whether the program is currently executing in a
  > transaction or not.
  > It might be good to at least mention this in a comment in the code.
I've documented it in the comment.

> On Tue, 2016-12-06 at 14:51 +0100, Stefan Liebler wrote:
>> +/* These builtins are correct.  Use them.  */
>
> Is "correct" the right word here?  I suppose they are always correct,
> it's just that you want something different for glibc internally.
>
I'll correct it.

I've attached the diff here and will later make one patch with changelog 
for this and the other two patches.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20170117_htm_2.patch
Type: text/x-patch
Size: 1169 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20170117/21d67f5b/attachment.bin>


More information about the Libc-alpha mailing list