From patchwork Mon Mar 27 10:26:12 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tetsuo Handa X-Patchwork-Id: 9646425 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 30CCE602D6 for ; Mon, 27 Mar 2017 10:57:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1696F2780C for ; Mon, 27 Mar 2017 10:57:37 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0B4F0282ED; Mon, 27 Mar 2017 10:57:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 79C812780C for ; Mon, 27 Mar 2017 10:57:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751652AbdC0K5g (ORCPT ); Mon, 27 Mar 2017 06:57:36 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:28072 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751592AbdC0K5g (ORCPT ); Mon, 27 Mar 2017 06:57:36 -0400 Received: from fsav104.sakura.ne.jp (fsav104.sakura.ne.jp [27.133.134.231]) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id v2RAQC9p026510; Mon, 27 Mar 2017 19:26:12 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav104.sakura.ne.jp (F-Secure/fsigk_smtp/530/fsav104.sakura.ne.jp); Mon, 27 Mar 2017 19:26:12 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav104.sakura.ne.jp) Received: from AQUA (softbank126227147111.bbtec.net [126.227.147.111]) (authenticated bits=0) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id v2RAQBaC026506; Mon, 27 Mar 2017 19:26:12 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) To: linux-security-module@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH] smack: Use __GFP_NOFAIL than panic() From: Tetsuo Handa Message-Id: <201703271926.JJI69202.MJVQFSFLOFtOOH@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Mon, 27 Mar 2017 19:26:12 +0900 Mime-Version: 1.0 Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: X-Virus-Scanned: ClamAV using ClamSMTP >From dbdac6060ac1a741cb95f370121339bcc4176aea Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Mon, 27 Mar 2017 14:06:52 +0900 Subject: [RFC PATCH] smack: Use __GFP_NOFAIL than panic() smk_cipso_doi() is called by two locations; upon boot up and upon writing to /smack/doi interface. It is theoretically possible that kmalloc(GFP_KERNEL) for the latter fails due to being killed by the OOM killer or memory allocation fault injection. Although use of __GFP_NOFAIL is not recommended, is it tolerable to use __GFP_NOFAIL when adding a recovery path for unlikely failure is not worthwhile but allocation is single-shot and amount of memory to allocate is known to be small enough? Signed-off-by: Tetsuo Handa --- security/smack/smackfs.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c index 366b835..4e45a77 100644 --- a/security/smack/smackfs.c +++ b/security/smack/smackfs.c @@ -721,9 +721,7 @@ static void smk_cipso_doi(void) printk(KERN_WARNING "%s:%d remove rc = %d\n", __func__, __LINE__, rc); - doip = kmalloc(sizeof(struct cipso_v4_doi), GFP_KERNEL); - if (doip == NULL) - panic("smack: Failed to initialize cipso DOI.\n"); + doip = kmalloc(sizeof(struct cipso_v4_doi), GFP_KERNEL | __GFP_NOFAIL); doip->map.std = NULL; doip->doi = smk_cipso_doi_value; doip->type = CIPSO_V4_MAP_PASS;