Received: by 10.223.164.202 with SMTP id h10csp2783340wrb; Sun, 12 Nov 2017 18:36:36 -0800 (PST) X-Google-Smtp-Source: AGs4zMbl5nijtqAyWmiv1UkDCb5Oeq2X7zGJapZk+m1nZGL0H7bf/ePtXFmiaIx+YfeDnxMxrBhm X-Received: by 10.159.207.149 with SMTP id z21mr1078946plo.262.1510540596010; Sun, 12 Nov 2017 18:36:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510540595; cv=none; d=google.com; s=arc-20160816; b=R6hhertzRvyh1HABMHKYVpt3DSnbyH28oxK22B7an+Yb3R7fp/E9M1fPTPKXXigYGX Y0TZBzZUcIiBMDe1wldHT+KxmURMyaeszSZcsOXcBAasix5HJHgF3lAS3DxZ4C24L3D6 7GSXfWMbZgMnSqHkv4W5+spk/lI2icgH9t666dFPYPV0d77XCDoZ7sQsWnA6xtUu8u2d Nw/BJxPyEJt97WLx+PoZDhOKEEX/blwV4xbVjWLoXe68bHuwyFTuN7021u0srCBA2YAH r58gD62V7UjUUeHX4Wzf/CWBLsNmGFeAg/3xt1idx/UiDtpkb6p6LIBWfutvTlqlygbp lVmA== 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:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=T1hc0hCm3wRg3rdQgauL94wjRNV6s+N7JvBpsWaHKSY=; b=rK8pVaRz/3KJa77VHrFu1YFrXTpETyzfpYJtTLal5ilWkL/IuiWRVK1tn7qGiTmPMM DzGu2dfgzxNJFnEMIsoHRVvWmI/fJCL/cZL0x1tZI/ZRY2Gq75SViK1Ak5Dp/trhjr+/ 2BzsKP9dvjm+7lZMD0rYbfkq+yWwEEkMhF4O/YTltJRoTZrNoL41gdzU/AQE44IACyqQ oQKytCGaNSUFio++yA2sBwkhZDbQIjkT0K0DCqdTby5oEMwfSTT3q/aku1PkOkwPwQ3z N2oc9guDbhUnxPE4KeK4JbEzmdMQnrE0Vo3/oia3DfiUBKrQ3sQDELuY13J1WxDme9Rz qfWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=WgM3lZro; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u9si2739544plr.580.2017.11.12.18.36.15; Sun, 12 Nov 2017 18:36:35 -0800 (PST) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=WgM3lZro; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751407AbdKMCeK (ORCPT + 87 others); Sun, 12 Nov 2017 21:34:10 -0500 Received: from mail-io0-f195.google.com ([209.85.223.195]:43907 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751107AbdKMCeI (ORCPT ); Sun, 12 Nov 2017 21:34:08 -0500 Received: by mail-io0-f195.google.com with SMTP id 134so19052701ioo.0; Sun, 12 Nov 2017 18:34:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=T1hc0hCm3wRg3rdQgauL94wjRNV6s+N7JvBpsWaHKSY=; b=WgM3lZroiXoTKy7+zsEqzf8vX+4IxjKT1aorBwX3bLWRe98lg90Vh11l6QhUw0+L7K Ga589LLjiYOQhn0nPGdaBPVLEsbXuXZcyIkyk2cthsx45uYDlev7EUTzfzh2H/MHJrQU sywolCKOZM12jh+90VT6IubUroY/AFpfUq5L3eeT11ylWeM6aoxzQHl/0I5IGVzbcURE uRlUg4d28nj80Rti+JMF5SblH/WyAIqAEuy7fwihJsGZKWuMz2HJUoou+7CBnNyHTr3L uEXIG7J1hdzNLTMeznYDY3sl2ZZDCPuqnpqG6zMHPGrWMzDHT+e0dgbzH4xA72hG502S mTDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=T1hc0hCm3wRg3rdQgauL94wjRNV6s+N7JvBpsWaHKSY=; b=IPgZVe0UYM8nLhLCXtri8HdwxbPuopm6aHCK3PaivNV+KQelLMNS8RMpMTM0vkPBSe TcbMSXRiw9p8FNUugKr6xmbru/QgJN5hcPKoW/CqWvYp0XVwv01nh302uFvrfe35GqpP NS+ya3ryUjMwH2QJI2J9JupcI1mJ7jQGFfdVzO5w4OolUIFtL7qrhdizjTTqW4xKNqh9 BXHtXsNNsTxiB2M461CkYWNMEz1nAGOfp0636EpBxkgGLnRUOdEn8SIzR4Lm80JcAXl7 YvZoA8nr/Nncs4RXniIOdytFjOaCvhOgUxT4LdLPoQnvpXiIvLsDUWjxP48mCRfXr3rA nsSQ== X-Gm-Message-State: AJaThX7aXmQP+/XnQ1K2L01KR39egwiwOaG8OzakAeNc7FhDk2mxbTbR g1QkCrH7TMDtzhMbZT1mAtcvWyU6n+/HbtmmkiY= X-Received: by 10.107.68.8 with SMTP id r8mr8613674ioa.192.1510540447136; Sun, 12 Nov 2017 18:34:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.62.213 with HTTP; Sun, 12 Nov 2017 18:34:06 -0800 (PST) In-Reply-To: References: <82ac0fc50f8fcdaf423b6ef1a66ee4d1d88d366b.1510118606.git.green.hu@gmail.com> <20171109012620.GY21978@ZenIV.linux.org.uk> From: Vincent Chen Date: Mon, 13 Nov 2017 10:34:06 +0800 Message-ID: Subject: Fwd: FW: [PATCH 17/31] nds32: Signal handling support To: viro@ftp.linux.org.uk Cc: greentime@andestech.com, linux-kernel@vger.kernel.org, arnd@arndb.de, linux-arch@vger.kernel.org, tglx@linutronix.de, jason@lakedaemon.net, marc.zyngier@arm.com, robh+dt@kernel.org, netdev@vger.kernel.org, vincentc@andestech.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> +static int restore_sigframe(struct pt_regs *regs, >> + struct rt_sigframe __user * sf) { > >[snip] > >> + err |=3D !valid_user_regs(regs); > >IDGI... Where do you modify ->ipsw at all and how can valid_user_regs() c= ome to be false here? > Thanks. This code is trivial and I will remove it in the next version patch >> +asmlinkage int sys_rt_sigreturn(struct pt_regs *regs) { >> + struct rt_sigframe __user *frame; >> + >> + /* Always make any pending restarted system calls return -EINTR */ >> + current->restart_block.fn =3D do_no_restart_syscall; >> + >> + /* >> + * Since we stacked the signal on a 64-bit boundary, >> + * then 'sp' should be two-word aligned here. If it's >> + * not, then the user is trying to mess with us. >> + */ >> + if (regs->sp & 7) >> + goto badframe; >> + >> + frame =3D (struct rt_sigframe __user *)regs->sp; >> + >> + if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) >> + goto badframe; >> + >> + if (restore_sigframe(regs, frame)) >> + goto badframe; >> + >> + if (restore_altstack(&frame->uc.uc_stack)) >> + goto badframe; >> + >> + return regs->uregs[0]; >> + >> +badframe: >> + force_sig(SIGSEGV, current); >> + return 0; >> +}\ > >AFAICS, you are copying arm; take a good look at sys_rt_sigreturn_wrapper = there - specifically, the 'mov why, #0' part. Consider what happens if you= get an interrupt at the moment when $r0 contains -ERESTARTSYS (for example) and signal arrives while we are processing the interrupt. It will be handled on the way out, without any syscall restart crap ('why' is 0 on that codepath). So far, so good, but think what'll happen when you are done with the signal handler. sigreturn() is called, the values we had stashed in sigcontext go back into registers (OK, pt_regs on kernel stack that will be used to reload the registers on return to userland)... and the signals that had been blocked for the duration of handlers (see sa_mask in sigaction(2)) get unblocked. And it turns out that you have one of those pending - it had arrived while we'd been in the handler. >Now we are fucked. You have TIF_SIGPENDING set, so do_notify_resume() is = called. And everything looks exactly as if you had a syscall restart situa= tion - regs->uregs[0] being one of -ERESTART... and 'syscall' flag being tr= ue. So we go into the second signal handler (as we ought to) with saved ->= ipc set 4 bytes back from where we were going to return. >It would've been the right thing to do if it *was* a syscall restart, but = we were returning to the location where the original interrupt had caught u= s. > >Result: with the right timing, an interrupt arriving when userland process= has $r0 equal -512 may lead to instruction pointer jumping 4 bytes back. >Pity the poor sod trying to debug that kind of breakage... > >Restart should *NOT* be triggered upon sigreturn(2). Thanks for your detailed description. I got it and I will fix this bug in the next version patch >> >> +static int >> +setup_return(struct pt_regs *regs, struct ksignal *ksig, void __user >> +* frame) { >> + unsigned long handler =3D (unsigned long)ksig->ka.sa.sa_handler; >> + unsigned long retcode; >> + >> + /* >> + * Maybe we need to deliver a 32-bit signal to a 26-bit task. >> >Deliver to what, again? That comment made sense (if rather sad one) on ar= m, but what is it doing here? > Thanks. I will remove it in the next version patch >> +static int do_signal(struct pt_regs *regs, int syscall) { >> + unsigned int retval =3D 0, continue_addr =3D 0, restart_addr =3D 0= ; >> + struct ksignal ksig; >> + int restart =3D 0; >> + >> + /* >> + * We want the common case to go fast, which >> + * is why we may in certain cases get here from >> + * kernel mode. Just return without doing anything >> + * if so. >> + */ >> + if (!user_mode(regs)) >> + return 0; > >Which cases would those be? Thanks. This code is trivial too. I will remove it in the next version patch From 1583549866109669764@xxx Thu Nov 09 01:27:16 +0000 2017 X-GM-THRID: 1583483404051892490 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread