* Re: [PATCH 1/1] seccomp: release seccomp after killing terminate clone/fork
[not found] <20211228053421.26825-1-calvin.liao@gmail.com>
@ 2021-12-29 23:53 ` Andrew Morton
0 siblings, 0 replies; only message in thread
From: Andrew Morton @ 2021-12-29 23:53 UTC (permalink / raw)
To: Calvin Liao
Cc: Matthias Brugger, Eric W . Biederman, Peter Zijlstra,
Christian Brauner, Jens Axboe, Alexey Gladkov, Mike Christie,
David Hildenbrand, Rolf Eike Beer, linux-kernel,
linux-arm-kernel, linux-mediatek, wsd_upstream, calvin.liao,
Andrea Arcangeli
On Tue, 28 Dec 2021 13:34:21 +0800 Calvin Liao <calvin.liao@gmail.com> wrote:
> From: "calvin.liao" <calvin.liao@mediatek.com>
>
> Add to release seccomp after killing terminate clone/fork to avoid
> memory leak when enabling CONFIG_SECCOMP.
>
Help us out here - where was this filter allocated? Please describe
the code flow which led to this leak. Rather than simply saying "there
is a leak".
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1698,6 +1698,13 @@ static void copy_seccomp(struct task_struct *p)
> #endif
> }
>
> +static void release_seccomp(struct task_struct *p)
> +{
> +#ifdef CONFIG_SECCOMP
> + seccomp_filter_release(p);
> +#endif
ifdefs aren't needed?
> +}
> +
> SYSCALL_DEFINE1(set_tid_address, int __user *, tidptr)
> {
> current->clear_child_tid = tidptr;
> @@ -2405,6 +2412,7 @@ static __latent_entropy struct task_struct *copy_process(
> return p;
>
> bad_fork_cancel_cgroup:
> + release_seccomp(p);
Why not simply call seccomp_filter_release() here, without ifdefs?
> sched_core_free(p);
> spin_unlock(¤t->sighand->siglock);
> write_unlock_irq(&tasklist_lock);
^ permalink raw reply [flat|nested] only message in thread