* Andrew Morton <[email protected]> wrote:
> > to solve this we must either change files_lock to be softirq-safe too
> > (bleh!), or we must forbid remove_proc_entry() use from softirq
> > contexts. Neither is a happy solution - remove_proc_entry() is used
> > within free_irq(), and who knows how many drivers do free_irq() in
> > softirq/tasklet context ...
>
> free_irq()'s /proc fiddling has always been a pain - we just shouldn't
> be doing filesystem things in irq/bh context.
the second patch i sent is quite straightforward.
> > Andrew, this needs to be resolved before v2.6.16, correct? Steve's patch
> > solves a real bug in the upstream kernel.
>
> It's not a very big bug - I think only Steve hit it, and that with a
> stress-test which was somewhat tuned to hit it.
still ...
> So we can afford to sit on the problem for a while, as long as someone
> is working on a broader /proc-sanity fix. But nobody will do that.
>
> I wonder if we can just punt the unregister_handler_proc/kfree up to a
> keventd callback.
i'd rather do the files_lock change i sent, and perhaps add a
WARN_ON_ONCE() to all known places that do a free_irq() from softirq
context.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
