Re: stack overflow

Re: stack overflow

[Zeshan Ahmad]

Hi

I have figured out why the patch is'nt working. 

Mark wrote:
>In my original, the code assumes that all general
>purpose slabs below
>"bufctl_limit" where suitable for bufctl allocation 
>(look at a 2.2.x
>version, in kmem_cache_sizes_init() I have a state
>variable called
>"found").
  
Since I am already using 2.2.x, so the patch is not
working. This means i am already using the variable
"found".
So this will not work i presume.

Any other solution available?

Regards
Zeshan

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: stack overflow

[Mark Hemment]

Hi Zeshan,

  What version of 2.2.x are you using, and have you applied any patches it
to?
  I'm not subscribed to linux-mm at the moment, so I missed your original
posting.

Mark


On Tue, 5 Sep 2000, Zeshan Ahmad wrote:

> Hi
> 
> I have figured out why the patch is'nt working. 
> 
> Mark wrote:
> >In my original, the code assumes that all general
> >purpose slabs below
> >"bufctl_limit" where suitable for bufctl allocation 
> >(look at a 2.2.x
> >version, in kmem_cache_sizes_init() I have a state
> >variable called
> >"found").
>   
> Since I am already using 2.2.x, so the patch is not
> working. This means i am already using the variable
> "found".
> So this will not work i presume.
> 
> Any other solution available?
> 
> Regards
> Zeshan
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Mail - Free email you can access from anywhere!
> http://mail.yahoo.com/
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: stack overflow

[Zeshan Ahmad]

[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]

Thanx for ur reply in considering my problem. I am
using Kernel version 2.2.14

I have attached the portion of mm/slab.c containing
the function kmem_cache_sizes_init from the kernel
code i am using with this mail. Plz have a look at it
and recommend me any changes.

Also plz suggest any good readings about "slab
allocator" on the net.

Thanx for ur support. Help is badly needed.
Anxiously waiting for ur reply.

Regards
ZESHAN
--- Mark Hemment <markhe@veritas.com> wrote:
> Hi Zeshan,
> 
>   What version of 2.2.x are you using, and have you
> applied any patches it
> to?
>   I'm not subscribed to linux-mm at the moment, so I
> missed your original
> posting.
> 
> Mark
> 
> 
> On Tue, 5 Sep 2000, Zeshan Ahmad wrote:
> 
> > Hi
> > 
> > I have figured out why the patch is'nt working. 
> > 
> > Mark wrote:
> > >In my original, the code assumes that all general
> > >purpose slabs below
> > >"bufctl_limit" where suitable for bufctl
> allocation 
> > >(look at a 2.2.x
> > >version, in kmem_cache_sizes_init() I have a
> state
> > >variable called
> > >"found").
> >   
> > Since I am already using 2.2.x, so the patch is
> not
> > working. This means i am already using the
> variable
> > "found".
> > So this will not work i presume.
> > 
> > Any other solution available?
> > 
> > Regards
> > Zeshan
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Mail - Free email you can access from
> anywhere!
> > http://mail.yahoo.com/
> > 
> 
> --
> To unsubscribe, send a message with 'unsubscribe
> linux-mm' in
> the body to majordomo@kvack.org.  For more info on
> Linux MM,
> see: http://www.linux.eu.org/Linux-MM/


__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

[-- Attachment #2: kmem_cache_sizes_init.txt --]
[-- Type: text/plain, Size: 1191 bytes --]

void __init kmem_cache_sizes_init(void)
{
	unsigned int	found = 0;

	cache_slabp = kmem_cache_create("slab_cache", sizeof(kmem_slab_t),
					0, SLAB_HWCACHE_ALIGN, NULL, NULL);

        if (cache_slabp) {
		char **names = cache_sizes_name;
		cache_sizes_t *sizes = cache_sizes;
		do {
			/* For performance, all the general caches are L1 aligned.
			 * This should be particularly beneficial on SMP boxes, as it
			 * eliminates "false sharing".
			 * Note for systems short on memory removing the alignment will
			 * allow tighter packing of the smaller caches. */
			if (!(sizes->cs_cachep =
			      kmem_cache_create(*names++, sizes->cs_size,
						0, SLAB_HWCACHE_ALIGN, NULL, NULL)))
				goto panic_time;
			if (!found) {
				/* Inc off-slab bufctl limit until the ceiling is hit. */
				if (SLAB_BUFCTL(sizes->cs_cachep->c_flags))
					found++;
				else
					bufctl_limit =
						(sizes->cs_size/sizeof(kmem_bufctl_t));
			}
			sizes->cs_cachep->c_flags |= SLAB_CFLGS_GENERAL;
			sizes++;
		} while (sizes->cs_size);
#if	SLAB_SELFTEST
		kmem_self_test();
#endif	/* SLAB_SELFTEST */
		return;
	}
panic_time:
	panic("kmem_cache_sizes_init: Error creating caches");
	/* NOTREACHED */
}

stack overflow

[Zeshan Ahmad]

Hi

Can any1 tell me how can the stack size be changed in
the Kernel. i am experiencing a stack overflow problem
when the function kmem_cache_sizes_init is called in
/init/main.c The exact place where the stack overflow
occurs is in the function kmem_cache_slabmgmt in
/mm/slab.c

Is there any way to change the stack size in Kernel?
Can the change in stack size simply solve this Kernel
stack overflow problem?

Urgent help is needed.

ZEESHAN

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: stack overflow

[Matti Aarnio]

On Mon, Sep 04, 2000 at 03:47:44AM -0700, Zeshan Ahmad wrote:
> Hi
> 
> Can any1 tell me how can the stack size be changed in
> the Kernel. i am experiencing a stack overflow problem

	In kernel ?  DON'T!

> when the function kmem_cache_sizes_init is called in
> /init/main.c The exact place where the stack overflow
> occurs is in the function kmem_cache_slabmgmt in
> /mm/slab.c
> 
> Is there any way to change the stack size in Kernel?
> Can the change in stack size simply solve this Kernel
> stack overflow problem?

	That is indicative that somewhere along the path
	you are:  a) recursin, b) otherwise wasting stack
	with too large local allocations (e.g. "auto"
	variables).

	In the kernel space: NEVER use stack-based buffers,
	always  kmalloc().  (If they are more than 8-16 bytes
	in size, that is.)  Similarly, NEVER use alloca() !

> Urgent help is needed.
> 
> ZEESHAN

/Matti Aarnio
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: stack overflow

[Tigran Aivazian]

On Mon, 4 Sep 2000, Matti Aarnio wrote:
> > when the function kmem_cache_sizes_init is called in
> > /init/main.c The exact place where the stack overflow
> > occurs is in the function kmem_cache_slabmgmt in
> > /mm/slab.c
> > 
> > Is there any way to change the stack size in Kernel?
> > Can the change in stack size simply solve this Kernel
> > stack overflow problem?
> 
> 	That is indicative that somewhere along the path
> 	you are:  a) recursin

looking at the code, it seems in theory possible to recurse via
kmem_cache_alloc()->kmem_cache_grow()->kmem_cache_slabmgmt()->kmem_cache_alloc() but
I thought Mark invented offslab_limit to prevent this.

Maybe decreasing offslab_limit can help? Defer to Mark...

Regards,
Tigran

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: stack overflow

[Mark Hemment]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1525 bytes --]

Hi,

  A quick look indicates what could be the problem.
  In my original, the code assumes that all general purpose slabs below
"bufctl_limit" where suitable for bufctl allocation (look at a 2.2.x
version, in kmem_cache_sizes_init() I have a state variable called
"found").
  The modified code (by who?), which now uses "offslab_limit", removes
the assumption, which could very well be causing the stack overflow; the
code now breaks the comment "Inc off-slab bufctl limit until the ceiling
is hit" as it has no ceiling.
  Bringing back the state variable will close at least one door.

  I've attached a completely untested (and uncompiled) patch.

  If this doesn't fix it, I'll look deeper.

Mark



On Mon, 4 Sep 2000, Tigran Aivazian wrote:

> On Mon, 4 Sep 2000, Matti Aarnio wrote:
> > > when the function kmem_cache_sizes_init is called in
> > > /init/main.c The exact place where the stack overflow
> > > occurs is in the function kmem_cache_slabmgmt in
> > > /mm/slab.c
> > > 
> > > Is there any way to change the stack size in Kernel?
> > > Can the change in stack size simply solve this Kernel
> > > stack overflow problem?
> > 
> > 	That is indicative that somewhere along the path
> > 	you are:  a) recursin
> 
> looking at the code, it seems in theory possible to recurse via
> kmem_cache_alloc()->kmem_cache_grow()->kmem_cache_slabmgmt()->kmem_cache_alloc() but
> I thought Mark invented offslab_limit to prevent this.
> 
> Maybe decreasing offslab_limit can help? Defer to Mark...
> 
> Regards,
> Tigran
> 

[-- Attachment #2: slab.patch --]
[-- Type: TEXT/PLAIN, Size: 1152 bytes --]

--- slab.c.00	Tue Sep  5 12:49:16 2000
+++ slab.c	Tue Sep  5 12:51:36 2000
@@ -424,14 +424,17 @@
  */
 void __init kmem_cache_sizes_init(void)
 {
+	unsigned int	limit_found;
 	cache_sizes_t *sizes = cache_sizes;
 	char name[20];
+
 	/*
 	 * Fragmentation resistance on low memory - only use bigger
 	 * page orders on machines with more than 32MB of memory.
 	 */
 	if (num_physpages > (32 << 20) >> PAGE_SHIFT)
 		slab_break_gfp_order = BREAK_GFP_ORDER_HI;
+	limit_found = 0;
 	do {
 		/* For performance, all the general caches are L1 aligned.
 		 * This should be particularly beneficial on SMP boxes, as it
@@ -446,9 +449,12 @@
 		}
 
 		/* Inc off-slab bufctl limit until the ceiling is hit. */
-		if (!(OFF_SLAB(sizes->cs_cachep))) {
-			offslab_limit = sizes->cs_size-sizeof(slab_t);
-			offslab_limit /= 2;
+		if (limit_found == 0) {
+			if (!(OFF_SLAB(sizes->cs_cachep))) {
+				offslab_limit = sizes->cs_size-sizeof(slab_t);
+				offslab_limit /= 2;
+			} else
+				limit_found = 1;
 		}
 		sprintf(name, "size-%Zd(DMA)",sizes->cs_size);
 		sizes->cs_dmacachep = kmem_cache_create(name, sizes->cs_size, 0,