[syzbot ci] Re: net: Revert tx queue length on partial failure in dev_qdisc_change_tx_queue_len()

[syzbot ci] Re: net: Revert tx queue length on partial failure in dev_qdisc_change_tx_queue_len()

[syzbot ci]

syzbot ci has tested the following series

[v1] net: Revert tx queue length on partial failure in dev_qdisc_change_tx_queue_len()
https://lore.kernel.org/all/<20250722071508.12497-1-suchitkarunakaran@gmail.com>
* [PATCH] net: Revert tx queue length on partial failure in dev_qdisc_change_tx_queue_len()

and found the following issue:
BUG: unable to handle kernel paging request in dev_qdisc_change_tx_queue_len

Full report is available here:
https://ci.syzbot.org/series/75b0a15e-cca4-4e46-8bf9-595c0dd34915

***

BUG: unable to handle kernel paging request in dev_qdisc_change_tx_queue_len

tree:      netdev
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net.git
base:      81e0db8e839822b8380ce4716cd564a593ccbfc5
arch:      amd64
compiler:  Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
config:    https://ci.syzbot.org/builds/2ee305f2-ddb8-45c6-8f47-2a150dc6dd22/config
syz repro: https://ci.syzbot.org/findings/1e75a6d3-11ac-48da-af27-60753abb61c7/syz_repro

netlink: 'syz.2.18': attribute type 13 has an invalid length.
netlink: 'syz.2.18': attribute type 17 has an invalid length.
BUG: unable to handle page fault for address: ffffed4821fa6a4b
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 13ffee067 P4D 13ffee067 PUD 0 
Oops: Oops: 0000 [#1] SMP KASAN PTI
CPU: 1 UID: 0 PID: 5980 Comm: syz.2.18 Not tainted 6.16.0-rc6-syzkaller-00128-g81e0db8e8398-dirty #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:dev_qdisc_change_tx_queue_len+0x542/0x640
Code: be 7f 05 00 00 48 c7 c2 20 d2 95 8c e8 27 db 27 f8 44 89 e0 48 69 c0 c0 01 00 00 49 8d 1c 06 48 83 c3 18 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00 74 08 48 89 df e8 1f af ab f8 48 8b 1b 4c 8d 73 18
RSP: 0018:ffffc900024beaa0 EFLAGS: 00010a06
RAX: 1ffff14821fa6a4b RBX: ffff8a410fd35258 RCX: ffff888020f2d640
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffc900024beb90 R08: ffffffff8fa1d6f7 R09: 1ffffffff1f43ade
R10: dffffc0000000000 R11: fffffbfff1f43adf R12: 00000000ffffffff
R13: dffffc0000000000 R14: ffff88810fd35400 R15: ffff88810ffe2018
FS:  00007fa854ede6c0(0000) GS:ffff8881a3c23000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffed4821fa6a4b CR3: 00000000295fa000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 netif_change_tx_queue_len+0x167/0x270
 do_setlink+0xdfb/0x41c0
 rtnl_newlink+0x149f/0x1c70
 rtnetlink_rcv_msg+0x7cf/0xb70
 netlink_rcv_skb+0x208/0x470
 netlink_unicast+0x75c/0x8e0
 netlink_sendmsg+0x805/0xb30
 __sock_sendmsg+0x21c/0x270
 ____sys_sendmsg+0x505/0x830
 ___sys_sendmsg+0x21f/0x2a0
 __x64_sys_sendmsg+0x19b/0x260
 do_syscall_64+0xfa/0x3b0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fa853f8e9a9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fa854ede038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fa8541b5fa0 RCX: 00007fa853f8e9a9
RDX: 0000000000000000 RSI: 0000200000000180 RDI: 0000000000000003
RBP: 00007fa854010d69 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007fa8541b5fa0 R15: 00007ffe5a5f8288
 </TASK>
Modules linked in:
CR2: ffffed4821fa6a4b
---[ end trace 0000000000000000 ]---
RIP: 0010:dev_qdisc_change_tx_queue_len+0x542/0x640
Code: be 7f 05 00 00 48 c7 c2 20 d2 95 8c e8 27 db 27 f8 44 89 e0 48 69 c0 c0 01 00 00 49 8d 1c 06 48 83 c3 18 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00 74 08 48 89 df e8 1f af ab f8 48 8b 1b 4c 8d 73 18
RSP: 0018:ffffc900024beaa0 EFLAGS: 00010a06
RAX: 1ffff14821fa6a4b RBX: ffff8a410fd35258 RCX: ffff888020f2d640
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffc900024beb90 R08: ffffffff8fa1d6f7 R09: 1ffffffff1f43ade
R10: dffffc0000000000 R11: fffffbfff1f43adf R12: 00000000ffffffff
R13: dffffc0000000000 R14: ffff88810fd35400 R15: ffff88810ffe2018
FS:  00007fa854ede6c0(0000) GS:ffff8881a3c23000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffed4821fa6a4b CR3: 00000000295fa000 CR4: 00000000000006f0


---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.

Re: [syzbot ci] Re: net: Revert tx queue length on partial failure in dev_qdisc_change_tx_queue_len()

[Jakub Kicinski]

On Tue, 22 Jul 2025 09:40:31 -0700 syzbot ci wrote:
> syzbot ci has tested the following series
> 
> [v1] net: Revert tx queue length on partial failure in dev_qdisc_change_tx_queue_len()
> https://lore.kernel.org/all/<20250722071508.12497-1-suchitkarunakaran@gmail.com>
> * [PATCH] net: Revert tx queue length on partial failure in dev_qdisc_change_tx_queue_len()
> 
> and found the following issue:
> BUG: unable to handle kernel paging request in dev_qdisc_change_tx_queue_len
> 
> Full report is available here:
> https://ci.syzbot.org/series/75b0a15e-cca4-4e46-8bf9-595c0dd34915

I think this email is missing a References: header ?
It doesn't get threaded properly.

Re: Re: [syzbot ci] Re: net: Revert tx queue length on partial failure in dev_qdisc_change_tx_queue_len()

[Aleksandr Nogikh]

Hi Jakub,

On Tue, 22 Jul 2025 Jakub Kicinski wrote:
> I think this email is missing a References: header ?
> It doesn't get threaded properly.

Yes, that was indeed a bug that has now been fixed, thanks for
reaching out!

-- 
Aleksandr

Re: [syzbot ci] Re: net: Revert tx queue length on partial failure in dev_qdisc_change_tx_queue_len()

[Jakub Kicinski]

On Wed, 23 Jul 2025 18:25:47 +0200 Aleksandr Nogikh wrote:
> On Tue, 22 Jul 2025 Jakub Kicinski wrote:
> > I think this email is missing a References: header ?
> > It doesn't get threaded properly.  
> 
> Yes, that was indeed a bug that has now been fixed, thanks for
> reaching out!

Thank you!

Re: [syzbot ci] Re: net: Revert tx queue length on partial failure in dev_qdisc_change_tx_queue_len()

[Jakub Kicinski]

On Wed, 23 Jul 2025 09:47:20 -0700 Jakub Kicinski wrote:
> On Wed, 23 Jul 2025 18:25:47 +0200 Aleksandr Nogikh wrote:
> > On Tue, 22 Jul 2025 Jakub Kicinski wrote:  
> > > I think this email is missing a References: header ?
> > > It doesn't get threaded properly.    
> > 
> > Yes, that was indeed a bug that has now been fixed, thanks for
> > reaching out!  
> 
> Thank you!

One more thing, would it be possible to add / correct the DKIM on these
messages? Looks like when our bots load the syzbot ci emails from lore
the DKIM verification fails. I see a X-Google-DKIM-Signature: header,
but no real DKIM-Signature:

Re: [syzbot ci] Re: net: Revert tx queue length on partial failure in dev_qdisc_change_tx_queue_len()

[Aleksandr Nogikh]

Hi Jakub,

On Thu, Aug 7, 2025 at 3:41 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Wed, 23 Jul 2025 09:47:20 -0700 Jakub Kicinski wrote:
> > On Wed, 23 Jul 2025 18:25:47 +0200 Aleksandr Nogikh wrote:
> > > On Tue, 22 Jul 2025 Jakub Kicinski wrote:
> > > > I think this email is missing a References: header ?
> > > > It doesn't get threaded properly.
> > >
> > > Yes, that was indeed a bug that has now been fixed, thanks for
> > > reaching out!
> >
> > Thank you!
>
> One more thing, would it be possible to add / correct the DKIM on these
> messages? Looks like when our bots load the syzbot ci emails from lore
> the DKIM verification fails. I see a X-Google-DKIM-Signature: header,
> but no real DKIM-Signature:

Thanks for letting us know!
Do these bots also face DKIM verification issues with regular syzbot
emails? We send them absolutely the same way, so the problem must
affect all reports.

We use the GAE Mail API, and its documentation[1] says that it signs
emails with DKIM only if a custom domain is configured. Since we send
from the default GAE domain, this would explain the verification
failures.

We'll explore the ways to fix this.

[1] https://cloud.google.com/appengine/docs/standard/services/mail?tab=go#authentication_with_domainkeys_identified_mail_dkim

-- 
Aleksandr

Re: [syzbot ci] Re: net: Revert tx queue length on partial failure in dev_qdisc_change_tx_queue_len()

[Jakub Kicinski]

On Thu, 7 Aug 2025 17:09:24 +0200 Aleksandr Nogikh wrote:
> > One more thing, would it be possible to add / correct the DKIM on these
> > messages? Looks like when our bots load the syzbot ci emails from lore
> > the DKIM verification fails. I see a X-Google-DKIM-Signature: header,
> > but no real DKIM-Signature:  
> 
> Thanks for letting us know!
> Do these bots also face DKIM verification issues with regular syzbot
> emails? We send them absolutely the same way, so the problem must
> affect all reports.

I haven't checked, TBH, we don't have any automation for normal
reports :( For the CI reports I was trying to hook them up to
some actions, kick the patch out of our test branch unless human
confirms that the report is a false positive.

> We use the GAE Mail API, and its documentation[1] says that it signs
> emails with DKIM only if a custom domain is configured. Since we send
> from the default GAE domain, this would explain the verification
> failures.
> 
> We'll explore the ways to fix this.
> 
> [1] https://cloud.google.com/appengine/docs/standard/services/mail?tab=go#authentication_with_domainkeys_identified_mail_dkim