Messages in this thread | | | From | Rusty Russell <> | Subject | Re: [PATCH] Make kthread_stop() not oops when passed a bad pointer | Date | Wed, 6 Aug 2008 11:22:58 +1000 |
| |
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/
| |