![]() | |||||||||||||
Messages in this thread |
On Tuesday 05 August 2008 23:55:59 Matthew Wilcox wrote: > Make kthread_stop a little more robust against numbskulls > like me. > > Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Hi Willy, I really do sympathize with your problem; but the quest is to figure out how to identify it before the code is run, not to put a non-orthogonal bandaid here which can hurt other cases. How about a more ambitious "we've oopsed so break a mutex every 30 seconds of waiting" patch? > + if (!k || IS_ERR(k)) > + return -EINVAL; 1) There's no reason that kthread_stop is uniquely difficult to use. Why pick on that one? 2) I know that kfree() handles NULL, but kthread_create/kthread_run never return NULL, unlike kmalloc(). 3) If we really want to pass a failed kthread_create() through kthread_stop(), we should return PTR_ERR(k) here. But that should only be done if it made it harder for the callers to screw up, which I don't think it does. 4) After a successful kthread_run(), kthread_stop() will always return the value from the threadfn callback. ie. kthread_stop() doesn't ever fail. A simple semantic, which this patch breaks. 5) Covering up programmer errors is not good policy. I dislike WARN_ON() because an oops is much harder to miss. Painful for you, but The System Works. Sorry, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2008-08-06 08:39 [from the cache] ©2003-2008 | |||||||||||||