* [syzbot] [afs?] [net?] KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packet
@ 2026-01-07 15:34 syzbot
2026-01-08 13:42 ` David Howells
0 siblings, 1 reply; 4+ messages in thread
From: syzbot @ 2026-01-07 15:34 UTC (permalink / raw)
To: davem, dhowells, edumazet, horms, kuba, linux-afs, linux-kernel,
marc.dionne, netdev, pabeni, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 30f09200cc4a Merge tag 'arm64-fixes' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13446e12580000
kernel config: https://syzkaller.appspot.com/x/.config?x=655255e3ef31c19b
dashboard link: https://syzkaller.appspot.com/bug?extid=6182afad5045e6703b3d
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/445be400b5e4/disk-30f09200.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/8be295d83690/vmlinux-30f09200.xz
kernel image: https://storage.googleapis.com/syzbot-assets/ae2ac2a81686/bzImage-30f09200.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+6182afad5045e6703b3d@syzkaller.appspotmail.com
==================================================================
BUG: KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packet
write to 0xffff8881044ab560 of 8 bytes by task 4063 on cpu 1:
rxrpc_send_data_packet+0x1593/0x1df0 net/rxrpc/output.c:714
rxrpc_transmit_fresh_data net/rxrpc/call_event.c:255 [inline]
rxrpc_transmit_some_data+0x63c/0x8b0 net/rxrpc/call_event.c:277
rxrpc_input_call_event+0x8bb/0xf30 net/rxrpc/call_event.c:401
rxrpc_io_thread+0x1c1e/0x21c0 net/rxrpc/io_thread.c:550
kthread+0x489/0x510 kernel/kthread.c:463
ret_from_fork+0x122/0x1b0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
read to 0xffff8881044ab560 of 8 bytes by task 3500 on cpu 0:
rxrpc_peer_keepalive_dispatch net/rxrpc/peer_event.c:268 [inline]
rxrpc_peer_keepalive_worker+0x44e/0x800 net/rxrpc/peer_event.c:341
process_one_work kernel/workqueue.c:3263 [inline]
process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3346
worker_thread+0x582/0x770 kernel/workqueue.c:3427
kthread+0x489/0x510 kernel/kthread.c:463
ret_from_fork+0x122/0x1b0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
value changed: 0x0000000000000000 -> 0x0000000000000029
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 UID: 0 PID: 3500 Comm: kworker/u9:1 Not tainted syzkaller #0 PREEMPT(voluntary)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
Workqueue: krxrpcd rxrpc_peer_keepalive_worker
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [syzbot] [afs?] [net?] KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packet
2026-01-07 15:34 [syzbot] [afs?] [net?] KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packet syzbot
@ 2026-01-08 13:42 ` David Howells
2026-01-08 13:59 ` Eric Dumazet
0 siblings, 1 reply; 4+ messages in thread
From: David Howells @ 2026-01-08 13:42 UTC (permalink / raw)
To: syzbot
Cc: dhowells, davem, edumazet, horms, kuba, linux-afs, linux-kernel,
marc.dionne, netdev, pabeni, syzkaller-bugs
I think that this shouldn't be a problem. The write is:
conn->peer->last_tx_at = ktime_get_seconds();
and the read is:
keepalive_at = peer->last_tx_at + RXRPC_KEEPALIVE_TIME;
an approximate time is fine as we're estimating when to send a keepalive
packet if we haven't transmitted a packet in a while.
David
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [syzbot] [afs?] [net?] KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packet
2026-01-08 13:42 ` David Howells
@ 2026-01-08 13:59 ` Eric Dumazet
2026-01-08 14:28 ` David Howells
0 siblings, 1 reply; 4+ messages in thread
From: Eric Dumazet @ 2026-01-08 13:59 UTC (permalink / raw)
To: David Howells
Cc: syzbot, davem, horms, kuba, linux-afs, linux-kernel, marc.dionne,
netdev, pabeni, syzkaller-bugs
On Thu, Jan 8, 2026 at 2:42 PM David Howells <dhowells@redhat.com> wrote:
>
> I think that this shouldn't be a problem. The write is:
>
> conn->peer->last_tx_at = ktime_get_seconds();
>
> and the read is:
>
> keepalive_at = peer->last_tx_at + RXRPC_KEEPALIVE_TIME;
>
> an approximate time is fine as we're estimating when to send a keepalive
> packet if we haven't transmitted a packet in a while.
LGTM, but potential load and store tearing should be avoided, using
READ_ONCE() and WRITE_ONCE().
last_tx_at being time64_t, this would still be racy on 32bit arches.
last_tx_at could probably be an "unsigned long" (in jiffies units)...
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [syzbot] [afs?] [net?] KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packet
2026-01-08 13:59 ` Eric Dumazet
@ 2026-01-08 14:28 ` David Howells
0 siblings, 0 replies; 4+ messages in thread
From: David Howells @ 2026-01-08 14:28 UTC (permalink / raw)
To: Eric Dumazet
Cc: dhowells, syzbot, davem, horms, kuba, linux-afs, linux-kernel,
marc.dionne, netdev, pabeni, syzkaller-bugs
Eric Dumazet <edumazet@google.com> wrote:
> LGTM, but potential load and store tearing should be avoided, using
> READ_ONCE() and WRITE_ONCE().
Fair point.
> last_tx_at being time64_t, this would still be racy on 32bit arches.
>
> last_tx_at could probably be an "unsigned long" (in jiffies units)...
I've tried avoiding jiffies where possible. We have way too many different
clocks with different granularities and uses in the kernel, but you might be
right.
David
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-01-08 14:28 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-01-07 15:34 [syzbot] [afs?] [net?] KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packet syzbot
2026-01-08 13:42 ` David Howells
2026-01-08 13:59 ` Eric Dumazet
2026-01-08 14:28 ` David Howells
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox