* Re: Occasional oops with IPSec and IPv6.
From: Nick Bowler @ 2011-11-21 15:12 UTC (permalink / raw)
To: Timo Teräs; +Cc: Eric Dumazet, netdev, David S. Miller
In-Reply-To: <4EC75C99.4000304@iki.fi>
On 2011-11-19 09:36 +0200, Timo Teräs wrote:
> On 11/18/2011 11:21 PM, Nick Bowler wrote:
> > On 2011-11-18 22:06 +0200, Timo Teräs wrote:
> >> Alternatively, we could just run the "slow path" unconditionally with
> >> the test load to see if it fixes the issue. At least that'd be pretty
> >> good test if it's a problem in the ipv6 fragmentation code or something
> >> else.
> >
> > Good call. I replaced the "correct geometry" check with an
> > unconditional "goto slow_path_clean;", and I can no longer reproduce the
> > crash. So at the very least, I have a workaround now. (I still have
> > Herbert Xu's six patches applied on top of Linus' master).
>
> Ok, so it's most likely ipv6 code issue then. My change just happened to
> trigger it.
>
> > I then tried the smaller change above, but this does not correct the
> > issue.
>
> That's not it then (likely).
>
> I did notice that the headroom of the main skb is never checked. So my
> other suggestion is to try something like:
>
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 1c9bf8b..735c4dc 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -668,7 +668,8 @@ int ip6_fragment(struct sk_buff *skb, int
> (*output)(struct sk_buff *))
>
> if (first_len - hlen > mtu ||
> ((first_len - hlen) & 7) ||
> - skb_cloned(skb))
> + skb_cloned(skb) ||
> + skb_headroom(skb) < sizeof(struct frag_hdr))
> goto slow_path;
>
> skb_walk_frags(skb, frag) {
Tried this (still on top of Herbert Xu's patch set) to no avail; the
crash still occurs :(.
Using the unconditional slow path workaround, I ran the test over the
weekend and it did not crash, so that seems to be stable.
> Other than that, I hope some of the ipv6 people could take a look at it.
> But the problem is that somewhere some headroom check isn't taking
> place, or is checking for too little of headroom.
Thanks,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* Re: [patch] fix error handle in ip_mc_add_src()
From: Eric Dumazet @ 2011-11-21 15:24 UTC (permalink / raw)
To: Jun Zhao; +Cc: davem, netdev
In-Reply-To: <1321887946.14281.27.camel@barry.pixelworks.com>
Le lundi 21 novembre 2011 à 23:05 +0800, Jun Zhao a écrit :
> When add sources to interface failure, need to roll back the sfcount[MODE]
> to before state. We need to match it corresponding.
>
Missing "---" separator
> diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
> index c7472ef..276719a 100644
> --- a/net/ipv4/igmp.c
> +++ b/net/ipv4/igmp.c
> @@ -1716,7 +1716,8 @@ static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
> if (err) {
> int j;
>
> - pmc->sfcount[sfmode]--;
> + if(!delta)
Missing space, should be : if (!delta)
> + pmc->sfcount[sfmode]--;
> for (j=0; j<i; j++)
> (void) ip_mc_del1_src(pmc, sfmode, &psfsrc[j]);
> } else if (isexclude != (pmc->sfcount[MCAST_EXCLUDE] != 0)) {
>
> Signed-off-by: Jun Zhao <mypopydev@gmail.com>
>
Your "Signed-off-by:" should come before actual patch
Please read Documentation/SubmittingPatches
Thanks
^ permalink raw reply
* Re: [patch] fix error handle in ip_mc_add_src()
From: Jun Zhao @ 2011-11-21 15:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev
In-Reply-To: <1321889066.10470.10.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Mon, 2011-11-21 at 16:24 +0100, Eric Dumazet wrote:
> Le lundi 21 novembre 2011 à 23:05 +0800, Jun Zhao a écrit :
> > When add sources to interface failure, need to roll back the sfcount[MODE]
> > to before state. We need to match it corresponding.
> >
>
> Missing "---" separator
>
> > diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
> > index c7472ef..276719a 100644
> > --- a/net/ipv4/igmp.c
> > +++ b/net/ipv4/igmp.c
> > @@ -1716,7 +1716,8 @@ static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
> > if (err) {
> > int j;
> >
> > - pmc->sfcount[sfmode]--;
> > + if(!delta)
>
> Missing space, should be : if (!delta)
>
> > + pmc->sfcount[sfmode]--;
> > for (j=0; j<i; j++)
> > (void) ip_mc_del1_src(pmc, sfmode, &psfsrc[j]);
> > } else if (isexclude != (pmc->sfcount[MCAST_EXCLUDE] != 0)) {
> >
> > Signed-off-by: Jun Zhao <mypopydev@gmail.com>
> >
>
> Your "Signed-off-by:" should come before actual patch
>
> Please read Documentation/SubmittingPatches
>
> Thanks
>
>
>
Tks, Eric Dumazet , I will re-submit this patch and follow the format.
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Markus Trippelsdorf @ 2011-11-21 15:36 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alex,Shi, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, tj
In-Reply-To: <1321884966.10470.2.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 2011.11.21 at 15:16 +0100, Eric Dumazet wrote:
> Le lundi 21 novembre 2011 à 14:15 +0100, Markus Trippelsdorf a écrit :
>
> > I've enabled CONFIG_SLUB_DEBUG_ON and this is what happend:
> >
>
> Thanks
>
> Please continue to provide more samples.
>
> There is something wrong somewhere, but where exactly, its hard to say.
New sample. This one points to lib/idr.c:
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
radeon 0000:01:05.0: setting latency timer to 64
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE0000
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon 0000:01:05.0: VRAM: 128M 0x00000000C0000000 - 0x00000000C7FFFFFF (128M used)
radeon 0000:01:05.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone kernel: Available graphics memory: 4083428 kiB.
[TTM] Zone dma32: Available graphics memory: 2097152 kiB.
[TTM] Initializing pool allocator.
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
radeon 0000:01:05.0: WB enabled
[drm] ring test succeeded in 1 usecs
[drm] radeon: ib pool ready.
[drm] ib test succeeded in 0 usecs
=============================================================================
BUG idr_layer_cache: Poison overwritten
-----------------------------------------------------------------------------
INFO: 0xffff880215650800-0xffff880215650803. First byte 0x0 instead of 0x6b
INFO: Slab 0xffffea0008559400 objects=18 used=18 fp=0x (null) flags=0x4000000000004080
INFO: Object 0xffff8802156506d0 @offset=1744 fp=0xffff880215650a38
Bytes b4 ffff8802156506c0: a4 6f fb ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a .o......ZZZZZZZZ
Object ffff8802156506d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156506e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156506f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650700: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650710: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650720: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650730: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650740: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650750: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650770: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650780: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650790: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156507a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156507b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156507c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156507d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156507e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156507f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
Object ffff880215650810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650820: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650830: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650840: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650850: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650860: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650870: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650880: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215650890: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156508a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156508b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156508c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156508d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156508e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
Redzone ffff8802156508f0: bb bb bb bb bb bb bb bb ........
Padding ffff880215650a30: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
Pid: 1, comm: swapper Not tainted 3.2.0-rc2-00274-g6fe4c6d #71
Call Trace:
[<ffffffff81101cf8>] ? print_section+0x38/0x40
[<ffffffff811021f3>] print_trailer+0xe3/0x150
[<ffffffff811023f0>] check_bytes_and_report+0xe0/0x100
[<ffffffff811031e6>] check_object+0x1c6/0x240
[<ffffffff812031f0>] ? idr_pre_get+0x60/0x90
[<ffffffff814c5c43>] alloc_debug_processing+0x62/0xe4
[<ffffffff814c64f1>] __slab_alloc.constprop.69+0x1a4/0x1e0
[<ffffffff8129ae77>] ? drm_property_create+0x47/0x110
[<ffffffff812031f0>] ? idr_pre_get+0x60/0x90
[<ffffffff81104db1>] kmem_cache_alloc+0x121/0x150
[<ffffffff812031f0>] ? idr_pre_get+0x60/0x90
[<ffffffff812031f0>] idr_pre_get+0x60/0x90
[<ffffffff8129870a>] drm_mode_object_get+0x6a/0xc0
[<ffffffff8129ae95>] drm_property_create+0x65/0x110
[<ffffffff8129b15d>] drm_mode_config_init+0xfd/0x190
[<ffffffff812e12ad>] radeon_modeset_init+0x1d/0x860
[<ffffffff813211c7>] ? radeon_acpi_init+0x87/0xc0
[<ffffffff812c37b8>] radeon_driver_load_kms+0xf8/0x150
[<ffffffff81295a06>] drm_get_pci_dev+0x186/0x2d0
[<ffffffff814bf1fd>] ? radeon_pci_probe+0x9e/0xb8
[<ffffffff814bf20f>] radeon_pci_probe+0xb0/0xb8
[<ffffffff8121be15>] pci_device_probe+0x75/0xa0
[<ffffffff81324e1a>] ? driver_sysfs_add+0x7a/0xb0
[<ffffffff81325021>] driver_probe_device+0x71/0x190
[<ffffffff813251db>] __driver_attach+0x9b/0xa0
[<ffffffff81325140>] ? driver_probe_device+0x190/0x190
[<ffffffff81323e0d>] bus_for_each_dev+0x4d/0x90
[<ffffffff813252f9>] driver_attach+0x19/0x20
[<ffffffff81324598>] bus_add_driver+0x188/0x250
[<ffffffff81325942>] driver_register+0x72/0x150
[<ffffffff81321de5>] ? device_add+0x75/0x600
[<ffffffff8121bb7d>] __pci_register_driver+0x5d/0xd0
[<ffffffff81295c54>] drm_pci_init+0x104/0x120
[<ffffffff818abefa>] ? ttm_init+0x62/0x62
[<ffffffff818abfe1>] radeon_init+0xe7/0xe9
[<ffffffff81890883>] do_one_initcall+0x7a/0x129
[<ffffffff818909cc>] kernel_init+0x9a/0x114
[<ffffffff814cddb4>] kernel_thread_helper+0x4/0x10
[<ffffffff81890932>] ? do_one_initcall+0x129/0x129
[<ffffffff814cddb0>] ? gs_change+0xb/0xb
FIX idr_layer_cache: Restoring 0xffff880215650800-0xffff880215650803=0x6b
FIX idr_layer_cache: Marking all objects used
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm] VGA
[drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm] Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm] DVI-D
[drm] HPD3
[drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm] Encoders:
[drm] DFP3: INTERNAL_KLDSCP_LVTMA
[drm] radeon: power management initialized
[drm] fb mappable at 0xF0142000
[drm] vram apper at 0xF0000000
[drm] size 7299072
[drm] fb depth is 24
[drm] pitch is 6912
fbcon: radeondrmfb (fb0) is primary device
Console: switching to colour frame buffer device 131x105
...
--
Markus
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [patch] fix error handle in ip_mc_add_src()
From: David Stevens @ 2011-11-21 15:37 UTC (permalink / raw)
To: Jun Zhao; +Cc: davem, Eric Dumazet, netdev, netdev-owner
In-Reply-To: <1321889410.14281.31.camel@barry.pixelworks.com>
With Eric's changes,
Acked-by: David L Stevens <dlstevens@us.ibm.com>
Good catch!
+-DLS
netdev-owner@vger.kernel.org wrote on 11/21/2011 07:30:10 AM:
> From: Jun Zhao <mypopydev@gmail.com>
> To: Eric Dumazet <eric.dumazet@gmail.com>,
> Cc: davem@davemloft.net, netdev@vger.kernel.org
> Date: 11/21/2011 07:32 AM
> Subject: Re: [patch] fix error handle in ip_mc_add_src()
> Sent by: netdev-owner@vger.kernel.org
>
> On Mon, 2011-11-21 at 16:24 +0100, Eric Dumazet wrote:
> > Le lundi 21 novembre 2011 à 23:05 +0800, Jun Zhao a écrit :
> > > When add sources to interface failure, need to roll back the
> sfcount[MODE]
> > > to before state. We need to match it corresponding.
> > >
> >
> > Missing "---" separator
> >
> > > diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
> > > index c7472ef..276719a 100644
> > > --- a/net/ipv4/igmp.c
> > > +++ b/net/ipv4/igmp.c
> > > @@ -1716,7 +1716,8 @@ static int ip_mc_add_src(struct in_device
> *in_dev, __be32 *pmca, int sfmode,
> > > if (err) {
> > > int j;
> > >
> > > - pmc->sfcount[sfmode]--;
> > > + if(!delta)
> >
> > Missing space, should be : if (!delta)
> >
> > > + pmc->sfcount[sfmode]--;
> > > for (j=0; j<i; j++)
> > > (void) ip_mc_del1_src(pmc, sfmode, &psfsrc[j]);
> > > } else if (isexclude != (pmc->sfcount[MCAST_EXCLUDE] != 0)) {
> > >
> > > Signed-off-by: Jun Zhao <mypopydev@gmail.com>
> > >
> >
> > Your "Signed-off-by:" should come before actual patch
> >
> > Please read Documentation/SubmittingPatches
> >
> > Thanks
> >
> >
> >
>
> Tks, Eric Dumazet , I will re-submit this patch and follow the format.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Eric Dumazet @ 2011-11-21 15:48 UTC (permalink / raw)
To: Markus Trippelsdorf
Cc: Alex,Shi, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, tj
In-Reply-To: <20111121153621.GA1678@x4.trippels.de>
Le lundi 21 novembre 2011 à 16:36 +0100, Markus Trippelsdorf a écrit :
> On 2011.11.21 at 15:16 +0100, Eric Dumazet wrote:
> > Le lundi 21 novembre 2011 à 14:15 +0100, Markus Trippelsdorf a écrit :
> >
> > > I've enabled CONFIG_SLUB_DEBUG_ON and this is what happend:
> > >
> >
> > Thanks
> >
> > Please continue to provide more samples.
> >
> > There is something wrong somewhere, but where exactly, its hard to say.
>
> New sample. This one points to lib/idr.c:
>
> [drm] Initialized drm 1.1.0 20060810
> [drm] radeon defaulting to kernel modesetting.
> [drm] radeon kernel modesetting enabled.
> radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> radeon 0000:01:05.0: setting latency timer to 64
> [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
> [drm] register mmio base: 0xFBEE0000
> [drm] register mmio size: 65536
> ATOM BIOS: 113
> radeon 0000:01:05.0: VRAM: 128M 0x00000000C0000000 - 0x00000000C7FFFFFF (128M used)
> radeon 0000:01:05.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF
> [drm] Detected VRAM RAM=128M, BAR=128M
> [drm] RAM width 32bits DDR
> [TTM] Zone kernel: Available graphics memory: 4083428 kiB.
> [TTM] Zone dma32: Available graphics memory: 2097152 kiB.
> [TTM] Initializing pool allocator.
> [drm] radeon: 128M of VRAM memory ready
> [drm] radeon: 512M of GTT memory ready.
> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [drm] Driver supports precise vblank timestamp query.
> [drm] radeon: irq initialized.
> [drm] GART: num cpu pages 131072, num gpu pages 131072
> [drm] Loading RS780 Microcode
> [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
> radeon 0000:01:05.0: WB enabled
> [drm] ring test succeeded in 1 usecs
> [drm] radeon: ib pool ready.
> [drm] ib test succeeded in 0 usecs
> =============================================================================
> BUG idr_layer_cache: Poison overwritten
> -----------------------------------------------------------------------------
Thanks, could you now add "CONFIG_DEBUG_PAGEALLOC=y" in your config as
well ?
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Markus Trippelsdorf @ 2011-11-21 15:51 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alex,Shi, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, tj
In-Reply-To: <20111121153621.GA1678@x4.trippels.de>
On 2011.11.21 at 16:36 +0100, Markus Trippelsdorf wrote:
> On 2011.11.21 at 15:16 +0100, Eric Dumazet wrote:
> > Le lundi 21 novembre 2011 à 14:15 +0100, Markus Trippelsdorf a écrit :
> >
> > > I've enabled CONFIG_SLUB_DEBUG_ON and this is what happend:
> > >
> >
> > Thanks
> >
> > Please continue to provide more samples.
> >
> > There is something wrong somewhere, but where exactly, its hard to say.
>
> =============================================================================
> BUG idr_layer_cache: Poison overwritten
> -----------------------------------------------------------------------------
>
> INFO: 0xffff880215650800-0xffff880215650803. First byte 0x0 instead of 0x6b
> INFO: Slab 0xffffea0008559400 objects=18 used=18 fp=0x (null) flags=0x4000000000004080
> INFO: Object 0xffff8802156506d0 @offset=1744 fp=0xffff880215650a38
>
> Bytes b4 ffff8802156506c0: a4 6f fb ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a .o......ZZZZZZZZ
> Object ffff8802156506d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156506e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156506f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650700: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650710: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650720: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650730: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650740: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650750: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650770: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650780: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650790: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156507a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156507b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156507c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156507d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156507e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156507f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
> Object ffff880215650810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650820: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650830: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650840: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650850: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650860: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650870: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650880: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650890: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156508a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156508b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156508c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156508d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156508e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
> Redzone ffff8802156508f0: bb bb bb bb bb bb bb bb ........
> Padding ffff880215650a30: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
> Pid: 1, comm: swapper Not tainted 3.2.0-rc2-00274-g6fe4c6d #71
> Call Trace:
> [<ffffffff81101cf8>] ? print_section+0x38/0x40
> [<ffffffff811021f3>] print_trailer+0xe3/0x150
> [<ffffffff811023f0>] check_bytes_and_report+0xe0/0x100
> [<ffffffff811031e6>] check_object+0x1c6/0x240
> [<ffffffff812031f0>] ? idr_pre_get+0x60/0x90
> [<ffffffff814c5c43>] alloc_debug_processing+0x62/0xe4
> [<ffffffff814c64f1>] __slab_alloc.constprop.69+0x1a4/0x1e0
> [<ffffffff8129ae77>] ? drm_property_create+0x47/0x110
> [<ffffffff812031f0>] ? idr_pre_get+0x60/0x90
> [<ffffffff81104db1>] kmem_cache_alloc+0x121/0x150
> [<ffffffff812031f0>] ? idr_pre_get+0x60/0x90
> [<ffffffff812031f0>] idr_pre_get+0x60/0x90
> [<ffffffff8129870a>] drm_mode_object_get+0x6a/0xc0
> [<ffffffff8129ae95>] drm_property_create+0x65/0x110
> [<ffffffff8129b15d>] drm_mode_config_init+0xfd/0x190
> [<ffffffff812e12ad>] radeon_modeset_init+0x1d/0x860
> [<ffffffff813211c7>] ? radeon_acpi_init+0x87/0xc0
> [<ffffffff812c37b8>] radeon_driver_load_kms+0xf8/0x150
> [<ffffffff81295a06>] drm_get_pci_dev+0x186/0x2d0
> [<ffffffff814bf1fd>] ? radeon_pci_probe+0x9e/0xb8
> [<ffffffff814bf20f>] radeon_pci_probe+0xb0/0xb8
> [<ffffffff8121be15>] pci_device_probe+0x75/0xa0
> [<ffffffff81324e1a>] ? driver_sysfs_add+0x7a/0xb0
> [<ffffffff81325021>] driver_probe_device+0x71/0x190
> [<ffffffff813251db>] __driver_attach+0x9b/0xa0
> [<ffffffff81325140>] ? driver_probe_device+0x190/0x190
> [<ffffffff81323e0d>] bus_for_each_dev+0x4d/0x90
> [<ffffffff813252f9>] driver_attach+0x19/0x20
> [<ffffffff81324598>] bus_add_driver+0x188/0x250
> [<ffffffff81325942>] driver_register+0x72/0x150
> [<ffffffff81321de5>] ? device_add+0x75/0x600
> [<ffffffff8121bb7d>] __pci_register_driver+0x5d/0xd0
> [<ffffffff81295c54>] drm_pci_init+0x104/0x120
> [<ffffffff818abefa>] ? ttm_init+0x62/0x62
> [<ffffffff818abfe1>] radeon_init+0xe7/0xe9
> [<ffffffff81890883>] do_one_initcall+0x7a/0x129
> [<ffffffff818909cc>] kernel_init+0x9a/0x114
> [<ffffffff814cddb4>] kernel_thread_helper+0x4/0x10
> [<ffffffff81890932>] ? do_one_initcall+0x129/0x129
> [<ffffffff814cddb0>] ? gs_change+0xb/0xb
> FIX idr_layer_cache: Restoring 0xffff880215650800-0xffff880215650803=0x6b
>
> FIX idr_layer_cache: Marking all objects used
Running "slabinfo -v" later:
Nov 21 16:41:03 x4 kernel: =============================================================================
Nov 21 16:41:03 x4 kernel: BUG idr_layer_cache: Redzone overwritten
Nov 21 16:41:03 x4 kernel: -----------------------------------------------------------------------------
Nov 21 16:41:03 x4 kernel:
Nov 21 16:41:03 x4 kernel: INFO: 0xffff8802156508f0-0xffff8802156508f7. First byte 0xbb instead of 0xcc
Nov 21 16:41:03 x4 kernel: INFO: Slab 0xffffea0008559400 objects=18 used=18 fp=0x (null) flags=0x4000000000004081
Nov 21 16:41:03 x4 kernel: INFO: Object 0xffff8802156506d0 @offset=1744 fp=0xffff880215650a38
Nov 21 16:41:03 x4 kernel:
Nov 21 16:41:03 x4 kernel: Bytes b4 ffff8802156506c0: a4 6f fb ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a .o......ZZZZZZZZ
Nov 21 16:41:03 x4 kernel: Object ffff8802156506d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff8802156506e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff8802156506f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650700: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650710: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650720: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650730: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650740: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650750: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650770: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650780: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650790: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff8802156507a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff8802156507b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff8802156507c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff8802156507d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff8802156507e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff8802156507f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650800: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650820: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650830: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650840: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650850: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650860: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650870: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650880: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff880215650890: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff8802156508a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff8802156508b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff8802156508c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff8802156508d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:41:03 x4 kernel: Object ffff8802156508e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
Nov 21 16:41:03 x4 kernel: Redzone ffff8802156508f0: bb bb bb bb bb bb bb bb ........
Nov 21 16:41:03 x4 kernel: Padding ffff880215650a30: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
Nov 21 16:41:03 x4 kernel: Pid: 12278, comm: slabinfo Not tainted 3.2.0-rc2-00274-g6fe4c6d #71
Nov 21 16:41:03 x4 kernel: Call Trace:
Nov 21 16:41:03 x4 kernel: [<ffffffff81101cf8>] ? print_section+0x38/0x40
Nov 21 16:41:03 x4 kernel: [<ffffffff811021f3>] print_trailer+0xe3/0x150
Nov 21 16:41:03 x4 kernel: [<ffffffff811023f0>] check_bytes_and_report+0xe0/0x100
Nov 21 16:41:03 x4 kernel: [<ffffffff811031a3>] check_object+0x183/0x240
Nov 21 16:41:03 x4 kernel: [<ffffffff81103cc0>] validate_slab_slab+0x1c0/0x230
Nov 21 16:41:03 x4 kernel: [<ffffffff811061f6>] validate_store+0xf6/0x190
Nov 21 16:41:03 x4 kernel: [<ffffffff8110163c>] slab_attr_store+0x1c/0x30
Nov 21 16:41:03 x4 kernel: [<ffffffff811634f8>] sysfs_write_file+0xc8/0x140
Nov 21 16:41:03 x4 kernel: [<ffffffff8110dc93>] vfs_write+0xa3/0x160
Nov 21 16:41:03 x4 kernel: [<ffffffff8110de25>] sys_write+0x45/0x90
Nov 21 16:41:03 x4 kernel: [<ffffffff814ccbfb>] system_call_fastpath+0x16/0x1b
Nov 21 16:41:03 x4 kernel: FIX idr_layer_cache: Restoring 0xffff8802156508f0-0xffff8802156508f7=0xcc
Nov 21 16:41:03 x4 kernel:
Nov 21 16:42:07 x4 kernel: =============================================================================
Nov 21 16:42:07 x4 kernel: BUG idr_layer_cache: Redzone overwritten
Nov 21 16:42:07 x4 kernel: -----------------------------------------------------------------------------
Nov 21 16:42:07 x4 kernel:
Nov 21 16:42:07 x4 kernel: INFO: 0xffff880215650c58-0xffff880215650c5f. First byte 0xbb instead of 0xcc
Nov 21 16:42:07 x4 kernel: INFO: Slab 0xffffea0008559400 objects=18 used=18 fp=0x (null) flags=0x4000000000004081
Nov 21 16:42:07 x4 kernel: INFO: Object 0xffff880215650a38 @offset=2616 fp=0xffff880215650da0
Nov 21 16:42:07 x4 kernel:
Nov 21 16:42:07 x4 kernel: Bytes b4 ffff880215650a28: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
Nov 21 16:42:07 x4 kernel: Object ffff880215650a38: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650a48: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650a58: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650a68: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650a78: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650a88: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650a98: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650aa8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650ab8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650ac8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650ad8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650ae8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650af8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650b08: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650b18: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650b28: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650b38: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650b48: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650b58: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650b68: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650b78: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650b88: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650b98: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650ba8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650bb8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650bc8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650bd8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650be8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650bf8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650c08: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650c18: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650c28: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650c38: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 16:42:07 x4 kernel: Object ffff880215650c48: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
Nov 21 16:42:07 x4 kernel: Redzone ffff880215650c58: bb bb bb bb bb bb bb bb ........
Nov 21 16:42:07 x4 kernel: Padding ffff880215650d98: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
Nov 21 16:42:07 x4 kernel: Pid: 12924, comm: slabinfo Not tainted 3.2.0-rc2-00274-g6fe4c6d #71
Nov 21 16:42:07 x4 kernel: Call Trace:
Nov 21 16:42:07 x4 kernel: [<ffffffff81101cf8>] ? print_section+0x38/0x40
Nov 21 16:42:07 x4 kernel: [<ffffffff811021f3>] print_trailer+0xe3/0x150
Nov 21 16:42:07 x4 kernel: [<ffffffff811023f0>] check_bytes_and_report+0xe0/0x100
Nov 21 16:42:07 x4 kernel: [<ffffffff811031a3>] check_object+0x183/0x240
Nov 21 16:42:07 x4 kernel: [<ffffffff81103cc0>] validate_slab_slab+0x1c0/0x230
Nov 21 16:42:07 x4 kernel: [<ffffffff811061f6>] validate_store+0xf6/0x190
Nov 21 16:42:07 x4 kernel: [<ffffffff8110163c>] slab_attr_store+0x1c/0x30
Nov 21 16:42:07 x4 kernel: [<ffffffff811634f8>] sysfs_write_file+0xc8/0x140
Nov 21 16:42:07 x4 kernel: [<ffffffff8110dc93>] vfs_write+0xa3/0x160
Nov 21 16:42:07 x4 kernel: [<ffffffff8110de25>] sys_write+0x45/0x90
Nov 21 16:42:07 x4 kernel: [<ffffffff814ccbfb>] system_call_fastpath+0x16/0x1b
Nov 21 16:42:07 x4 kernel: FIX idr_layer_cache: Restoring 0xffff880215650c58-0xffff880215650c5f=0xcc
--
Markus
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [patch] fix error handle in ip_mc_add_src()
From: Jun Zhao @ 2011-11-21 15:51 UTC (permalink / raw)
To: davem; +Cc: netdev, Eric Dumazet, David Stevens
from: Jun Zhao <mypopydev@gmail.com>
When add sources to interface failure, need to roll back the sfcount[MODE]
to before state. We need to match it corresponding.
Signed-off-by: Jun Zhao <mypopydev@gmail.com>
---
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index c7472ef..b2ca095 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1716,7 +1716,8 @@ static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
if (err) {
int j;
- pmc->sfcount[sfmode]--;
+ if (!delta)
+ pmc->sfcount[sfmode]--;
for (j=0; j<i; j++)
(void) ip_mc_del1_src(pmc, sfmode, &psfsrc[j]);
} else if (isexclude != (pmc->sfcount[MCAST_EXCLUDE] != 0)) {
^ permalink raw reply related
* Re: [patch] fix error handle in ip_mc_add_src()
From: Eric Dumazet @ 2011-11-21 16:00 UTC (permalink / raw)
To: Jun Zhao; +Cc: davem, netdev, David Stevens
In-Reply-To: <1321890701.14281.51.camel@barry.pixelworks.com>
Le lundi 21 novembre 2011 à 23:51 +0800, Jun Zhao a écrit :
> from: Jun Zhao <mypopydev@gmail.com>
>
> When add sources to interface failure, need to roll back the sfcount[MODE]
> to before state. We need to match it corresponding.
>
> Signed-off-by: Jun Zhao <mypopydev@gmail.com>
Thanks !
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* [patch v2 1/1] fix error handle in ip_mc_add_src()
From: Jun Zhao @ 2011-11-21 16:05 UTC (permalink / raw)
To: davem; +Cc: Eric Dumazet, netdev, David Stevens
from: Jun Zhao <mypopydev@gmail.com>
When add sources to interface failure, need to roll back the sfcount[MODE]
to before state. We need to match it corresponding.
Acked-by: David L Stevens <dlstevens@us.ibm.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Jun Zhao <mypopydev@gmail.com>
---
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index c7472ef..b2ca095 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1716,7 +1716,8 @@ static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
if (err) {
int j;
- pmc->sfcount[sfmode]--;
+ if (!delta)
+ pmc->sfcount[sfmode]--;
for (j=0; j<i; j++)
(void) ip_mc_del1_src(pmc, sfmode, &psfsrc[j]);
} else if (isexclude != (pmc->sfcount[MCAST_EXCLUDE] != 0)) {
^ permalink raw reply related
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Markus Trippelsdorf @ 2011-11-21 16:10 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alex,Shi, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, tj
In-Reply-To: <1321890510.10470.11.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 2011.11.21 at 16:48 +0100, Eric Dumazet wrote:
> Le lundi 21 novembre 2011 à 16:36 +0100, Markus Trippelsdorf a écrit :
> > On 2011.11.21 at 15:16 +0100, Eric Dumazet wrote:
> > > Le lundi 21 novembre 2011 à 14:15 +0100, Markus Trippelsdorf a écrit :
> > >
> > > > I've enabled CONFIG_SLUB_DEBUG_ON and this is what happend:
> > > >
> > >
> > > Thanks
> > >
> > > Please continue to provide more samples.
> > >
> > > There is something wrong somewhere, but where exactly, its hard to say.
> >
> > New sample. This one points to lib/idr.c:
> >
> > [drm] Initialized drm 1.1.0 20060810
> > [drm] radeon defaulting to kernel modesetting.
> > [drm] radeon kernel modesetting enabled.
> > radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> > radeon 0000:01:05.0: setting latency timer to 64
> > [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
> > [drm] register mmio base: 0xFBEE0000
> > [drm] register mmio size: 65536
> > ATOM BIOS: 113
> > radeon 0000:01:05.0: VRAM: 128M 0x00000000C0000000 - 0x00000000C7FFFFFF (128M used)
> > radeon 0000:01:05.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF
> > [drm] Detected VRAM RAM=128M, BAR=128M
> > [drm] RAM width 32bits DDR
> > [TTM] Zone kernel: Available graphics memory: 4083428 kiB.
> > [TTM] Zone dma32: Available graphics memory: 2097152 kiB.
> > [TTM] Initializing pool allocator.
> > [drm] radeon: 128M of VRAM memory ready
> > [drm] radeon: 512M of GTT memory ready.
> > [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> > [drm] Driver supports precise vblank timestamp query.
> > [drm] radeon: irq initialized.
> > [drm] GART: num cpu pages 131072, num gpu pages 131072
> > [drm] Loading RS780 Microcode
> > [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
> > radeon 0000:01:05.0: WB enabled
> > [drm] ring test succeeded in 1 usecs
> > [drm] radeon: ib pool ready.
> > [drm] ib test succeeded in 0 usecs
> > =============================================================================
> > BUG idr_layer_cache: Poison overwritten
> > -----------------------------------------------------------------------------
>
> Thanks, could you now add "CONFIG_DEBUG_PAGEALLOC=y" in your config as
> well ?
Sure. This one happend with CONFIG_DEBUG_PAGEALLOC=y:
[drm] Initialized radeon 2.11.0 20080528 for 0000:01:05.0 on minor 0
loop: module loaded
ahci 0000:00:11.0: version 3.0
ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ccc
scsi0 : ahci
scsi1 : ahci
=============================================================================
BUG task_struct: Poison overwritten
-----------------------------------------------------------------------------
INFO: 0xffff880215c43800-0xffff880215c43803. First byte 0x0 instead of 0x6b
INFO: Allocated in copy_process+0xc4/0xf60 age=168 cpu=1 pid=5
__slab_alloc.constprop.70+0x1a4/0x1e0
kmem_cache_alloc+0x126/0x160
copy_process+0xc4/0xf60
do_fork+0x100/0x2b0
kernel_thread+0x6c/0x70
__call_usermodehelper+0x31/0xa0
process_one_work+0x11a/0x430
worker_thread+0x126/0x2d0
kthread+0x87/0x90
kernel_thread_helper+0x4/0x10
INFO: Freed in free_task+0x3e/0x50 age=156 cpu=2 pid=13
__slab_free+0x33/0x2d0
kmem_cache_free+0x104/0x120
free_task+0x3e/0x50
__put_task_struct+0xb0/0x110
delayed_put_task_struct+0x3b/0xa0
__rcu_process_callbacks+0x12a/0x350
rcu_process_callbacks+0x62/0x140
__do_softirq+0xa8/0x200
run_ksoftirqd+0x107/0x210
kthread+0x87/0x90
kernel_thread_helper+0x4/0x10
INFO: Slab 0xffffea0008571000 objects=17 used=17 fp=0x (null) flags=0x4000000000004080
INFO: Object 0xffff880215c432c0 @offset=12992 fp=0xffff880215c41d00
Bytes b4 ffff880215c432b0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
Object ffff880215c432c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c432d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c432e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c432f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43300: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43310: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43320: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43330: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43340: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43350: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43360: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43370: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43380: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43390: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c433a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c433b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c433c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c433d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c433e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c433f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43400: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43410: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43420: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43430: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43440: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43450: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43460: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43470: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43480: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43490: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c434a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c434b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c434c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c434d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c434e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c434f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43500: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43510: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43520: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43530: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43540: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43550: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43560: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43570: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43580: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43590: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c435a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c435b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c435c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c435d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c435e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c435f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43600: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43610: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43620: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43630: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43640: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43650: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43660: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43670: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43680: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43690: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c436a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c436b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c436c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c436d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c436e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c436f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43700: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43710: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43720: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43730: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43740: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43750: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43770: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43780: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43790: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c437a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c437b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c437c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c437d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c437e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c437f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
Object ffff880215c43810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43820: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43830: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43840: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43850: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43860: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43870: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43880: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c43890: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215c438a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
Redzone ffff880215c438b0: bb bb bb bb bb bb bb bb ........
Padding ffff880215c439f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
Pid: 5, comm: kworker/u:0 Not tainted 3.2.0-rc2-00274-g6fe4c6d #72
Call Trace:
[<ffffffff81101ca8>] ? print_section+0x38/0x40
[<ffffffff811021a3>] print_trailer+0xe3/0x150
[<ffffffff811023a0>] check_bytes_and_report+0xe0/0x100
[<ffffffff81103196>] check_object+0x1c6/0x240
[<ffffffff8106b034>] ? copy_process+0xc4/0xf60
[<ffffffff814c5bb3>] alloc_debug_processing+0x62/0xe4
[<ffffffff814c6461>] __slab_alloc.constprop.70+0x1a4/0x1e0
[<ffffffff8106b034>] ? copy_process+0xc4/0xf60
[<ffffffff814ca12a>] ? schedule+0x3a/0x50
[<ffffffff81104d66>] kmem_cache_alloc+0x126/0x160
[<ffffffff8106b034>] ? copy_process+0xc4/0xf60
[<ffffffff81065f18>] ? enqueue_task_fair+0xf8/0x140
[<ffffffff8106b034>] copy_process+0xc4/0xf60
[<ffffffff8106c000>] do_fork+0x100/0x2b0
[<ffffffff810920fd>] ? sched_clock_local+0x1d/0x90
[<ffffffff81044dec>] kernel_thread+0x6c/0x70
[<ffffffff81084430>] ? proc_cap_handler+0x180/0x180
[<ffffffff814cdd30>] ? gs_change+0xb/0xb
[<ffffffff810845a1>] __call_usermodehelper+0x31/0xa0
[<ffffffff810869ba>] process_one_work+0x11a/0x430
[<ffffffff81084570>] ? call_usermodehelper_freeinfo+0x30/0x30
[<ffffffff81087026>] worker_thread+0x126/0x2d0
[<ffffffff81086f00>] ? rescuer_thread+0x1f0/0x1f0
[<ffffffff8108bb87>] kthread+0x87/0x90
[<ffffffff814cdd34>] kernel_thread_helper+0x4/0x10
[<ffffffff8108bb00>] ? kthread_flush_work_fn+0x10/0x10
[<ffffffff814cdd30>] ? gs_change+0xb/0xb
FIX task_struct: Restoring 0xffff880215c43800-0xffff880215c43803=0x6b
FIX task_struct: Marking all objects used
...
debug: unmapping init memory ffffffff8187d000..ffffffff818ea000
Write protecting the kernel read-only data: 8192k
debug: unmapping init memory ffff8800014d1000..ffff880001600000
debug: unmapping init memory ffff8800017e0000..ffff880001800000
...
slabinfo -v gives:
SLUB: task_struct 10 slabs counted but counter=11
--
Markus
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Markus Trippelsdorf @ 2011-11-21 16:34 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alex,Shi, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, tj
In-Reply-To: <20111121161036.GA1679@x4.trippels.de>
On 2011.11.21 at 17:10 +0100, Markus Trippelsdorf wrote:
> On 2011.11.21 at 16:48 +0100, Eric Dumazet wrote:
> > Le lundi 21 novembre 2011 à 16:36 +0100, Markus Trippelsdorf a écrit :
> > > On 2011.11.21 at 15:16 +0100, Eric Dumazet wrote:
> > > > Le lundi 21 novembre 2011 à 14:15 +0100, Markus Trippelsdorf a écrit :
> > > >
> > > > > I've enabled CONFIG_SLUB_DEBUG_ON and this is what happend:
> > > > >
> > > >
> > > > Thanks
> > > >
> > > > Please continue to provide more samples.
> > > >
> > > > There is something wrong somewhere, but where exactly, its hard to say.
> > >
> > > New sample. This one points to lib/idr.c:
> > >
> > > =============================================================================
> > > BUG idr_layer_cache: Poison overwritten
> > > -----------------------------------------------------------------------------
> >
> > Thanks, could you now add "CONFIG_DEBUG_PAGEALLOC=y" in your config as
> > well ?
>
> Sure. This one happend with CONFIG_DEBUG_PAGEALLOC=y:
>
> =============================================================================
> BUG task_struct: Poison overwritten
> -----------------------------------------------------------------------------
And sometimes this one that I've reported earlier already:
(see: http://thread.gmane.org/gmane.linux.kernel/1215023 )
------------[ cut here ]------------
WARNING: at fs/sysfs/sysfs.h:195 sysfs_get_inode+0x136/0x140()
Hardware name: System Product Name
Pid: 1876, comm: slabinfo Not tainted 3.2.0-rc2-00274-g6fe4c6d #72
Call Trace:
[<ffffffff8106cac5>] warn_slowpath_common+0x75/0xb0
[<ffffffff8106cbc5>] warn_slowpath_null+0x15/0x20
[<ffffffff81163236>] sysfs_get_inode+0x136/0x140
[<ffffffff81164cef>] sysfs_lookup+0x6f/0x110
[<ffffffff811173f9>] d_alloc_and_lookup+0x39/0x80
[<ffffffff81118774>] do_lookup+0x294/0x3a0
[<ffffffff8111798a>] ? inode_permission+0x7a/0xb0
[<ffffffff8111a3f7>] do_last.isra.46+0x137/0x7f0
[<ffffffff8111ab76>] path_openat+0xc6/0x370
[<ffffffff81117606>] ? getname_flags+0x36/0x230
[<ffffffff810ec852>] ? handle_mm_fault+0x192/0x290
[<ffffffff8111ae5c>] do_filp_open+0x3c/0x90
[<ffffffff81127c8c>] ? alloc_fd+0xdc/0x120
[<ffffffff8110ce77>] do_sys_open+0xe7/0x1c0
[<ffffffff8110cf6b>] sys_open+0x1b/0x20
[<ffffffff814ccb7b>] system_call_fastpath+0x16/0x1b
---[ end trace b1377eb8b131d37d ]---
--
Markus
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: iproute2 back at kernel.org
From: Stephen Hemminger @ 2011-11-21 16:47 UTC (permalink / raw)
To: Petr Šabata; +Cc: netdev
In-Reply-To: <20111121091534.GA23163@rincewind.brq.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 596 bytes --]
On Mon, 21 Nov 2011 10:15:34 +0100
Petr Šabata <contyk@redhat.com> wrote:
> On Tue, Oct 11, 2011 at 04:59:08PM -0700, Stephen Hemminger wrote:
> > Now that kernel.org is back online, the iproute2 repository is back
> > at it's old location.
> > git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2
> >
> > I have frozen and tagged the v3.0 release, but don't have a good place
> > to put the tar ball yet (stay tuned). Also the signing key for the release
> > will be changing.
>
> Are there any news on this?
Should be today, there are some issues with setup
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: bridge: HSR support
From: Arvid Brodin @ 2011-11-21 16:52 UTC (permalink / raw)
To: netdev
In-Reply-To: <4EAACB7A.4090207@enea.com>
Arvid Brodin wrote:
> Arvid Brodin wrote:
>> Stephen Hemminger wrote:
>>> On Tue, 11 Oct 2011 20:25:08 +0200
>>> Arvid Brodin <arvid.brodin@enea.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I want to add support for HSR ("High-availability Seamless Redundancy",
>>>> IEC-62439-3) to the bridge code. With HSR, all connected units have two network
>>>> ports and are connected in a ring. All new Ethernet packets are sent on both
>>>> ports (or passed through if the current unit is not the originating unit). The
>>>> same packet is never passed twice. Non-HSR units are not allowed in the ring.
>>>>
>>>> This gives instant, reconfiguration-free failover.
>>>>
> *snip*
>> I need to do two things:
>>
>> 1) Bind two network interfaces into one (say, eth0 & eth1 => hsr0). Frames sent on
>> hsr0 should get an HSR tag (including the correct EtherType) and go out on both
>> eth0 and eth1.
>>
>> 2) Ingress frames on eth0 & eth1, with EtherType 0x88fb, should be captured and
>> handled specially (either received on hsr0 or forwarded to the other bound
>> physical interface).
>>
>> Any ideas on the best way to implement this -- what's the nicest place to "hook
>> into" for this?
>>
I need some help with the code for creating virtual hsr devices.
To reiterate, a hsr device acts as a kind of master for two physical ethernet
devices. Any frame sent on the hsrX device should be forwarded to and sent from
both physical devices. Frames coming in on one of the physical devices should
be bridged to the other physical device, or received on the hsr device if the
host is the intended destination.
Questions:
1) net_device features. Should I just logically AND the features fields of the
physical interfaces to get a correct value for the hsr device?
2) net_device priv_flags / flags:
I'm guessing I need to clear IFF_XMIT_DST_RELEASE on all involved interfaces
to be able to send outgoing frames on multiple interfaces?
Can I set IFF_DONT_BRIDGE on the physical interfaces to prevent them being
used in a bridge?
Can I call netdev_set_master() on the physical devices to stop them from
being used in e.g. a bond?
3) Stats: is there a reason not to use the net_device->stats field for
statistics on the hsr device? (I see many drivers keep their own
net_device_stats data and implement ndo_get_stats64() instead.)
--
Arvid Brodin
Enea Services Stockholm AB
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Eric Dumazet @ 2011-11-21 16:52 UTC (permalink / raw)
To: Markus Trippelsdorf
Cc: Alex,Shi, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, tj
In-Reply-To: <20111121161036.GA1679@x4.trippels.de>
Le lundi 21 novembre 2011 à 17:10 +0100, Markus Trippelsdorf a écrit :
> Sure. This one happend with CONFIG_DEBUG_PAGEALLOC=y:
>
> [drm] Initialized radeon 2.11.0 20080528 for 0000:01:05.0 on minor 0
> loop: module loaded
> ahci 0000:00:11.0: version 3.0
> ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
> ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
> ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ccc
> scsi0 : ahci
> scsi1 : ahci
> =============================================================================
> BUG task_struct: Poison overwritten
> -----------------------------------------------------------------------------
Unfortunately thats the same problem, not catched by DEBUG_PAGEALLOC
because freed page is immediately reused.
We should keep pages in free list longer, to have a bigger window.
Hmm...
Please try following patch :
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 9dd443d..b8932a6 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1196,7 +1196,7 @@ void free_hot_cold_page(struct page *page, int cold)
}
pcp = &this_cpu_ptr(zone->pageset)->pcp;
- if (cold)
+ if (IS_ENABLED(CONFIG_DEBUG_PAGEALLOC) || cold)
list_add_tail(&page->lru, &pcp->lists[migratetype]);
else
list_add(&page->lru, &pcp->lists[migratetype]);
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH] tc: comment spelling fixes
From: Stephen Hemminger @ 2011-11-21 16:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/include/linux/pkt_sched.h 2011-11-09 13:54:59.780009551 -0800
+++ b/include/linux/pkt_sched.h 2011-11-21 08:51:20.062228855 -0800
@@ -30,7 +30,7 @@
*/
struct tc_stats {
- __u64 bytes; /* NUmber of enqueues bytes */
+ __u64 bytes; /* Number of enqueues bytes */
__u32 packets; /* Number of enqueued packets */
__u32 drops; /* Packets dropped because of lack of resources */
__u32 overlimits; /* Number of throttle events when this
@@ -297,7 +297,7 @@ struct tc_htb_glob {
__u32 debug; /* debug flags */
/* stats */
- __u32 direct_pkts; /* count of non shapped packets */
+ __u32 direct_pkts; /* count of non shaped packets */
};
enum {
TCA_HTB_UNSPEC,
@@ -503,7 +503,7 @@ enum {
};
#define NETEM_LOSS_MAX (__NETEM_LOSS_MAX - 1)
-/* State transition probablities for 4 state model */
+/* State transition probabilities for 4 state model */
struct tc_netem_gimodel {
__u32 p13;
__u32 p31;
^ permalink raw reply
* Re: [PATCH 6/8] net/mlx4_en: allow setting number of rx rings for, RSS/TCP
From: Ben Hutchings @ 2011-11-21 16:57 UTC (permalink / raw)
To: Yevgeny Petrilin; +Cc: davem, netdev, ogerlitz, oren, amirv
In-Reply-To: <4ECA0F44.1080004@mellanox.co.il>
On Mon, 2011-11-21 at 10:43 +0200, Yevgeny Petrilin wrote:
> From: Amir Vadai <amirv@mellanox.co.il>
>
> Make RSS TCP divert packets only to part of the rx rings, other could be
> accessed by using flow steering or RFS acceleration
[...]
The ethtool {get,set}_rxfh_indir operations are a standard and more
flexible interface for configuring this.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [RFC PATCH 00/17] netfilter: IPv6 NAT
From: Patrick McHardy @ 2011-11-21 17:01 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter-devel, netdev, ulrich.weber
In-Reply-To: <alpine.LNX.2.01.1111211402350.25806@frira.zrqbmnf.qr>
On 11/21/2011 02:05 PM, Jan Engelhardt wrote:
> On Monday 2011-11-21 06:45, kaber@trash.net wrote:
>
>> net/ipv4/netfilter/ipt_REDIRECT.c | 23 +-
>> .../{nf_nat_standalone.c => iptable_nat.c} | 265 ++++-----
>> net/ipv4/netfilter/nf_nat_irc.c | 4 +-
>> net/netfilter/nf_conntrack_sip.c | 119 +++--
> Pablo once hinted that the patches (and not just the diffstat) should
> also be produced using move semantics rather than the delete-add cycle,
> for the reader's benefit. To do this, so I have found, one can use
>
> git send-email ... --format-patch -M
Yeah, I didn't use -M this time so people can test the patches
by applying them directly. I'll add it during the next submission
after setting up a public git tree.
^ permalink raw reply
* Re: [PATCH net-next 1/3] be2net: fix to display Pause autonegotiation setting
From: Ben Hutchings @ 2011-11-21 17:10 UTC (permalink / raw)
To: Ajit Khaparde; +Cc: netdev, davem
In-Reply-To: <20111121051240.GA17132@akhaparde-VBox>
On Sun, 2011-11-20 at 23:12 -0600, Ajit Khaparde wrote:
> Pause autonegotiation is supported by default.
>
> Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
> ---
> drivers/net/ethernet/emulex/benet/be_ethtool.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c b/drivers/net/ethernet/emulex/benet/be_ethtool.c
> index 575c783..ff53489 100644
> --- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
> +++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
> @@ -538,7 +538,7 @@ be_get_pauseparam(struct net_device *netdev, struct ethtool_pauseparam *ecmd)
> struct be_adapter *adapter = netdev_priv(netdev);
>
> be_cmd_get_flow_control(adapter, &ecmd->tx_pause, &ecmd->rx_pause);
> - ecmd->autoneg = 0;
> + ecmd->autoneg = 1;
> }
>
> static int
This is surely not true for XFP and SFP+ interfaces.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] tc: comment spelling fixes
From: Ben Hutchings @ 2011-11-21 17:12 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20111121085346.2203c4f4@nehalam.linuxnetplumber.net>
On Mon, 2011-11-21 at 08:53 -0800, Stephen Hemminger wrote:
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> --- a/include/linux/pkt_sched.h 2011-11-09 13:54:59.780009551 -0800
> +++ b/include/linux/pkt_sched.h 2011-11-21 08:51:20.062228855 -0800
> @@ -30,7 +30,7 @@
> */
>
> struct tc_stats {
> - __u64 bytes; /* NUmber of enqueues bytes */
> + __u64 bytes; /* Number of enqueues bytes */
[...]
Further fix needed: 'enqueued'.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Eric Dumazet @ 2011-11-21 17:15 UTC (permalink / raw)
To: Markus Trippelsdorf
Cc: Alex,Shi, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, tj
In-Reply-To: <1321894353.10470.19.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Le lundi 21 novembre 2011 à 17:52 +0100, Eric Dumazet a écrit :
> Le lundi 21 novembre 2011 à 17:10 +0100, Markus Trippelsdorf a écrit :
>
> > Sure. This one happend with CONFIG_DEBUG_PAGEALLOC=y:
> >
> > [drm] Initialized radeon 2.11.0 20080528 for 0000:01:05.0 on minor 0
> > loop: module loaded
> > ahci 0000:00:11.0: version 3.0
> > ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
> > ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
> > ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ccc
> > scsi0 : ahci
> > scsi1 : ahci
> > =============================================================================
> > BUG task_struct: Poison overwritten
> > -----------------------------------------------------------------------------
>
> Unfortunately thats the same problem, not catched by DEBUG_PAGEALLOC
> because freed page is immediately reused.
>
> We should keep pages in free list longer, to have a bigger window.
>
> Hmm...
>
> Please try following patch :
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 9dd443d..b8932a6 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1196,7 +1196,7 @@ void free_hot_cold_page(struct page *page, int cold)
> }
>
> pcp = &this_cpu_ptr(zone->pageset)->pcp;
> - if (cold)
> + if (IS_ENABLED(CONFIG_DEBUG_PAGEALLOC) || cold)
> list_add_tail(&page->lru, &pcp->lists[migratetype]);
> else
> list_add(&page->lru, &pcp->lists[migratetype]);
>
Also add "slub_max_order=0" to your boot command, since it will make the
pool larger...
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: MPLS for Linux kernel
From: Stephen Hemminger @ 2011-11-21 17:17 UTC (permalink / raw)
To: jorge; +Cc: igorm, Linux Network Development list
In-Reply-To: <4ECA67C6.2080802@dti2.net>
On Mon, 21 Nov 2011 16:01:26 +0100
"Jorge Boncompte [DTI2]" <jorge@dti2.net> wrote:
> El 20/11/2011 22:59, Igor Maravić escribió:
> > Hi all,
> > I've been working on implementation of MPLS for Linux kernel, for a
> > some time now.
> > I continued the work of James Leu
> > (https://sourceforge.net/projects/mpls-linux/) and used some fixes of
> > Jorge Boncompte
> > (http://mpls-linux.git.sourceforge.net/git/gitweb.cgi?p=mpls-linux/net-next;a=shortlog;h=refs/heads/net-next-mpls).
> >
> > I fixed a lot of bugs, so now it can be compiled and run with all
> > Kernel Hacking options enabled.
> > My code could be found on this sites:
> >
> > https://github.com/i-maravic/MPLS-Linux
> > https://github.com/i-maravic/iproute2
> >
> > Any feedback is appreciated :)
>
> Provide, clean, separated, and commented changes to the upstream project as we
> have asked you several times to do.
>
> mpls-linux it is not ready to go upstream in my opinion.
Out of tree is out of mind. Very few developers will bother with
a kernel component not in the mainline tree.
Staging?
^ permalink raw reply
* Re: Kernel v3.0.8 igb driver dies when pulling network cable
From: Alexander Duyck @ 2011-11-21 17:20 UTC (permalink / raw)
To: Stefan Priebe
Cc: Stable Tree, stable, Greg KH, LKML, Linux Netdev List,
Jeff Kirsher,
Jesse Brandeburg <jesse.brandeburg@intel.com> Bruce Allan,
Carolyn Wyborny, Don Skidmore, Greg Rose, PJ Waskiewicz,
John Ronciak
In-Reply-To: <4ECA4362.2050307@profihost.ag>
Stefan,
You are going to need to clarify some things since as far as I know we
never released a v3.0.8 driver, and the kernel in the bug below is a
version 2.6.40.8 which sounds more like a modified and possibly
backported Linux kernel since as far as I know Linus never released a
2.6.40 kernel version.
In order to be able to assist you we will need some additional
information. What Linux distro are your running? Do you have the
latest updates from them? Also have you tried running the latest
out-of-tree driver we provide at e1000.sf.net in order to verify if the
same issue occurs with that driver?
Thanks,
Alex
On 11/21/2011 04:26 AM, Stefan Priebe wrote:
> Hi List,
>
> i triggered this bug nultiple times by just pulling out the network
> cable while running v3.0.8.
>
> [ 838.740689] igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow
> Control: RX/TX
> [ 838.761489] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [ 848.654167] ------------[ cut here ]------------
> [ 848.673476] WARNING: at net/sched/sch_generic.c:255
> dev_watchdog+0x25d/0x270()
> [ 848.692857] Hardware name: X8DTN
> [ 848.712062] NETDEV WATCHDOG: eth0 (igb): transmit queue 0 timed out
> [ 848.731613] Modules linked in: xt_tcpudp iptable_filter ip_tables
> x_tables coretemp k8temp ipv6 dm_snapshot dm_mod
> [ 848.752265] Pid: 0, comm: swapper Not tainted 2.6.40.8intel #3
> [ 848.773156] Call Trace:
> [ 848.793730] <IRQ> [<ffffffff8153be3d>] ? dev_watchdog+0x25d/0x270
> [ 848.793740] [<ffffffff81045eb0>] warn_slowpath_common+0x80/0xc0
> [ 848.793744] [<ffffffff81045fe9>] warn_slowpath_fmt+0x69/0x70
> [ 848.793749] [<ffffffff81012288>] ?
> intel_pmu_nhm_enable_all+0x158/0x190
> [ 848.793755] [<ffffffff81469917>] ? igb_poll+0x807/0xde0
> [ 848.793758] [<ffffffff810125e4>] ? x86_pmu_enable+0x1f4/0x270
> [ 848.793763] [<ffffffff810b1666>] ? perf_event_task_tick+0xa6/0x2e0
> [ 848.793767] [<ffffffff8153be3d>] dev_watchdog+0x25d/0x270
> [ 848.793772] [<ffffffff8105511c>] run_timer_softirq+0x1cc/0x320
> [ 848.793776] [<ffffffff8153bbe0>] ? __netdev_watchdog_up+0x80/0x80
> [ 848.793782] [<ffffffff8101d0d8>] ? lapic_next_event+0x18/0x20
> [ 848.793787] [<ffffffff8104c390>] __do_softirq+0xd0/0x1c0
> [ 848.793793] [<ffffffff815e288c>] call_softirq+0x1c/0x30
> [ 848.793798] [<ffffffff810047b5>] do_softirq+0x55/0x90
> [ 848.793801] [<ffffffff8104c16d>] irq_exit+0xad/0xe0
> [ 848.793805] [<ffffffff8101ddc9>] smp_apic_timer_interrupt+0x69/0xa0
> [ 848.793809] [<ffffffff815e2053>] apic_timer_interrupt+0x13/0x20
> [ 848.793811] <EOI> [<ffffffff81317093>] ? intel_idle+0xb3/0x120
> [ 848.793820] [<ffffffff81317075>] ? intel_idle+0x95/0x120
> [ 848.793824] [<ffffffff814f7d5c>] cpuidle_idle_call+0xdc/0x1a0
> [ 848.793829] [<ffffffff81002091>] cpu_idle+0xb1/0x110
> [ 848.793833] [<ffffffff815c54dd>] rest_init+0x6d/0x80
> [ 848.793837] [<ffffffff81acbc5d>] start_kernel+0x3a2/0x44c
> [ 848.793847] [<ffffffff81acb295>] x86_64_start_reservations+0xa5/0xc9
> [ 848.793851] [<ffffffff81acb3a2>] x86_64_start_kernel+0xe9/0xfb
> [ 848.793853] ---[ end trace 737c145f3289e2ce ]---
> [ 848.794085] igb 0000:0a:00.0: eth0: Reset adapter
> [ 849.019407] eth0: no IPv6 routers present
> [ 851.626949] igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow
> Control: RX/TX
> [ 861.637255] igb 0000:0a:00.0: eth0: Reset adapter
> [ 864.479252] igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow
> Control: RX/TX
>
> Greet Stefan
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Markus Trippelsdorf @ 2011-11-21 17:35 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alex,Shi, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, tj
In-Reply-To: <1321895706.10470.21.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 2011.11.21 at 18:15 +0100, Eric Dumazet wrote:
> Le lundi 21 novembre 2011 à 17:52 +0100, Eric Dumazet a écrit :
> > Le lundi 21 novembre 2011 à 17:10 +0100, Markus Trippelsdorf a écrit :
> >
> > > Sure. This one happend with CONFIG_DEBUG_PAGEALLOC=y:
> > >
> > > [drm] Initialized radeon 2.11.0 20080528 for 0000:01:05.0 on minor 0
> > > loop: module loaded
> > > ahci 0000:00:11.0: version 3.0
> > > ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
> > > ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
> > > ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ccc
> > > scsi0 : ahci
> > > scsi1 : ahci
> > > =============================================================================
> > > BUG task_struct: Poison overwritten
> > > -----------------------------------------------------------------------------
> >
> > Unfortunately thats the same problem, not catched by DEBUG_PAGEALLOC
> > because freed page is immediately reused.
> >
> > We should keep pages in free list longer, to have a bigger window.
> >
> > Hmm...
> >
> > Please try following patch :
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 9dd443d..b8932a6 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1196,7 +1196,7 @@ void free_hot_cold_page(struct page *page, int cold)
> > }
> >
> > pcp = &this_cpu_ptr(zone->pageset)->pcp;
> > - if (cold)
> > + if (IS_ENABLED(CONFIG_DEBUG_PAGEALLOC) || cold)
> > list_add_tail(&page->lru, &pcp->lists[migratetype]);
> > else
> > list_add(&page->lru, &pcp->lists[migratetype]);
> >
>
>
> Also add "slub_max_order=0" to your boot command, since it will make the
> pool larger...
New one:
=============================================================================
BUG task_xstate: Not a valid slab page
-----------------------------------------------------------------------------
INFO: Slab 0xffffea0000044300 objects=32767 used=65535 fp=0x (null) flags=0x0401
Pid: 9, comm: ksoftirqd/1 Not tainted 3.2.0-rc2-00274-g6fe4c6d-dirty #75
Call Trace:
[<ffffffff81101c1d>] slab_err+0x7d/0x90
[<ffffffff8103e29f>] ? dump_trace+0x16f/0x2e0
[<ffffffff81044764>] ? free_thread_xstate+0x24/0x40
[<ffffffff81044764>] ? free_thread_xstate+0x24/0x40
[<ffffffff81102566>] check_slab+0x96/0xc0
[<ffffffff814c5c29>] free_debug_processing+0x34/0x19c
[<ffffffff81101d9a>] ? set_track+0x5a/0x190
[<ffffffff8110cf2b>] ? sys_open+0x1b/0x20
[<ffffffff814c5e55>] __slab_free+0x33/0x2d0
[<ffffffff8110cf2b>] ? sys_open+0x1b/0x20
[<ffffffff81105134>] kmem_cache_free+0x104/0x120
[<ffffffff81044764>] free_thread_xstate+0x24/0x40
[<ffffffff81044794>] free_thread_info+0x14/0x30
[<ffffffff8106a4ff>] free_task+0x2f/0x50
[<ffffffff8106a5d0>] __put_task_struct+0xb0/0x110
[<ffffffff8106eb4b>] delayed_put_task_struct+0x3b/0xa0
[<ffffffff810aa01a>] __rcu_process_callbacks+0x12a/0x350
[<ffffffff810aa2a2>] rcu_process_callbacks+0x62/0x140
[<ffffffff81072e18>] __do_softirq+0xa8/0x200
[<ffffffff81073077>] run_ksoftirqd+0x107/0x210
[<ffffffff81072f70>] ? __do_softirq+0x200/0x200
[<ffffffff8108bb87>] kthread+0x87/0x90
[<ffffffff814cdcf4>] kernel_thread_helper+0x4/0x10
[<ffffffff8108bb00>] ? kthread_flush_work_fn+0x10/0x10
[<ffffffff814cdcf0>] ? gs_change+0xb/0xb
FIX task_xstate: Object at 0xffffffff8110cf2b not freed
--
Markus
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/6 v4] macvlan: MAC Address filtering support for passthru mode
From: Greg Rose @ 2011-11-21 17:41 UTC (permalink / raw)
To: Ben Hutchings
Cc: Roopa Prabhu, netdev@vger.kernel.org, davem@davemloft.net,
chrisw@redhat.com, sri@us.ibm.com, dragos.tatulea@gmail.com,
kvm@vger.kernel.org, arnd@arndb.de, mst@redhat.com,
mchan@broadcom.com, dwang2@cisco.com, shemminger@vyatta.com,
eric.dumazet@gmail.com, kaber@trash.net, benve@cisco.com
In-Reply-To: <1321638038.2883.28.camel@bwh-desktop>
On 11/18/2011 9:40 AM, Ben Hutchings wrote:
> On Fri, 2011-11-18 at 08:58 -0800, Greg Rose wrote:
>> On 11/17/2011 4:44 PM, Ben Hutchings wrote:
>>> On Thu, 2011-11-17 at 16:32 -0800, Greg Rose wrote:
>>>> On 11/17/2011 4:15 PM, Ben Hutchings wrote:
>>>>> Sorry to come to this rather late.
>>>>>
>>>>> On Tue, 2011-11-08 at 23:55 -0800, Roopa Prabhu wrote:
>>>>> [...]
>>>>>> v2 -> v3
>>>>>> - Moved set and get filter ops from rtnl_link_ops to netdev_ops
>>>>>> - Support for SRIOV VFs.
>>>>>> [Note: The get filters msg (in the way current get rtnetlink handles
>>>>>> it) might get too big for SRIOV vfs. This patch follows existing sriov
>>>>>> vf get code and tries to accomodate filters for all VF's in a PF.
>>>>>> And for the SRIOV case I have only tested the fact that the VF
>>>>>> arguments are getting delivered to rtnetlink correctly. The code
>>>>>> follows existing sriov vf handling code so rest of it should work fine]
>>>>> [...]
>>>>>
>>>>> This is already broken for large numbers of VFs, and increasing the
>>>>> amount of information per VF is going to make the situation worse. I am
>>>>> no netlink expert but I think that the current approach of bundling all
>>>>> information about an interface in a single message may not be
>>>>> sustainable.
>>>>>
>>>>> Also, I'm unclear on why this interface is to be used to set filtering
>>>>> for the (PF) net device as well as for related VFs. Doesn't that
>>>>> duplicate the functionality of ndo_set_rx_mode and
>>>>> ndo_vlan_rx_{add,kill}_vid?
>>>>
>>>> Functionally yes but contextually no. This allows the PF driver to know
>>>> that it is setting these filters in the context of the existence of VFs,
>>>> allowing it to take appropriate action. The other two functions may be
>>>> called without the presence of SR-IOV enablement and the existence of VFs.
>>>>
>>>> Anyway, that's why I asked Roopa to add that capability.
>>>
>>> I don't follow. The PF driver already knows whether it has enabled VFs.
>>>
>>> How do filters set this way interact with filters set through the
>>> existing operations? Should they override promiscuous mode? None of
>>> this has been specified.
>>
>> Promiscuous mode is exactly the issue this feature is intended for. I'm
>> not familiar with the solarflare device but Intel HW promiscuous mode is
>> only promiscuous on the physical port, not on the VEB. So a packet sent
>> from a VF will not be captured by the PF across the VEB unless the MAC
>> and VLAN filters have been programmed into the HW.
>
> Yes, I get it. The hardware bridge needs to know more about the address
> configuration on the host than the driver is getting at the moment.
>
>> So you may not need
>> the feature for your devices but it is required for Intel devices.
>
> Well we don't have the hardware bridge but that means each VF driver
> needs to know whether to fall back to the software bridge. The net
> driver needs much the same additional information.
>
>> And
>> it's a fairly simple request, just allow -1 to indicate that the target
>> of the filter requests is for the PF itself. Using the already existing
>> set_rx_mode function wont' work because the PF driver will look at it
>> and figure it's in promiscuous mode anyway, so it won't set the filters
>> into the HW. At least that is how it is in the case of our HW and
>> driver. Again, the behavior of your HW and driver is unknown to me and
>> thus you may not require this feature.
>
> What concerns me is that this seems to be a workaround rather than a fix
> for over-use of promiscuous mode, and it changes the semantics of
> filtering modes in ways that haven't been well-specified.
I feel the opposite is true. It allows a known set of receive filters
so that you don't have to use promiscuous mode, which cuts down on
overhead from processing packets the upper layer stack isn't really
interested in.
>
> What if there's a software bridge between two net devices corresponding
> to separate physical ports, so that they really need to be promiscuous?
> What if the administrator runs tcpdump and really wants the (PF) net
> device to be promiscuous?
I don't believe there is anything in this patch set that removes
promiscuous mode operation as it is commonly used. Perhaps I've missed
something.
>
> These cases shouldn't break because of VF acceleration.
I don't see how they would in the case of Intel HW. And these new ops
to set rx filters are something that Intel HW needs because it
implements a VEB that is *not* a learning bridge and we don't want it to
be a learning bridge because of security concerns. It is better for our
requirements to be allowed to set the MAC/VLAN filters that we want a VF
to be able to see.
> Or at least we
> should make a conscious and documented decision that 'promiscuous'
> doesn't mean that if you enable it on your network adapter.
Again, I don't know of any plans to change anything relating to putting
a device in promiscuous mode or changing the semantics of what
promiscuous mode means.
- Greg
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox