On Mon, May 16, 2011 at 4:23 PM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: > I just updated the bz with these questions, but we can have the > conversation here... > > I'm just a bit concerned by the fact that there are > a couple of places that sets F_SETSIG and then sets F_NOTIFY, > so does that mean those places are potential race cases as > well? > where does this happen? There are 3 places where I have seen these fcntl's. The first three are: 1. in idmapd.c, at nfsopen() 2. in gssd_proc.c at process_clnt_dir() 3. in gssd_main_loop.c at topdirs_add_entry() In all of these cases, the pattern is to set the SETSIG to something useful, and then enable NOTIFY, though; thus they should not determine a race. [there is also a fourth one in idmapd, where the signals are actually initialized (lines 357-360); however, in the case of failure of the first SETSIG the daemon does not start] > Also, after you applied this patch, did the problem go away? I honestly don't know: the problem seems to have disappeared, in the sense that the patched daemon has not died. However, before it occurred with quite a random pattern (usually, once per day per machine, but it really depended) so I cannot be sure (it might be it was also related to the overall load - unfortunately I do not have the proper statistics). best, lg -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
