CRIU uses ns_last_pid to fork a process with a specified pid. For example, if we need to create a process with the pid of 10000, we write 9999 into /proc/sys/kernel/ns_last_pid $ echo 9999 > /proc/sys/kernel/ns_last_pid; sh -c 'echo $$' 10000 This behaviour has been broken and now if we write 9999 to ns_last_pid, a process will get the pid 9999. This patch restores the old behaviour. fixes: ("pid: replace pid bitmap implementation with IDR API") Cc: Gargi Sharma <gs051095@gmail.com> Cc: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Andrei Vagin <avagin@openvz.org> --- kernel/pid_namespace.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c index fea2c24fa460..504dadb1d920 100644 --- a/kernel/pid_namespace.c +++ b/kernel/pid_namespace.c @@ -287,6 +287,7 @@ static int pid_ns_ctl_handler(struct ctl_table *table, int write, { struct pid_namespace *pid_ns = task_active_pid_ns(current); struct ctl_table tmp = *table; + int ret, next; if (write && !ns_capable(pid_ns->user_ns, CAP_SYS_ADMIN)) return -EPERM; @@ -297,8 +298,18 @@ static int pid_ns_ctl_handler(struct ctl_table *table, int write, * it should synchronize its usage with external means. */ - tmp.data = &pid_ns->idr.idr_next; - return proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos); + next = idr_get_cursor(&pid_ns->idr) - 1; + + tmp.data = &next; + ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos); + if (ret < 0) + return ret; + + if (!write) + return 0; + + idr_set_cursor(&pid_ns->idr, next + 1); + return 0; } extern int pid_max; -- 2.13.6
On 11/03, Andrei Vagin wrote:
>
> @@ -297,8 +298,18 @@ static int pid_ns_ctl_handler(struct ctl_table *table, int write,
> * it should synchronize its usage with external means.
> */
>
> - tmp.data = &pid_ns->idr.idr_next;
> - return proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
> + next = idr_get_cursor(&pid_ns->idr) - 1;
> +
> + tmp.data = &next;
> + ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
> + if (ret < 0)
> + return ret;
> +
> + if (!write)
> + return 0;
> +
> + idr_set_cursor(&pid_ns->idr, next + 1);
> + return 0;
Ah yes, we should also take "write" into account, I forgot it is readable.
Can't resist, to me
err = proc_dointvec_minmax(...);
if (!err && write)
idr_set_cursor(...);
return err;
looks a bit more readable, but this is matter of taste of course.
Acked-by: Oleg Nesterov <oleg@redhat.com>
CRIU uses ns_last_pid to fork a process with a specified pid. For example, if we need to create a process with the pid of 10000, we write 9999 into /proc/sys/kernel/ns_last_pid $ echo 9999 > /proc/sys/kernel/ns_last_pid; sh -c 'echo $$' 10000 This behaviour has been broken and now if we write 9999 to ns_last_pid, a process will get the pid 9999. This patch restores the old behaviour. v2: make code a bit more readable // Oleg fixes: ("pid: replace pid bitmap implementation with IDR API") Cc: Gargi Sharma <gs051095@gmail.com> Cc: Oleg Nesterov <oleg@redhat.com> Acked-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Andrei Vagin <avagin@openvz.org> --- kernel/pid_namespace.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c index fea2c24fa460..0b53eef7d34b 100644 --- a/kernel/pid_namespace.c +++ b/kernel/pid_namespace.c @@ -287,6 +287,7 @@ static int pid_ns_ctl_handler(struct ctl_table *table, int write, { struct pid_namespace *pid_ns = task_active_pid_ns(current); struct ctl_table tmp = *table; + int ret, next; if (write && !ns_capable(pid_ns->user_ns, CAP_SYS_ADMIN)) return -EPERM; @@ -297,8 +298,14 @@ static int pid_ns_ctl_handler(struct ctl_table *table, int write, * it should synchronize its usage with external means. */ - tmp.data = &pid_ns->idr.idr_next; - return proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos); + next = idr_get_cursor(&pid_ns->idr) - 1; + + tmp.data = &next; + ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos); + if (!ret && write) + idr_set_cursor(&pid_ns->idr, next + 1); + + return ret; } extern int pid_max; -- 2.13.6