Re: [PATCH v3] seccomp: Improve performace by optimizing rmb()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Feb 24, 2021, at 12:03 AM, wanghongzhe <wanghongzhe@xxxxxxxxxx> wrote:
> 
> As Kees haved accepted the v2 patch at a381b70a1 which just
> replaced rmb() with smp_rmb(), this patch will base on that and just adjust
> the smp_rmb() to the correct position.
> 
> As the original comment shown (and indeed it should be):
>   /*
>    * Make sure that any changes to mode from another thread have
>    * been seen after SYSCALL_WORK_SECCOMP was seen.
>    */
> the smp_rmb() should be put between reading SYSCALL_WORK_SECCOMP and reading
> seccomp.mode to make sure that any changes to mode from another thread have
> been seen after SYSCALL_WORK_SECCOMP was seen, for TSYNC situation. However,
> it is misplaced between reading seccomp.mode and seccomp->filter. This issue
> seems to be misintroduced at 13aa72f0fd0a9f98a41cefb662487269e2f1ad65 which
> aims to refactor the filter callback and the API. So let's just adjust the
> smp_rmb() to the correct position.
> 
> A next optimization patch will be provided if this ajustment is appropriate.

Would it be better to make the syscall work read be smp_load_acquire()?

> 
> v2 -> v3:
> - move the smp_rmb() to the correct position
> 
> v1 -> v2:
> - only replace rmb() with smp_rmb()
> - provide the performance test number
> 
> RFC -> v1:
> - replace rmb() with smp_rmb()
> - move the smp_rmb() logic to the middle between TIF_SECCOMP and mode
> 
> Signed-off-by: wanghongzhe <wanghongzhe@xxxxxxxxxx>
> ---
> kernel/seccomp.c | 15 +++++++--------
> 1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 1d60fc2c9987..64b236cb8a7f 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -1160,12 +1160,6 @@ static int __seccomp_filter(int this_syscall, const struct seccomp_data *sd,
>    int data;
>    struct seccomp_data sd_local;
> 
> -    /*
> -     * Make sure that any changes to mode from another thread have
> -     * been seen after SYSCALL_WORK_SECCOMP was seen.
> -     */
> -    smp_rmb();
> -
>    if (!sd) {
>        populate_seccomp_data(&sd_local);
>        sd = &sd_local;
> @@ -1291,7 +1285,6 @@ static int __seccomp_filter(int this_syscall, const struct seccomp_data *sd,
> 
> int __secure_computing(const struct seccomp_data *sd)
> {
> -    int mode = current->seccomp.mode;
>    int this_syscall;
> 
>    if (IS_ENABLED(CONFIG_CHECKPOINT_RESTORE) &&
> @@ -1301,7 +1294,13 @@ int __secure_computing(const struct seccomp_data *sd)
>    this_syscall = sd ? sd->nr :
>        syscall_get_nr(current, current_pt_regs());
> 
> -    switch (mode) {
> +    /* 
> +     * Make sure that any changes to mode from another thread have
> +     * been seen after SYSCALL_WORK_SECCOMP was seen.
> +     */
> +    smp_rmb();
> +
> +    switch (current->seccomp.mode) {
>    case SECCOMP_MODE_STRICT:
>        __secure_computing_strict(this_syscall);  /* may call do_exit */
>        return 0;
> -- 
> 2.19.1
> 




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux