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;
Date:   Wed, 3 Aug 2022 08:37:51 -0700
From:   Jakub Kicinski <kuba@kernel.org>
To:     Bruno Goncalves <bgoncalv@redhat.com>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Networking <netdev@vger.kernel.org>,
        CKI Project <cki-project@redhat.com>
Subject: Re: RIP: 0010:qede_load+0x128d/0x13b0 [qede] - 5.19.0
Message-ID: <20220803083751.40b6ee93@kernel.org>
In-Reply-To: <CA+QYu4ob4cbh3Vnh9DWgaPpyw8nTLFG__TbBpBsYg1tWJPxygg@mail.gmail.com>
References: <CA+QYu4qxW1BUcbC9MwG1BxXjPO96sa9BOUXOHCj1SLY7ObJnQw@mail.gmail.com>
        <20220802122356.6f163a79@kernel.org>
        <CA+QYu4ob4cbh3Vnh9DWgaPpyw8nTLFG__TbBpBsYg1tWJPxygg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 3 Aug 2022 14:13:00 +0200 Bruno Goncalves wrote:
> Got this from the most recent failure (kernel built using commit 0805c6fb39f6):
> 
> the tarball is https://s3.amazonaws.com/arr-cki-prod-trusted-artifacts/trusted-artifacts/603714145/build%20x86_64%20debug/2807738987/artifacts/kernel-mainline.kernel.org-redhat_603714145_x86_64_debug.tar.gz
> and the call trace from
> https://s3.us-east-1.amazonaws.com/arr-cki-prod-datawarehouse-public/datawarehouse-public/2022/08/02/redhat:603123526/build_x86_64_redhat:603123526_x86_64_debug/tests/1/results_0001/console.log/console.log
> 
> [   69.876513] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
> [   69.888521] Hardware name: HPE ProLiant DL325 Gen10 Plus/ProLiant
> DL325 Gen10 Plus, BIOS A43 08/09/2021
> [   69.897971] RIP: 0010:qede_load.cold
> (/builds/2807738987/workdir/./include/linux/spinlock.h:389
> /builds/2807738987/workdir/./include/linux/netdevice.h:4294
> /builds/2807738987/workdir/./include/linux/netdevice.h:4385
> /builds/2807738987/workdir/drivers/net/ethernet/qlogic/qede/qede_main.c:2594
> /builds/2807738987/workdir/drivers/net/ethernet/qlogic/qede/qede_main.c:2575)

Thanks a lot! That seems to point the finger at commit 3aa6bce9af0e
("net: watchdog: hold device global xmit lock during tx disable") but
frankly IDK why... The driver must be fully initialized to get to
ndo_open() so how is the tx_global_lock busted?!

Would you be able to re-run with CONFIG_KASAN=y ?
Perhaps KASAN can tell us what's messing up the lock.