Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp79447imm; Thu, 7 Jun 2018 14:10:38 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIcpN9hjwFceOFkf8XL837lDdxLnm/H0bCHVr6nKJFKJkLHF01QIpdc3jKGU3nxMxf15x5t X-Received: by 2002:a63:b407:: with SMTP id s7-v6mr2917812pgf.334.1528405838394; Thu, 07 Jun 2018 14:10:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528405838; cv=none; d=google.com; s=arc-20160816; b=bh0/glY1LfpwLB9vhExqcdK4i93SEoHhs8Zklq2cp2EZ/r2LSNuNfle/pYFlig3qpd /rlg+/Em6F8NumskNXtshb7BN7hc8ht3tqmelYyUN2ZXW2/Zr1ZeMoOBejX8dkOVjBZc SfzFWpQ3pO/nlIOq8AKtXgr2won8LjEUe5FqEsHKEQ7zXnht2tx/LhmfzvIJTMite/vg h3YZOF8UMy1LV+RORJydP868ddBtmdQH52fIdDGdc9AMizVtL/APdh4rQXy7l8bUMWwf z9SB/BbKhBY7an04amIPl3M5Fmic9+qNeXz6S5qYKD1JPkVtfOAyZpCE7ZHvyc5VqRIr SVJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=Suran/Ft9yXd/Egb/zAUxeUjmXtqnsF4yo0LP60SGFM=; b=eUpmAOzh/qCOQG8EbwvWhhZuuj4/JS8h9AFI7w2u/z07O90Sp0WR5vVp8gzyElEVjD IPkTbPo14TbETXHhwiAg4vZIRVlcuhmimKWbntTBV9GUo7HbRJxhOgvVsoiBgJVClb8V 7zpj2cA9nIrULmhEPGGwSKbRbOqXPEpWk+s6oCb1FFdFfZSjur9nKgUnOsTqKGRBhYIu 9G1L37ElVc5lDvic3MAR5ovayReVTuteodEynGM6wI8CRa6H5ulg/JBazUm9xnVzYZgt d32unkuEcdJv6du9KQ+ayR0dPByMng7uD+oOsMOVUHzU+5hMQHOOzOM9shdTQL+plhRt 1Qcg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 128-v6si43952956pgb.176.2018.06.07.14.09.54; Thu, 07 Jun 2018 14:10:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751641AbeFGVGE (ORCPT + 99 others); Thu, 7 Jun 2018 17:06:04 -0400 Received: from terminus.zytor.com ([198.137.202.136]:51147 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751045AbeFGVGD (ORCPT ); Thu, 7 Jun 2018 17:06:03 -0400 Received: from carbon-x1.hos.anvin.org (c-24-5-245-234.hsd1.ca.comcast.net [24.5.245.234] (may be forged)) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id w57L5okh2334854 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Jun 2018 14:05:51 -0700 Subject: Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86? To: "Leizhen (ThunderTown)" , Thomas Gleixner , Ingo Molnar , x86l , Dominik Brodowski , Andy Lutomirski , linux-kernel Cc: yaomin2@huawei.com References: <5B1672FE.4050705@huawei.com> <5B1792C9.8010203@huawei.com> <5B17A6B6.70300@huawei.com> <5B188E2B.7040700@huawei.com> From: "H. Peter Anvin" Message-ID: <64b61360-803d-b987-6721-e9eb0ebe63a7@zytor.com> Date: Thu, 7 Jun 2018 14:05:45 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <5B188E2B.7040700@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/06/18 18:45, Leizhen (ThunderTown) wrote: >> >> The use of signals without SA_RESTORER is considered obsolete, but it's somewhat surprising that the vdso isn't there; it should be mapped even for static binaries esp. on i386 since it is the preferred way to do system calls (you don't need to parse the ELF for that.) Are you explicitly disabling the VDSO? If so, Don't Do That. > > Yes, the vdso was explicitly disabled by the tester. Thanks. > Are there any use cases that calls for this? Maybe we should drop this option. -hpa