Bug#850182: Please disable TSX in stretch and backport to jessie
On Thu, 05 Jan 2017, Aurelien Jarno wrote: > On 2017-01-05 09:15, Henrique de Moraes Holschuh wrote: > > Also valid for S/390x, POWER, and anything else where glibc 2.24 > > supports hardware lock elision. > > Do you have some pointers about the different behaviour of locking > primitives on S/390 and POWER? They accept to "unlock" already unlocked I got it from one of the multiple places describing TSX, were it was compared to other implementations. Can't find the source right now, though, so I apologise :-( > mutexes and I haven't seen any bug report about that so far. There have > been a few issues fixed on the glibc and gcc side at the beginning, but > it hasn't been the case for quite some time now. I'd say whatever information source I got it from was likely wrong, then. Which might actually be a good thing... Since we *do* have boxes running S/390x and POWER with hardware lock elision enabled, I propose we could simply test for it if there is any doubt. So, it looks like hardware lock elision should be disabled only for x86/x86-64. -- Henrique Holschuh
Bug#850182: Please disable TSX in stretch and backport to jessie
On 2017-01-05 09:15, Henrique de Moraes Holschuh wrote: > On Wed, Jan 4, 2017, at 17:04, Ian Jackson wrote: > > amd64 with TSX is for the purposes of pthreads like a new > > architecture: the locking primitives behave differently and expose > > extra bugs. > > Also valid for S/390x, POWER, and anything else where glibc 2.24 > supports hardware lock elision. Do you have some pointers about the different behaviour of locking primitives on S/390 and POWER? They accept to "unlock" already unlocked mutexes and I haven't seen any bug report about that so far. There have been a few issues fixed on the glibc and gcc side at the beginning, but it hasn't been the case for quite some time now. Also Note that IBM doesn't apply market segmentation the same way than Intel, so all relatively recent CPUs (less than 5 years for POWER, less than 3 years for S/390) do support transactional memory. Actually we even require a POWER7+ CPU for the ppc64el port, so we are sure to have transactional memory instructions. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#850182: Please disable TSX in stretch and backport to jessie
On 2017-01-04 19:04, Ian Jackson wrote:
> Package: eglibc
>
> Gilles Filippini writes ("Request for help - scilab segfaults with TSX"):
> > I've just noticed this RC bug [1] against scilab. [...]
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844134
> > [2] https://lists.debian.org/debian-devel/2016/11/threads.html#00210
> ...
> > I don't have access to any box with TSX enabled, and failed to find any
> > porterbox as well. [...]
>
> amd64 with TSX is for the purposes of pthreads like a new
> architecture: the locking primitives behave differently and expose
> extra bugs.
>
> These extra bugs will be discovered only by chance (as we see in that
> bug report and in the earlier bugs #843324 and maybe #842796). As
> more TSX-capable hardware becomes available, we will discover more of
> them, during the life of stretch, when they are hard to fix.
>
> Also, we don't have the capability to debug them. I don't think we
> can have a release architecture for stretch that has no porterboxes.
>
> So please would the libc be changed not to make use of these features
> for stretch. The downsides will be somewhat lower performance and
> not detecting some preexisting bugs; but the upsides are not shipping
> undetected bugs, and not throwing useful software out of Debian.
>
> Please would you make a decision quickly.
This has already been fixed for jessie in version 2.19-18+deb8u7
(currently in proposed-updates, will be in the next stable release).
This has also been done for stretch in our git repository, but not yet
uploaded.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Bug#850182: Please disable TSX in stretch and backport to jessie
On Wed, Jan 4, 2017, at 17:04, Ian Jackson wrote: > amd64 with TSX is for the purposes of pthreads like a new > architecture: the locking primitives behave differently and expose > extra bugs. Also valid for S/390x, POWER, and anything else where glibc 2.24 supports hardware lock elision. > These extra bugs will be discovered only by chance (as we see in that > bug report and in the earlier bugs #843324 and maybe #842796). As > more TSX-capable hardware becomes available, we will discover more of > them, during the life of stretch, when they are hard to fix. > > Also, we don't have the capability to debug them. I don't think we > can have a release architecture for stretch that has no porterboxes. All it takes is an extra "if(unlikely(lock-is-unlocked)) raise(SIGSEGV);" line on the libpthread unlock path for no-lock-elision). Or you could generate a warning instead. That said, I am not speaking against disabling hardware lock elision acceleration for Debian Stretch. We might be better off disabling it. -- Henrique de Moraes Holschuh
Bug#850182: Please disable TSX in stretch and backport to jessie
Package: eglibc
Gilles Filippini writes ("Request for help - scilab segfaults with TSX"):
> I've just noticed this RC bug [1] against scilab. [...]
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844134
> [2] https://lists.debian.org/debian-devel/2016/11/threads.html#00210
...
> I don't have access to any box with TSX enabled, and failed to find any
> porterbox as well. [...]
amd64 with TSX is for the purposes of pthreads like a new
architecture: the locking primitives behave differently and expose
extra bugs.
These extra bugs will be discovered only by chance (as we see in that
bug report and in the earlier bugs #843324 and maybe #842796). As
more TSX-capable hardware becomes available, we will discover more of
them, during the life of stretch, when they are hard to fix.
Also, we don't have the capability to debug them. I don't think we
can have a release architecture for stretch that has no porterboxes.
So please would the libc be changed not to make use of these features
for stretch. The downsides will be somewhat lower performance and
not detecting some preexisting bugs; but the upsides are not shipping
undetected bugs, and not throwing useful software out of Debian.
Please would you make a decision quickly.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
