From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Carlos O'Donell Newsgroups: gmane.comp.lib.glibc.alpha Subject: Re: [PATCH 0/2] nptl: Update struct pthread_unwind_buf Date: Fri, 23 Feb 2018 22:41:24 -0800 Message-ID: References: <20180201205757.51911-1-hjl.tools@gmail.com> <4abf9786-1879-f16c-5a01-3261cd718d63@redhat.com> <87inb7pug7.fsf@mid.deneb.enyo.de> <2a02aac9-6aa3-4dc6-b122-039ae85365e8@redhat.com> <87d11emoap.fsf@mid.deneb.enyo.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1519454375 5644 195.159.176.226 (24 Feb 2018 06:39:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 24 Feb 2018 06:39:35 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: "H.J. Lu" , libc-alpha@sourceware.org To: Florian Weimer Original-X-From: libc-alpha-return-90551-glibc-alpha=m.gmane.org@sourceware.org Sat Feb 24 07:39:31 2018 Return-path: Envelope-to: glibc-alpha@blaine.gmane.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=ULfd6sGUQEdJf1Kx mdsKBXRn3G77DPY6rYj1tptE0Ot1dQvuNxTaHnmWHs2b4JSiYymPaOPKqVTyukxC h8ssJ4tDBl4U/ywgckzCxO6x1x9TgYDg5cXC1RxV4mqDzclzZ3Vr0sSLbb+jQggg hiK2TSlgcWzKPLCpqp5k7dJ2u58= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=eMoVTyibjT2NJeon0hFnad +bDHM=; b=g8qINA1VZGyEH02xqagh2tjm+fIs3GwK2STt1Le6yXWaGn1S2UDjB8 s5rJREHgOCUeP1rUiw3aiyUVbYqjBNpMlzrQnqFHvm7VT8OIxovxFS569tHIPOmN fpcBwSvGW8EHBHzZ5P8o3QZFYIW56Vj65RlWq777tAiZfTXorTMRM= Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy= X-HELO: mail-qt0-f176.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=hv5M4BVBqL5Z40RAT8Wecre/jWAByaIjW9ORg29yyh8=; b=YXoAeD7WgKqVSg2xuKKlfpSB8CvuvgOzTAq5hAWM5Audc1GGyfqRpq8Y+HG/P/X9pW N5Ic+eBrQMqfD1DYGK6dl32EnujpNLtVHdQNJPC/m1UCFBC5QAen6u/JR7VhEXaQgb6D LvXlKxdJJrVFhVxB1dSd4DJJbrEqDgQvflVZTUuhXrWO08PmuOfWLAefKaKV4isCrj+A O+zEemZJ/C0UKtEiZ00yCW7U7eSe6ejEANJubAwXl+svkbAnCDoQsp7CGyV2Y2k0aTWf G78K8es/rLwqfFO5GNJwuV/keBZq1m+lHuygSyGeFCGpFKyE9H3tP/8QKgjmghS9P2be 5jLw== X-Gm-Message-State: APf1xPBnLxyuEIVMsUhZ5wJ4UIqrybDEf8QO2i3P8Og7Bpbr86EpyO1N DBwJPnkNbIXghQYKpSqGmU4131asCD0= X-Google-Smtp-Source: AG47ELt8gWBYDdvRs7V8GEoWuVpJ+pmvnhWfADh0zWj0Me7IEagJyFlegyZhsg0wA9ZHx9IgDMRb3g== X-Received: by 10.237.59.146 with SMTP id r18mr6717766qte.231.1519454487626; Fri, 23 Feb 2018 22:41:27 -0800 (PST) In-Reply-To: <87d11emoap.fsf@mid.deneb.enyo.de> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:82883 Archived-At: Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1epTUW-0000mR-Lo for glibc-alpha@blaine.gmane.org; Sat, 24 Feb 2018 07:39:29 +0100 Received: (qmail 34978 invoked by alias); 24 Feb 2018 06:41:31 -0000 Received: (qmail 34967 invoked by uid 89); 24 Feb 2018 06:41:30 -0000 On 02/09/2018 02:48 AM, Florian Weimer wrote: > In short, the only thing need to ensure is that the over-write from > __sigsetjmp stays within __cancel_buf. Then we are good, without > changing the stack layout for cancellation. > > My proposal is still rather hackish, but so is the existing code (the > truncated jump buffer), and HJ's approach of storing the shadow stack > pointer in the signal save area of the non-truncated jump buffer. But > I think we can make it work. I disagree completely. I think this is an an elegant solution to an ugly problem. We need to see if HJ has any other requirements which may conflict with this suggestion. -- Cheers, Carlos.