On Tue, Sep 16, 2014 at 5:05 PM, Richard Larocque <rlarocque@xxxxxxxxxx> wrote: > Adds new prctl calls to enable or disable VDSO loading for a process > and its children. > > The PR_SET_DISABLE_VDSO call takes one argument, which is interpreted as > a boolean value. If true, it disables the loading of the VDSO on exec() > for this process and any children created after this call. A false > value unsets the flag. > > The PR_GET_DISABLE_VDSO option returns a non-negative true value if VDSO > loading has been disabled for this process, zero if it has not been > disabled, and a negative value in case of error. > > These prctl calls are hidden behind a new Kconfig, > CONFIG_VDSO_DISABLE_PRCTL. This feature is available only on x86. > > The command line option vdso=0 overrides the behavior of > PR_SET_DISABLE_VDSO, however, PR_GET_DISABLE_VDSO will coninue to return > whetever setting was last set with PR_SET_DISABLE_VDSO. > > Signed-off-by: Richard Larocque <rlarocque@xxxxxxxxxx> > --- > This patch is part of some work to better handle times and CRIU migration. > I suspect that there are other use cases out there, so I'm offering this > patch separately. > > When considering CRIU migration and times, we put some thought into how > to handle the rdtsc instruction. If we migrate between machines or across > reboots, the migrated process will see values that could break its assumptions > about how rdtsc is supposed to work. I don't get it. If __vdso_clock_gettime returns the wrong value in any scenario, we should fix that. Simiarly, CRIU *already works*, unless there's something I don't know of. That being said, I would like an option to gate off RDTSC for a process and its children in order to make PR_TSC_SIGSEGV more useful. All the prerequisites are there now. What problem are you trying to solve exactly? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
