Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp649454ioo; Thu, 26 May 2022 11:18:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxytqJinLePNbFZNb8xDTH+V+pmYz8X/Z+fKDdeV2AqPbRIWgJNwx/yd1IXEoiumhYyjjo/ X-Received: by 2002:a17:902:f647:b0:161:67af:6bf0 with SMTP id m7-20020a170902f64700b0016167af6bf0mr37512219plg.100.1653589115283; Thu, 26 May 2022 11:18:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653589115; cv=none; d=google.com; s=arc-20160816; b=Q7KTLcLfasJlr0AzSiEiMxGMCi5+MLy7i2ndMV5KFa/QydPn8u3bgW8kbDpcGUl5KS OWbsfH+ybeQUZnvgr7aYjW5ELqtt2YjaCHRNLwhXPDsVVX0jAsfe0MbGdXlS+RQ0m84R K+mRNUroTWs+gmzUw7ordveI0ICzG+asG2CO3/xY7W9BJDlZI3MjflaPvDfEPR0jvOUz G7a5uPviLPJvBdKMDOKrexOhP/Fikl21+XCppwS8wDZpw5akB9b7clCbq6Z9566R+8N2 2Q8Ky5cLQOoAUFPgblphK8X7g6n5wOnsCJY9hGnUrWWEgceCEdK5wfdDC7KWy9kKm0hQ 1oTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:to:from:cc:in-reply-to:subject:date:dkim-signature; bh=sZBB3cFJmHUKx647UvH8/q/X0Zv3XJtlmYlf4oGcSPQ=; b=vW0hdfLzKb+OG8ekPhaKvEvwnoFDPAX71Y3lc+skYKzFrsOEg2IUNtZagBZdaJZxVc wl+irIC/fjxMCqEPvF7Zxkq607iI7TlkPGGm/sZUMLkWTknDy++2UeLyNwnPjMAdewnW JH1lZHunR3pam3G3NqECSwUTabs9qezUz/V0zuoHRcqpQ1NQvKomkpZy8FT7mMq0vWA1 kf+4DyTlOf/Cfxo4IpO2uAZlSDwT3nQC3PR/SirmHkOMhth69BsN/KtjpxeOr8/Ypml+ 1E+i0si4tJys7GfIC0N9JBcDm6GDecAE77o80gcdqa3y0PY2f5kzzIdP0C2egM/9wuoI EKNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dabbelt-com.20210112.gappssmtp.com header.s=20210112 header.b=k79hTMkl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mq3-20020a17090b380300b001e068d1f6dcsi3381967pjb.71.2022.05.26.11.18.22; Thu, 26 May 2022 11:18:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@dabbelt-com.20210112.gappssmtp.com header.s=20210112 header.b=k79hTMkl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233169AbiEZAnP (ORCPT + 99 others); Wed, 25 May 2022 20:43:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33074 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344804AbiEZAnM (ORCPT ); Wed, 25 May 2022 20:43:12 -0400 Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DAEFEA76EA for ; Wed, 25 May 2022 17:43:11 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id z25so418750pfr.1 for ; Wed, 25 May 2022 17:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=sZBB3cFJmHUKx647UvH8/q/X0Zv3XJtlmYlf4oGcSPQ=; b=k79hTMklqRVciCR3lGtpKRUXYMofhOcscF0ctAqoTwqO2GaIXsepK3iVYkd5VLpLDE VmGliHiJsqBbCa5Ka5QizTlvASwyKy19TIz8rRKUSiKpFVD4D531/gZpyC4eEPOwnD3z R0+d+uwUZNyfZlRIfZrYlRdc+gRLwk3h4j0b61sXHe9B54wRb81lilUNrv3FHPUhfGGN ewYwOsvjkGZFpC/5j3nNakOHz+raQjG6KChm/YMdaZuqXCIH1c8+HgPIt0sDatnjE1oF Bb+SoHcLYC5aM8ES/8uJHulkcuNU2vPyeZVt+zk/rBGC/5/Zj65hIzgD627evhuRRiaS Jx2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=sZBB3cFJmHUKx647UvH8/q/X0Zv3XJtlmYlf4oGcSPQ=; b=UwQnor4pzdhnxO6lXosr85otuE9aD+A/cPi3q79YgWUU7Aa5sOQuCP0wtk41MJ5Ar3 sK3xjnTiqmSuMcOMzHsiPYG3R094GzGky04aLoyIS4PqQfXwyVeDvlaksD2zHZz4aJAz NGMh3XYUmQ/LeQVRzz85jCMkZYP4pinOED2xB0nQf5mmuS94CKJRHWBOMyUPV33RIncq G/UEUhWd64XwMu90OCcmDynz2V6oij68vZFoG22kqRli4a+oaPUWRkU3A2y9lQmzcNBY aE3Sog5whQgfLfbnuWDL2BuDRM6LmJ/S4GT70sR35gvZGX0BL3OFMrK5IDevkShdpqrC /m3A== X-Gm-Message-State: AOAM531ZZot/NQerc+wb5RpyWTWWWZe42WRtcfEFud8SPeUU3vLBxoPE gYazZquXt/amwOmYrfKZvjA4Lg== X-Received: by 2002:a05:6a00:194f:b0:518:81fe:fcc6 with SMTP id s15-20020a056a00194f00b0051881fefcc6mr24241050pfk.64.1653525791230; Wed, 25 May 2022 17:43:11 -0700 (PDT) Received: from localhost ([12.3.194.138]) by smtp.gmail.com with ESMTPSA id k13-20020a170902ce0d00b001635b86a790sm27389plg.44.2022.05.25.17.43.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 May 2022 17:43:10 -0700 (PDT) Date: Wed, 25 May 2022 17:43:10 -0700 (PDT) X-Google-Original-Date: Wed, 25 May 2022 17:42:57 PDT (-0700) Subject: Re: [PATCH] riscv: compat: Using seperated vdso_maps for compat_vdso_info In-Reply-To: CC: linux@roeck-us.net, Arnd Bergmann , heiko@sntech.de, linux-riscv@lists.infradead.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, guoren@linux.alibaba.com From: Palmer Dabbelt To: guoren@kernel.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 25 May 2022 17:39:39 PDT (-0700), Palmer Dabbelt wrote: > On Wed, 25 May 2022 15:56:07 PDT (-0700), linux@roeck-us.net wrote: >> On 5/25/22 14:34, Palmer Dabbelt wrote: >>> On Wed, 25 May 2022 14:15:03 PDT (-0700), linux@roeck-us.net wrote: >>>> On 5/25/22 09:04, guoren@kernel.org wrote: >>>>> From: Guo Ren >>>>> >>>>> This is a fixup for vdso implementation which caused musl to >>>>> fail. >>>>> >>>>> [   11.600082] Run /sbin/init as init process >>>>> [   11.628561] init[1]: unhandled signal 11 code 0x1 at >>>>> 0x0000000000000000 in libc.so[ffffff8ad39000+a4000] >>>>> [   11.629398] CPU: 0 PID: 1 Comm: init Not tainted >>>>> 5.18.0-rc7-next-20220520 #1 >>>>> [   11.629462] Hardware name: riscv-virtio,qemu (DT) >>>>> [   11.629546] epc : 00ffffff8ada1100 ra : 00ffffff8ada13c8 sp : >>>>> 00ffffffc58199f0 >>>>> [   11.629586]  gp : 00ffffff8ad39000 tp : 00ffffff8ade0998 t0 : >>>>> ffffffffffffffff >>>>> [   11.629598]  t1 : 00ffffffc5819fd0 t2 : 0000000000000000 s0 : >>>>> 00ffffff8ade0cc0 >>>>> [   11.629610]  s1 : 00ffffff8ade0cc0 a0 : 0000000000000000 a1 : >>>>> 00ffffffc5819a00 >>>>> [   11.629622]  a2 : 0000000000000001 a3 : 000000000000001e a4 : >>>>> 00ffffffc5819b00 >>>>> [   11.629634]  a5 : 00ffffffc5819b00 a6 : 0000000000000000 a7 : >>>>> 0000000000000000 >>>>> [   11.629645]  s2 : 00ffffff8ade0ac8 s3 : 00ffffff8ade0ec8 s4 : >>>>> 00ffffff8ade0728 >>>>> [   11.629656]  s5 : 00ffffff8ade0a90 s6 : 0000000000000000 s7 : >>>>> 00ffffffc5819e40 >>>>> [   11.629667]  s8 : 00ffffff8ade0ca0 s9 : 00ffffff8addba50 s10: >>>>> 0000000000000000 >>>>> [   11.629678]  s11: 0000000000000000 t3 : 0000000000000002 t4 : >>>>> 0000000000000001 >>>>> [   11.629688]  t5 : 0000000000020000 t6 : ffffffffffffffff >>>>> [   11.629699] status: 0000000000004020 badaddr: 0000000000000000 >>>>> cause: 000000000000000d >>>>> >>>>> The last __vdso_init(&compat_vdso_info) replaces the data in normal >>>>> vdso_info. This is an obvious bug. >>>>> >>>>> Reported-by: Guenter Roeck >>>>> Signed-off-by: Guo Ren >>>>> Signed-off-by: Guo Ren >>>>> Cc: Palmer Dabbelt >>>>> Cc: Heiko Stübner >>>> >>>> Tested-by: Guenter Roeck >>> >>> Sorry I'm a bit buried right now, this is fixing the issue you pointed out earlier? >>> >> Yes. > > Awosome, I think that was the only big blocker so far. > > I added a musl-based userspace to my test setup, which is rv64-only > (buildroot doesn't have rv32 musl, I thought upstream had it but maybe > i'm misremembering). This patch fixes the bug, so I've added it to > for-next with Just saw the v2, so I'm using that instead. > > Fixes: 3092eb456375 ("riscv: compat: vdso: Add setup additional pages implementation") > > which I think is correct, but LMK if there's an issue. > > Thanks! > > (and also sorry I poked Geert instead of you about this one, oops ;)) > >> >> Thanks, >> Guenter >> >>>> >>>>> --- >>>>>   arch/riscv/kernel/vdso.c | 15 +++++++++++++-- >>>>>   1 file changed, 13 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/arch/riscv/kernel/vdso.c b/arch/riscv/kernel/vdso.c >>>>> index 50fe4c877603..69b05b6c181b 100644 >>>>> --- a/arch/riscv/kernel/vdso.c >>>>> +++ b/arch/riscv/kernel/vdso.c >>>>> @@ -206,12 +206,23 @@ static struct __vdso_info vdso_info __ro_after_init = { >>>>>   }; >>>>> >>>>>   #ifdef CONFIG_COMPAT >>>>> +static struct vm_special_mapping rv_compat_vdso_maps[] __ro_after_init = { >>>>> +    [RV_VDSO_MAP_VVAR] = { >>>>> +        .name   = "[vvar]", >>>>> +        .fault = vvar_fault, >>>>> +    }, >>>>> +    [RV_VDSO_MAP_VDSO] = { >>>>> +        .name   = "[vdso]", >>>>> +        .mremap = vdso_mremap, >>>>> +    }, >>>>> +}; >>>>> + >>>>>   static struct __vdso_info compat_vdso_info __ro_after_init = { >>>>>       .name = "compat_vdso", >>>>>       .vdso_code_start = compat_vdso_start, >>>>>       .vdso_code_end = compat_vdso_end, >>>>> -    .dm = &rv_vdso_maps[RV_VDSO_MAP_VVAR], >>>>> -    .cm = &rv_vdso_maps[RV_VDSO_MAP_VDSO], >>>>> +    .dm = &rv_compat_vdso_maps[RV_VDSO_MAP_VVAR], >>>>> +    .cm = &rv_compat_vdso_maps[RV_VDSO_MAP_VDSO], >>>>>   }; >>>>>   #endif >>>>>