On Wed, Jun 25, 2014 at 10:32 AM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote: > On 06/25, Andy Lutomirski wrote: >> >> Write the filter, then smp_mb (or maybe a weaker barrier is okay), >> then set the bit. > > Yes, exactly, this is what I meant. Plas rmb() in __secure_computing(). > > But I still can't understand the rest of your discussion about the > ordering we need ;) Let me try again from scratch. Currently there are three relevant variables: TIF_SECCOMP, seccomp.mode, and seccomp.filter. __secure_computing needs seccomp.mode and seccomp.filter to be in sync, and it wants (but doesn't really need) TIF_SECCOMP to be in sync as well. My suggestion is to rearrange it a bit. Move mode into seccomp.filter (so that filter == NULL implies no seccomp) and don't check TIF_SECCOMP in secure_computing. Then turning on seccomp is entirely atomic except for the fact that the seccomp hooks won't be called if filter != NULL but !TIF_SECCOMP. This removes all ordering requirements. Alternatively, __secure_computing could still BUG_ON(!seccomp.filter). In that case, filter needs to be set before TIF_SECCOMP is set, but that's straightforward. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
