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 X-Spam-Level: X-Spam-Status: No, score=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70F2DC43461 for ; Wed, 21 Apr 2021 08:11:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3B7D761434 for ; Wed, 21 Apr 2021 08:11:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234490AbhDUIMT (ORCPT ); Wed, 21 Apr 2021 04:12:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58204 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234441AbhDUIMS (ORCPT ); Wed, 21 Apr 2021 04:12:18 -0400 Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 24A40C06174A for ; Wed, 21 Apr 2021 01:11:46 -0700 (PDT) Received: by mail-oi1-x229.google.com with SMTP id u80so8063243oia.0 for ; Wed, 21 Apr 2021 01:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=msdAKUkaozlyVVqcOzRUhmh/jucXO4phsOtdu8kld0Q=; b=pmcZpnXrP/hJMVCWPTO21s5w2C6jBAae3cwns8jXbIAlH8wJ0ociggMr54Xu8ecPyu Ts3vAfnbXRjGjjaOpdE3khaNxMfkIVFLJs/VPTchrldH57VyWiKm8/PkO/l23yKf4/B3 PXP7y7a4IoRg94BZn74bFwwZuTsbMP2+7LlFMn6D4/NCGWLNAD/L1eTKPx8wPv62+K5u Q63UbNpzHT2Bhe2SyiaDu8W01foSt9YJIpvEZ+mbLLePdV1OVgc1nHGpkdTQIyVNOYz5 7nu42E7mOjFlfnXKGUZk9PnyUQSPNEG+OC0vaYfSAZ+E4f+Cce2o4a7yASOZ0U6u4TA8 eCag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=msdAKUkaozlyVVqcOzRUhmh/jucXO4phsOtdu8kld0Q=; b=SEy9mdSW0NDNR6jlFpHqH9LrOW+d+BJhwb7/YcO55txBSP3yRSr6eA267nbqKYCH3E x7wZpCxg4DUJq95UfjEXEt0j4uwRFk6PpORAE9L8U1t0tjy6qAsJ6dm1lBB3MwI0VWUs m2WLf0exyHICm3Y7ztreKqsRyZyvh2SQNnqkS0JWVZ1hQNoBaw5EJzFKdSkAohd0vhce /3S+FWydVIJqV7pgDVnqjKQzxhQwB61Yl5PZQl/osQzn24l2uv3dzeX0Drd/E+XsyNgG gvHrKRO6ZuBW6HcK4VHdUeIW1RAqMlJHLdkK8fJwv+edj9fNJ2fLXm6RMIaVcwtT6AxR WjYA== X-Gm-Message-State: AOAM533XMMJmRmHQbykRIhD8AJHEsACRqvLSXdK8z3HZ62F1+8SRrI6R EKG5Mw0JjvztkDVfwH46DJoJefSqUPJMTJHaRJUK6Q== X-Google-Smtp-Source: ABdhPJy1tfc8MMLbLxb17dL/Fz+emF7KQc0Sq2AZPCRIAITdiREKq62E+vLNNTXjO6JYEXGn4JOR0UYxdckLCtorADI= X-Received: by 2002:aca:bb06:: with SMTP id l6mr6066042oif.121.1618992705356; Wed, 21 Apr 2021 01:11:45 -0700 (PDT) MIME-Version: 1.0 References: <20210408103605.1676875-1-elver@google.com> <20210408103605.1676875-6-elver@google.com> <1fbf3429-42e5-0959-9a5c-91de80f02b6a@samsung.com> <43f8a3bf-34c5-0fc9-c335-7f92eaf23022@samsung.com> In-Reply-To: From: Marco Elver Date: Wed, 21 Apr 2021 10:11:33 +0200 Message-ID: Subject: Re: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf to siginfo To: Marek Szyprowski Cc: Peter Zijlstra , Alexander Shishkin , Arnaldo Carvalho de Melo , Ingo Molnar , Jiri Olsa , Mark Rutland , Namhyung Kim , Thomas Gleixner , Alexander Potapenko , Al Viro , Arnd Bergmann , Christian Brauner , Dmitry Vyukov , Jann Horn , Jens Axboe , Matt Morehouse , Peter Collingbourne , Ian Rogers , Oleg Nesterov , kasan-dev , linux-arch , linux-fsdevel , LKML , "the arch/x86 maintainers" , "open list:KERNEL SELFTEST FRAMEWORK" , Geert Uytterhoeven , Bartlomiej Zolnierkiewicz Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org On Wed, 21 Apr 2021 at 09:35, Marek Szyprowski wrote: > > On 21.04.2021 08:21, Marek Szyprowski wrote: > > On 21.04.2021 00:42, Marco Elver wrote: > >> On Tue, 20 Apr 2021 at 23:26, Marek Szyprowski > >> wrote: > >>> On 08.04.2021 12:36, Marco Elver wrote: > >>>> Introduces the TRAP_PERF si_code, and associated siginfo_t field > >>>> si_perf. These will be used by the perf event subsystem to send > >>>> signals > >>>> (if requested) to the task where an event occurred. > >>>> > >>>> Acked-by: Geert Uytterhoeven # m68k > >>>> Acked-by: Arnd Bergmann # asm-generic > >>>> Signed-off-by: Marco Elver > >>> This patch landed in linux-next as commit fb6cc127e0b6 ("signal: > >>> Introduce TRAP_PERF si_code and si_perf to siginfo"). It causes > >>> regression on my test systems (arm 32bit and 64bit). Most systems fails > >>> to boot in the given time frame. I've observed that there is a timeout > >>> waiting for udev to populate /dev and then also during the network > >>> interfaces configuration. Reverting this commit, together with > >>> 97ba62b27867 ("perf: Add support for SIGTRAP on perf events") to let it > >>> compile, on top of next-20210420 fixes the issue. > >> Thanks, this is weird for sure and nothing in particular stands out. > >> > >> I have questions: > >> -- Can you please share your config? > > > > This happens with standard multi_v7_defconfig (arm) or just defconfig > > for arm64. > > > >> -- Also, can you share how you run this? Can it be reproduced in qemu? > > Nothing special. I just boot my test systems and see that they are > > waiting lots of time during the udev populating /dev and network > > interfaces configuration. I didn't try with qemu yet. > >> -- How did you derive this patch to be at fault? Why not just > >> 97ba62b27867, given you also need to revert it? > > Well, I've just run my boot tests with automated 'git bisect' and that > > was its result. It was a bit late in the evening, so I didn't analyze > > it further, I've just posted a report about the issue I've found. It > > looks that bisecting pointed to a wrong commit somehow. > >> If you are unsure which patch exactly it is, can you try just > >> reverting 97ba62b27867 and see what happens? > > > > Indeed, this is a real faulty commit. Initially I've decided to revert > > it to let kernel compile (it uses some symbols introduced by this > > commit). Reverting only it on top of linux-next 20210420 also fixes > > the issue. I'm sorry for the noise in this thread. I hope we will find > > what really causes the issue. > > This was a premature conclusion. It looks that during the test I've did > while writing that reply, the modules were not deployed properly and a > test board (RPi4) booted without modules. In that case the board booted > fine and there was no udev timeout. After deploying kernel modules, the > udev timeout is back. I'm confused now. Can you confirm that the problem is due to your kernel modules, or do you think it's still due to 97ba62b27867? Or fb6cc127e0b6 (this patch)? Thanks, -- Marco