On Mon, Aug 24, 2020 at 5:52 PM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > There seems to be no reason to use GFP_ATOMIC in these cases. > > Signed-off-by: Ondrej Mosnacek <omosnace@xxxxxxxxxx> > --- > security/selinux/hooks.c | 6 +++--- > security/selinux/ss/policydb.c | 10 +++++----- > 2 files changed, 8 insertions(+), 8 deletions(-) I found at least one more unjustified GFP_ATOMIC in services.c, so I'll probably respin this patch so it is all in one commit. I didn't bother looking at services.c at first, since most of the allocations there are bound to GFP_ATOMIC due to the policy read lock being held. -- Ondrej Mosnacek Software Engineer, Platform Security - SELinux kernel Red Hat, Inc.
