All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Cc: Christoph Lameter <cl@linux.com>, Pekka Enberg <penberg@kernel.org>
Subject: Re: possible regression on 3.13 when calling flush_dcache_page
Date: Mon, 6 Jan 2014 09:26:48 +0900	[thread overview]
Message-ID: <20140106002648.GC696@lge.com> (raw)
In-Reply-To: <20140103145404.GC18002@ldesroches-Latitude-E6320>

On Fri, Jan 03, 2014 at 03:54:04PM +0100, Ludovic Desroches wrote:
> Hi,
> 
> On Tue, Dec 24, 2013 at 03:38:37PM +0900, Joonsoo Kim wrote:
> 
> [...]
> 
> > > > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > > > variable on slab management structure and replace variable name. So there
> > > > > > > is no functional change.
> 
> You are right, the commit given by git bisect was not the good one...
> Since I removed other patches done on top of it, I thought it really was
> this one but in fact it is 8456a64.

Okay. It seems more reasonable to me.
I guess that this is the same issue with following link.
http://lkml.org/lkml/2014/1/4/81

And, perhaps, that patch solves your problem. But I'm not sure that it is the
best solution for this problem. I should discuss with slab maintainers.

I will think about this problem more deeply and report the solution to you
as soon as possible.

Thanks.

> 
>  dd0f774  Fri Jan 3 12:33:55 2014 +0100  Revert "slab: remove useless
> statement for checking pfmemalloc"  Ludovic Desroches 
>  ff7487d  Fri Jan 3 12:32:33 2014 +0100  Revert "slab: rename
> slab_bufctl to slab_freelist"  Ludovic Desroches 
>  b963564  Fri Jan 3 12:32:13 2014 +0100  Revert "slab: fix to calm down
> kmemleak warning"  Ludovic Desroches 
>  3fcfe50  Fri Jan 3 12:30:32 2014 +0100  Revert "slab: replace
> non-existing 'struct freelist *' with 'void *'"  Ludovic Desroches 
>  750a795  Fri Jan 3 12:30:16 2014 +0100  Revert "memcg, kmem: rename
> cache_from_memcg to cache_from_memcg_idx"  Ludovic Desroches 
>  7e2de8a  Fri Jan 3 12:30:10 2014 +0100  mmc: atmel-mci: disable pdc
> Ludovic Desroches
> 
> In this case I have the kernel oops. If I revert 8456a64 too, it
> disappears.
> 
> I will try to test it on other devices because I couldn't reproduce it
> with newer ones (but it's not the same ARM architecture so I would like
> to see if it's also related to the device itself).
> 
> In attachment, there are the results of /proc/slabinfo before inserted the
> sdio wifi module causing the oops.
> 
> Regards
> 
> Ludovic


WARNING: multiple messages have this Message-ID (diff)
From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Cc: Christoph Lameter <cl@linux.com>, Pekka Enberg <penberg@kernel.org>
Subject: Re: possible regression on 3.13 when calling flush_dcache_page
Date: Mon, 6 Jan 2014 09:26:48 +0900	[thread overview]
Message-ID: <20140106002648.GC696@lge.com> (raw)
In-Reply-To: <20140103145404.GC18002@ldesroches-Latitude-E6320>

On Fri, Jan 03, 2014 at 03:54:04PM +0100, Ludovic Desroches wrote:
> Hi,
> 
> On Tue, Dec 24, 2013 at 03:38:37PM +0900, Joonsoo Kim wrote:
> 
> [...]
> 
> > > > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > > > variable on slab management structure and replace variable name. So there
> > > > > > > is no functional change.
> 
> You are right, the commit given by git bisect was not the good one...
> Since I removed other patches done on top of it, I thought it really was
> this one but in fact it is 8456a64.

Okay. It seems more reasonable to me.
I guess that this is the same issue with following link.
http://lkml.org/lkml/2014/1/4/81

And, perhaps, that patch solves your problem. But I'm not sure that it is the
best solution for this problem. I should discuss with slab maintainers.

I will think about this problem more deeply and report the solution to you
as soon as possible.

Thanks.

> 
>  dd0f774  Fri Jan 3 12:33:55 2014 +0100  Revert "slab: remove useless
> statement for checking pfmemalloc"  Ludovic Desroches 
>  ff7487d  Fri Jan 3 12:32:33 2014 +0100  Revert "slab: rename
> slab_bufctl to slab_freelist"  Ludovic Desroches 
>  b963564  Fri Jan 3 12:32:13 2014 +0100  Revert "slab: fix to calm down
> kmemleak warning"  Ludovic Desroches 
>  3fcfe50  Fri Jan 3 12:30:32 2014 +0100  Revert "slab: replace
> non-existing 'struct freelist *' with 'void *'"  Ludovic Desroches 
>  750a795  Fri Jan 3 12:30:16 2014 +0100  Revert "memcg, kmem: rename
> cache_from_memcg to cache_from_memcg_idx"  Ludovic Desroches 
>  7e2de8a  Fri Jan 3 12:30:10 2014 +0100  mmc: atmel-mci: disable pdc
> Ludovic Desroches
> 
> In this case I have the kernel oops. If I revert 8456a64 too, it
> disappears.
> 
> I will try to test it on other devices because I couldn't reproduce it
> with newer ones (but it's not the same ARM architecture so I would like
> to see if it's also related to the device itself).
> 
> In attachment, there are the results of /proc/slabinfo before inserted the
> sdio wifi module causing the oops.
> 
> Regards
> 
> Ludovic

--
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-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: iamjoonsoo.kim@lge.com (Joonsoo Kim)
To: linux-arm-kernel@lists.infradead.org
Subject: possible regression on 3.13 when calling flush_dcache_page
Date: Mon, 6 Jan 2014 09:26:48 +0900	[thread overview]
Message-ID: <20140106002648.GC696@lge.com> (raw)
In-Reply-To: <20140103145404.GC18002@ldesroches-Latitude-E6320>

On Fri, Jan 03, 2014 at 03:54:04PM +0100, Ludovic Desroches wrote:
> Hi,
> 
> On Tue, Dec 24, 2013 at 03:38:37PM +0900, Joonsoo Kim wrote:
> 
> [...]
> 
> > > > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > > > variable on slab management structure and replace variable name. So there
> > > > > > > is no functional change.
> 
> You are right, the commit given by git bisect was not the good one...
> Since I removed other patches done on top of it, I thought it really was
> this one but in fact it is 8456a64.

Okay. It seems more reasonable to me.
I guess that this is the same issue with following link.
http://lkml.org/lkml/2014/1/4/81

And, perhaps, that patch solves your problem. But I'm not sure that it is the
best solution for this problem. I should discuss with slab maintainers.

I will think about this problem more deeply and report the solution to you
as soon as possible.

Thanks.

> 
>  dd0f774  Fri Jan 3 12:33:55 2014 +0100  Revert "slab: remove useless
> statement for checking pfmemalloc"  Ludovic Desroches 
>  ff7487d  Fri Jan 3 12:32:33 2014 +0100  Revert "slab: rename
> slab_bufctl to slab_freelist"  Ludovic Desroches 
>  b963564  Fri Jan 3 12:32:13 2014 +0100  Revert "slab: fix to calm down
> kmemleak warning"  Ludovic Desroches 
>  3fcfe50  Fri Jan 3 12:30:32 2014 +0100  Revert "slab: replace
> non-existing 'struct freelist *' with 'void *'"  Ludovic Desroches 
>  750a795  Fri Jan 3 12:30:16 2014 +0100  Revert "memcg, kmem: rename
> cache_from_memcg to cache_from_memcg_idx"  Ludovic Desroches 
>  7e2de8a  Fri Jan 3 12:30:10 2014 +0100  mmc: atmel-mci: disable pdc
> Ludovic Desroches
> 
> In this case I have the kernel oops. If I revert 8456a64 too, it
> disappears.
> 
> I will try to test it on other devices because I couldn't reproduce it
> with newer ones (but it's not the same ARM architecture so I would like
> to see if it's also related to the device itself).
> 
> In attachment, there are the results of /proc/slabinfo before inserted the
> sdio wifi module causing the oops.
> 
> Regards
> 
> Ludovic

  reply	other threads:[~2014-01-06  0:26 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-12 14:31 possible regression on 3.13 when calling flush_dcache_page Ludovic Desroches
2013-12-12 14:31 ` Ludovic Desroches
2013-12-12 14:31 ` Ludovic Desroches
2013-12-12 14:36 ` Ludovic Desroches
2013-12-12 14:36   ` Ludovic Desroches
2013-12-12 14:36   ` Ludovic Desroches
2013-12-12 14:36   ` Ludovic Desroches
2013-12-13  1:59   ` Joonsoo Kim
2013-12-13  1:59     ` Joonsoo Kim
2013-12-13  1:59     ` Joonsoo Kim
2013-12-16 14:43     ` Ludovic Desroches
2013-12-16 14:43       ` Ludovic Desroches
2013-12-16 14:43       ` Ludovic Desroches
2013-12-18  7:21       ` Joonsoo Kim
2013-12-18  7:21         ` Joonsoo Kim
2013-12-18  7:21         ` Joonsoo Kim
2013-12-20  8:08         ` Ludovic Desroches
2013-12-20  8:08           ` Ludovic Desroches
2013-12-20  8:08           ` Ludovic Desroches
2013-12-20  8:08           ` Ludovic Desroches
2013-12-23 22:44           ` Ludovic Desroches
2013-12-23 22:44             ` Ludovic Desroches
2013-12-23 22:44             ` Ludovic Desroches
2013-12-24  6:38             ` Joonsoo Kim
2013-12-24  6:38               ` Joonsoo Kim
2013-12-24  6:38               ` Joonsoo Kim
2014-01-03 14:54               ` Ludovic Desroches
2014-01-03 14:54                 ` Ludovic Desroches
2014-01-03 14:54                 ` Ludovic Desroches
2014-01-06  0:26                 ` Joonsoo Kim [this message]
2014-01-06  0:26                   ` Joonsoo Kim
2014-01-06  0:26                   ` Joonsoo Kim
2014-01-06  9:34                   ` Ludovic Desroches
2014-01-06  9:34                     ` Ludovic Desroches
2014-01-06  9:34                     ` Ludovic Desroches
2014-01-06  9:34                     ` Ludovic Desroches
2014-01-09  7:16                     ` Joonsoo Kim
2014-01-09  7:16                       ` Joonsoo Kim
2014-01-09  7:16                       ` Joonsoo Kim
2013-12-12 17:13 ` Russell King - ARM Linux
2013-12-12 17:13   ` Russell King - ARM Linux
2013-12-12 17:13   ` Russell King - ARM Linux
2013-12-16 10:49   ` Ludovic Desroches
2013-12-16 10:49     ` Ludovic Desroches
2013-12-16 10:49     ` Ludovic Desroches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140106002648.GC696@lge.com \
    --to=iamjoonsoo.kim@lge.com \
    --cc=cl@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=penberg@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.