* possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-20 8:08 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-20 8:08 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > Hello,
> >
> > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > fix mmc mailing list address error
> > > >
> > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > Hi,
> > > > >
> > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > flush_dcache_page (log at the end of the message).
> > > > >
> > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > the error is the following one:
> > > > >
> > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > >
> > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > in the atmel-mci driver.
> > >
> > > Hello,
> > >
> > > 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.
> > >
> >
> > If I have reverted this patch and other ones you did on top of it and
> > the issue disappear.
>
> Hello,
>
> Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
>
> And how about testing with artificially increasing size of struct slab on
> top of this commit (106a74e)?
>
> I really wonder why the problem happens, because this doesn't cause any
> functional change as far as I know. Only side-effect from this patch is
> decreasing size of struct slab.
Sorry I am not at the office, I have tried to reproduce it with a
different device and a different sdcard but without success. I'll test
it on Monday.
Regards
Ludovic
>
> Thanks.
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 2ec2336..d2240fd 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -174,6 +174,7 @@ struct slab {
> struct {
> struct list_head list;
> void *s_mem; /* including colour offset */
> + unsigned int x;
> unsigned int active; /* num of objs active in slab */
> };
> };
>
> >
> > > I doubt that side-effect of this patch reveals a bug in other place.
> > > Side-effect is reduced memory usage for slab management structure. It would
> > > makes some slabs have more objects with more density since slab management
> > > structure is sometimes on the page for objects. So if it diminishes, more
> > > objects can be in the page.
> > >
> > > Anyway, I will look at it more. If you have any progress, please let me know.
> >
> > No progress at the moment.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email at kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-20 8:08 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-20 8:08 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel, Ludovic Desroches
Hello,
On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > Hello,
> >
> > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > fix mmc mailing list address error
> > > >
> > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > Hi,
> > > > >
> > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > flush_dcache_page (log at the end of the message).
> > > > >
> > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > the error is the following one:
> > > > >
> > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > >
> > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > in the atmel-mci driver.
> > >
> > > Hello,
> > >
> > > 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.
> > >
> >
> > If I have reverted this patch and other ones you did on top of it and
> > the issue disappear.
>
> Hello,
>
> Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
>
> And how about testing with artificially increasing size of struct slab on
> top of this commit (106a74e)?
>
> I really wonder why the problem happens, because this doesn't cause any
> functional change as far as I know. Only side-effect from this patch is
> decreasing size of struct slab.
Sorry I am not at the office, I have tried to reproduce it with a
different device and a different sdcard but without success. I'll test
it on Monday.
Regards
Ludovic
>
> Thanks.
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 2ec2336..d2240fd 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -174,6 +174,7 @@ struct slab {
> struct {
> struct list_head list;
> void *s_mem; /* including colour offset */
> + unsigned int x;
> unsigned int active; /* num of objs active in slab */
> };
> };
>
> >
> > > I doubt that side-effect of this patch reveals a bug in other place.
> > > Side-effect is reduced memory usage for slab management structure. It would
> > > makes some slabs have more objects with more density since slab management
> > > structure is sometimes on the page for objects. So if it diminishes, more
> > > objects can be in the page.
> > >
> > > Anyway, I will look at it more. If you have any progress, please let me know.
> >
> > No progress at the moment.
>
> --
> 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>
--
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>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-20 8:08 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-20 8:08 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel, Ludovic Desroches
Hello,
On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > Hello,
> >
> > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > fix mmc mailing list address error
> > > >
> > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > Hi,
> > > > >
> > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > flush_dcache_page (log at the end of the message).
> > > > >
> > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > the error is the following one:
> > > > >
> > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > >
> > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > in the atmel-mci driver.
> > >
> > > Hello,
> > >
> > > 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.
> > >
> >
> > If I have reverted this patch and other ones you did on top of it and
> > the issue disappear.
>
> Hello,
>
> Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
>
> And how about testing with artificially increasing size of struct slab on
> top of this commit (106a74e)?
>
> I really wonder why the problem happens, because this doesn't cause any
> functional change as far as I know. Only side-effect from this patch is
> decreasing size of struct slab.
Sorry I am not at the office, I have tried to reproduce it with a
different device and a different sdcard but without success. I'll test
it on Monday.
Regards
Ludovic
>
> Thanks.
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 2ec2336..d2240fd 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -174,6 +174,7 @@ struct slab {
> struct {
> struct list_head list;
> void *s_mem; /* including colour offset */
> + unsigned int x;
> unsigned int active; /* num of objs active in slab */
> };
> };
>
> >
> > > I doubt that side-effect of this patch reveals a bug in other place.
> > > Side-effect is reduced memory usage for slab management structure. It would
> > > makes some slabs have more objects with more density since slab management
> > > structure is sometimes on the page for objects. So if it diminishes, more
> > > objects can be in the page.
> > >
> > > Anyway, I will look at it more. If you have any progress, please let me know.
> >
> > No progress at the moment.
>
> --
> 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>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2013-12-20 8:08 ` Ludovic Desroches
(?)
@ 2013-12-23 22:44 ` Ludovic Desroches
-1 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-23 22:44 UTC (permalink / raw)
To: Joonsoo Kim, linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
Cc: Ludovic Desroches
On Fri, Dec 20, 2013 at 09:08:51AM +0100, Ludovic Desroches wrote:
> Hello,
>
> On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> > On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > > Hello,
> > >
> > > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > > fix mmc mailing list address error
> > > > >
> > > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > > Hi,
> > > > > >
> > > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > > flush_dcache_page (log at the end of the message).
> > > > > >
> > > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > > the error is the following one:
> > > > > >
> > > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > > >
> > > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > > in the atmel-mci driver.
> > > >
> > > > Hello,
> > > >
> > > > 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.
> > > >
> > >
> > > If I have reverted this patch and other ones you did on top of it and
> > > the issue disappear.
> >
> > Hello,
> >
> > Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
> >
> > And how about testing with artificially increasing size of struct slab on
> > top of this commit (106a74e)?
> >
> > I really wonder why the problem happens, because this doesn't cause any
> > functional change as far as I know. Only side-effect from this patch is
> > decreasing size of struct slab.
>
> Sorry I am not at the office, I have tried to reproduce it with a
> different device and a different sdcard but without success. I'll test
> it on Monday.
I am still not at the office but I get the same device and the same
sdcard and I don't reproduce it. I am not totally in the same
conditions. It seems there is an extra parameter causing this bug but I
don't figure out which one at the moment.
>
> Regards
>
> Ludovic
>
> >
> > Thanks.
> >
> > diff --git a/mm/slab.c b/mm/slab.c
> > index 2ec2336..d2240fd 100644
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -174,6 +174,7 @@ struct slab {
> > struct {
> > struct list_head list;
> > void *s_mem; /* including colour offset */
> > + unsigned int x;
> > unsigned int active; /* num of objs active in slab */
> > };
> > };
> >
> > >
> > > > I doubt that side-effect of this patch reveals a bug in other place.
> > > > Side-effect is reduced memory usage for slab management structure. It would
> > > > makes some slabs have more objects with more density since slab management
> > > > structure is sometimes on the page for objects. So if it diminishes, more
> > > > objects can be in the page.
> > > >
> > > > Anyway, I will look at it more. If you have any progress, please let me know.
> > >
> > > No progress at the moment.
> >
> > --
> > 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>
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-23 22:44 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-23 22:44 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Dec 20, 2013 at 09:08:51AM +0100, Ludovic Desroches wrote:
> Hello,
>
> On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> > On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > > Hello,
> > >
> > > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > > fix mmc mailing list address error
> > > > >
> > > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > > Hi,
> > > > > >
> > > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > > flush_dcache_page (log at the end of the message).
> > > > > >
> > > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > > the error is the following one:
> > > > > >
> > > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > > >
> > > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > > in the atmel-mci driver.
> > > >
> > > > Hello,
> > > >
> > > > 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.
> > > >
> > >
> > > If I have reverted this patch and other ones you did on top of it and
> > > the issue disappear.
> >
> > Hello,
> >
> > Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
> >
> > And how about testing with artificially increasing size of struct slab on
> > top of this commit (106a74e)?
> >
> > I really wonder why the problem happens, because this doesn't cause any
> > functional change as far as I know. Only side-effect from this patch is
> > decreasing size of struct slab.
>
> Sorry I am not at the office, I have tried to reproduce it with a
> different device and a different sdcard but without success. I'll test
> it on Monday.
I am still not at the office but I get the same device and the same
sdcard and I don't reproduce it. I am not totally in the same
conditions. It seems there is an extra parameter causing this bug but I
don't figure out which one at the moment.
>
> Regards
>
> Ludovic
>
> >
> > Thanks.
> >
> > diff --git a/mm/slab.c b/mm/slab.c
> > index 2ec2336..d2240fd 100644
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -174,6 +174,7 @@ struct slab {
> > struct {
> > struct list_head list;
> > void *s_mem; /* including colour offset */
> > + unsigned int x;
> > unsigned int active; /* num of objs active in slab */
> > };
> > };
> >
> > >
> > > > I doubt that side-effect of this patch reveals a bug in other place.
> > > > Side-effect is reduced memory usage for slab management structure. It would
> > > > makes some slabs have more objects with more density since slab management
> > > > structure is sometimes on the page for objects. So if it diminishes, more
> > > > objects can be in the page.
> > > >
> > > > Anyway, I will look at it more. If you have any progress, please let me know.
> > >
> > > No progress at the moment.
> >
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majordomo at kvack.org. For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a href=mailto:"dont@kvack.org"> email at kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-23 22:44 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-23 22:44 UTC (permalink / raw)
To: Joonsoo Kim, linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
Cc: Ludovic Desroches
On Fri, Dec 20, 2013 at 09:08:51AM +0100, Ludovic Desroches wrote:
> Hello,
>
> On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> > On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > > Hello,
> > >
> > > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > > fix mmc mailing list address error
> > > > >
> > > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > > Hi,
> > > > > >
> > > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > > flush_dcache_page (log at the end of the message).
> > > > > >
> > > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > > the error is the following one:
> > > > > >
> > > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > > >
> > > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > > in the atmel-mci driver.
> > > >
> > > > Hello,
> > > >
> > > > 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.
> > > >
> > >
> > > If I have reverted this patch and other ones you did on top of it and
> > > the issue disappear.
> >
> > Hello,
> >
> > Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
> >
> > And how about testing with artificially increasing size of struct slab on
> > top of this commit (106a74e)?
> >
> > I really wonder why the problem happens, because this doesn't cause any
> > functional change as far as I know. Only side-effect from this patch is
> > decreasing size of struct slab.
>
> Sorry I am not at the office, I have tried to reproduce it with a
> different device and a different sdcard but without success. I'll test
> it on Monday.
I am still not at the office but I get the same device and the same
sdcard and I don't reproduce it. I am not totally in the same
conditions. It seems there is an extra parameter causing this bug but I
don't figure out which one at the moment.
>
> Regards
>
> Ludovic
>
> >
> > Thanks.
> >
> > diff --git a/mm/slab.c b/mm/slab.c
> > index 2ec2336..d2240fd 100644
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -174,6 +174,7 @@ struct slab {
> > struct {
> > struct list_head list;
> > void *s_mem; /* including colour offset */
> > + unsigned int x;
> > unsigned int active; /* num of objs active in slab */
> > };
> > };
> >
> > >
> > > > I doubt that side-effect of this patch reveals a bug in other place.
> > > > Side-effect is reduced memory usage for slab management structure. It would
> > > > makes some slabs have more objects with more density since slab management
> > > > structure is sometimes on the page for objects. So if it diminishes, more
> > > > objects can be in the page.
> > > >
> > > > Anyway, I will look at it more. If you have any progress, please let me know.
> > >
> > > No progress at the moment.
> >
> > --
> > 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>
--
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>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2013-12-23 22:44 ` Ludovic Desroches
(?)
@ 2013-12-24 6:38 ` Joonsoo Kim
-1 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2013-12-24 6:38 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
On Mon, Dec 23, 2013 at 11:44:35PM +0100, Ludovic Desroches wrote:
> On Fri, Dec 20, 2013 at 09:08:51AM +0100, Ludovic Desroches wrote:
> > Hello,
> >
> > On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> > > On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > > > Hello,
> > > >
> > > > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > > > fix mmc mailing list address error
> > > > > >
> > > > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > > > flush_dcache_page (log at the end of the message).
> > > > > > >
> > > > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > > > the error is the following one:
> > > > > > >
> > > > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > > > >
> > > > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > > > in the atmel-mci driver.
> > > > >
> > > > > Hello,
> > > > >
> > > > > 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.
> > > > >
> > > >
> > > > If I have reverted this patch and other ones you did on top of it and
> > > > the issue disappear.
> > >
> > > Hello,
> > >
> > > Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
> > >
> > > And how about testing with artificially increasing size of struct slab on
> > > top of this commit (106a74e)?
> > >
> > > I really wonder why the problem happens, because this doesn't cause any
> > > functional change as far as I know. Only side-effect from this patch is
> > > decreasing size of struct slab.
> >
> > Sorry I am not at the office, I have tried to reproduce it with a
> > different device and a different sdcard but without success. I'll test
> > it on Monday.
>
> I am still not at the office but I get the same device and the same
> sdcard and I don't reproduce it. I am not totally in the same
> conditions. It seems there is an extra parameter causing this bug but I
> don't figure out which one at the moment.
Okay. I will wait for you!
Thanks for informing progress.
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-24 6:38 ` Joonsoo Kim
0 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2013-12-24 6:38 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Dec 23, 2013 at 11:44:35PM +0100, Ludovic Desroches wrote:
> On Fri, Dec 20, 2013 at 09:08:51AM +0100, Ludovic Desroches wrote:
> > Hello,
> >
> > On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> > > On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > > > Hello,
> > > >
> > > > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > > > fix mmc mailing list address error
> > > > > >
> > > > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > > > flush_dcache_page (log at the end of the message).
> > > > > > >
> > > > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > > > the error is the following one:
> > > > > > >
> > > > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > > > >
> > > > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > > > in the atmel-mci driver.
> > > > >
> > > > > Hello,
> > > > >
> > > > > 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.
> > > > >
> > > >
> > > > If I have reverted this patch and other ones you did on top of it and
> > > > the issue disappear.
> > >
> > > Hello,
> > >
> > > Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
> > >
> > > And how about testing with artificially increasing size of struct slab on
> > > top of this commit (106a74e)?
> > >
> > > I really wonder why the problem happens, because this doesn't cause any
> > > functional change as far as I know. Only side-effect from this patch is
> > > decreasing size of struct slab.
> >
> > Sorry I am not at the office, I have tried to reproduce it with a
> > different device and a different sdcard but without success. I'll test
> > it on Monday.
>
> I am still not at the office but I get the same device and the same
> sdcard and I don't reproduce it. I am not totally in the same
> conditions. It seems there is an extra parameter causing this bug but I
> don't figure out which one at the moment.
Okay. I will wait for you!
Thanks for informing progress.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-24 6:38 ` Joonsoo Kim
0 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2013-12-24 6:38 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
On Mon, Dec 23, 2013 at 11:44:35PM +0100, Ludovic Desroches wrote:
> On Fri, Dec 20, 2013 at 09:08:51AM +0100, Ludovic Desroches wrote:
> > Hello,
> >
> > On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> > > On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > > > Hello,
> > > >
> > > > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > > > fix mmc mailing list address error
> > > > > >
> > > > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > > > flush_dcache_page (log at the end of the message).
> > > > > > >
> > > > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > > > the error is the following one:
> > > > > > >
> > > > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > > > >
> > > > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > > > in the atmel-mci driver.
> > > > >
> > > > > Hello,
> > > > >
> > > > > 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.
> > > > >
> > > >
> > > > If I have reverted this patch and other ones you did on top of it and
> > > > the issue disappear.
> > >
> > > Hello,
> > >
> > > Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
> > >
> > > And how about testing with artificially increasing size of struct slab on
> > > top of this commit (106a74e)?
> > >
> > > I really wonder why the problem happens, because this doesn't cause any
> > > functional change as far as I know. Only side-effect from this patch is
> > > decreasing size of struct slab.
> >
> > Sorry I am not at the office, I have tried to reproduce it with a
> > different device and a different sdcard but without success. I'll test
> > it on Monday.
>
> I am still not at the office but I get the same device and the same
> sdcard and I don't reproduce it. I am not totally in the same
> conditions. It seems there is an extra parameter causing this bug but I
> don't figure out which one at the moment.
Okay. I will wait for you!
Thanks for informing progress.
--
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>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2013-12-24 6:38 ` Joonsoo Kim
(?)
@ 2014-01-03 14:54 ` Ludovic Desroches
-1 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2014-01-03 14:54 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel, Ludovic Desroches
[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]
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.
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
[-- Attachment #2: 8456a64_reverted.log --]
[-- Type: text/plain, Size: 14408 bytes --]
# cat /proc/slabinfo
slabinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_sla>
ubi_wl_entry_slab 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
ubifs_inode_slab 0 0 368 10 1 : tunables 54 27 0 : slabdata 0 0 0
fib6_nodes 1 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip6_dst_cache 1 17 224 17 1 : tunables 120 60 0 : slabdata 1 1 0
PINGv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
RAWv6 4 11 704 11 2 : tunables 54 27 0 : slabdata 1 1 0
UDPLITEv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
UDPv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCPv6 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCPv6 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCPv6 0 0 1344 3 1 : tunables 24 12 0 : slabdata 0 0 0
sd_ext_cdb 2 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
nfs_direct_cache 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
nfs_commit_data 4 9 416 9 1 : tunables 54 27 0 : slabdata 1 1 0
nfs_write_data 32 36 608 6 1 : tunables 54 27 0 : slabdata 6 6 0
nfs_read_data 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_page 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fat_inode_cache 0 0 360 11 1 : tunables 54 27 0 : slabdata 0 0 0
fat_cache 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_transaction_s 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_inode 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_handle 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_head 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_table_s 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_record_s 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
ext4_xattr 0 0 48 78 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_free_data 0 0 40 92 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_allocation_context 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_prealloc_space 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_system_zone 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_io_end 0 0 40 92 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_extent_status 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
configfs_dir_cache 1 68 56 68 1 : tunables 120 60 0 : slabdata 1 1 0
kioctx 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
kiocb 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fanotify_response_event 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_event_private_data 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_inode_mark 12 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
dnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
dnotify_struct 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
dio 0 0 328 12 1 : tunables 54 27 0 : slabdata 0 0 0
fasync_cache 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
posix_timers_cache 0 0 152 26 1 : tunables 120 60 0 : slabdata 0 0 0
uid_cache 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
rpc_inode_cache 0 0 320 12 1 : tunables 54 27 0 : slabdata 0 0 0
rpc_buffers 8 8 2048 2 1 : tunables 24 12 0 : slabdata 4 4 0
rpc_tasks 8 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
UNIX 5 8 480 8 1 : tunables 54 27 0 : slabdata 1 1 0
UDP-Lite 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tcp_bind_bucket 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
inet_peer_cache 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0
ip_fib_trie 3 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip_fib_alias 4 145 24 145 1 : tunables 120 60 0 : slabdata 1 1 0
ip_dst_cache 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0
PING 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
RAW 1 7 576 7 1 : tunables 54 27 0 : slabdata 1 1 0
UDP 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCP 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCP 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCP 0 0 1216 3 1 : tunables 24 12 0 : slabdata 0 0 0
eventpoll_pwq 9 92 40 92 1 : tunables 120 60 0 : slabdata 1 1 0
eventpoll_epi 9 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
sgpool-128 2 2 2048 2 1 : tunables 24 12 0 : slabdata 1 1 0
sgpool-64 2 4 1024 4 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-32 2 8 512 8 1 : tunables 54 27 0 : slabdata 1 random: nonblocking pool is initialized
1 0
sgpool-16 2 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
sgpool-8 2 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
scsi_data_buffer 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
blkdev_queue 14 14 1032 7 2 : tunables 24 12 0 : slabdata 2 2 0
blkdev_requests 8 18 216 18 1 : tunables 120 60 0 : slabdata 1 1 0
blkdev_ioc 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event_holder 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event 1 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
bio-0 2 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-256 2 2 3072 2 2 : tunables 24 12 0 : slabdata 1 1 0
biovec-128 0 0 1536 5 2 : tunables 24 12 0 : slabdata 0 0 0
biovec-64 0 0 768 5 1 : tunables 54 27 0 : slabdata 0 0 0
biovec-16 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
sock_inode_cache 21 36 320 12 1 : tunables 54 27 0 : slabdata 3 3 0
skbuff_fclone_cache 0 0 352 11 1 : tunables 54 27 0 : slabdata 0 0 0
skbuff_head_cache 4 20 192 20 1 : tunables 120 60 0 : slabdata 1 1 0
file_lock_cache 4 35 112 35 1 : tunables 120 60 0 : slabdata 1 1 0
shmem_inode_cache 394 396 312 12 1 : tunables 54 27 0 : slabdata 33 33 0
pool_workqueue 6 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
proc_inode_cache 48 48 312 12 1 : tunables 54 27 0 : slabdata 4 4 0
sigqueue 0 0 144 27 1 : tunables 120 60 0 : slabdata 0 0 0
bdev_cache 13 18 416 9 1 : tunables 54 27 0 : slabdata 2 2 0
sysfs_dir_cache 2926 2940 64 60 1 : tunables 120 60 0 : slabdata 49 49 0
mnt_cache 20 24 160 24 1 : tunables 120 60 0 : slabdata 1 1 0
filp 96 120 160 24 1 : tunables 120 60 0 : slabdata 5 5 0
inode_cache 1563 1568 280 14 1 : tunables 54 27 0 : slabdata 112 112 0
dentry 2030 2030 136 29 1 : tunables 120 60 0 : slabdata 70 70 0
names_cache 1 1 4096 1 1 : tunables 24 12 0 : slabdata 1 1 0
buffer_head 0 0 56 68 1 : tunables 120 60 0 : slabdata 0 0 0
nsproxy 1 145 24 145 1 : tunables 120 60 0 : slabdata 1 1 0
vm_area_struct 215 396 88 44 1 : tunables 120 60 0 : slabdata 9 9 0
mm_struct 20 20 384 10 1 : tunables 54 27 0 : slabdata 2 2 0
fs_cache 11 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
files_cache 11 40 192 20 1 : tunables 120 60 0 : slabdata 2 2 0
signal_cache 29 42 512 7 1 : tunables 54 27 0 : slabdata 6 6 0
sighand_cache 33 33 1312 3 1 : tunables 24 12 0 : slabdata 11 11 0
task_struct 29 42 672 6 1 : tunables 54 27 0 : slabdata 7 7 0
cred_jar 40 120 96 40 1 : tunables 120 60 0 : slabdata 3 3 0
anon_vma_chain 254 678 32 113 1 : tunables 120 60 0 : slabdata 6 6 0
anon_vma 193 435 24 145 1 : tunables 120 60 0 : slabdata 3 3 0
pid 33 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
radix_tree_node 130 143 296 13 1 : tunables 54 27 0 : slabdata 11 11 0
idr_layer_cache 62 63 1080 7 2 : tunables 24 12 0 : slabdata 9 9 0
kmalloc-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-2097152 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-1048576 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-524288 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-262144 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-65536 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-32768 2 2 32768 1 8 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-16384 1 1 16384 1 4 : tunables 8 4 0 : slabdata 1 1 0
kmalloc-8192 2 2 8192 1 2 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-4096 4 4 4096 1 1 : tunables 24 12 0 : slabdata 4 4 0
kmalloc-2048 28 28 2048 2 1 : tunables 24 12 0 : slabdata 14 14 0
kmalloc-1024 39 44 1024 4 1 : tunables 54 27 0 : slabdata 11 11 0
kmalloc-512 204 208 512 8 1 : tunables 54 27 0 : slabdata 26 26 0
kmalloc-256 183 195 256 15 1 : tunables 120 60 0 : slabdata 13 13 0
kmalloc-192 134 140 192 20 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-128 204 210 128 30 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-96 1099 1120 96 40 1 : tunables 120 60 0 : slabdata 28 28 0
kmalloc-64 648 720 64 60 1 : tunables 120 60 0 : slabdata 12 12 0
kmalloc-32 3018 3164 32 113 1 : tunables 120 60 0 : slabdata 28 28 0
kmem_cache 131 160 96 40 1 : tunables 120 60 0 : slabdata 4 4 0
[-- Attachment #3: with_8456a64.log --]
[-- Type: text/plain, Size: 14367 bytes --]
# cat /proc/slabinfo
slabinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_sla>
ubi_wl_entry_slab 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
ubifs_inode_slab 0 0 368 11 1 : tunables 54 27 0 : slabdata 0 0 0
fib6_nodes 1 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip6_dst_cache 1 17 224 17 1 : tunables 120 60 0 : slabdata 1 1 0
PINGv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
RAWv6 4 11 704 11 2 : tunables 54 27 0 : slabdata 1 1 0
UDPLITEv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
UDPv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCPv6 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCPv6 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCPv6 0 0 1344 3 1 : tunables 24 12 0 : slabdata 0 0 0
sd_ext_cdb 2 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
nfs_direct_cache 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
nfs_commit_data 4 9 416 9 1 : tunables 54 27 0 : slabdata 1 1 0
nfs_write_data 32 36 608 6 1 : tunables 54 27 0 : slabdata 6 6 0
nfs_read_data 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_page 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fat_inode_cache 0 0 360 11 1 : tunables 54 27 0 : slabdata 0 0 0
fat_cache 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_transaction_s 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_inode 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_handle 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_head 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_table_s 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_record_s 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
ext4_xattr 0 0 48 78 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_free_data 0 0 40 93 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_allocation_context 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_prealloc_space 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_system_zone 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_io_end 0 0 40 93 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_extent_status 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
configfs_dir_cache 1 68 56 68 1 : tunables 120 60 0 : slabdata 1 1 0
kioctx 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
kiocb 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fanotify_response_event 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_event_private_data 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_inode_mark 12 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
dnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
dnotify_struct 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
dio 0 0 328 12 1 : tunables 54 27 0 : slabdata 0 0 0
fasync_cache 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
posix_timers_cache 0 0 152 26 1 : tunables 120 60 0 : slabdata 0 0 0
uid_cache 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
rpc_inode_cache 0 0 320 12 1 : tunables 54 27 0 : slabdata 0 0 0
rpc_buffers 8 8 2048 2 1 : tunables 24 12 0 : slabdata 4 4 0
rpc_tasks 8 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
UNIX 5 8 480 8 1 : tunables 54 27 0 : slabdata 1 1 0
UDP-Lite 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tcp_bind_bucket 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
inet_peer_cache 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
ip_fib_trie 3 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip_fib_alias 4 146 24 146 1 : tunables 120 60 0 : slabdata 1 1 0
ip_dst_cache 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
PING 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
RAW 1 7 576 7 1 : tunables 54 27 0 : slabdata 1 1 0
UDP 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCP 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCP 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCP 0 0 1216 3 1 : tunables 24 12 0 : slabdata 0 0 0
eventpoll_pwq 9 93 40 93 1 : tunables 120 60 0 : slabdata 1 1 0
eventpoll_epi 9 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
sgpool-128 2 2 2048 2 1 : tunables 24 12 0 : slabdata 1 1 0
sgpool-64 2 4 1024 4 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-32 2 8 512 8 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-16 2 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
sgpool-8 2 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
scsi_data_buffer 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
blkdev_queue 14 14 1032 7 2 : tunables 24 12 0 : slabdata 2 2 0
blkdev_requests 8 18 216 18 1 : tunables 120 60 0 : slabdata 1 1 0
blkdev_ioc 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event_holder 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event 1 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
bio-0 2 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-256 2 2 3072 2 2 : tunables 24 12 0 : slabdata 1 1 0
biovec-128 0 0 1536 5 2 : tunables 24 12 0 : slabdata 0 0 0
biovec-64 0 0 768 5 1 : tunables 54 27 0 : slabdata 0 0 0
biovec-16 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
sock_inode_cache 19 36 320 12 1 : tunables 54 27 0 : slabdata 3 3 0
skbuff_fclone_cache 0 0 352 11 1 : tunables 54 27 0 : slabdata 0 0 0
skbuff_head_cache 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
file_lock_cache 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
shmem_inode_cache 394 396 312 12 1 : tunables 54 27 0 : slabdata 33 33 0
pool_workqueue 6 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
proc_inode_cache 12 12 312 12 1 : tunables 54 27 0 : slabdata 1 1 0
sigqueue 0 0 144 27 1 : tunables 120 60 0 : slabdata 0 0 0
bdev_cache 13 18 416 9 1 : tunables 54 27 0 : slabdata 2 2 0
sysfs_dir_cache 2926 2940 64 60 1 : tunables 120 60 0 : slabdata 49 49 0
mnt_cache 20 24 160 24 1 : tunables 120 60 0 : slabdata 1 1 0
filp 65 144 160 24 1 : tunables 120 60 0 : slabdata 6 6 0
inode_cache 1564 1568 280 14 1 : tunables 54 27 0 : slabdata 112 112 0
dentry 2001 2059 136 29 1 : tunables 120 60 0 : slabdata 71 71 0
names_cache 1 1 4096 1 1 : tunables 24 12 0 : slabdata 1 1 0
buffer_head 0 0 56 68 1 : tunables 120 60 0 : slabdata 0 0 0
nsproxy 1 146 24 146 1 : tunables 120 60 0 : slabdata 1 1 0
vm_area_struct 267 352 88 44 1 : tunables 120 60 0 : slabdata 8 8 0
mm_struct 20 20 384 10 1 : tunables 54 27 0 : slabdata 2 2 0
fs_cache 23 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
files_cache 23 40 192 20 1 : tunables 120 60 0 : slabdata 2 2 0
signal_cache 42 42 512 7 1 : tunables 54 27 0 : slabdata 6 6 0
sighand_cache 33 33 1312 3 1 : tunables 24 12 0 : slabdata 11 11 0
task_struct 44 48 672 6 1 : tunables 54 27 0 : slabdata 8 8 0
cred_jar 53 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
anon_vma_chain 304 791 32 113 1 : tunables 120 60 0 : slabdata 7 7 0
anon_vma 146 438 24 146 1 : tunables 120 60 0 : slabdata 3 3 0
pid 45 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
radix_tree_node 131 143 296 13 1 : tunables 54 27 0 : slabdata 11 11 0
idr_layer_cache 62 63 1080 7 2 : tunables 24 12 0 : slabdata 9 9 0
kmalloc-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-2097152 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-1048576 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-524288 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-262144 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-65536 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-32768 2 2 32768 1 8 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-16384 1 1 16384 1 4 : tunables 8 4 0 : slabdata 1 1 0
kmalloc-8192 2 2 8192 1 2 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-4096 4 4 4096 1 1 : tunables 24 12 0 : slabdata 4 4 0
kmalloc-2048 28 28 2048 2 1 : tunables 24 12 0 : slabdata 14 14 0
kmalloc-1024 38 40 1024 4 1 : tunables 54 27 0 : slabdata 10 10 0
kmalloc-512 203 208 512 8 1 : tunables 54 27 0 : slabdata 26 26 0
kmalloc-256 195 195 256 15 1 : tunables 120 60 0 : slabdata 13 13 0
kmalloc-192 140 140 192 20 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-128 217 217 128 31 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-96 1111 1120 96 40 1 : tunables 120 60 0 : slabdata 28 28 0
kmalloc-64 621 660 64 60 1 : tunables 120 60 0 : slabdata 11 11 0
kmalloc-32 3056 3164 32 113 1 : tunables 120 60 0 : slabdata 28 28 0
kmem_cache 131 160 96 40 1 : tunables 120 60 0 : slabdata 4 4 0
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-03 14:54 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2014-01-03 14:54 UTC (permalink / raw)
To: linux-arm-kernel
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.
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
-------------- next part --------------
# cat /proc/slabinfo
slabinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_sla>
ubi_wl_entry_slab 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
ubifs_inode_slab 0 0 368 10 1 : tunables 54 27 0 : slabdata 0 0 0
fib6_nodes 1 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip6_dst_cache 1 17 224 17 1 : tunables 120 60 0 : slabdata 1 1 0
PINGv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
RAWv6 4 11 704 11 2 : tunables 54 27 0 : slabdata 1 1 0
UDPLITEv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
UDPv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCPv6 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCPv6 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCPv6 0 0 1344 3 1 : tunables 24 12 0 : slabdata 0 0 0
sd_ext_cdb 2 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
nfs_direct_cache 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
nfs_commit_data 4 9 416 9 1 : tunables 54 27 0 : slabdata 1 1 0
nfs_write_data 32 36 608 6 1 : tunables 54 27 0 : slabdata 6 6 0
nfs_read_data 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_page 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fat_inode_cache 0 0 360 11 1 : tunables 54 27 0 : slabdata 0 0 0
fat_cache 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_transaction_s 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_inode 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_handle 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_head 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_table_s 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_record_s 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
ext4_xattr 0 0 48 78 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_free_data 0 0 40 92 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_allocation_context 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_prealloc_space 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_system_zone 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_io_end 0 0 40 92 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_extent_status 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
configfs_dir_cache 1 68 56 68 1 : tunables 120 60 0 : slabdata 1 1 0
kioctx 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
kiocb 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fanotify_response_event 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_event_private_data 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_inode_mark 12 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
dnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
dnotify_struct 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
dio 0 0 328 12 1 : tunables 54 27 0 : slabdata 0 0 0
fasync_cache 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
posix_timers_cache 0 0 152 26 1 : tunables 120 60 0 : slabdata 0 0 0
uid_cache 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
rpc_inode_cache 0 0 320 12 1 : tunables 54 27 0 : slabdata 0 0 0
rpc_buffers 8 8 2048 2 1 : tunables 24 12 0 : slabdata 4 4 0
rpc_tasks 8 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
UNIX 5 8 480 8 1 : tunables 54 27 0 : slabdata 1 1 0
UDP-Lite 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tcp_bind_bucket 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
inet_peer_cache 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0
ip_fib_trie 3 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip_fib_alias 4 145 24 145 1 : tunables 120 60 0 : slabdata 1 1 0
ip_dst_cache 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0
PING 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
RAW 1 7 576 7 1 : tunables 54 27 0 : slabdata 1 1 0
UDP 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCP 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCP 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCP 0 0 1216 3 1 : tunables 24 12 0 : slabdata 0 0 0
eventpoll_pwq 9 92 40 92 1 : tunables 120 60 0 : slabdata 1 1 0
eventpoll_epi 9 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
sgpool-128 2 2 2048 2 1 : tunables 24 12 0 : slabdata 1 1 0
sgpool-64 2 4 1024 4 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-32 2 8 512 8 1 : tunables 54 27 0 : slabdata 1 random: nonblocking pool is initialized
1 0
sgpool-16 2 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
sgpool-8 2 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
scsi_data_buffer 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
blkdev_queue 14 14 1032 7 2 : tunables 24 12 0 : slabdata 2 2 0
blkdev_requests 8 18 216 18 1 : tunables 120 60 0 : slabdata 1 1 0
blkdev_ioc 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event_holder 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event 1 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
bio-0 2 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-256 2 2 3072 2 2 : tunables 24 12 0 : slabdata 1 1 0
biovec-128 0 0 1536 5 2 : tunables 24 12 0 : slabdata 0 0 0
biovec-64 0 0 768 5 1 : tunables 54 27 0 : slabdata 0 0 0
biovec-16 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
sock_inode_cache 21 36 320 12 1 : tunables 54 27 0 : slabdata 3 3 0
skbuff_fclone_cache 0 0 352 11 1 : tunables 54 27 0 : slabdata 0 0 0
skbuff_head_cache 4 20 192 20 1 : tunables 120 60 0 : slabdata 1 1 0
file_lock_cache 4 35 112 35 1 : tunables 120 60 0 : slabdata 1 1 0
shmem_inode_cache 394 396 312 12 1 : tunables 54 27 0 : slabdata 33 33 0
pool_workqueue 6 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
proc_inode_cache 48 48 312 12 1 : tunables 54 27 0 : slabdata 4 4 0
sigqueue 0 0 144 27 1 : tunables 120 60 0 : slabdata 0 0 0
bdev_cache 13 18 416 9 1 : tunables 54 27 0 : slabdata 2 2 0
sysfs_dir_cache 2926 2940 64 60 1 : tunables 120 60 0 : slabdata 49 49 0
mnt_cache 20 24 160 24 1 : tunables 120 60 0 : slabdata 1 1 0
filp 96 120 160 24 1 : tunables 120 60 0 : slabdata 5 5 0
inode_cache 1563 1568 280 14 1 : tunables 54 27 0 : slabdata 112 112 0
dentry 2030 2030 136 29 1 : tunables 120 60 0 : slabdata 70 70 0
names_cache 1 1 4096 1 1 : tunables 24 12 0 : slabdata 1 1 0
buffer_head 0 0 56 68 1 : tunables 120 60 0 : slabdata 0 0 0
nsproxy 1 145 24 145 1 : tunables 120 60 0 : slabdata 1 1 0
vm_area_struct 215 396 88 44 1 : tunables 120 60 0 : slabdata 9 9 0
mm_struct 20 20 384 10 1 : tunables 54 27 0 : slabdata 2 2 0
fs_cache 11 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
files_cache 11 40 192 20 1 : tunables 120 60 0 : slabdata 2 2 0
signal_cache 29 42 512 7 1 : tunables 54 27 0 : slabdata 6 6 0
sighand_cache 33 33 1312 3 1 : tunables 24 12 0 : slabdata 11 11 0
task_struct 29 42 672 6 1 : tunables 54 27 0 : slabdata 7 7 0
cred_jar 40 120 96 40 1 : tunables 120 60 0 : slabdata 3 3 0
anon_vma_chain 254 678 32 113 1 : tunables 120 60 0 : slabdata 6 6 0
anon_vma 193 435 24 145 1 : tunables 120 60 0 : slabdata 3 3 0
pid 33 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
radix_tree_node 130 143 296 13 1 : tunables 54 27 0 : slabdata 11 11 0
idr_layer_cache 62 63 1080 7 2 : tunables 24 12 0 : slabdata 9 9 0
kmalloc-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-2097152 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-1048576 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-524288 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-262144 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-65536 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-32768 2 2 32768 1 8 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-16384 1 1 16384 1 4 : tunables 8 4 0 : slabdata 1 1 0
kmalloc-8192 2 2 8192 1 2 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-4096 4 4 4096 1 1 : tunables 24 12 0 : slabdata 4 4 0
kmalloc-2048 28 28 2048 2 1 : tunables 24 12 0 : slabdata 14 14 0
kmalloc-1024 39 44 1024 4 1 : tunables 54 27 0 : slabdata 11 11 0
kmalloc-512 204 208 512 8 1 : tunables 54 27 0 : slabdata 26 26 0
kmalloc-256 183 195 256 15 1 : tunables 120 60 0 : slabdata 13 13 0
kmalloc-192 134 140 192 20 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-128 204 210 128 30 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-96 1099 1120 96 40 1 : tunables 120 60 0 : slabdata 28 28 0
kmalloc-64 648 720 64 60 1 : tunables 120 60 0 : slabdata 12 12 0
kmalloc-32 3018 3164 32 113 1 : tunables 120 60 0 : slabdata 28 28 0
kmem_cache 131 160 96 40 1 : tunables 120 60 0 : slabdata 4 4 0
-------------- next part --------------
# cat /proc/slabinfo
slabinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_sla>
ubi_wl_entry_slab 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
ubifs_inode_slab 0 0 368 11 1 : tunables 54 27 0 : slabdata 0 0 0
fib6_nodes 1 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip6_dst_cache 1 17 224 17 1 : tunables 120 60 0 : slabdata 1 1 0
PINGv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
RAWv6 4 11 704 11 2 : tunables 54 27 0 : slabdata 1 1 0
UDPLITEv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
UDPv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCPv6 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCPv6 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCPv6 0 0 1344 3 1 : tunables 24 12 0 : slabdata 0 0 0
sd_ext_cdb 2 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
nfs_direct_cache 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
nfs_commit_data 4 9 416 9 1 : tunables 54 27 0 : slabdata 1 1 0
nfs_write_data 32 36 608 6 1 : tunables 54 27 0 : slabdata 6 6 0
nfs_read_data 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_page 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fat_inode_cache 0 0 360 11 1 : tunables 54 27 0 : slabdata 0 0 0
fat_cache 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_transaction_s 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_inode 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_handle 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_head 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_table_s 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_record_s 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
ext4_xattr 0 0 48 78 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_free_data 0 0 40 93 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_allocation_context 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_prealloc_space 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_system_zone 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_io_end 0 0 40 93 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_extent_status 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
configfs_dir_cache 1 68 56 68 1 : tunables 120 60 0 : slabdata 1 1 0
kioctx 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
kiocb 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fanotify_response_event 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_event_private_data 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_inode_mark 12 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
dnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
dnotify_struct 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
dio 0 0 328 12 1 : tunables 54 27 0 : slabdata 0 0 0
fasync_cache 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
posix_timers_cache 0 0 152 26 1 : tunables 120 60 0 : slabdata 0 0 0
uid_cache 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
rpc_inode_cache 0 0 320 12 1 : tunables 54 27 0 : slabdata 0 0 0
rpc_buffers 8 8 2048 2 1 : tunables 24 12 0 : slabdata 4 4 0
rpc_tasks 8 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
UNIX 5 8 480 8 1 : tunables 54 27 0 : slabdata 1 1 0
UDP-Lite 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tcp_bind_bucket 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
inet_peer_cache 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
ip_fib_trie 3 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip_fib_alias 4 146 24 146 1 : tunables 120 60 0 : slabdata 1 1 0
ip_dst_cache 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
PING 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
RAW 1 7 576 7 1 : tunables 54 27 0 : slabdata 1 1 0
UDP 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCP 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCP 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCP 0 0 1216 3 1 : tunables 24 12 0 : slabdata 0 0 0
eventpoll_pwq 9 93 40 93 1 : tunables 120 60 0 : slabdata 1 1 0
eventpoll_epi 9 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
sgpool-128 2 2 2048 2 1 : tunables 24 12 0 : slabdata 1 1 0
sgpool-64 2 4 1024 4 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-32 2 8 512 8 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-16 2 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
sgpool-8 2 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
scsi_data_buffer 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
blkdev_queue 14 14 1032 7 2 : tunables 24 12 0 : slabdata 2 2 0
blkdev_requests 8 18 216 18 1 : tunables 120 60 0 : slabdata 1 1 0
blkdev_ioc 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event_holder 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event 1 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
bio-0 2 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-256 2 2 3072 2 2 : tunables 24 12 0 : slabdata 1 1 0
biovec-128 0 0 1536 5 2 : tunables 24 12 0 : slabdata 0 0 0
biovec-64 0 0 768 5 1 : tunables 54 27 0 : slabdata 0 0 0
biovec-16 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
sock_inode_cache 19 36 320 12 1 : tunables 54 27 0 : slabdata 3 3 0
skbuff_fclone_cache 0 0 352 11 1 : tunables 54 27 0 : slabdata 0 0 0
skbuff_head_cache 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
file_lock_cache 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
shmem_inode_cache 394 396 312 12 1 : tunables 54 27 0 : slabdata 33 33 0
pool_workqueue 6 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
proc_inode_cache 12 12 312 12 1 : tunables 54 27 0 : slabdata 1 1 0
sigqueue 0 0 144 27 1 : tunables 120 60 0 : slabdata 0 0 0
bdev_cache 13 18 416 9 1 : tunables 54 27 0 : slabdata 2 2 0
sysfs_dir_cache 2926 2940 64 60 1 : tunables 120 60 0 : slabdata 49 49 0
mnt_cache 20 24 160 24 1 : tunables 120 60 0 : slabdata 1 1 0
filp 65 144 160 24 1 : tunables 120 60 0 : slabdata 6 6 0
inode_cache 1564 1568 280 14 1 : tunables 54 27 0 : slabdata 112 112 0
dentry 2001 2059 136 29 1 : tunables 120 60 0 : slabdata 71 71 0
names_cache 1 1 4096 1 1 : tunables 24 12 0 : slabdata 1 1 0
buffer_head 0 0 56 68 1 : tunables 120 60 0 : slabdata 0 0 0
nsproxy 1 146 24 146 1 : tunables 120 60 0 : slabdata 1 1 0
vm_area_struct 267 352 88 44 1 : tunables 120 60 0 : slabdata 8 8 0
mm_struct 20 20 384 10 1 : tunables 54 27 0 : slabdata 2 2 0
fs_cache 23 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
files_cache 23 40 192 20 1 : tunables 120 60 0 : slabdata 2 2 0
signal_cache 42 42 512 7 1 : tunables 54 27 0 : slabdata 6 6 0
sighand_cache 33 33 1312 3 1 : tunables 24 12 0 : slabdata 11 11 0
task_struct 44 48 672 6 1 : tunables 54 27 0 : slabdata 8 8 0
cred_jar 53 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
anon_vma_chain 304 791 32 113 1 : tunables 120 60 0 : slabdata 7 7 0
anon_vma 146 438 24 146 1 : tunables 120 60 0 : slabdata 3 3 0
pid 45 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
radix_tree_node 131 143 296 13 1 : tunables 54 27 0 : slabdata 11 11 0
idr_layer_cache 62 63 1080 7 2 : tunables 24 12 0 : slabdata 9 9 0
kmalloc-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-2097152 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-1048576 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-524288 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-262144 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-65536 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-32768 2 2 32768 1 8 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-16384 1 1 16384 1 4 : tunables 8 4 0 : slabdata 1 1 0
kmalloc-8192 2 2 8192 1 2 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-4096 4 4 4096 1 1 : tunables 24 12 0 : slabdata 4 4 0
kmalloc-2048 28 28 2048 2 1 : tunables 24 12 0 : slabdata 14 14 0
kmalloc-1024 38 40 1024 4 1 : tunables 54 27 0 : slabdata 10 10 0
kmalloc-512 203 208 512 8 1 : tunables 54 27 0 : slabdata 26 26 0
kmalloc-256 195 195 256 15 1 : tunables 120 60 0 : slabdata 13 13 0
kmalloc-192 140 140 192 20 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-128 217 217 128 31 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-96 1111 1120 96 40 1 : tunables 120 60 0 : slabdata 28 28 0
kmalloc-64 621 660 64 60 1 : tunables 120 60 0 : slabdata 11 11 0
kmalloc-32 3056 3164 32 113 1 : tunables 120 60 0 : slabdata 28 28 0
kmem_cache 131 160 96 40 1 : tunables 120 60 0 : slabdata 4 4 0
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-03 14:54 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2014-01-03 14:54 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel, Ludovic Desroches
[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]
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.
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
[-- Attachment #2: 8456a64_reverted.log --]
[-- Type: text/plain, Size: 14408 bytes --]
# cat /proc/slabinfo
slabinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_sla>
ubi_wl_entry_slab 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
ubifs_inode_slab 0 0 368 10 1 : tunables 54 27 0 : slabdata 0 0 0
fib6_nodes 1 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip6_dst_cache 1 17 224 17 1 : tunables 120 60 0 : slabdata 1 1 0
PINGv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
RAWv6 4 11 704 11 2 : tunables 54 27 0 : slabdata 1 1 0
UDPLITEv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
UDPv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCPv6 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCPv6 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCPv6 0 0 1344 3 1 : tunables 24 12 0 : slabdata 0 0 0
sd_ext_cdb 2 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
nfs_direct_cache 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
nfs_commit_data 4 9 416 9 1 : tunables 54 27 0 : slabdata 1 1 0
nfs_write_data 32 36 608 6 1 : tunables 54 27 0 : slabdata 6 6 0
nfs_read_data 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_page 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fat_inode_cache 0 0 360 11 1 : tunables 54 27 0 : slabdata 0 0 0
fat_cache 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_transaction_s 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_inode 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_handle 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_head 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_table_s 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_record_s 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
ext4_xattr 0 0 48 78 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_free_data 0 0 40 92 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_allocation_context 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_prealloc_space 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_system_zone 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_io_end 0 0 40 92 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_extent_status 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
configfs_dir_cache 1 68 56 68 1 : tunables 120 60 0 : slabdata 1 1 0
kioctx 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
kiocb 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fanotify_response_event 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_event_private_data 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_inode_mark 12 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
dnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
dnotify_struct 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
dio 0 0 328 12 1 : tunables 54 27 0 : slabdata 0 0 0
fasync_cache 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
posix_timers_cache 0 0 152 26 1 : tunables 120 60 0 : slabdata 0 0 0
uid_cache 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
rpc_inode_cache 0 0 320 12 1 : tunables 54 27 0 : slabdata 0 0 0
rpc_buffers 8 8 2048 2 1 : tunables 24 12 0 : slabdata 4 4 0
rpc_tasks 8 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
UNIX 5 8 480 8 1 : tunables 54 27 0 : slabdata 1 1 0
UDP-Lite 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tcp_bind_bucket 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
inet_peer_cache 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0
ip_fib_trie 3 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip_fib_alias 4 145 24 145 1 : tunables 120 60 0 : slabdata 1 1 0
ip_dst_cache 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0
PING 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
RAW 1 7 576 7 1 : tunables 54 27 0 : slabdata 1 1 0
UDP 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCP 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCP 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCP 0 0 1216 3 1 : tunables 24 12 0 : slabdata 0 0 0
eventpoll_pwq 9 92 40 92 1 : tunables 120 60 0 : slabdata 1 1 0
eventpoll_epi 9 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
sgpool-128 2 2 2048 2 1 : tunables 24 12 0 : slabdata 1 1 0
sgpool-64 2 4 1024 4 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-32 2 8 512 8 1 : tunables 54 27 0 : slabdata 1 random: nonblocking pool is initialized
1 0
sgpool-16 2 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
sgpool-8 2 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
scsi_data_buffer 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
blkdev_queue 14 14 1032 7 2 : tunables 24 12 0 : slabdata 2 2 0
blkdev_requests 8 18 216 18 1 : tunables 120 60 0 : slabdata 1 1 0
blkdev_ioc 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event_holder 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event 1 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
bio-0 2 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-256 2 2 3072 2 2 : tunables 24 12 0 : slabdata 1 1 0
biovec-128 0 0 1536 5 2 : tunables 24 12 0 : slabdata 0 0 0
biovec-64 0 0 768 5 1 : tunables 54 27 0 : slabdata 0 0 0
biovec-16 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
sock_inode_cache 21 36 320 12 1 : tunables 54 27 0 : slabdata 3 3 0
skbuff_fclone_cache 0 0 352 11 1 : tunables 54 27 0 : slabdata 0 0 0
skbuff_head_cache 4 20 192 20 1 : tunables 120 60 0 : slabdata 1 1 0
file_lock_cache 4 35 112 35 1 : tunables 120 60 0 : slabdata 1 1 0
shmem_inode_cache 394 396 312 12 1 : tunables 54 27 0 : slabdata 33 33 0
pool_workqueue 6 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
proc_inode_cache 48 48 312 12 1 : tunables 54 27 0 : slabdata 4 4 0
sigqueue 0 0 144 27 1 : tunables 120 60 0 : slabdata 0 0 0
bdev_cache 13 18 416 9 1 : tunables 54 27 0 : slabdata 2 2 0
sysfs_dir_cache 2926 2940 64 60 1 : tunables 120 60 0 : slabdata 49 49 0
mnt_cache 20 24 160 24 1 : tunables 120 60 0 : slabdata 1 1 0
filp 96 120 160 24 1 : tunables 120 60 0 : slabdata 5 5 0
inode_cache 1563 1568 280 14 1 : tunables 54 27 0 : slabdata 112 112 0
dentry 2030 2030 136 29 1 : tunables 120 60 0 : slabdata 70 70 0
names_cache 1 1 4096 1 1 : tunables 24 12 0 : slabdata 1 1 0
buffer_head 0 0 56 68 1 : tunables 120 60 0 : slabdata 0 0 0
nsproxy 1 145 24 145 1 : tunables 120 60 0 : slabdata 1 1 0
vm_area_struct 215 396 88 44 1 : tunables 120 60 0 : slabdata 9 9 0
mm_struct 20 20 384 10 1 : tunables 54 27 0 : slabdata 2 2 0
fs_cache 11 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
files_cache 11 40 192 20 1 : tunables 120 60 0 : slabdata 2 2 0
signal_cache 29 42 512 7 1 : tunables 54 27 0 : slabdata 6 6 0
sighand_cache 33 33 1312 3 1 : tunables 24 12 0 : slabdata 11 11 0
task_struct 29 42 672 6 1 : tunables 54 27 0 : slabdata 7 7 0
cred_jar 40 120 96 40 1 : tunables 120 60 0 : slabdata 3 3 0
anon_vma_chain 254 678 32 113 1 : tunables 120 60 0 : slabdata 6 6 0
anon_vma 193 435 24 145 1 : tunables 120 60 0 : slabdata 3 3 0
pid 33 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
radix_tree_node 130 143 296 13 1 : tunables 54 27 0 : slabdata 11 11 0
idr_layer_cache 62 63 1080 7 2 : tunables 24 12 0 : slabdata 9 9 0
kmalloc-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-2097152 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-1048576 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-524288 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-262144 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-65536 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-32768 2 2 32768 1 8 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-16384 1 1 16384 1 4 : tunables 8 4 0 : slabdata 1 1 0
kmalloc-8192 2 2 8192 1 2 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-4096 4 4 4096 1 1 : tunables 24 12 0 : slabdata 4 4 0
kmalloc-2048 28 28 2048 2 1 : tunables 24 12 0 : slabdata 14 14 0
kmalloc-1024 39 44 1024 4 1 : tunables 54 27 0 : slabdata 11 11 0
kmalloc-512 204 208 512 8 1 : tunables 54 27 0 : slabdata 26 26 0
kmalloc-256 183 195 256 15 1 : tunables 120 60 0 : slabdata 13 13 0
kmalloc-192 134 140 192 20 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-128 204 210 128 30 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-96 1099 1120 96 40 1 : tunables 120 60 0 : slabdata 28 28 0
kmalloc-64 648 720 64 60 1 : tunables 120 60 0 : slabdata 12 12 0
kmalloc-32 3018 3164 32 113 1 : tunables 120 60 0 : slabdata 28 28 0
kmem_cache 131 160 96 40 1 : tunables 120 60 0 : slabdata 4 4 0
[-- Attachment #3: with_8456a64.log --]
[-- Type: text/plain, Size: 14367 bytes --]
# cat /proc/slabinfo
slabinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_sla>
ubi_wl_entry_slab 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
ubifs_inode_slab 0 0 368 11 1 : tunables 54 27 0 : slabdata 0 0 0
fib6_nodes 1 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip6_dst_cache 1 17 224 17 1 : tunables 120 60 0 : slabdata 1 1 0
PINGv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
RAWv6 4 11 704 11 2 : tunables 54 27 0 : slabdata 1 1 0
UDPLITEv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
UDPv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCPv6 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCPv6 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCPv6 0 0 1344 3 1 : tunables 24 12 0 : slabdata 0 0 0
sd_ext_cdb 2 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
nfs_direct_cache 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
nfs_commit_data 4 9 416 9 1 : tunables 54 27 0 : slabdata 1 1 0
nfs_write_data 32 36 608 6 1 : tunables 54 27 0 : slabdata 6 6 0
nfs_read_data 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_page 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fat_inode_cache 0 0 360 11 1 : tunables 54 27 0 : slabdata 0 0 0
fat_cache 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_transaction_s 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_inode 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_handle 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_head 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_table_s 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_record_s 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
ext4_xattr 0 0 48 78 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_free_data 0 0 40 93 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_allocation_context 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_prealloc_space 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_system_zone 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_io_end 0 0 40 93 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_extent_status 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
configfs_dir_cache 1 68 56 68 1 : tunables 120 60 0 : slabdata 1 1 0
kioctx 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
kiocb 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fanotify_response_event 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_event_private_data 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_inode_mark 12 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
dnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
dnotify_struct 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
dio 0 0 328 12 1 : tunables 54 27 0 : slabdata 0 0 0
fasync_cache 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
posix_timers_cache 0 0 152 26 1 : tunables 120 60 0 : slabdata 0 0 0
uid_cache 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
rpc_inode_cache 0 0 320 12 1 : tunables 54 27 0 : slabdata 0 0 0
rpc_buffers 8 8 2048 2 1 : tunables 24 12 0 : slabdata 4 4 0
rpc_tasks 8 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
UNIX 5 8 480 8 1 : tunables 54 27 0 : slabdata 1 1 0
UDP-Lite 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tcp_bind_bucket 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
inet_peer_cache 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
ip_fib_trie 3 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip_fib_alias 4 146 24 146 1 : tunables 120 60 0 : slabdata 1 1 0
ip_dst_cache 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
PING 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
RAW 1 7 576 7 1 : tunables 54 27 0 : slabdata 1 1 0
UDP 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCP 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCP 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCP 0 0 1216 3 1 : tunables 24 12 0 : slabdata 0 0 0
eventpoll_pwq 9 93 40 93 1 : tunables 120 60 0 : slabdata 1 1 0
eventpoll_epi 9 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
sgpool-128 2 2 2048 2 1 : tunables 24 12 0 : slabdata 1 1 0
sgpool-64 2 4 1024 4 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-32 2 8 512 8 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-16 2 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
sgpool-8 2 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
scsi_data_buffer 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
blkdev_queue 14 14 1032 7 2 : tunables 24 12 0 : slabdata 2 2 0
blkdev_requests 8 18 216 18 1 : tunables 120 60 0 : slabdata 1 1 0
blkdev_ioc 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event_holder 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event 1 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
bio-0 2 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-256 2 2 3072 2 2 : tunables 24 12 0 : slabdata 1 1 0
biovec-128 0 0 1536 5 2 : tunables 24 12 0 : slabdata 0 0 0
biovec-64 0 0 768 5 1 : tunables 54 27 0 : slabdata 0 0 0
biovec-16 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
sock_inode_cache 19 36 320 12 1 : tunables 54 27 0 : slabdata 3 3 0
skbuff_fclone_cache 0 0 352 11 1 : tunables 54 27 0 : slabdata 0 0 0
skbuff_head_cache 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
file_lock_cache 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
shmem_inode_cache 394 396 312 12 1 : tunables 54 27 0 : slabdata 33 33 0
pool_workqueue 6 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
proc_inode_cache 12 12 312 12 1 : tunables 54 27 0 : slabdata 1 1 0
sigqueue 0 0 144 27 1 : tunables 120 60 0 : slabdata 0 0 0
bdev_cache 13 18 416 9 1 : tunables 54 27 0 : slabdata 2 2 0
sysfs_dir_cache 2926 2940 64 60 1 : tunables 120 60 0 : slabdata 49 49 0
mnt_cache 20 24 160 24 1 : tunables 120 60 0 : slabdata 1 1 0
filp 65 144 160 24 1 : tunables 120 60 0 : slabdata 6 6 0
inode_cache 1564 1568 280 14 1 : tunables 54 27 0 : slabdata 112 112 0
dentry 2001 2059 136 29 1 : tunables 120 60 0 : slabdata 71 71 0
names_cache 1 1 4096 1 1 : tunables 24 12 0 : slabdata 1 1 0
buffer_head 0 0 56 68 1 : tunables 120 60 0 : slabdata 0 0 0
nsproxy 1 146 24 146 1 : tunables 120 60 0 : slabdata 1 1 0
vm_area_struct 267 352 88 44 1 : tunables 120 60 0 : slabdata 8 8 0
mm_struct 20 20 384 10 1 : tunables 54 27 0 : slabdata 2 2 0
fs_cache 23 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
files_cache 23 40 192 20 1 : tunables 120 60 0 : slabdata 2 2 0
signal_cache 42 42 512 7 1 : tunables 54 27 0 : slabdata 6 6 0
sighand_cache 33 33 1312 3 1 : tunables 24 12 0 : slabdata 11 11 0
task_struct 44 48 672 6 1 : tunables 54 27 0 : slabdata 8 8 0
cred_jar 53 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
anon_vma_chain 304 791 32 113 1 : tunables 120 60 0 : slabdata 7 7 0
anon_vma 146 438 24 146 1 : tunables 120 60 0 : slabdata 3 3 0
pid 45 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
radix_tree_node 131 143 296 13 1 : tunables 54 27 0 : slabdata 11 11 0
idr_layer_cache 62 63 1080 7 2 : tunables 24 12 0 : slabdata 9 9 0
kmalloc-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-2097152 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-1048576 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-524288 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-262144 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-65536 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-32768 2 2 32768 1 8 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-16384 1 1 16384 1 4 : tunables 8 4 0 : slabdata 1 1 0
kmalloc-8192 2 2 8192 1 2 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-4096 4 4 4096 1 1 : tunables 24 12 0 : slabdata 4 4 0
kmalloc-2048 28 28 2048 2 1 : tunables 24 12 0 : slabdata 14 14 0
kmalloc-1024 38 40 1024 4 1 : tunables 54 27 0 : slabdata 10 10 0
kmalloc-512 203 208 512 8 1 : tunables 54 27 0 : slabdata 26 26 0
kmalloc-256 195 195 256 15 1 : tunables 120 60 0 : slabdata 13 13 0
kmalloc-192 140 140 192 20 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-128 217 217 128 31 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-96 1111 1120 96 40 1 : tunables 120 60 0 : slabdata 28 28 0
kmalloc-64 621 660 64 60 1 : tunables 120 60 0 : slabdata 11 11 0
kmalloc-32 3056 3164 32 113 1 : tunables 120 60 0 : slabdata 28 28 0
kmem_cache 131 160 96 40 1 : tunables 120 60 0 : slabdata 4 4 0
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2014-01-03 14:54 ` Ludovic Desroches
(?)
@ 2014-01-06 0:26 ` Joonsoo Kim
-1 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2014-01-06 0:26 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
Cc: Christoph Lameter, Pekka Enberg
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-06 0:26 ` Joonsoo Kim
0 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2014-01-06 0:26 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-06 0:26 ` Joonsoo Kim
0 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2014-01-06 0:26 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
Cc: Christoph Lameter, Pekka Enberg
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>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2014-01-06 0:26 ` Joonsoo Kim
(?)
(?)
@ 2014-01-06 9:34 ` Ludovic Desroches
-1 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2014-01-06 9:34 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel,
Christoph Lameter, Pekka Enberg, Ludovic Desroches
On Mon, Jan 06, 2014 at 09:26:48AM +0900, Joonsoo Kim wrote:
> 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.
Yes this patch solves my problem.
>
> I will think about this problem more deeply and report the solution to you
> as soon as possible.
Ok thanks.
>
> 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>
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-06 9:34 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2014-01-06 9:34 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 06, 2014 at 09:26:48AM +0900, Joonsoo Kim wrote:
> 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.
Yes this patch solves my problem.
>
> I will think about this problem more deeply and report the solution to you
> as soon as possible.
Ok thanks.
>
> 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 at kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email at kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-06 9:34 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2014-01-06 9:34 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel,
Christoph Lameter, Pekka Enberg, Ludovic Desroches
On Mon, Jan 06, 2014 at 09:26:48AM +0900, Joonsoo Kim wrote:
> 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.
Yes this patch solves my problem.
>
> I will think about this problem more deeply and report the solution to you
> as soon as possible.
Ok thanks.
>
> 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>
--
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>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-06 9:34 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2014-01-06 9:34 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel,
Christoph Lameter, Pekka Enberg, Ludovic Desroches
On Mon, Jan 06, 2014 at 09:26:48AM +0900, Joonsoo Kim wrote:
> 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.
Yes this patch solves my problem.
>
> I will think about this problem more deeply and report the solution to you
> as soon as possible.
Ok thanks.
>
> 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>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2014-01-06 9:34 ` Ludovic Desroches
(?)
@ 2014-01-09 7:16 ` Joonsoo Kim
-1 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2014-01-09 7:16 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel,
Christoph Lameter, Pekka Enberg
On Mon, Jan 06, 2014 at 10:34:09AM +0100, Ludovic Desroches wrote:
> On Mon, Jan 06, 2014 at 09:26:48AM +0900, Joonsoo Kim wrote:
> > 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.
>
> Yes this patch solves my problem.
>
> >
> > I will think about this problem more deeply and report the solution to you
> > as soon as possible.
>
> Ok thanks.
>
Hello,
That patch will be merged through Andrew's tree.
Use it to fix your problem :)
Thanks.
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-09 7:16 ` Joonsoo Kim
0 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2014-01-09 7:16 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 06, 2014 at 10:34:09AM +0100, Ludovic Desroches wrote:
> On Mon, Jan 06, 2014 at 09:26:48AM +0900, Joonsoo Kim wrote:
> > 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.
>
> Yes this patch solves my problem.
>
> >
> > I will think about this problem more deeply and report the solution to you
> > as soon as possible.
>
> Ok thanks.
>
Hello,
That patch will be merged through Andrew's tree.
Use it to fix your problem :)
Thanks.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-09 7:16 ` Joonsoo Kim
0 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2014-01-09 7:16 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel,
Christoph Lameter, Pekka Enberg
On Mon, Jan 06, 2014 at 10:34:09AM +0100, Ludovic Desroches wrote:
> On Mon, Jan 06, 2014 at 09:26:48AM +0900, Joonsoo Kim wrote:
> > 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.
>
> Yes this patch solves my problem.
>
> >
> > I will think about this problem more deeply and report the solution to you
> > as soon as possible.
>
> Ok thanks.
>
Hello,
That patch will be merged through Andrew's tree.
Use it to fix your problem :)
Thanks.
--
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>
^ permalink raw reply [flat|nested] 45+ messages in thread