>> +/**>> + * prctl_set_seccomp: configures current->seccomp.mode>> + * @seccomp_mode: requested mode to use>> + * @filter: optional struct sock_fprog for use with SECCOMP_MODE_FILTER>> + *>> + * This function may be called repeatedly with a @seccomp_mode of>> + * SECCOMP_MODE_FILTER to install additional filters. Every filter>> + * successfully installed will be evaluated (in reverse order) for each system>> + * call the task makes.>> + *>> + * It is not possible to transition change the current->seccomp.mode after>> + * one has been set on a task.>> That reads awkwardly, do you mean the mode can't be changed once it's set?

Yup - I will fix that. It doesn't even make sense :)

> --->> Reviewed-by: Indan Zupancic <indan@nul.nu>

Thanks!

> All in all I'm quite happy with how the code is now, at least this bit.> I'm still unsure about the networking patch and the 32-bit BPF on 64-bit> archs mismatch.

Yeah - that is really the most challenging set of compromises, but Ithink they are the right ones.

> As for the unlimited filter count, I'm not sure how to fix that.> The problem is that filters are inherited and shared. Limiting the> list length (tree depth) helps a bit, then the total memory usage> is limited by max number of processes. It may make sense to limit> the total instruction count instead of the number of filters.

I'll take a stab at tree path size for starters and hopefully we canencourage consumers of the API to check for errors on return.