* [RFC] Fix failure path in alloc_pid()
@ 2018-12-18 21:53 Matthew Wilcox
2018-12-19 9:28 ` Eric W. Biederman
2018-12-20 16:20 ` Oleg Nesterov
0 siblings, 2 replies; 3+ messages in thread
From: Matthew Wilcox @ 2018-12-18 21:53 UTC (permalink / raw)
To: Eric W. Biederman, Gargi Sharma, Rik van Riel, Oleg Nesterov; +Cc: linux-kernel
The failure path removes the allocated PIDs from the wrong namespace.
I believe this is correct, but have not tested it. Spotted by inspection,
do we have a test suite for PID namespaces? Some error injection,
perhaps?
Fixes: 95846ecf9dac ("pid: replace pid bitmap implementation with IDR API")
diff --git a/kernel/pid.c b/kernel/pid.c
index b2f6c506035da..75264e0d1e71d 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -233,8 +233,11 @@ struct pid *alloc_pid(struct pid_namespace *ns)
out_free:
spin_lock_irq(&pidmap_lock);
- while (++i <= ns->level)
- idr_remove(&ns->idr, (pid->numbers + i)->nr);
+ upid = pid->numbers + i;
+ while (++i <= ns->level) {
+ upid++;
+ idr_remove(&upid->ns->idr, upid->nr);
+ }
/* On failure to allocate the first pid, reset the state */
if (ns->pid_allocated == PIDNS_ADDING)
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [RFC] Fix failure path in alloc_pid()
2018-12-18 21:53 [RFC] Fix failure path in alloc_pid() Matthew Wilcox
@ 2018-12-19 9:28 ` Eric W. Biederman
2018-12-20 16:20 ` Oleg Nesterov
1 sibling, 0 replies; 3+ messages in thread
From: Eric W. Biederman @ 2018-12-19 9:28 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: Gargi Sharma, Rik van Riel, Oleg Nesterov, linux-kernel
Matthew Wilcox <willy@infradead.org> writes:
> The failure path removes the allocated PIDs from the wrong namespace.
> I believe this is correct, but have not tested it. Spotted by inspection,
> do we have a test suite for PID namespaces? Some error injection,
> perhaps?
>
> Fixes: 95846ecf9dac ("pid: replace pid bitmap implementation with IDR API")
>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
> diff --git a/kernel/pid.c b/kernel/pid.c
> index b2f6c506035da..75264e0d1e71d 100644
> --- a/kernel/pid.c
> +++ b/kernel/pid.c
> @@ -233,8 +233,11 @@ struct pid *alloc_pid(struct pid_namespace *ns)
>
> out_free:
> spin_lock_irq(&pidmap_lock);
> - while (++i <= ns->level)
> - idr_remove(&ns->idr, (pid->numbers + i)->nr);
> + upid = pid->numbers + i;
> + while (++i <= ns->level) {
> + upid++;
> + idr_remove(&upid->ns->idr, upid->nr);
> + }
>
> /* On failure to allocate the first pid, reset the state */
> if (ns->pid_allocated == PIDNS_ADDING)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] Fix failure path in alloc_pid()
2018-12-18 21:53 [RFC] Fix failure path in alloc_pid() Matthew Wilcox
2018-12-19 9:28 ` Eric W. Biederman
@ 2018-12-20 16:20 ` Oleg Nesterov
1 sibling, 0 replies; 3+ messages in thread
From: Oleg Nesterov @ 2018-12-20 16:20 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Eric W. Biederman, Gargi Sharma, Rik van Riel, linux-kernel
On 12/18, Matthew Wilcox wrote:
>
> --- a/kernel/pid.c
> +++ b/kernel/pid.c
> @@ -233,8 +233,11 @@ struct pid *alloc_pid(struct pid_namespace *ns)
>
> out_free:
> spin_lock_irq(&pidmap_lock);
> - while (++i <= ns->level)
> - idr_remove(&ns->idr, (pid->numbers + i)->nr);
> + upid = pid->numbers + i;
> + while (++i <= ns->level) {
> + upid++;
> + idr_remove(&upid->ns->idr, upid->nr);
can't resist...
while (++i <= ns->level) {
upid = pid->numbers + i;
idr_remove(&upid->ns->idr, upid->nr);
}
looks a bit more clean to me, but this is cosmetic and subjective.
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-12-20 16:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-18 21:53 [RFC] Fix failure path in alloc_pid() Matthew Wilcox
2018-12-19 9:28 ` Eric W. Biederman
2018-12-20 16:20 ` Oleg Nesterov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).