linux-kernel - Re: [PATCH 1/2] Really ignore kmem_cache

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

Message-ID: <20060828210312.GE20105@schatzie.adilger.int>
Date:	Mon, 28 Aug 2006 15:03:12 -0600
From:	Andreas Dilger <adilger@...sterfs.com>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 1/2] Really ignore kmem_cache_destroy return value

On Aug 26, 2006  01:20 +0400, Alexey Dobriyan wrote:
> * Rougly half of callers already do it by not checking return value
> * Those who check it printk something, however, slab_error already printed
>   the name of failed cache.
> * XFS BUGs on failed kmem_cache_destroy which is not the decision
>   low-level filesystem driver should make. Converted to ignore.

If you are changing this, then it is better to add the BUG() at destroy time
right now.  This makes it MUCH easier to track down the cause (i.e. when
there are slab items that failed to be released, instead of getting a BUG()
the next time someone tries to load that module and the slab already exists).

Just because a lot of code doesn't check the return value, doesn't mean
it shouldn't be possible to do so.  Consider if there is lots of code
that doesn't check the kmalloc() return value - just because it works
most of the time doesn't mean we should start removing the checks for
a failed kmalloc().

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
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/