From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1506FC433F5 for ; Tue, 25 Jan 2022 20:18:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230016AbiAYUR7 (ORCPT ); Tue, 25 Jan 2022 15:17:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229540AbiAYUR4 (ORCPT ); Tue, 25 Jan 2022 15:17:56 -0500 Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E13C1C06173B for ; Tue, 25 Jan 2022 12:17:55 -0800 (PST) Received: by mail-yb1-xb30.google.com with SMTP id 23so65019092ybf.7 for ; Tue, 25 Jan 2022 12:17:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atishpatra.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xH4919BBQDatXV47ZV39NtXvgYYtXrd/TsEbvbZr80k=; b=MfklnOCQVmnZ1DGtZ/7lH8SHjstb5OvkICRH3LZOqLvcVDHKV0C4/qab9nARYCxi07 SkqgzSsp4w8mfq9ydwKA+Pq4fo943Kkwmo7LEUszNU5r+EGEZe9b7JQskqSHPiwQ9xjS 6+3mmdc2jub7xRbVt6HrtXDQmbjJj3kJkwuzk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xH4919BBQDatXV47ZV39NtXvgYYtXrd/TsEbvbZr80k=; b=eu/6sU0PdtYyisPZJHT8naq1UkEG9zgAxhRvE8V+p2KTVoD50tvnDlVKzuil6m3Ko3 U/haIBDweNlU4gyyjFk0v/Gq997ZKYPczhBwwHSyCQE6xB4XFcV+BxUpZds0B3IH+e51 XpiXXMXBW/c1P1jV8aDyJJQUCvSjseauvoAIoNFifPx50xiL4wJMqERQ7T5Z6u9W95aT le4FlkIlNSkzRFnY23Wmz5OCyFq3jEChxAeaNqravMWPprhG7Oqx0QOedcZGzYOe2wDv VovqpvxvMKfB2E7tRACa/wiEtK3Mydbc+EhLGRXCpTRm7I+JjdVIMYD0K0jqOBbXSwdV yT2Q== X-Gm-Message-State: AOAM532+XskJdXaMJSWKBW0aiABBeDiR9bwo7mGbWyQ3iPKC/zFshyxJ cUWS+O+kQvN12bEtBZvJUaPVx1lqCiszbZeuWSnX X-Google-Smtp-Source: ABdhPJz4ErEQdG2kZzS4RU3R+TozqNSpTkyZlNySmm+OUFhQWBU6G++H14erGITpDeyTZi30ICVtSwClulYTDTDEhuI= X-Received: by 2002:a25:ac9a:: with SMTP id x26mr4798915ybi.713.1643141875109; Tue, 25 Jan 2022 12:17:55 -0800 (PST) MIME-Version: 1.0 References: <20220120090918.2646626-1-atishp@rivosinc.com> <20220120090918.2646626-7-atishp@rivosinc.com> In-Reply-To: From: Atish Patra Date: Tue, 25 Jan 2022 12:17:44 -0800 Message-ID: Subject: Re: [PATCH v3 6/6] RISC-V: Do not use cpumask data structure for hartid bitmap To: Geert Uytterhoeven Cc: Atish Patra , Linux Kernel Mailing List , Anup Patel , Albert Ou , Damien Le Moal , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Jisheng Zhang , Krzysztof Kozlowski , linux-riscv , Palmer Dabbelt , Paul Walmsley , Rob Herring , Emil Renner Berthing Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, Jan 25, 2022 at 12:12 PM Geert Uytterhoeven wrote: > > Hi Atish, > > On Thu, Jan 20, 2022 at 10:12 AM Atish Patra wrote: > > Currently, SBI APIs accept a hartmask that is generated from struct > > cpumask. Cpumask data structure can hold upto NR_CPUs value. Thus, it > > is not the correct data structure for hartids as it can be higher > > than NR_CPUs for platforms with sparse or discontguous hartids. > > > > Remove all association between hartid mask and struct cpumask. > > > > Reviewed-by: Anup Patel (For Linux RISC-V changes) > > Acked-by: Anup Patel (For KVM RISC-V changes) > > Signed-off-by: Atish Patra > > Thanks for your patch, which is now commit 26fb751ca37846c9 ("RISC-V: > Do not use cpumask data structure for hartid bitmap") in v5.17-rc1. > > I am having an issue with random userspace SEGVs on Starlight Beta > (which needs out-of-tree patches). It doesn't always manifest > itself immediately, so it took a while to bisect, but I suspect the > above commit to be the culprit. > I have never seen one before during my testing. How frequently do you see them? Does it happen while running anything or just idle user space results in SEGVs randomly. Do you have a trace that I can look into ? > So far the Icicle looks unaffected. > > Do you have a clue? > Thanks! > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds -- Regards, Atish