From: Torvald Riegel <triegel@redhat.com>
To: David Miller <davem@davemloft.net>
Cc: adhemerval.zanella@linaro.org, andreas@gaisler.com,
libc-alpha@sourceware.org
Subject: Re: Remove sparcv8 support
Date: Mon, 24 Oct 2016 17:14:00 -0000 [thread overview]
Message-ID: <1477329229.7146.84.camel@localhost.localdomain> (raw)
In-Reply-To: <20161021.110249.687908473092175894.davem@davemloft.net>
On Fri, 2016-10-21 at 11:02 -0400, David Miller wrote:
> From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
> Date: Fri, 21 Oct 2016 11:13:09 -0200
>
> > This is because new algorithm uses atomic_compare_exchange_weak_release and
> > for pre-v9 sparc32 it will have to use a lock embedded into the barrier
> > (as for previous implementation). Ideally we would like to do in a way that
> > can be embedded into the generic code so that you don't have to maintain
> > sparc-specific files.
>
> I would not put that into a generic implementation, such a scheme
> deadlocks in the presence of signals.
>
> And yes the existing sparc v7 locking deadlocks this way as well and
> has done so since day one, many of the threaded test cases in glibc
> timeout and fail for this very reason.
>
> The only long term solution is to do what ARM and others have done
> which is provide an atomic primitive in the Linux kernel which
> executes via a system call or similar which will eliminate the signal
> based deadlocks.
I think this is reasonable. Should we stop supporting pre-v9 sparc32
until such a kernel-side solution is in place (and we can test whether
it is present)?
If the specific arch one is building for has CAS, we could also continue
to support it with that as a prerequisite.
next prev parent reply other threads:[~2016-10-24 17:14 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-20 19:47 Adhemerval Zanella
2016-10-20 20:56 ` David Miller
2016-10-21 9:02 ` Andreas Larsson
2016-10-21 13:13 ` Adhemerval Zanella
2016-10-21 15:03 ` David Miller
2016-10-24 17:14 ` Torvald Riegel [this message]
2016-10-24 17:25 ` Torvald Riegel
2016-10-24 17:43 ` Adhemerval Zanella
2016-10-25 14:34 ` Andreas Larsson
2016-10-25 14:45 ` Adhemerval Zanella
2016-10-26 14:46 ` Andreas Larsson
2016-10-26 18:03 ` Adhemerval Zanella
2016-10-26 18:47 ` David Miller
2016-10-26 19:39 ` Adhemerval Zanella
2016-10-27 10:54 ` Torvald Riegel
2016-10-27 14:36 ` Carlos O'Donell
2016-11-07 16:38 ` David Miller
2016-11-07 21:21 ` Sam Ravnborg
2016-11-08 1:06 ` David Miller
2016-11-09 5:49 ` Sam Ravnborg
2016-11-10 23:33 ` David Miller
2016-11-09 17:08 ` Torvald Riegel
2016-11-09 17:16 ` David Miller
2016-11-10 5:05 ` Torvald Riegel
2016-11-10 16:41 ` Chris Metcalf
2016-11-10 17:08 ` Torvald Riegel
2016-11-10 18:22 ` Chris Metcalf
2016-11-10 23:38 ` Torvald Riegel
2016-10-27 10:38 ` Torvald Riegel
2016-11-01 15:27 ` Andreas Larsson
2016-10-25 14:34 ` Andreas Larsson
2016-10-25 16:22 ` Torvald Riegel
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=1477329229.7146.84.camel@localhost.localdomain \
--to=triegel@redhat.com \
--cc=adhemerval.zanella@linaro.org \
--cc=andreas@gaisler.com \
--cc=davem@davemloft.net \
--cc=libc-alpha@sourceware.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 read-only IMAP folder(s) and NNTP newsgroup(s).