> don't actually have to care --- if loading an invalid profile can bring down > the system, then that's no worse than an arbitrary module that crashes the > machine. Not sure if there will ever be user loadable profiles; at least at > that point we had to care. CAP_SYS_RAWIO is needed to do arbitary patching/loading in the capability model so if you are using lesser capabilities it is a (minor) capability rise but not a big problem, just ugly and wanting a fix > > > + /* > > > + * Replacement needs to allocate a new aa_task_context for each > > > + * task confined by old_profile. To do this the profile locks > > > + * are only held when the actual switch is done per task. While > > > + * looping to allocate a new aa_task_context the old_task list > > > + * may get shorter if tasks exit/change their profile but will > > > + * not get longer as new task will not use old_profile detecting > > > + * that is stale. > > > + */ > > > + do { > > > + new_cxt = aa_alloc_task_context(GFP_KERNEL | __GFP_NOFAIL); > > > > NOFAIL is usually a bad sign. It should be only used if there is no > > alternative. > > At this point there is no secure alternative to allocating a task context --- > except killing the task, maybe. Can you count the number needed, preallocate them and then when you know for sure either succeed or fail the operation as a whole ? - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html