[PATCH] sh: Do not pass SLAB_POISON to kmem_cache_create()

[PATCH] sh: Do not pass SLAB_POISON to kmem_cache_create()

[Matt Fleming]

SLAB_POISON is not a valid flag for kmem_create_cache() unless
CONFIG_DEBUG_SLAB is set, and can we ever know if it's set? Since no
drivers seem to use this flag just remove it from the flags argument.

Acked-by: Adrian McMenamin <adrian@newgolddream.dyndns.info>
Signed-off-by: Matt Fleming <mjf@gentoo.org>
---
 drivers/sh/maple/maple.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/sh/maple/maple.c b/drivers/sh/maple/maple.c
index d1812d3..63f0de2 100644
--- a/drivers/sh/maple/maple.c
+++ b/drivers/sh/maple/maple.c
@@ -827,7 +827,7 @@ static int __init maple_bus_init(void)
 
 	maple_queue_cache  	    kmem_cache_create("maple_queue_cache", 0x400, 0,
-			      SLAB_POISON|SLAB_HWCACHE_ALIGN, NULL);
+			      SLAB_HWCACHE_ALIGN, NULL);
 
 	if (!maple_queue_cache)
 		goto cleanup_bothirqs;
-- 
1.5.6.4

Re: [PATCH] sh: Do not pass SLAB_POISON to kmem_cache_create()

[Paul Mundt]

On Sun, Dec 14, 2008 at 05:09:16PM +0000, Matt Fleming wrote:
> SLAB_POISON is not a valid flag for kmem_create_cache() unless
> CONFIG_DEBUG_SLAB is set, and can we ever know if it's set? Since no
> drivers seem to use this flag just remove it from the flags argument.
> 
> Acked-by: Adrian McMenamin <adrian@newgolddream.dyndns.info>
> Signed-off-by: Matt Fleming <mjf@gentoo.org>

Applied, thanks. In the future, if your patch is tied to a fixed
subsystem, please denote that in the subject. ie, something like
'sh: maple: ...' so it is obvious where the problem is and what it does
and does not apply to. There is no need to punish the rest of the port
for the sins of the dreamcast.

Re: [PATCH] sh: Do not pass SLAB_POISON to kmem_cache_create()

[Matt Fleming]

On Tue, Dec 16, 2008 at 09:22:35AM +0900, Paul Mundt wrote:
> 
> Applied, thanks. In the future, if your patch is tied to a fixed
> subsystem, please denote that in the subject. ie, something like
> 'sh: maple: ...' so it is obvious where the problem is and what it does
> and does not apply to. There is no need to punish the rest of the port
> for the sins of the dreamcast.

Sorry, will do.