netif_rx_mode_sync(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… netif_rx_mode_sync(9)

okay so bestie, welcome to the Kernel API Manual, section 9 β€” this is the page for netif_rx_mode_sync, and honestly? it's giving "small function, big main character energy" ✨


πŸŽ€ NAME πŸŽ€

netif_rx_mode_sync β€” sync that rx mode inline, no waiting around, periodt πŸ’…


✨ SYNOPSIS ✨

void netif_rx_mode_sync (struct net_device *dev );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • dev β€” the network device. that's it, that's the whole argument list, she's low maintenance 🫢

πŸ’– DESCRIPTION πŸ’–

okay so picture this: you're a driver and you implement ndo_set_rx_mode_async. that means your rx mode callback gets executed from a workqueue. sounds cute, right? and it is β€” it lets the callback sleep 😴 which is genuinely useful.

BUT (and this is the plot twist 😭) it also means the hardware update is deferred, so it may not be visible to userspace by the time the initiating syscall returns. not us finding out the vibes were off the whole time πŸ’€

so what does netif_rx_mode_sync do? she steals the workqueue update and executes it inline. literally just takes it and runs it right there, no queue, no waiting. and the reason is honestly iconic: it preserves the atomicity of operations to the userspace. that's the whole point. she ate and left no crumbs πŸ‘‘


🌈 SEE ALSO 🌈

this list is long bestie, buckle up 🧚 the kernel file is ./net/core/dev_addr_lists.c, and:


🫢 quick vibe check before you go: the hardware update being deferred is the actual consequence of the workqueue path β€” that's not a bug, that's just how it works. this function is the "do it right now instead" button.

and that's the page! tysm for reading, this was ./net/core, dated October 2026, and the girl herself is netif_rx_mode_sync(9) β€” mwah πŸ’‹πŸ’œ

πŸ“¦ where this page comes from