linux-kernel - [PATCH] GFP_KERNEL malloc with lock held in net/wireless/mwifiex

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <1312495562.2629.53.camel@localhost.localdomain>
Date:	Fri, 05 Aug 2011 00:05:58 +0200
From:	Thomas Meyer <thomas@...3r.de>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	kernel-janitors@...r.kernel.org
Subject: [PATCH] GFP_KERNEL malloc with lock held in net/wireless/mwifiex

From: Thomas Meyer <thomas@...3r.de>

 Find functions that refer to GFP_KERNEL but are called with locks held.
 The proposed change of converting the GFP_KERNEL is not necessarily the
 correct one.  It may be desired to unlock the lock, or to not call the
 function under the lock in the first place.

 The semantic patch that makes this output is available
 in scripts/coccinelle/locks/call_kern.cocci.

 More information about semantic patching is available at
 http://coccinelle.lip6.fr/

Signed-off-by: Thomas Meyer <thomas@...3r.de>
---
the function mwifiex_save_curr_bcn() is guarded by:

 spin_lock_irqsave(&priv->curr_bcn_buf_lock, flags);
 mwifiex_save_curr_bcn(priv);
 spin_unlock_irqrestore(&priv->curr_bcn_buf_lock, flags);

Is it okay to allocate memory with a spin lock held and interrupts
disabled in this case?

diff -u -p a/drivers/net/wireless/mwifiex/scan.c b/drivers/net/wireless/mwifiex/scan.c
--- a/drivers/net/wireless/mwifiex/scan.c 2011-07-26 00:46:08.483511656 +0200
+++ b/drivers/net/wireless/mwifiex/scan.c 2011-08-02 09:36:50.174808818 +0200
@@ -2998,7 +2998,7 @@ mwifiex_save_curr_bcn(struct mwifiex_pri
 
 		kfree(priv->curr_bcn_buf);
 		priv->curr_bcn_buf = kzalloc(curr_bss->beacon_buf_size,
-						GFP_KERNEL);
+						GFP_ATOMIC);
 		if (!priv->curr_bcn_buf) {
 			dev_err(priv->adapter->dev,
 					"failed to alloc curr_bcn_buf\n");


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/