Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1255650imm; Wed, 6 Jun 2018 12:58:26 -0700 (PDT) X-Google-Smtp-Source: ADUXVKK0jDQ1w6rnrGgj9k/gvpYC6FoDCf5SI5CHLscvYdTaE/NsBCfReI1OnS1O535GMTGO93HD X-Received: by 2002:a17:902:ba87:: with SMTP id k7-v6mr4631524pls.271.1528315106813; Wed, 06 Jun 2018 12:58:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528315106; cv=none; d=google.com; s=arc-20160816; b=dgU1Dqocl240Rz92LyOjgGAU11dB+BzSuVc2n0u2viCyMuLifVcvGgSrnmCM28++MW 7hpNXRnTo6rRraBcybwEXfb5UVIC0C7mSRSJeO6/IbQu+xwtuB91jC24oE4F9MVLqYfb dVAdcStUolLgGuDIeMIT/SXEqj5Otf9sGd1bt6OatPR3IFgM+kn9M3HS6cpVAfiy9vj7 zKbZayXEOJB1d0fmkT0gGh01IQnavPo8Obs2aEO+rbHEz37f7WpelgEnQhI2d5EkhiWg JJCp3c/4OCUzwypIY17oIVsPUYYqE6vM8Rt5Q1tS9LRi8JC7twjyypUTtYiVsY1uljnn 8Z/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:from:cc:to:subject :content-transfer-encoding:mime-version:references:in-reply-to :user-agent:date:arc-authentication-results; bh=xnZg0DdD8nunG3kywkNMgJLmRGg0yl+KTi4OtYnG7g8=; b=qP9c+WPGbTPUHdUXFxk7yVinFNIICNBBBaAuvs53DnDjyhAxn6ZC3yROd50AryEOD7 EQ1bkRigbmU8Zenvil7krh3z1vrh6gurOPhtgNho7C0/e5CbBnTQTSze7I4PlVxQEjAJ 24hQm+j7s5cWHz9nbDuz+cGOEDbfXpEcOYOI5gEhlKiBtPeOMLqNWSVkdA0HT4iiDVY0 WzjFcrBMYZu5pjpxRPwqlWRS47++CQubs/2VM99tH9fZgvW6/1s7S5ZV20hx28H9w5bG S2oTLoZflOqXQ2d9xqfgEgFNA/xN8sFKPSKl4Pzle5kh0RSpAVl9Si0ODORJYP9BaPpf aapA== 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 w6-v6si8355644pgr.164.2018.06.06.12.58.12; Wed, 06 Jun 2018 12:58:26 -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 S1754052AbeFFRtM convert rfc822-to-8bit (ORCPT + 99 others); Wed, 6 Jun 2018 13:49:12 -0400 Received: from terminus.zytor.com ([198.137.202.136]:54439 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754023AbeFFRtL (ORCPT ); Wed, 6 Jun 2018 13:49:11 -0400 Received: from wld62.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 w56Hmuqb1868640 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 6 Jun 2018 10:48:57 -0700 Date: Wed, 06 Jun 2018 10:48:49 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <5B17A6B6.70300@huawei.com> References: <5B1672FE.4050705@huawei.com> <5B1792C9.8010203@huawei.com> <5B17A6B6.70300@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT 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, Thunder Town From: hpa@zytor.com Message-ID: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On June 6, 2018 2:17:42 AM PDT, "Leizhen (ThunderTown)" wrote: >I found that glibc has already dealt with this case. So this issue must >have been met before, should it be maintained by libc/user? > > if (GLRO(dl_sysinfo_dso) == NULL) > { > kact.sa_flags |= SA_RESTORER; > > kact.sa_restorer = ((act->sa_flags & SA_SIGINFO) > ? &restore_rt : &restore); > } > > >On 2018/6/6 15:52, Leizhen (ThunderTown) wrote: >> >> >> On 2018/6/5 19:24, Leizhen (ThunderTown) wrote: >>> After I executed "echo 0 > /proc/sys/abi/vsyscall32" to disable >vdso, the rt_sigaction01 test case from ltp_2015 failed. >>> The test case source code please refer to the attachment, and the >output as blow: >>> >>> ----------------- >>> ./rt_sigaction01 >>> rt_sigaction01 0 TINFO : signal: 34 >>> rt_sigaction01 1 TPASS : rt_sigaction call succeeded: result = >0 >>> rt_sigaction01 0 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO >>> rt_sigaction01 0 TINFO : Signal Handler Called with signal >number 34 >>> >>> Segmentation fault >>> ------------------ >>> >>> >>> Is this the desired result? In function ia32_setup_rt_frame, I found >below code: >>> >>> if (ksig->ka.sa.sa_flags & SA_RESTORER) >>> restorer = ksig->ka.sa.sa_restorer; >>> else >>> restorer = current->mm->context.vdso + >>> vdso_image_32.sym___kernel_rt_sigreturn; >>> put_user_ex(ptr_to_compat(restorer), &frame->pretcode); >>> >>> Because the vdso is disabled, so current->mm->context.vdso is NULL, >which cause the result of frame->pretcode invalid. >>> >>> I'm not sure whether this is a kernel bug or just an error of test >case itself. Can anyone help me? >>> >> 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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.