On 7/2/13 10:12 PM, Andrew Morton wrote:
On Tue, 2 Jul 2013 21:49:26 +0900 Tetsuo Handa
wrote:
Some architectures (e.g. powerpc built with CONFIG_PPC_256K_PAGES=y
CONFIG_FORCE_MAX_ZONEORDER=11) get PAGE_SHIFT + MAX_ORDER > 26.
In 3.10 kernels, CONFIG_LOCKDEP=y with PAGE_SHIFT + MAX_ORDER > 2
On Tue, 2 Jul 2013 21:49:26 +0900 Tetsuo Handa
wrote:
> Some architectures (e.g. powerpc built with CONFIG_PPC_256K_PAGES=y
> CONFIG_FORCE_MAX_ZONEORDER=11) get PAGE_SHIFT + MAX_ORDER > 26.
>
> In 3.10 kernels, CONFIG_LOCKDEP=y with PAGE_SHIFT + MAX_ORDER > 26 makes
> init_lock_keys() dereferen
Andrew Morton wrote:
> Look, I'll make this easier:
>
> : Subject: slab: fix init_lock_keys
> :
> : In 3.10 kernels with CONFIG_LOCKDEP=y on architectures with
> : PAGE_SHIFT + MAX_ORDER > 26 such as [architecture goes here], the kernel
> does
> : [x] when the user does [y].
> :
> : init_lock_ke
On Tue, 2 Jul 2013 06:45:27 +0900 Tetsuo Handa
wrote:
>
> > I've read through the thread trying to work out what the end-user
> > impact of that fix is, but it's all clear as mud. It's possible that
> > the end-user effect is `kernel locks up after printing "Booting the
> > kernel"'. Or maybe
Andrew Morton wrote:
> On Tue, 7 May 2013 14:28:49 + Christoph Lameter wrote:
>
> > On Tue, 7 May 2013, Tetsuo Handa wrote:
> >
> > > > These are exclusively from the module load. So the kernel seems to be
> > > > clean of large kmalloc's ?
> > > >
> > > There are modules (e.g. TOMOYO) which
On Tue, 7 May 2013 14:28:49 + Christoph Lameter wrote:
> On Tue, 7 May 2013, Tetsuo Handa wrote:
>
> > > These are exclusively from the module load. So the kernel seems to be
> > > clean of large kmalloc's ?
> > >
> > There are modules (e.g. TOMOYO) which do not check for KMALLOC_MAX_SIZE
>
Tetsuo Handa wrote:
> Christoph Lameter wrote:
> > Subject: SLAB: Fix init_lock_keys
> >
> > init_lock_keys goes too far in initializing values in kmalloc_caches because
> > it assumed that the size of the kmalloc array goes up to MAX_ORDER.
> > However, the size
> > of the kmalloc array for SLAB
On Fri, 10 May 2013, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
> > Can we manage with allocating only 26 elements when MAX_ORDER + PAGE_SHIFT
> > > 26
> > (e.g. PAGE_SIZE == 256 * 1024) ?
> >
> > Can kmalloc_index()/kmalloc_size()/kmalloc_slab() etc. work correctly when
> > MAX_ORDER + PAGE_SHIFT
Tetsuo Handa wrote:
> Can we manage with allocating only 26 elements when MAX_ORDER + PAGE_SHIFT >
> 26
> (e.g. PAGE_SIZE == 256 * 1024) ?
>
> Can kmalloc_index()/kmalloc_size()/kmalloc_slab() etc. work correctly when
> MAX_ORDER + PAGE_SHIFT > 26 (e.g. PAGE_SIZE == 256 * 1024) ?
>
Today I compa
Christoph Lameter wrote:
> - for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) {
> + for (i = 1; i =< KMALLOC_SHIFT_HIGH; i++) {
mm/slab.c: In function 'init_node_lock_keys':
mm/slab.c:568:17: error: expected expression before '<' token
What I'm worrying is:
/*
* The largest kmalloc
On Thu, 9 May 2013, Tetsuo Handa wrote:
> + BUILD_BUG_ON(PAGE_SHIFT + MAX_ORDER != KMALLOC_SHIFT_HIGH + 1);
> for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) {
Yea looping to PAGE_SHIFT + MAX_ORDER is fundamentally wrong.
Subject: SLAB: Fix init_lock_keys()
init_lock_keys goes too f
Tetsuo Handa wrote:
> > Christoph Lameter wrote:
> > > What is MAX_ORDER on the architecture?
> >
> > In my environment (x86_32), the constants are
> >
> > MAX_ORDER=11 PAGE_SHIFT=12 KMALLOC_SHIFT_HIGH=22 KMALLOC_MAX_SIZE=4194304
> >
>
> I don't know if any, but on an architecture with PAGE_S
On Tue, 7 May 2013, Pekka Enberg wrote:
> On Tue, May 7, 2013 at 5:23 PM, Christoph Lameter wrote:
> > Well this is because you did not take the patch that changed the way
> > KMALLOC_SHIFT_HIGH is treated.
>
> Is that still needed? I only took the ones Tetsuo said were needed to
> fix the issue
On Tue, May 7, 2013 at 5:23 PM, Christoph Lameter wrote:
> Well this is because you did not take the patch that changed the way
> KMALLOC_SHIFT_HIGH is treated.
Is that still needed? I only took the ones Tetsuo said were needed to
fix the issue at hand.
Pekka
--
To unsubs
On Mon, 6 May 2013, Pekka Enberg wrote:
> On Fri, May 3, 2013 at 9:04 PM, Christoph Lameter wrote:
> > - for (i = KMALLOC_SHIFT_LOW; i < KMALLOC_SHIFT_HIGH; i++)
>
> This didn't match what I had in my tree. I fixed it by hand but please
> verify the end result:
>
> https://git.kernel.org/cg
On Tue, 7 May 2013, Tetsuo Handa wrote:
> > These are exclusively from the module load. So the kernel seems to be
> > clean of large kmalloc's ?
> >
> There are modules (e.g. TOMOYO) which do not check for KMALLOC_MAX_SIZE limit
> and expect kmalloc() larger than KMALLOC_MAX_SIZE bytes to return N
Christoph Lameter wrote:
> On Sat, 4 May 2013, Tetsuo Handa wrote:
>
> > Christoph Lameter wrote:
> > > Ok could I see the kernel logs with the warnings?
> > Sure.
>
> These are exclusively from the module load. So the kernel seems to be
> clean of large kmalloc's ?
>
There are modules (e.g. TOM
On Fri, May 3, 2013 at 9:04 PM, Christoph Lameter wrote:
> - for (i = KMALLOC_SHIFT_LOW; i < KMALLOC_SHIFT_HIGH; i++)
This didn't match what I had in my tree. I fixed it by hand but please
verify the end result:
https://git.kernel.org/cgit/linux/kernel/git/penberg/linux.git/commit/?h=slab/
On Mon, 6 May 2013, Pekka Enberg wrote:
> This doesn't seem to apply against slab/next branch. What tree did you
> use to generate the patch?
Slab/next from a couple of weeks ago.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vge
On Sat, 4 May 2013, Tetsuo Handa wrote:
> Christoph Lameter wrote:
> > Ok could I see the kernel logs with the warnings?
> Sure.
These are exclusively from the module load. So the kernel seems to be
clean of large kmalloc's ?
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
On Mon, May 6, 2013 at 9:59 AM, Geert Uytterhoeven wrote:
> On Fri, May 3, 2013 at 5:43 PM, Christoph Lameter wrote:
>> Subject: slab: Return NULL for oversized allocations
>>
>> The inline path seems to have changed the SLAB behavior for very large
>> kmalloc allocations. This patch restores the
On Fri, May 3, 2013 at 5:43 PM, Christoph Lameter wrote:
> Subject: slab: Return NULL for oversized allocations
>
> The inline path seems to have changed the SLAB behavior for very large
> kmalloc allocations. This patch restores the old behavior but also
> adds diagnostics so that we can figure w
On Fri, May 3, 2013 at 9:04 PM, Christoph Lameter wrote:
> Enabling various debugging options increases the size of structures and
> the subslab handling in SLABs kmem_cache_create will start to fail.
>
>
> Here is a fix for that:
>
> Subject: Fix bootstrap creation of kmalloc caches
>
> For SLAB
Christoph Lameter wrote:
> Ok could I see the kernel logs with the warnings?
Sure.
-- testcase --
volatile unsigned int size;
for (size = 4 * 1024 * 1024; size <= 32 * 1024 * 1024; size <<= 1) {
void *ptr = kmalloc(size, GFP_KERNEL);
printk("kmalloc(%u)=%p\n", size,
On Sat, 4 May 2013, Tetsuo Handa wrote:
> Subject: slab: Return NULL for oversized allocations
> (Date: Fri, 3 May 2013 15:43:18 +)
>
> and
>
> Subject: Fix bootstrap creation of kmalloc caches
> (Date: Fri, 3 May 2013 18:04:18 +)
>
> on linux-next-20130426 made my kernel boots fin
Applying
Subject: slab: Return NULL for oversized allocations
(Date: Fri, 3 May 2013 15:43:18 +)
and
Subject: Fix bootstrap creation of kmalloc caches
(Date: Fri, 3 May 2013 18:04:18 +)
on linux-next-20130426 made my kernel boots fine and passes the allocation
testcases. Thank y
Enabling various debugging options increases the size of structures and
the subslab handling in SLABs kmem_cache_create will start to fail.
Here is a fix for that:
Subject: Fix bootstrap creation of kmalloc caches
For SLAB the kmalloc caches must be created in ascending sizes
in order for the O
On Fri, 3 May 2013, Tetsuo Handa wrote:
> I don't think this patch is sufficient. There are functions (e.g. kstrdup())
> which call variant functions (e.g. kmalloc_track_caller()). I think we need to
> check size at functions which determine index from size (e.g. kmalloc_slab()).
Right.
> > Inde
Christoph Lameter wrote:
> I have booted such a configuration just fine. Please have a look at the
> kernel config that I send or send me yours.
OK. Here are complete steps to reproduce using QEMU on CentOS 6.4.
(1) Compile the kernel for x86_32 and run it on QEMU.
$ cd /tmp/
$ wget -O -
ht
On Wed, 1 May 2013, Tetsuo Handa wrote:
> The culprit location is possibly in SLAB because the kernel boots if built
> with
> CONFIG_DEBUG_SLAB=n || CONFIG_DEBUG_SPINLOCK=n || CONFIG_DEBUG_PAGEALLOC=n.
I have booted such a configuration just fine. Please have a look at the
kernel config that I s
On Wed, 1 May 2013, Pekka Enberg wrote:
> Why is that? Historically it has returned NULL, hasn't it? We have
had cases
> where kernel code (naively) uses size directly from userspace and we
> definitely don't want to BUG_ON on it.
In that case the size is dynamic and then we return an er
On Wed, 1 May 2013, Pekka Enberg wrote:
> > This behavior has been in there for years. Why try a kmalloc that
> > always fails since the size is too big?
>
> ...because want the extra protection for cases where size is controlled by
> userspace. This is consistent with kcalloc() that returns NULL
Tetsuo Handa wrote:
> > Hmm... Where does this fail? In slab?
> >
> It hangs (with CPU#0 spinning) immediately after printing
>
> Decompressing Linux... Parsing ELF... done.
> Booting the kernel.
>
> lines. Today I heard that gdb can be used if I use qemu, but I doubt that I
> can
> manage
Christoph Lameter wrote:
> > "kmalloc() returning NULL for these allocations" is needed by "try kmalloc()
> > first, fallback to vmalloc()" allocation. There are kernel modules which
> > expect
> > kmalloc() to return NULL rather than oops when the requested size is larger
> > than KMALLOC_MAX_SIZ
On 4/30/13 8:27 PM, Christoph Lameter wrote:
"kmalloc() returning NULL for these allocations" is needed by "try kmalloc()
first, fallback to vmalloc()" allocation. There are kernel modules which expect
kmalloc() to return NULL rather than oops when the requested size is larger
than KMALLOC_MAX_SI
On 4/30/13 5:34 PM, Christoph Lameter wrote:
On Tue, 30 Apr 2013, Tetsuo Handa wrote:
Current diff is:
[off by one stuff okay]
diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h
index 113ec08..be1446a 100644
--- a/include/linux/slab_def.h
+++ b/include/linux/slab_def.h
@@ -126
On Wed, 1 May 2013, Tetsuo Handa wrote:
> Christoph Lameter wrote:
> > On Tue, 30 Apr 2013, Tetsuo Handa wrote:
> >
> > > The testcases still trigger BUG() at 32M:
> >
> > I thought we established that MAX_ORDER only allows a maximum of 8M sized
> > allocations? Why are you trying 32M?
>
> Only f
Christoph Lameter wrote:
> On Tue, 30 Apr 2013, Tetsuo Handa wrote:
>
> > The testcases still trigger BUG() at 32M:
>
> I thought we established that MAX_ORDER only allows a maximum of 8M sized
> allocations? Why are you trying 32M?
Only for regression testing. At least until Linux 3.9, requesti
On Tue, 30 Apr 2013, Tetsuo Handa wrote:
> Current diff is:
[off by one stuff okay]
> diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h
> index 113ec08..be1446a 100644
> --- a/include/linux/slab_def.h
> +++ b/include/linux/slab_def.h
> @@ -126,6 +126,9 @@ static __always_inline vo
On Tue, 30 Apr 2013, Tetsuo Handa wrote:
> The testcases still trigger BUG() at 32M:
I thought we established that MAX_ORDER only allows a maximum of 8M sized
allocations? Why are you trying 32M?
The BUG() should trigger for these allocations.
--
To unsubscribe from this list: send the line "un
Christoph Lameter wrote:
> Ok so the maximum allocation is 11+12=23 which is 8M. KMALLOC_MAX_SIZE
> amd KMALLOC_SHIFT_HIGH are wrong.
>
> Take the -1 off the constants under #ifdef CONFIG_SLAB in
Current diff is:
-- patch start --
diff --git a/include/linux/slab.h b/include/linux
On Tue, 30 Apr 2013, Tetsuo Handa wrote:
> Glauber Costa wrote:
> > If I am right, the following (untested) patch should solve the problem.
>
> This patch did not help;
>
> kmalloc(8 * 1024 * 1024, GFP_KERNEL)
>
> still causes both
>
> include/linux/slab_def.h:136: warning: array subscript is
Tetsuo Handa wrote:
> Glauber Costa wrote:
> > If I am right, the following (untested) patch should solve the problem.
>
> This patch did not help;
>
> kmalloc(8 * 1024 * 1024, GFP_KERNEL)
>
> still causes both
>
> include/linux/slab_def.h:136: warning: array subscript is above array bounds
On 04/29/2013 07:46 PM, Christoph Lameter wrote:
> On Mon, 29 Apr 2013, Glauber Costa wrote:
>
>> On 04/29/2013 06:59 PM, Christoph Lameter wrote:
>>> The code in kmalloc_index() creates a BUG() and preferentially should
>>> create a compile time failure when a number that is too big is passed to
On Mon, 29 Apr 2013, Glauber Costa wrote:
> On 04/29/2013 06:59 PM, Christoph Lameter wrote:
> > The code in kmalloc_index() creates a BUG() and preferentially should
> > create a compile time failure when a number that is too big is passed to it.
> >
> > What is MAX_ORDER on the architecture?
>
>
Glauber Costa wrote:
> If I am right, the following (untested) patch should solve the problem.
This patch did not help;
kmalloc(8 * 1024 * 1024, GFP_KERNEL)
still causes both
include/linux/slab_def.h:136: warning: array subscript is above array bounds
and
BUG: unable to handle kernel NU
On 04/29/2013 06:59 PM, Christoph Lameter wrote:
> The code in kmalloc_index() creates a BUG() and preferentially should
> create a compile time failure when a number that is too big is passed to it.
>
> What is MAX_ORDER on the architecture?
Returning NULL is fine, but kmalloc_index currently do
On Mon, 29 Apr 2013, Glauber Costa wrote:
> >> causes no warning at compile time and returns NULL at runtime. But
> >>
> >> unsigned int size = 8 * 1024 * 1024;
> >> kmalloc(size, GFP_KERNEL);
> >>
> >> causes compile time warning
> >>
> >> include/linux/slab_def.h:136: warning: array subscr
On 04/29/2013 02:12 PM, Pekka Enberg wrote:
> On Mon, Apr 29, 2013 at 5:40 AM, Tetsuo Handa
> wrote:
>> Tetsuo Handa wrote:
>>> Also, kmalloc_index() in include/linux/slab.h can return 0 to 26.
>>>
>>> If (MAX_ORDER + PAGE_SHIFT - 1) > 25 is true and
>>> kmalloc_index(64 * 1024 * 1024) is requeste
On Mon, Apr 29, 2013 at 5:40 AM, Tetsuo Handa
wrote:
> Tetsuo Handa wrote:
>> Also, kmalloc_index() in include/linux/slab.h can return 0 to 26.
>>
>> If (MAX_ORDER + PAGE_SHIFT - 1) > 25 is true and
>> kmalloc_index(64 * 1024 * 1024) is requested (I don't know whether such case
>> happens), kmallo
On Thu, Apr 25, 2013 at 8:20 PM, Tetsuo Handa
wrote:
> Bisection (with a build fix from commit db845067 "slab: Fixup
> CONFIG_PAGE_ALLOC/DEBUG_SLAB_LEAK sections") reached commit e3366016
> "slab: Use common kmalloc_index/kmalloc_size functions".
> Would you have a look at commit e3366016?
Cc:
Tetsuo Handa wrote:
> Also, kmalloc_index() in include/linux/slab.h can return 0 to 26.
>
> If (MAX_ORDER + PAGE_SHIFT - 1) > 25 is true and
> kmalloc_index(64 * 1024 * 1024) is requested (I don't know whether such case
> happens), kmalloc_caches[26] is beyond the array, for kmalloc_caches[26]
> a
Tetsuo Handa wrote:
> Hello.
>
> linux-next-20130422 does not boot when built with CONFIG_DEBUG_SLAB=y &&
> CONFIG_DEBUG_SPINLOCK=y && CONFIG_DEBUG_PAGEALLOC=y .
>
> It hangs (with CPU#0 spinning) immediately after printing
>
> Decompressing Linux... Parsing ELF... done.
> Booting the kernel
53 matches
Mail list logo
