On 05/16/2011 09:38 AM, Luca Giuzzi wrote: > Dear All, > we have had problems on some of our machines (all Fedora 14), where > rpc.idmapd used to die with an `I/O possible' message at (basically) > random times. A strace suggested the issue being in nfsopen() where a > signal type is reset before notification is disabled; a signal at just > the right time might be the cause of the problem; see > https://bugzilla.redhat.com/show_bug.cgi?id=684308 > I am now proposing the (trivial) patch to the list as well. > > Best Regards, > luca giuzzi > > --- nfs-utils-1.2.3/utils/idmapd/idmapd.c.orig 2011-05-13 > 16:27:08.000000000 +0200 > +++ nfs-utils-1.2.3/utils/idmapd/idmapd.c 2011-05-13 16:27:16.000000000 +0200 > @@ -778,8 +778,8 @@ nfsopen(struct idmap_client *ic) > } else { > event_set(&ic->ic_event, ic->ic_fd, EV_READ, nfscb, ic); > event_add(&ic->ic_event, NULL); > - fcntl(ic->ic_dirfd, F_SETSIG, 0); > fcntl(ic->ic_dirfd, F_NOTIFY, 0); > + fcntl(ic->ic_dirfd, F_SETSIG, 0); > if (verbose > 0) > xlog_warn("Opened %s", ic->ic_path); > } 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? Also, after you applied this patch, did the problem go away? Finally, how often did this problem occur? tia, steved. -- 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
