On Wednesday, May 16, 2012 2:41:25 pm David Somayajulu wrote: > Hi All, > When ifp->if_ioctl() is invoked for the ioctl cmd SIOCADDMULTI, > > > > IN_MULTI_LOCK() is called in one of the functions in_joingroup() in the caller stack. > > > > >From netinet/in_var.h, line 357 : #define IN_MULTI_LOCK() mtx_lock(&in_multi_mtx) > > > > >From netinet/in_mcast.c > 1098 in_joingroup(struct ifnet *ifp, const struct in_addr *gina, > 1099 /*const*/ struct in_mfilter *imf, struct in_multi **pinm) > 1100 { > 1101 int error; > 1102 > 1103 IN_MULTI_LOCK(); > 1104 error = in_joingroup_locked(ifp, gina, imf, pinm); > 1105 IN_MULTI_UNLOCK(); > 1106 > > This is also the case for SIOCDELMULTI, where the function holding "in_multi_mtx" lock is in_leavegroup() > > This poses a problem in the driver in that the hardware dependent function performing it, is not allowed to sleep() in case it needs to poll some state. > > Question: > > 1. If I want to implement any delays - for the above case - in the driver using DELAY(usec) macro, is there a maximum amount of time that the driver is allowed to complete this function? I am concerned that if it takes to too long I might run into a soft_lockup() situation. > > 2. Is it o.k to defer the processing in a separate in a separate thread which can sleep() ? You can always queue a task to update the MAC table if you need to use a sleep. -- John BaldwinReceived on Thu May 17 2012 - 13:00:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:27 UTC