Messages in this thread | | | Subject | Re: [RFC][PATCH] Kernel thread signal handling. | From | David Woodhouse <> | Date | Mon, 13 Oct 2003 12:55:03 +0100 |
| |
On Mon, 2003-10-13 at 04:40 -0700, Andrew Morton wrote: > People think "I need to send a message to a kernel thread" and then, > immediately, "ah-hah! I'll use a signal!"
I've seen relatively little of this. Most of the problems I've been aware of have been kernel threads _not_ handling signals (or handling only SIGKILL) and going into endless loops of bouncing straight back out of schedule().
That problem is almost unrelated -- it happens because driver writes want to sleep in TASK_INTERRUPTIBLE state rather than TASK_UNINTERRUPTIBLE. The fix for that is to have a per-task 'uninterruptible_count' along much the same lines as preempt_count, where each function which is unable to handle an -EINTR return increments the count before calling down to another function which may have done that. But that's a 2.7 thing and mostly not related to this particular bug.
> Sounds like the GC should have been performed by a userspace process in the > first place?
Well, it would have to actually be done in kernel space but I suppose there could be an ioctl or syscall or something which causes a call to jffs2_garbage_collect_pass() to happen in the context of the caller, and the variables which are used to decide when to wake up could be exposed to userspace via sysfs, and the userspace daemon itself could register with the JFFS2 code so that it gets woken when those variables change... or maybe I could poll() on the sysfs file which contains them I suppose...
Er, no :)
> How does userspace identify the JFFS2 process to which to send the > signal?
daemonize("jffs2_gcd_mtd%d", c->mtd->index);
> > I don't any the benefit in changing this practice. > > Well I know I'm going to lose this one, but at least I get to bitch about > stuff.
Fair enough :)
Bitching accomplished; now can we fix the bug?
-- dwmw2
- 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/
| |