Received: by 10.192.165.148 with SMTP id m20csp3113124imm; Mon, 23 Apr 2018 00:19:19 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/sNvHOD0FKcDaYqaLimV0wJMEZl8+avjLNSwI6FwQ42wcJmFJ1n5jppysilybp2xHG10Gp X-Received: by 10.101.85.140 with SMTP id j12mr16513014pgs.262.1524467959900; Mon, 23 Apr 2018 00:19:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524467959; cv=none; d=google.com; s=arc-20160816; b=CwsJWE/hegbGAyBAAp5PXDfiViapgUbv6ALpNMLHFXZgna0eKnkSYZ9aOkOjkflKrX JC5v3B0yIeA0azX3uLTvk2c94dDzL2uVlfhY9n2Kv3tejow+YcopLDhi9YK1KQATKGQl TjBlNrGANMRHieNIlBO9lhy9h4J4/CMFjOUp3HYywRGT60D/1q1xBolpvAfASZcINntm Eh9VEJrripc/Vauw/MkbMQ/bfxyRpsTh43Ai2MRZQAMImBXOqIrFvNSj0GGNtjYjVOhF FbRm7BwLzf3UV0ZKEtOgiKB7BG4MJMYKqFtmjWC7U+PVFHyNxudIZhoVc9UMwjjNYLlg nr+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=OxcB+U7Nu7VUyKy8Jx2ejNTyzsrnM1k4NJeL/yKHQm8=; b=01v2g4W4zc39rqI89kod61r3DP1nNH4cNEPQWZqSQXxHhiL+b6GVHyGj/nP1GLodNP 26sEcE8Si2HuJqsi0QaGAzqZL/ev7ZKZIBaoPYfu95q4XwUMx1tBGOGmHGLmUEjZDeiL pKP9evhrClG1N18r7UZeMxYDaHvF+MpWMxRsh555dF91zk71asqNZfPg63CglfFo7t8O bGqotfGrLscsudaHQ0YHn9Abh9zOdIXfMDMAC/sfTHBLdj17MPW/vzSnyOm2/+vXc00L t5pybHE15+699K5fjxx4jp+v2b9mEP8iXK+gC9UvoRUUoRWxscfu1D2qpt0a5nZF3VbP B1Hw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@hev-cc.20150623.gappssmtp.com header.s=20150623 header.b=ZfQJ3esL; 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 f59-v6si9652460plb.106.2018.04.23.00.19.05; Mon, 23 Apr 2018 00:19:19 -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; dkim=pass header.i=@hev-cc.20150623.gappssmtp.com header.s=20150623 header.b=ZfQJ3esL; 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 S1754142AbeDWHQt (ORCPT + 99 others); Mon, 23 Apr 2018 03:16:49 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:34695 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751038AbeDWHQr (ORCPT ); Mon, 23 Apr 2018 03:16:47 -0400 Received: by mail-lf0-f67.google.com with SMTP id r7-v6so13374412lfr.1 for ; Mon, 23 Apr 2018 00:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hev-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OxcB+U7Nu7VUyKy8Jx2ejNTyzsrnM1k4NJeL/yKHQm8=; b=ZfQJ3esLWrHCuwCibpWoOc4NrXH0CYNa4B9nDtfoAK+9Y6E9QuTt7G6D0nP4CHUKWb hOIOwGt+39oc7MKJr0w826AMXMcaMYoLERFUiZZZjFUD7WP1liN6pcRU8WMess7uPLz/ D2JRnkZ8uV55rur1OCVDo8v+VpUm86zNhp4Nf2w0QZSUgMEALqVwxGFaXQPX3FyVeRa6 E7DM6kDfh7LOERnR47eCWg+wXs9I12IRHdPC0ncF6c8RT0c1Ftmu/RcvdYVx9LIdJnGk IhwFbipkpzjjyiwiAagzzDIvEDRqlXkIVJnG+uJVbif/fIjRXFDXZIDJuiw+/pFZvKFZ M5tA== 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; bh=OxcB+U7Nu7VUyKy8Jx2ejNTyzsrnM1k4NJeL/yKHQm8=; b=fih9Fb4optmY7Jnho/YSr+H2WL5A6si8HrxQndOxwMYvLQCKi0hdhl/8LdMnsmSSDu CvwdahTg3bsmG4X/pw26damaQscxf4Pl9I9WyxFuZfFb2PTpf+sNu3oPN90+pFmoHmTe o7PzXghvRtGvLuIbM4EJBNHuZHY8OIKgqu/F5+AWtapydc8FKWYzhKGmRmo04XZdnSzj vakH4Ssc6mgmJ8k6U9U+TyIv7q6Jy37ysLu5WO4+sohRP7o7dWW8IFp4eK6/n+MmNUTO JCGPP/k7SYzpNt8+bvqD9sEqI+AAgAVI6E1HejTOUZJ9v1HFHuZ2xtD1qh+2g/adcCfv XxyQ== X-Gm-Message-State: ALQs6tA3Ae0c4QrKpoQsfRnwCCf8wJxrdX98ctpMmx86BV0lz/P67u6x WaQMB/uDTeH4nmzlf4Hu969t65yiWV5u6WDct8CvEQ== X-Received: by 2002:a19:7013:: with SMTP id h19-v6mr7766199lfc.73.1524467805999; Mon, 23 Apr 2018 00:16:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:94c2:0:0:0:0:0 with HTTP; Mon, 23 Apr 2018 00:16:45 -0700 (PDT) X-Originating-IP: [172.247.34.138] In-Reply-To: <20180422135317.436671003@linuxfoundation.org> References: <20180422135315.254787616@linuxfoundation.org> <20180422135317.436671003@linuxfoundation.org> From: Heiher Date: Mon, 23 Apr 2018 15:16:45 +0800 Message-ID: Subject: Re: [PATCH 3.18 45/52] MIPS: memset.S: Fix clobber of v1 in last_fixup To: Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, James Hogan , Matt Redfearn , Ralf Baechle , linux-mips@linux-mips.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, IIRC, The v1 is a temporary register, value is not preserved across function calls. I don't see any functions that generated by compiler to restore values of v1 after clobbered it. On Sun, Apr 22, 2018 at 9:54 PM, Greg Kroah-Hartman wrote: > 3.18-stable review patch. If anyone has any objections, please let me know. > > ------------------ > > From: Matt Redfearn > > commit c96eebf07692e53bf4dd5987510d8b550e793598 upstream. > > The label .Llast_fixup\@ is jumped to on page fault within the final > byte set loop of memset (on < MIPSR6 architectures). For some reason, in > this fault handler, the v1 register is randomly set to a2 & STORMASK. > This clobbers v1 for the calling function. This can be observed with the > following test code: > > static int __init __attribute__((optimize("O0"))) test_clear_user(void) > { > register int t asm("v1"); > char *test; > int j, k; > > pr_info("\n\n\nTesting clear_user\n"); > test = vmalloc(PAGE_SIZE); > > for (j = 256; j < 512; j++) { > t = 0xa5a5a5a5; > if ((k = clear_user(test + PAGE_SIZE - 256, j)) != j - 256) { > pr_err("clear_user (%px %d) returned %d\n", test + PAGE_SIZE - 256, j, k); > } > if (t != 0xa5a5a5a5) { > pr_err("v1 was clobbered to 0x%x!\n", t); > } > } > > return 0; > } > late_initcall(test_clear_user); > > Which demonstrates that v1 is indeed clobbered (MIPS64): > > Testing clear_user > v1 was clobbered to 0x1! > v1 was clobbered to 0x2! > v1 was clobbered to 0x3! > v1 was clobbered to 0x4! > v1 was clobbered to 0x5! > v1 was clobbered to 0x6! > v1 was clobbered to 0x7! > > Since the number of bytes that could not be set is already contained in > a2, the andi placing a value in v1 is not necessary and actively > harmful in clobbering v1. > > Reported-by: James Hogan > Signed-off-by: Matt Redfearn > Cc: Ralf Baechle > Cc: linux-mips@linux-mips.org > Cc: stable@vger.kernel.org > Patchwork: https://patchwork.linux-mips.org/patch/19109/ > Signed-off-by: James Hogan > Signed-off-by: Greg Kroah-Hartman > > --- > arch/mips/lib/memset.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- a/arch/mips/lib/memset.S > +++ b/arch/mips/lib/memset.S > @@ -210,7 +210,7 @@ > > .Llast_fixup\@: > jr ra > - andi v1, a2, STORMASK > + nop > > .Lsmall_fixup\@: > PTR_SUBU a2, t1, a0 > > > -- Best regards! Hev https://hev.cc