> > 1. Add a new unicast function to netlink.c: > > void *ethnl_unicast_put(struct sk_buff *skb, u32 portid, u32 seq, u8 > > cmd) > > > > 2. Use it in the notification function instead of the multicast previously used > along with genlmsg_unicast(). > > 'portid' and 'seq' taken from genl_info(), are added to the struct > ethtool_module_fw_flash, which is accessible from the work item. > > > > 3. Create a global list that holds nodes from type struct > ethtool_module_fw_flash() and add it as a field in the struct > ethtool_module_fw_flash. > > Before scheduling a work, a new node is added to the list. > > Makes sense. > > > 4. Add a new netlink notifier that when the relevant event takes place, > deletes the node from the list, wait until the end of the work item, with > cancel_work_sync() and free allocations. > > What's the "relevant event" in this case? Closing of the socket that user had > issued the command on? The event should match the below: event == NETLINK_URELEASE && notify->protocol == NETLINK_GENERIC Then iterate over the list to look for work that matches the dev and portid. The socket doesn’t close until the work is done in that case. > > Easiest way to "notice" the socket got closed would probably be to add some > info to genl_sk_priv_*(). ->sock_priv_destroy() will get called. But you can also > get a close notification in the family > ->unbind callback. > > I'm on the fence whether we should cancel the work. We could just mark the > command as 'no socket present' and stop sending notifications. > Not sure which is better.. Is there a scenario that we hit this event and won't intend to cancel the work? Thanks, Danielle
