public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
* [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