From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 10CED4746BC for ; Thu, 6 Aug 2026 12:03:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786017802; cv=none; b=czIIWCD/KWJkVHW66WECKwznnb6PBDg3gbQcTPGyl9CWPzxiS1xvIsFGR/pkhGW2Opl4X+WMkxnzKW1JEAk5eQqhwC80Wj0jQawfWYZaAuDtOQOS3THCCcneP1VWnVPnFynHZ51YjJUh6r9xI8m/A+U40eua77hKkKPDCiEqSgg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786017802; c=relaxed/simple; bh=W3D+9NixwQLoTJ1aioJtP64oWgPvbWXj8SUgRrzVThc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=k/mEhU2CqSuf1NhZBmHGnzNCV4Cx6dIO9DIA2qXXK0KrmDPE0ZB+8Uf/E2IygAhIZDiy7UglW4jWjRSKm69BsHXw4HTU83ifll16qYzWjA/5UagMsFdHA8iKcphJJdJr4YRnqqjOj1EIlTK0OUwC9qH/DPlizEIfpxv2L3IeOHU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=V+z8oKtv; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="V+z8oKtv" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4994c49f588so9131515e9.0 for ; Thu, 06 Aug 2026 05:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786017799; x=1786622599; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=SboEURbqMkITdM1PZFfh6XITB55ibq8iUKBfhFu40tQ=; b=V+z8oKtvo/6y8vZ3VnzWvymxDKEFnRu3sHHAJ22YvVOiP9NFNhkMa9p6sIwNcZk1Wu dz8/GXhumx+6cVOhSq+DBwBzue0oJR18nSEyX+rFcl9Ig76DmvLTwPToIHeZEXsze8nR Oa5f/vMBq+VY0ILhKQa0dLAQSxlg7RO0wRw3O1yKAgRGkKcsFMqcGg/DrnEWHxH7Ra0/ D6lqN14BhhugrolvcAWAaHPIwa6DwaLUuCZrjtZHGacYlekciDOES/6MoYCyudJuvOhf apeU4t9NppC2lmhBTMliJLxoYaG0ABXd6hU+bzoSpBJ5sxDmU+reLfbXlifQRYxo7nbn 2blw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786017799; x=1786622599; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=SboEURbqMkITdM1PZFfh6XITB55ibq8iUKBfhFu40tQ=; b=EflguoXhzL/OyCWKPYAQKf/RbJlNDyHZu2lEt8cgK9iwidPBsLCTFbKSfVcRwhQW8b G3TKiw3iNgCSTe6IGxBUyoiBubuPt9Cf3A2cVPM6hufesoduWpLVupMGOEbpAvFWHr45 6sDJGrQU3kd4xYSm01Lsg0INc1OpSPL+iWBkXeuZrzFJaRskKLqSYVGNv1+CJ1pn2zcT u4KSQHN7tp+00/zA40DbhWl3gMh29RGMDvOSn/yoHkB6vYjRytsZmGG5YvmTh2TslEYm g09lWY05HxrAy8ogb7w7SOQELz2Ce9Ys5RiaCVEXp/hqS3oYldd2RPm9+pyt0suHyFd+ KoAw== X-Forwarded-Encrypted: i=1; AHgh+RpfktM25T1zwTfDALPc7VQgZCpNYG7+xQ64tDqhGC1Lc81ouUMiq68rqc5nNmsvnqmOr7NJtPasPFMPbzQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yxq1F33TYAfT4wHb/B99ZWVE7cZ7pr6dgXnYs+DW4mMFW17dun9 7Tk/HdLdwgzDvZykv83eGCh6vQNscNlqMzlQTM2zBKrv0L7KyoElSnzB X-Gm-Gg: AR+sD11MHsX741pa0EjK7BNhU5zEe5/EYO+pW/8yE53P7IFLHPEEBzvghyNKV0gNwcy 7DbV25+KpVUcRNNWmAVzCiOiE8rmEYhLkbjOj5Zwl56yPMr4snkYXUl7oNH+uh5WTDLwnVuH4ey uLtavNigElGkbEGFelHaljevC3Qv2TujEb2F+UV2O0BCsNd9wkx5bY9jFpVc8dHm/u9JIGHAdQv /gSKUJCHAzBFb7tqOn0WJHVf+HX71EAYKYMwA8FPachYaguuoCXGUD1rbrvCVBbYo07jNjvX4NH QfXXC1uLjnhOuTgIoJANv7cPd0zcuj9UzwbGCWn/LTuv5kALiqnPBz61/mofCNdm4u7rgVVBHZr eB/7BiK020Qyy0nZKQSCbMaxpxWzTrzBHAOC7I15cjcvw12qqQL/fkGA2icYv5IZpUAx/zgWJ8O c48SsDQxIjz0a9tQMgBxHRGYU2frz+xipRQnYehuQQlwVvZBfgKISQwoVJX5RPbtePFQIB5tZsn ishJPajy+ILiJ0hqgnL7kjvmeE5XOdm1I3yK2XWXIk/i54vvsPYWF1eiUBTGQ9hscFn7VSLfdCi 9ofAps0hAEtkPyDGX7dspVhMY6DIeMZOj1aMCg== X-Received: by 2002:a05:600c:42d4:b0:499:59fd:dbfc with SMTP id 5b1f17b1804b1-49959fddc5emr4260805e9.1.1786017797413; Thu, 06 Aug 2026 05:03:17 -0700 (PDT) Received: from ?IPV6:2a01:4b00:bd21:4f00:7cc6:d3ca:494:116c? ([2a01:4b00:bd21:4f00:7cc6:d3ca:494:116c]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4994e98fdedsm127208355e9.4.2026.08.06.05.03.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Aug 2026 05:03:16 -0700 (PDT) Message-ID: <6fb5da63-526f-450a-ae8d-6a7d97f1bcf4@gmail.com> Date: Thu, 6 Aug 2026 13:03:19 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [syzbot] [net?] WARNING in netdev_queue_get_dma_dev To: Jakub Kicinski Cc: syzbot , davem@davemloft.net, edumazet@google.com, horms@kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, pabeni@redhat.com, syzkaller-bugs@googlegroups.com References: <6a71f80c.40259c87.584f4.04b9.GAE@google.com> <20260804140006.0210f6ca@kernel.org> <0a419b0b-18d6-42a4-962d-301ddd9d4498@gmail.com> <20260805165817.7e1fc367@kernel.org> Content-Language: en-US From: Pavel Begunkov In-Reply-To: <20260805165817.7e1fc367@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/6/26 00:58, Jakub Kicinski wrote: > On Wed, 5 Aug 2026 09:51:10 +0100 Pavel Begunkov wrote: >> On 8/4/26 22:00, Jakub Kicinski wrote: >>> Hi Pavel, could you TAL? >> >> It complains on not holding rtnl, so the netdev should be not >> qops-enabled, and we acquire it with netdev_get_by_index_lock(). >> It's going to be rejected later, but not sure whether netdev->lock >> protects its device and leasing logic well in this case. > > Hm, I see. > >> As a quick fix, let's fail it early in zcrx if there is no qops. > > I think we can switch the lockdep check in netdev_queue_get_dma_dev() > to netdev_assert_locked(dev)? Nothing should be calling that function > under rtnl_lock so the _compat() is a brainfart. The assert was useful in this report, i.e. flagged difference in locking expectation at least for me. I was thinking maybe netdev_queue_get_dma_dev() should fail. Or maybe even netdev_get_by_index_lock() is the problem; it's odd for it to return w/o rtnl lock with a device that expects it, but perhaps I don't know what dev->lock synchronises for !netdev_need_ops_lock() cases. In either case, I'd just fix it for 7.2 for now and defer figuring sth nicer for later. fwiw, devmem tcp seems to be fine as netdev_can_create_queue() should check it. -- Pavel Begunkov