[syzbot] [afs?] [net?] KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packet

[syzbot]

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+6182af...@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 syzk...@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

[David Howells]

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

[Eric Dumazet]

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)...

[David Howells]

Eric Dumazet <edum...@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