Netlink / udev folks, please review. On Sat, Jul 31, 2010 at 5:48 AM, Daniel Haid <d.haid@gogi.tv> wrote:CRDA is not the only thing called by the kernel where there would be an issue due to a delay with udev during bootup to react to a message. The kernel calls CRDA for udev through kobject_uevent_env(). Uevent messages are now broadcasted through netlinknetlink_broadcast_filtered() since the old method of using a direct call to /sbin/hotplug would lead to many processes being spawned and in some cases OOM. You can still use this though through CONFIG_UEVENT_HELPER_PATH which will issue call_usermodehelper() during early boot on an initramfs for example, if you so need it. I am not sure though if netlink broadcast messages would be reissued by the kernel during early boot if no one replied back to the send message but it is worth looking into. As far as I can tell you would be the first to notice this. In fact we actually had reports of two consecutive messages being being sent to userspace when only one was being sent to userspace so it may indeed be in fact true that messages are rebroadcasted somehow, I am just not sure so Cc'ing netdev and lkml. iw reg set will be ignored by net/wireless/reg.c as it is still waiting for last_request to be processed. It seems in your case the assumption that the request will be reissued in case udev is running at early boot is incorrect and we need to further understand exactly how these messages get queued and perhaps reissued or not. I considered recently changing the way we handle requests to userspace to use a completion handler but that would sit idle there for a while blocking on the reg_mutex... so decided against it. But could take a look again. We need a better understanding of how netlink broadcast messages get processed during early boot. Right now cfg80211 will drop duplicate requests or any request while we're still pending for the last one. Once we find out more details about how netlink broadcast messages get processed during early boot we can then rework things a bit. In the meantime can you try using CONFIG_UEVENT_HELPER_PATH during the initramfs? Luis --
| Greg KH | Og dreams of kernels |
| Jens Axboe | [PATCH 31/33] Fusion: sg chaining support |
| Arnd Bergmann | Re: finding your own dead "CONFIG_" variables |
| Mark Brown | [PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset |
| Tony Breeds | [LGUEST] Look in object dir for .config |
git: | |
| Brian Downing | Re: Git in a Nutshell guide |
| John Benes | Re: master has some toys |
| Matthias Lederhofer | [PATCH 4/7] introduce GIT_WORK_TREE to specify the work tree |
| Alexander Sulfrian< |
