On Mon, 2012-07-30 at 13:18 +0300, Pekka Enberg wrote:
> On Sat, Jul 14, 2012 at 2:12 AM, Shuah Khan wrote:
> > The label oops is used in CONFIG_DEBUG_VM ifdef block and is defined
> > outside ifdef CONFIG_DEBUG_VM block. This results in the following
> > build warning when built with CONFIG_DEBUG
On Mon, 30 Jul 2012, David Rientjes wrote:
> So much for compromise, I thought we had agreed that at least some of the
> checks for !name, in_interrupt() or bad size values should be moved out
> from under the #ifdef CONFIG_DEBUG_VM, but this wasn't done. This
> discussion would be irrelevent i
On Mon, 30 Jul 2012, Pekka Enberg wrote:
> > -Wunused-label is overridden in gcc for a label that is conditionally
> > referenced by using __maybe_unused in the kernel. I'm not sure what's so
> > obscure about
> >
> > out: __maybe_unused
> >
> > Are label attributes really that obsecure?
>
> I t
On Mon, Jul 30, 2012 at 10:56 PM, David Rientjes wrote:
> -Wunused-label is overridden in gcc for a label that is conditionally
> referenced by using __maybe_unused in the kernel. I'm not sure what's so
> obscure about
>
> out: __maybe_unused
>
> Are label attributes really that obsecure?
I thin
On Mon, 30 Jul 2012, Pekka Enberg wrote:
> > The label oops is used in CONFIG_DEBUG_VM ifdef block and is defined
> > outside ifdef CONFIG_DEBUG_VM block. This results in the following
> > build warning when built with CONFIG_DEBUG_VM disabled. Fix to move
> > label oops definition to inside a CON
On Sat, Jul 14, 2012 at 2:12 AM, Shuah Khan wrote:
> The label oops is used in CONFIG_DEBUG_VM ifdef block and is defined
> outside ifdef CONFIG_DEBUG_VM block. This results in the following
> build warning when built with CONFIG_DEBUG_VM disabled. Fix to move
> label oops definition to inside a C
On Mon, 23 Jul 2012, Glauber Costa wrote:
> >> worth including unconditionally. Furthermore, the size related checks
> >> certainly make sense and I don't see any harm in having them as well.
> >
> > There is a WARN_ON() there and then it returns NULL!!! Crazy. Causes a
> > NULL pointer dereferenc
On 07/17/2012 07:11 PM, Christoph Lameter wrote:
> On Tue, 17 Jul 2012, Pekka Enberg wrote:
>
>> Well, even SLUB checks for !name in mainline so that's definitely
>> worth including unconditionally. Furthermore, the size related checks
>> certainly make sense and I don't see any harm in having the
On Tue, 2012-07-17 at 17:46 +0300, Pekka Enberg wrote:
> On Mon, 16 Jul 2012, David Rientjes wrote:
> >> > The kernel cannot check everything and will blow up in unexpected ways if
> >> > someone codes something stupid. There are numerous debugging options that
> >> > need to be switched on to get
On Tue, 17 Jul 2012, Pekka Enberg wrote:
> Well, even SLUB checks for !name in mainline so that's definitely
> worth including unconditionally. Furthermore, the size related checks
> certainly make sense and I don't see any harm in having them as well.
There is a WARN_ON() there and then it retur
On Mon, 16 Jul 2012, David Rientjes wrote:
>> > The kernel cannot check everything and will blow up in unexpected ways if
>> > someone codes something stupid. There are numerous debugging options that
>> > need to be switched on to get better debugging information to investigate
>> > deper. Adding
On Mon, 16 Jul 2012, David Rientjes wrote:
> > The kernel cannot check everything and will blow up in unexpected ways if
> > someone codes something stupid. There are numerous debugging options that
> > need to be switched on to get better debugging information to investigate
> > deper. Adding spe
On Mon, 16 Jul 2012, Christoph Lameter wrote:
> > Sounds like a response from someone who is very familiar with slab
> > allocators. The reality, though, is that very few people are going to be
> > doing development with CONFIG_DEBUG_VM enabled unless they notice problems
> > beforehand.
>
> Ker
On Mon, 16 Jul 2012, David Rientjes wrote:
> > These checks are useless for regular kernel operations. They are
> > only useful when developing code and should only be enabled during
> > development. There is no point in testing the size and the name which are
> > typically constant when a slab is
On Mon, 16 Jul 2012, Christoph Lameter wrote:
> > > struct kmem_cache *kmem_cache_create(const char *name, size_t size,
> > > size_t align,
> > > unsigned long flags, void (*ctor)(void *))
> > > {
> > > struct kmem_cache *s = NULL;
> > >
> > > #ifdef CONFIG_DEBUG_VM
> > >
On Mon, 2012-07-16 at 09:17 -0500, Christoph Lameter wrote:
> On Mon, 16 Jul 2012, David Rientjes wrote:
>
> > On Sun, 15 Jul 2012, Shuah Khan wrote:
> >
> > > I can work on reshuffling the code. Do have a question though. This
> > > following sanity check is currently done only when CONFIG_DEBUG_
On Mon, 16 Jul 2012, David Rientjes wrote:
> On Sun, 15 Jul 2012, Shuah Khan wrote:
>
> > I can work on reshuffling the code. Do have a question though. This
> > following sanity check is currently done only when CONFIG_DEBUG_VM is
> > defined. However, it does appear to be something that is that
On Sun, 15 Jul 2012, Shuah Khan wrote:
> I can work on reshuffling the code. Do have a question though. This
> following sanity check is currently done only when CONFIG_DEBUG_VM is
> defined. However, it does appear to be something that is that should be
> checked even in regular path.
>
> struct
On Sat, 2012-07-14 at 15:01 +0300, Pekka Enberg wrote:
> I'm not exactly loving that either.
>
> It'd probably be better to reshuffle the code so that the debug checks
> end up in separate functions that are no-op for !CONFIG_DEBUG_VM. That
> way the _labels_ are used unconditionally although the
On Sat, Jul 14, 2012 at 12:18 PM, David Rientjes wrote:
> On Fri, 13 Jul 2012, Shuah Khan wrote:
>
>> diff --git a/mm/slab_common.c b/mm/slab_common.c
>> index 12637ce..aa3ca5b 100644
>> --- a/mm/slab_common.c
>> +++ b/mm/slab_common.c
>> @@ -98,7 +98,9 @@ struct kmem_cache *kmem_cache_create(cons
On Fri, 13 Jul 2012, Shuah Khan wrote:
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 12637ce..aa3ca5b 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -98,7 +98,9 @@ struct kmem_cache *kmem_cache_create(const char *name,
> size_t size, size_t align
>
> s = __kmem
The label oops is used in CONFIG_DEBUG_VM ifdef block and is defined
outside ifdef CONFIG_DEBUG_VM block. This results in the following
build warning when built with CONFIG_DEBUG_VM disabled. Fix to move
label oops definition to inside a CONFIG_DEBUG_VM block.
mm/slab_common.c: In function ‘kmem_
22 matches
Mail list logo
