Trond Myklebust <trond.myklebust@fys.uio.no> writes:Doesn't unmount handle that? Regardless kernel threads should be an implementation detail not a part of the user interface. If kernel threads are part of the user interface it makes them very hard to change. So it isn't that it doesn't make sense to me it is that it looks fundamentally broken and like a maintenance nightmare. I would rather kill kernel threads then try and simulate them when the kernel implementation has changed and kernel threads are not visible. If I could be convinced that signal handling in kernel threads is not something that will impede code modifications and refactoring I would have less of a problem, and might not care. With pid namespaces all kernel threads will disappear so how do we cope with the problem when the sysadmin can not see the kernel threads? Eric -
| Ingo Molnar | Re: x86: 4kstacks default |
| Gabriel C | modpost errors ( Re: 2.6.23-rc6-mm1) |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Press, Jonathan | RE: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface foron access scann... |
git: | |
| David Miller | Re: iptables very slow after commit784544739a25c30637397ace5489eeb6e15d7d49 |
| Natalie Protasevich | [BUG] New Kernel Bugs |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 13/37] dccp: Deprecate Ack Ratio sysctl |
