Re: Kernel WARNING splat in 3.14-rc1

2014-02-03 Thread Paul E. McKenney
On Mon, Feb 03, 2014 at 05:08:11PM -0600, Larry Finger wrote:
> On 02/03/2014 02:39 PM, David Rientjes wrote:
> >Commit c65c1877bd68 ("slub: use lockdep_assert_held") incorrectly required
> >that add_full() and remove_full() hold n->list_lock.  The lock is only
> >taken when kmem_cache_debug(s), since that's the only time it actually
> >does anything.
> >
> >Require that the lock only be taken under such a condition.
> >
> >Reported-by: Larry Finger 
> >Signed-off-by: David Rientjes 
> 
> You may add a "Tested-by: Larry Finger ".
> The patch cleans up the splat on my system. Thanks for the quick
> response.

Please feel free to add mine as well:

Tested-by: Paul E. McKenney 

And also feel free to ignore my patch as well.  ;-)

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Kernel WARNING splat in 3.14-rc1

2014-02-03 Thread Larry Finger

On 02/03/2014 02:39 PM, David Rientjes wrote:

Commit c65c1877bd68 ("slub: use lockdep_assert_held") incorrectly required
that add_full() and remove_full() hold n->list_lock.  The lock is only
taken when kmem_cache_debug(s), since that's the only time it actually
does anything.

Require that the lock only be taken under such a condition.

Reported-by: Larry Finger 
Signed-off-by: David Rientjes 


You may add a "Tested-by: Larry Finger ". The patch 
cleans up the splat on my system. Thanks for the quick response.


Larry

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Kernel WARNING splat in 3.14-rc1

2014-02-03 Thread Christoph Lameter
On Mon, 3 Feb 2014, David Rientjes wrote:

> Commit c65c1877bd68 ("slub: use lockdep_assert_held") incorrectly required
> that add_full() and remove_full() hold n->list_lock.  The lock is only
> taken when kmem_cache_debug(s), since that's the only time it actually
> does anything.

Acked-by: Christoph Lameter 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Kernel WARNING splat in 3.14-rc1

2014-02-03 Thread David Rientjes
Commit c65c1877bd68 ("slub: use lockdep_assert_held") incorrectly required 
that add_full() and remove_full() hold n->list_lock.  The lock is only 
taken when kmem_cache_debug(s), since that's the only time it actually 
does anything.

Require that the lock only be taken under such a condition.

Reported-by: Larry Finger 
Signed-off-by: David Rientjes 
---
 mm/slub.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1004,21 +1004,19 @@ static inline void slab_free_hook(struct kmem_cache *s, 
void *x)
 static void add_full(struct kmem_cache *s,
struct kmem_cache_node *n, struct page *page)
 {
-   lockdep_assert_held(>list_lock);
-
if (!(s->flags & SLAB_STORE_USER))
return;
 
+   lockdep_assert_held(>list_lock);
list_add(>lru, >full);
 }
 
 static void remove_full(struct kmem_cache *s, struct kmem_cache_node *n, 
struct page *page)
 {
-   lockdep_assert_held(>list_lock);
-
if (!(s->flags & SLAB_STORE_USER))
return;
 
+   lockdep_assert_held(>list_lock);
list_del(>lru);
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Kernel WARNING splat in 3.14-rc1

2014-02-03 Thread Larry Finger
On my freshly built 3.14-rc1 kernel, I get the following new warning splat from 
slub:


[   69.008845] [ cut here ]
[   69.008861] WARNING: CPU: 0 PID: 1578 at mm/slub.c:1007 
deactivate_slab+0x4bb/0x520()
[   69.008863] Modules linked in: rfcomm nfs fscache af_packet lockd sunrpc bnep 
rtl8723be arc4 rtl8723_common b43 rtl_pci rtlwifi mac80211 cfg80211 btusb bl
uetooth powernow_k8 kvm_amd kvm snd_hda_intel snd_hda_codec bcma snd_hwdep r852 
sdhci_pci sdhci snd_pcm sr_mod snd_seq ssb cdrom forcedeth sm_common pcspkr s
nd_timer serio_raw snd_seq_device snd nand mtd mmc_core rfkill ata_generic 
pata_amd nand_ids nand_bch bch nand_ecc 6lowpan_iphc soundcore btcoexist r592 ac v

ideo memstick button battery sg dm_mod autofs4 thermal processor thermal_sys 
hwmon
[   69.008934] CPU: 0 PID: 1578 Comm: akonadi_newmail Not tainted 
3.14.0-rc1-wl+ #60
[   69.008936] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook 
PC/30D6, BIOS F.27 11/27/2008

[   69.008939]  0009 880085ab1cd0 815ee4a0 

[   69.008945]  880085ab1d08 8104e768 ea0001ee69c0 
8800bb401800
[   69.008950]   8800bb400c80 0002 
880085ab1d18
[   69.008956] Call Trace:
[   69.008965]  [] dump_stack+0x4d/0x6f
[   69.008971]  [] warn_slowpath_common+0x78/0xa0
[   69.008976]  [] warn_slowpath_null+0x15/0x20
[   69.008980]  [] deactivate_slab+0x4bb/0x520
[   69.008985]  [] ? new_slab+0x1f9/0x300
[   69.008989]  [] __slab_alloc+0x34d/0x4f5
[   69.008994]  [] ? kmem_cache_alloc+0x18b/0x1c0
[   69.008999]  [] ? prepare_creds+0x21/0x1a0
[   69.009003]  [] ? prepare_creds+0x21/0x1a0
[   69.009007]  [] kmem_cache_alloc+0x18b/0x1c0
[   69.009011]  [] prepare_creds+0x21/0x1a0
[   69.009016]  [] SyS_access+0x35/0x1f0
[   69.009019]  [] system_call_fastpath+0x16/0x1b
[   69.009019] ---[ end trace c63f75644bfb030a ]---

There is a similar warning for my other CPU as well. The warning comes from 
"lockdep_assert_held(>list_lock);".


If needed, I can bisect this issue.

Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Kernel WARNING splat in 3.14-rc1

2014-02-03 Thread Larry Finger
On my freshly built 3.14-rc1 kernel, I get the following new warning splat from 
slub:


[   69.008845] [ cut here ]
[   69.008861] WARNING: CPU: 0 PID: 1578 at mm/slub.c:1007 
deactivate_slab+0x4bb/0x520()
[   69.008863] Modules linked in: rfcomm nfs fscache af_packet lockd sunrpc bnep 
rtl8723be arc4 rtl8723_common b43 rtl_pci rtlwifi mac80211 cfg80211 btusb bl
uetooth powernow_k8 kvm_amd kvm snd_hda_intel snd_hda_codec bcma snd_hwdep r852 
sdhci_pci sdhci snd_pcm sr_mod snd_seq ssb cdrom forcedeth sm_common pcspkr s
nd_timer serio_raw snd_seq_device snd nand mtd mmc_core rfkill ata_generic 
pata_amd nand_ids nand_bch bch nand_ecc 6lowpan_iphc soundcore btcoexist r592 ac v

ideo memstick button battery sg dm_mod autofs4 thermal processor thermal_sys 
hwmon
[   69.008934] CPU: 0 PID: 1578 Comm: akonadi_newmail Not tainted 
3.14.0-rc1-wl+ #60
[   69.008936] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook 
PC/30D6, BIOS F.27 11/27/2008

[   69.008939]  0009 880085ab1cd0 815ee4a0 

[   69.008945]  880085ab1d08 8104e768 ea0001ee69c0 
8800bb401800
[   69.008950]   8800bb400c80 0002 
880085ab1d18
[   69.008956] Call Trace:
[   69.008965]  [815ee4a0] dump_stack+0x4d/0x6f
[   69.008971]  [8104e768] warn_slowpath_common+0x78/0xa0
[   69.008976]  [8104e845] warn_slowpath_null+0x15/0x20
[   69.008980]  [8118581b] deactivate_slab+0x4bb/0x520
[   69.008985]  [81183429] ? new_slab+0x1f9/0x300
[   69.008989]  [815ebe57] __slab_alloc+0x34d/0x4f5
[   69.008994]  [81185a6b] ? kmem_cache_alloc+0x18b/0x1c0
[   69.008999]  [810770d1] ? prepare_creds+0x21/0x1a0
[   69.009003]  [810770d1] ? prepare_creds+0x21/0x1a0
[   69.009007]  [81185a6b] kmem_cache_alloc+0x18b/0x1c0
[   69.009011]  [810770d1] prepare_creds+0x21/0x1a0
[   69.009016]  [8119f955] SyS_access+0x35/0x1f0
[   69.009019]  [815fe8a2] system_call_fastpath+0x16/0x1b
[   69.009019] ---[ end trace c63f75644bfb030a ]---

There is a similar warning for my other CPU as well. The warning comes from 
lockdep_assert_held(n-list_lock);.


If needed, I can bisect this issue.

Larry
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Kernel WARNING splat in 3.14-rc1

2014-02-03 Thread David Rientjes
Commit c65c1877bd68 (slub: use lockdep_assert_held) incorrectly required 
that add_full() and remove_full() hold n-list_lock.  The lock is only 
taken when kmem_cache_debug(s), since that's the only time it actually 
does anything.

Require that the lock only be taken under such a condition.

Reported-by: Larry Finger larry.fin...@lwfinger.net
Signed-off-by: David Rientjes rient...@google.com
---
 mm/slub.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1004,21 +1004,19 @@ static inline void slab_free_hook(struct kmem_cache *s, 
void *x)
 static void add_full(struct kmem_cache *s,
struct kmem_cache_node *n, struct page *page)
 {
-   lockdep_assert_held(n-list_lock);
-
if (!(s-flags  SLAB_STORE_USER))
return;
 
+   lockdep_assert_held(n-list_lock);
list_add(page-lru, n-full);
 }
 
 static void remove_full(struct kmem_cache *s, struct kmem_cache_node *n, 
struct page *page)
 {
-   lockdep_assert_held(n-list_lock);
-
if (!(s-flags  SLAB_STORE_USER))
return;
 
+   lockdep_assert_held(n-list_lock);
list_del(page-lru);
 }
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Kernel WARNING splat in 3.14-rc1

2014-02-03 Thread Christoph Lameter
On Mon, 3 Feb 2014, David Rientjes wrote:

 Commit c65c1877bd68 (slub: use lockdep_assert_held) incorrectly required
 that add_full() and remove_full() hold n-list_lock.  The lock is only
 taken when kmem_cache_debug(s), since that's the only time it actually
 does anything.

Acked-by: Christoph Lameter c...@linux.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Kernel WARNING splat in 3.14-rc1

2014-02-03 Thread Larry Finger

On 02/03/2014 02:39 PM, David Rientjes wrote:

Commit c65c1877bd68 (slub: use lockdep_assert_held) incorrectly required
that add_full() and remove_full() hold n-list_lock.  The lock is only
taken when kmem_cache_debug(s), since that's the only time it actually
does anything.

Require that the lock only be taken under such a condition.

Reported-by: Larry Finger larry.fin...@lwfinger.net
Signed-off-by: David Rientjes rient...@google.com


You may add a Tested-by: Larry Finger larry.fin...@lwfinger.net. The patch 
cleans up the splat on my system. Thanks for the quick response.


Larry

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Kernel WARNING splat in 3.14-rc1

2014-02-03 Thread Paul E. McKenney
On Mon, Feb 03, 2014 at 05:08:11PM -0600, Larry Finger wrote:
 On 02/03/2014 02:39 PM, David Rientjes wrote:
 Commit c65c1877bd68 (slub: use lockdep_assert_held) incorrectly required
 that add_full() and remove_full() hold n-list_lock.  The lock is only
 taken when kmem_cache_debug(s), since that's the only time it actually
 does anything.
 
 Require that the lock only be taken under such a condition.
 
 Reported-by: Larry Finger larry.fin...@lwfinger.net
 Signed-off-by: David Rientjes rient...@google.com
 
 You may add a Tested-by: Larry Finger larry.fin...@lwfinger.net.
 The patch cleans up the splat on my system. Thanks for the quick
 response.

Please feel free to add mine as well:

Tested-by: Paul E. McKenney paul...@linux.vnet.ibm.com

And also feel free to ignore my patch as well.  ;-)

Thanx, Paul

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/