From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26780 invoked by alias); 24 Oct 2016 17:14:05 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 26764 invoked by uid 89); 24 Oct 2016 17:14:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=locking, miller, Miller X-HELO: mx1.redhat.com Message-ID: <1477329229.7146.84.camel@localhost.localdomain> Subject: Re: Remove sparcv8 support From: Torvald Riegel To: David Miller Cc: adhemerval.zanella@linaro.org, andreas@gaisler.com, libc-alpha@sourceware.org Date: Mon, 24 Oct 2016 17:14:00 -0000 In-Reply-To: <20161021.110249.687908473092175894.davem@davemloft.net> References: <48cdf008-b66a-d411-a07a-5a38595978b9@linaro.org> <5809D90E.1090005@gaisler.com> <2ebab6ef-3ca4-9ee5-3158-488f368b8a8d@linaro.org> <20161021.110249.687908473092175894.davem@davemloft.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00396.txt.bz2 On Fri, 2016-10-21 at 11:02 -0400, David Miller wrote: > From: Adhemerval Zanella > 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.