netdev - Re: [PATCH 1/4][MAC80211]: Fix GFP_KERNEL allocation under read lock.

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080506.225950.181623233.davem@davemloft.net>
Date:	Tue, 06 May 2008 22:59:50 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	xemul@...nvz.org
Cc:	johannes@...solutions.net, netdev@...eo.de, linville@...driver.com,
	linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 1/4][MAC80211]: Fix GFP_KERNEL allocation under read
 lock.

From: Pavel Emelyanov <xemul@...nvz.org>
Date: Wed, 07 May 2008 09:54:53 +0400

> David Miller wrote:
> > The whole reason we made kfree allow NULL points is so that
> > checks for it would be ommitted at kfree calls sides, whether
> > they be direct or indirect.
> 
> Hm... I really thought that this check in kfree is just for sanity 
> against some 3rd part code. But why kmem_cache_free() is not such then?

That's not what the check was added for.

If you look in the history, there are lots of changes that
are of the form "don't check for NULL, kfree() does that"
and it decreases kernel text size.  That was why the check
was added to kfree(), so we could do that.

There have been some discussions about kmem_cache_free() NULL
checks, but that tends to keep getting stalled in the mud
for whatever reason.

Whether you should resubmit your patch is up to the wireless
folks :-)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html