On Tue, Jun 05, 2007 at 03:23:40PM -0400, Jeff Layton wrote: > I recently sent a similar, smaller patch for this problem. After some > discussion with Steve and Shaggy, I think I better understand why cifsd > allows signals through, and I realize that my earlier patch wasn't > comprehensive enough > > The mount and unmount calls will send a KILL signal to cifsd to wake it > up if it happens to be blocked in kernel_recvmsg. The problem is that > it doesn't distinguish between "legitimate" signals sent for this > reason and spurious signals sent by a userspace process (for instance). > While this is definitely a "don't do that" sort of situation, we might > as well try to have cifsd be as signal-safe as possible. > > The following patch does this by making sure that we set tcpStatus to > CifsExiting before sending cifsd a signal, and having cifsd check for > that when it sees that it's been signalled. If the tcpStatus is not set > correctly, it ignores it, flushes signals and moves on. > > I've tested a similar backported version of this on an earlier kernel, > but have not tested this particular patch as of yet. The right way to fix this is to stop sending signals at all and have a kernel-internal way to get out of kernel_recvmsg. Uses of signals by kernel thread generally are bugs. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
