Messages in this thread | | | Date | Wed, 26 Jan 2000 19:16:49 +0100 | From | almesber@lrc ... | Subject | Re: [PATCH] root-hopping for pre-2.3.41-3 |
| |
Horst von Brand wrote: > I'd say go with the proposal of the fake root/cwd directory for kernel > threads that don't need access to the filesystem (all of them, I > guess). Cleanest way out, unless you allow them to live without root/cwd.
I agree with clean. The main problem here is to catch all threads/processes, including the ones not (yet) in the mainstream kernel and those which people haven't even written yet. I don't want something that breaks every once in a while in subtle ways for some silly and apparently unrelated reason.
Of course there's The One Right Way(tm) to do it:
- rename _*kernel_thread to _*kernel_thread_with_fs - find all other possible paths leading to kernel_thread/clone and do the same thing there - construct the dentry jail (may be a little tricky, e.g. I'm not sure if d_inode = NULL is safe, and there are a few other pointers I don't quite trust) - write a kernel_thread_without_fs that calls kernel_thread_with_fs and then puts the process into the dentry jail - change all 30+ calls to _*kernel_thread to _*kernel_thread_without_fs (and repeat this for all the other paths you've found above) - notify the authors, so they know what's happening to their code
This still has the following problems:
- you've just broken a few externally maintained packages, e.g. probably PCMCIA - threads that start early but access the file system only later still cause problems - doesn't help a bit with processes that aren't kernel threads
Of course, the latter two are somewhat hypothetical at the moment.
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |