On Wed, Jun 25, 2014 at 4:30 PM, Manuel Bouyer <[email protected]> wrote: > On Wed, Jun 25, 2014 at 02:43:16PM +0900, Ryota Ozaki wrote: >> Hi, >> >> I found a strange behavior of if_wm that >> its interrupt handler may call its if_start >> (xmit function) eventually. I don't think >> it's sane. It makes difficult to use mutex for MP. >> >> Here is a call trace: >> wm_intr => wm_linkintr => wm_linkintr_gmii => >> mii_pollstat => makphy_service => mii_phy_update => >> if_link_state_change => in6_if_link_up => >> nd6_dad_start => nd6_dad_ns_output => ... => >> => ether_output => ... => wm_start >> >> The interrupt handler calls mii, mii notifies >> a link state change to inet6, and inet6 tries DAD. >> This IPv6 DAD code (nd6_dad_start and >> nd6_dad_ns_output) is the main issue of my claim. >> nd6_dad_start normally sets up a callout for >> nd6_dad_ns_output, however, it may call >> nd6_dad_ns_output directly at random. >> >> Looking at (1), in6_if_link_up picks a random delay >> (in tick) ranging from 0 to hz and passes it to >> nd6_dad_start. nd6_dad_start sets up a callout if >> the delay > 0 while calls nd6_dad_ns_output directly >> if the delay == 0 (2). This random behavior makes >> debugging difficult. >> >> OpenBSD seems to have changed nd6_dad_start to always >> call a callout regardless of the delay (3). I think >> we should do such an approach as that. By doing so, >> we can avoid the above wm_intr => wm_start problem. >> >> My proposal to fix the problem of nd6_dad_start is to >> allow a negative value of the delay to indicate that >> no delay is required and nd6_dad_ns_output is called >> directly. For any other value including zero, >> a callout is always used. >> >> Any comments? > > why not change in6_if_link_up() to use a delay >= 1 instead of 0 ?
My change intends to make it clear whether a callout will be used or not. I think it's error-prone. ozaki-r > > -- > Manuel Bouyer <[email protected]> > NetBSD: 26 ans d'experience feront toujours la difference > --
