On 09/05/2017 08:24 AM, Alan Cox wrote: >>> anymore. But I'm already _running_ this program. If I could fork() I >>> could already get a second copy of the sucker and call main() again >>> myself if necessary, but I can't, so... > > You can - ptrace 8) Oh I can call clone() with various flags and try to fake it myself, it just won't do what I want. :) >>> honoring the suid bit if people feel that way. I just wanna unblock >>> vfork() while still running this code. > > Would it make more sense to have a way to promote your vfork into a > fork when you hit these cases (I appreciate that fork on NOMMU has a much > higher performance cost as you start having to softmmu copy or swap > pages). It's not the performance cost, it's rewriting all the pointers. Without address translation, copying the existing mappings to a new range requires finding and adjusting every pointer to the old data, which you can do for the executable mappings in PIE* binaries, but tracking down all the pointers on the stack, heap, and in your global variables? Flaming pain. Making fork() work on nommu is basically the same problem as making garbage collection work in C on mmu. Thus those of us who defend vfork() from the people who don't understand why it exists periodically suggesting we remove it. > Alan Rob * or FDPIC, which is basically just PIE with 4 individually relocatable text/data/rodata/bss segments instead of one big mapping you relocate as a contiguous block; both work on nommu but fdpic can fit into more fragmented memory, and becauase the segments are independent it lets nommu share some segments between processes (code+rodata**) without sharing others (data and bss). That's why nommu can't run normal elf but can run PIE or FDPIC binaries. Or binflt which is the old a.out version. ** Don't ask me what happens when rodata contains a constant pointer to a bss or data object. I'm guessing the compiler Does A Thing. Ask Rich Felker? -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
