* kmemleak through e1000?
@ 2014-03-04 15:55 Daniel Borkmann
2014-03-04 20:58 ` Bjorn Helgaas
0 siblings, 1 reply; 7+ messages in thread
From: Daniel Borkmann @ 2014-03-04 15:55 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: Jesse Brandeburg, Bjorn Helgaas, linux-pci, e1000-devel
Hi all, I'm not very familiar with the e1000 code, but on the latest
net.git kernel I get reliably the following (not sure if it's actually
caused by e1000 though):
unreferenced object 0xffff8800361a7d80 (size 32):
comm "systemd-udevd", pid 246, jiffies 4294677997 (age 1117.522s)
hex dump (first 32 bytes):
60 7d 1a 36 00 88 ff ff 24 01 00 00 00 00 00 00 `}.6....$.......
f0 aa 35 81 ff ff ff ff 00 00 00 00 00 00 00 00 ..5.............
backtrace:
[<ffffffff8166609e>] kmemleak_alloc+0x4e/0xb0
[<ffffffff8119f547>] kmem_cache_alloc_trace+0xd7/0x220
[<ffffffff8135ad48>] populate_msi_sysfs+0x128/0x220
[<ffffffff8135b4b8>] pci_enable_msi_block+0x1b8/0x2c0
[<ffffffffa0221781>] e1000e_set_interrupt_capability+0x41/0x120 [e1000e]
[<ffffffffa0226047>] e1000_probe+0x3a7/0xe20 [e1000e]
[<ffffffff81343805>] local_pci_probe+0x45/0xa0
[<ffffffff81344b89>] pci_device_probe+0xd9/0x130
[<ffffffff813fc317>] driver_probe_device+0x87/0x390
[<ffffffff813fc6f3>] __driver_attach+0x93/0xa0
[<ffffffff813fa323>] bus_for_each_dev+0x63/0xa0
[<ffffffff813fbd6e>] driver_attach+0x1e/0x20
[<ffffffff813fb950>] bus_add_driver+0x180/0x250
[<ffffffff813fcd04>] driver_register+0x64/0xf0
[<ffffffff813431ab>] __pci_register_driver+0x4b/0x50
[<ffffffffa0240041>] iptable_filter_hook+0x41/0x70 [iptable_filter]
unreferenced object 0xffff8800c4ac1920 (size 32):
comm "NetworkManager", pid 409, jiffies 4294693366 (age 1102.161s)
hex dump (first 32 bytes):
34 34 00 c4 00 88 ff ff 00 00 00 00 00 00 00 00 44..............
00 00 00 00 00 00 00 00 6f 2e 32 00 00 00 00 00 ........o.2.....
backtrace:
[<ffffffff8166609e>] kmemleak_alloc+0x4e/0xb0
[<ffffffff8119f547>] kmem_cache_alloc_trace+0xd7/0x220
[<ffffffff8135ad2f>] populate_msi_sysfs+0x10f/0x220
[<ffffffff8135b4b8>] pci_enable_msi_block+0x1b8/0x2c0
[<ffffffffa0226ce5>] e1000_open+0x225/0x5b0 [e1000e]
[<ffffffff815785af>] __dev_open+0xbf/0x140
[<ffffffff815788bd>] __dev_change_flags+0x9d/0x170
[<ffffffff815789b9>] dev_change_flags+0x29/0x60
[<ffffffff81585482>] do_setlink+0x312/0x9e0
[<ffffffff81587958>] rtnl_newlink+0x508/0x710
[<ffffffff81584199>] rtnetlink_rcv_msg+0x99/0x260
[<ffffffff815a3269>] netlink_rcv_skb+0xa9/0xc0
[<ffffffff815840f8>] rtnetlink_rcv+0x28/0x30
[<ffffffff815a2bd8>] netlink_unicast+0x168/0x250
[<ffffffff815a2fa1>] netlink_sendmsg+0x2e1/0x3f0
[<ffffffff8155cc6b>] sock_sendmsg+0x8b/0xc0
unreferenced object 0xffff8800c4ac17a0 (size 32):
comm "NetworkManager", pid 409, jiffies 4294693366 (age 1102.161s)
hex dump (first 32 bytes):
20 19 ac c4 00 88 ff ff 24 01 00 00 00 00 00 00 .......$.......
f0 aa 35 81 ff ff ff ff 00 00 00 00 00 00 00 00 ..5.............
backtrace:
[<ffffffff8166609e>] kmemleak_alloc+0x4e/0xb0
[<ffffffff8119f547>] kmem_cache_alloc_trace+0xd7/0x220
[<ffffffff8135ad48>] populate_msi_sysfs+0x128/0x220
[<ffffffff8135b4b8>] pci_enable_msi_block+0x1b8/0x2c0
[<ffffffffa0226ce5>] e1000_open+0x225/0x5b0 [e1000e]
[<ffffffff815785af>] __dev_open+0xbf/0x140
[<ffffffff815788bd>] __dev_change_flags+0x9d/0x170
[<ffffffff815789b9>] dev_change_flags+0x29/0x60
[<ffffffff81585482>] do_setlink+0x312/0x9e0
[<ffffffff81587958>] rtnl_newlink+0x508/0x710
[<ffffffff81584199>] rtnetlink_rcv_msg+0x99/0x260
[<ffffffff815a3269>] netlink_rcv_skb+0xa9/0xc0
[<ffffffff815840f8>] rtnetlink_rcv+0x28/0x30
[<ffffffff815a2bd8>] netlink_unicast+0x168/0x250
[<ffffffff815a2fa1>] netlink_sendmsg+0x2e1/0x3f0
[<ffffffff8155cc6b>] sock_sendmsg+0x8b/0xc0
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: kmemleak through e1000?
2014-03-04 15:55 kmemleak through e1000? Daniel Borkmann
@ 2014-03-04 20:58 ` Bjorn Helgaas
2014-03-04 21:11 ` [E1000-devel] " Nelson, Shannon
2014-03-04 21:55 ` Daniel Borkmann
0 siblings, 2 replies; 7+ messages in thread
From: Bjorn Helgaas @ 2014-03-04 20:58 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Jeff Kirsher, Jesse Brandeburg, linux-pci@vger.kernel.org,
e1000-devel@lists.sourceforge.net
On Tue, Mar 4, 2014 at 8:55 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
> Hi all, I'm not very familiar with the e1000 code, but on the latest
> net.git kernel I get reliably the following (not sure if it's actually
> caused by e1000 though):
Thanks a lot for the report. What kernel is this exactly (URL and
SHA-1 hash)? We have fixes for a couple leaks already queued up [1,
2], so possibly you're seeing those leaks. If you already have those
fixes in net.git, then we should investigate further.
Bjorn
[1] http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/msi&id=13f81c099bee8141f764fd41a1f4b68b93be3296
[2] http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/msi&id=b3bac8e57c82e8d3e05f4abcb18c4f0a40656655
> unreferenced object 0xffff8800361a7d80 (size 32):
> comm "systemd-udevd", pid 246, jiffies 4294677997 (age 1117.522s)
> hex dump (first 32 bytes):
> 60 7d 1a 36 00 88 ff ff 24 01 00 00 00 00 00 00 `}.6....$.......
> f0 aa 35 81 ff ff ff ff 00 00 00 00 00 00 00 00 ..5.............
> backtrace:
> [<ffffffff8166609e>] kmemleak_alloc+0x4e/0xb0
> [<ffffffff8119f547>] kmem_cache_alloc_trace+0xd7/0x220
> [<ffffffff8135ad48>] populate_msi_sysfs+0x128/0x220
> [<ffffffff8135b4b8>] pci_enable_msi_block+0x1b8/0x2c0
> [<ffffffffa0221781>] e1000e_set_interrupt_capability+0x41/0x120 [e1000e]
> [<ffffffffa0226047>] e1000_probe+0x3a7/0xe20 [e1000e]
> [<ffffffff81343805>] local_pci_probe+0x45/0xa0
> [<ffffffff81344b89>] pci_device_probe+0xd9/0x130
> [<ffffffff813fc317>] driver_probe_device+0x87/0x390
> [<ffffffff813fc6f3>] __driver_attach+0x93/0xa0
> [<ffffffff813fa323>] bus_for_each_dev+0x63/0xa0
> [<ffffffff813fbd6e>] driver_attach+0x1e/0x20
> [<ffffffff813fb950>] bus_add_driver+0x180/0x250
> [<ffffffff813fcd04>] driver_register+0x64/0xf0
> [<ffffffff813431ab>] __pci_register_driver+0x4b/0x50
> [<ffffffffa0240041>] iptable_filter_hook+0x41/0x70 [iptable_filter]
> unreferenced object 0xffff8800c4ac1920 (size 32):
> comm "NetworkManager", pid 409, jiffies 4294693366 (age 1102.161s)
> hex dump (first 32 bytes):
> 34 34 00 c4 00 88 ff ff 00 00 00 00 00 00 00 00 44..............
> 00 00 00 00 00 00 00 00 6f 2e 32 00 00 00 00 00 ........o.2.....
> backtrace:
> [<ffffffff8166609e>] kmemleak_alloc+0x4e/0xb0
> [<ffffffff8119f547>] kmem_cache_alloc_trace+0xd7/0x220
> [<ffffffff8135ad2f>] populate_msi_sysfs+0x10f/0x220
> [<ffffffff8135b4b8>] pci_enable_msi_block+0x1b8/0x2c0
> [<ffffffffa0226ce5>] e1000_open+0x225/0x5b0 [e1000e]
> [<ffffffff815785af>] __dev_open+0xbf/0x140
> [<ffffffff815788bd>] __dev_change_flags+0x9d/0x170
> [<ffffffff815789b9>] dev_change_flags+0x29/0x60
> [<ffffffff81585482>] do_setlink+0x312/0x9e0
> [<ffffffff81587958>] rtnl_newlink+0x508/0x710
> [<ffffffff81584199>] rtnetlink_rcv_msg+0x99/0x260
> [<ffffffff815a3269>] netlink_rcv_skb+0xa9/0xc0
> [<ffffffff815840f8>] rtnetlink_rcv+0x28/0x30
> [<ffffffff815a2bd8>] netlink_unicast+0x168/0x250
> [<ffffffff815a2fa1>] netlink_sendmsg+0x2e1/0x3f0
> [<ffffffff8155cc6b>] sock_sendmsg+0x8b/0xc0
> unreferenced object 0xffff8800c4ac17a0 (size 32):
> comm "NetworkManager", pid 409, jiffies 4294693366 (age 1102.161s)
> hex dump (first 32 bytes):
> 20 19 ac c4 00 88 ff ff 24 01 00 00 00 00 00 00 .......$.......
> f0 aa 35 81 ff ff ff ff 00 00 00 00 00 00 00 00 ..5.............
> backtrace:
> [<ffffffff8166609e>] kmemleak_alloc+0x4e/0xb0
> [<ffffffff8119f547>] kmem_cache_alloc_trace+0xd7/0x220
> [<ffffffff8135ad48>] populate_msi_sysfs+0x128/0x220
> [<ffffffff8135b4b8>] pci_enable_msi_block+0x1b8/0x2c0
> [<ffffffffa0226ce5>] e1000_open+0x225/0x5b0 [e1000e]
> [<ffffffff815785af>] __dev_open+0xbf/0x140
> [<ffffffff815788bd>] __dev_change_flags+0x9d/0x170
> [<ffffffff815789b9>] dev_change_flags+0x29/0x60
> [<ffffffff81585482>] do_setlink+0x312/0x9e0
> [<ffffffff81587958>] rtnl_newlink+0x508/0x710
> [<ffffffff81584199>] rtnetlink_rcv_msg+0x99/0x260
> [<ffffffff815a3269>] netlink_rcv_skb+0xa9/0xc0
> [<ffffffff815840f8>] rtnetlink_rcv+0x28/0x30
> [<ffffffff815a2bd8>] netlink_unicast+0x168/0x250
> [<ffffffff815a2fa1>] netlink_sendmsg+0x2e1/0x3f0
> [<ffffffff8155cc6b>] sock_sendmsg+0x8b/0xc0
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [E1000-devel] kmemleak through e1000?
2014-03-04 20:58 ` Bjorn Helgaas
@ 2014-03-04 21:11 ` Nelson, Shannon
2014-03-04 21:33 ` Bjorn Helgaas
2014-03-04 21:55 ` Daniel Borkmann
1 sibling, 1 reply; 7+ messages in thread
From: Nelson, Shannon @ 2014-03-04 21:11 UTC (permalink / raw)
To: Bjorn Helgaas, Daniel Borkmann
Cc: e1000-devel@lists.sourceforge.net, linux-pci@vger.kernel.org,
Brandeburg, Jesse
> From: Bjorn Helgaas [mailto:bhelgaas@google.com]
>
> On Tue, Mar 4, 2014 at 8:55 AM, Daniel Borkmann <dborkman@redhat.com>
> wrote:
> > Hi all, I'm not very familiar with the e1000 code, but on the latest
> > net.git kernel I get reliably the following (not sure if it's actually
> > caused by e1000 though):
>
> Thanks a lot for the report. What kernel is this exactly (URL and
> SHA-1 hash)? We have fixes for a couple leaks already queued up [1,
> 2], so possibly you're seeing those leaks. If you already have those
> fixes in net.git, then we should investigate further.
>
> Bjorn
FYI - I've recently seen similar kmemleak reports from ixgbe and i40e drivers, all seemly pointing to the msix allocations. I didn't have a chance to track them down, but they were seen in variations of net-next 3.14.0-rc3.
sln
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [E1000-devel] kmemleak through e1000?
2014-03-04 21:11 ` [E1000-devel] " Nelson, Shannon
@ 2014-03-04 21:33 ` Bjorn Helgaas
0 siblings, 0 replies; 7+ messages in thread
From: Bjorn Helgaas @ 2014-03-04 21:33 UTC (permalink / raw)
To: Nelson, Shannon
Cc: Daniel Borkmann, e1000-devel@lists.sourceforge.net,
linux-pci@vger.kernel.org, Brandeburg, Jesse
On Tue, Mar 4, 2014 at 2:11 PM, Nelson, Shannon
<shannon.nelson@intel.com> wrote:
>> From: Bjorn Helgaas [mailto:bhelgaas@google.com]
>>
>> On Tue, Mar 4, 2014 at 8:55 AM, Daniel Borkmann <dborkman@redhat.com>
>> wrote:
>> > Hi all, I'm not very familiar with the e1000 code, but on the latest
>> > net.git kernel I get reliably the following (not sure if it's actually
>> > caused by e1000 though):
>>
>> Thanks a lot for the report. What kernel is this exactly (URL and
>> SHA-1 hash)? We have fixes for a couple leaks already queued up [1,
>> 2], so possibly you're seeing those leaks. If you already have those
>> fixes in net.git, then we should investigate further.
>>
>> Bjorn
>
>
> FYI - I've recently seen similar kmemleak reports from ixgbe and i40e drivers, all seemly pointing to the msix allocations. I didn't have a chance to track them down, but they were seen in variations of net-next 3.14.0-rc3.
I don't think that has the leak fixes in it yet. I'm looking here:
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/log/drivers/pci/msi.c
which does not contain the fixes from 2014-02-13 that are listed here:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/pci/msi.c
In particular, these two look related:
PCI/MSI: Fix leak of msi_attrs
PCI/MSI: Check kmalloc() return value, fix leak of name
So if you do look into them further, make sure you pick up these fixes
first, and let me know if you still see issues.
Bjorn
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: kmemleak through e1000?
2014-03-04 20:58 ` Bjorn Helgaas
2014-03-04 21:11 ` [E1000-devel] " Nelson, Shannon
@ 2014-03-04 21:55 ` Daniel Borkmann
2014-03-04 22:49 ` Bjorn Helgaas
1 sibling, 1 reply; 7+ messages in thread
From: Daniel Borkmann @ 2014-03-04 21:55 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Jeff Kirsher, Jesse Brandeburg, linux-pci@vger.kernel.org,
e1000-devel@lists.sourceforge.net
On 03/04/2014 09:58 PM, Bjorn Helgaas wrote:
> On Tue, Mar 4, 2014 at 8:55 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
>> Hi all, I'm not very familiar with the e1000 code, but on the latest
>> net.git kernel I get reliably the following (not sure if it's actually
>> caused by e1000 though):
>
> Thanks a lot for the report. What kernel is this exactly (URL and
> SHA-1 hash)? We have fixes for a couple leaks already queued up [1,
> 2], so possibly you're seeing those leaks. If you already have those
> fixes in net.git, then we should investigate further.
Great, good to know Bjorn.
I was using [1] with 8b4703e9bd117 ("macvlan: Add support for 'always_on'
offload features") as HEAD.
[1] https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/
> Bjorn
>
> [1] http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/msi&id=13f81c099bee8141f764fd41a1f4b68b93be3296
> [2] http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/msi&id=b3bac8e57c82e8d3e05f4abcb18c4f0a40656655
>
>> unreferenced object 0xffff8800361a7d80 (size 32):
>> comm "systemd-udevd", pid 246, jiffies 4294677997 (age 1117.522s)
>> hex dump (first 32 bytes):
>> 60 7d 1a 36 00 88 ff ff 24 01 00 00 00 00 00 00 `}.6....$.......
>> f0 aa 35 81 ff ff ff ff 00 00 00 00 00 00 00 00 ..5.............
>> backtrace:
>> [<ffffffff8166609e>] kmemleak_alloc+0x4e/0xb0
>> [<ffffffff8119f547>] kmem_cache_alloc_trace+0xd7/0x220
>> [<ffffffff8135ad48>] populate_msi_sysfs+0x128/0x220
>> [<ffffffff8135b4b8>] pci_enable_msi_block+0x1b8/0x2c0
>> [<ffffffffa0221781>] e1000e_set_interrupt_capability+0x41/0x120 [e1000e]
>> [<ffffffffa0226047>] e1000_probe+0x3a7/0xe20 [e1000e]
>> [<ffffffff81343805>] local_pci_probe+0x45/0xa0
>> [<ffffffff81344b89>] pci_device_probe+0xd9/0x130
>> [<ffffffff813fc317>] driver_probe_device+0x87/0x390
>> [<ffffffff813fc6f3>] __driver_attach+0x93/0xa0
>> [<ffffffff813fa323>] bus_for_each_dev+0x63/0xa0
>> [<ffffffff813fbd6e>] driver_attach+0x1e/0x20
>> [<ffffffff813fb950>] bus_add_driver+0x180/0x250
>> [<ffffffff813fcd04>] driver_register+0x64/0xf0
>> [<ffffffff813431ab>] __pci_register_driver+0x4b/0x50
>> [<ffffffffa0240041>] iptable_filter_hook+0x41/0x70 [iptable_filter]
>> unreferenced object 0xffff8800c4ac1920 (size 32):
>> comm "NetworkManager", pid 409, jiffies 4294693366 (age 1102.161s)
>> hex dump (first 32 bytes):
>> 34 34 00 c4 00 88 ff ff 00 00 00 00 00 00 00 00 44..............
>> 00 00 00 00 00 00 00 00 6f 2e 32 00 00 00 00 00 ........o.2.....
>> backtrace:
>> [<ffffffff8166609e>] kmemleak_alloc+0x4e/0xb0
>> [<ffffffff8119f547>] kmem_cache_alloc_trace+0xd7/0x220
>> [<ffffffff8135ad2f>] populate_msi_sysfs+0x10f/0x220
>> [<ffffffff8135b4b8>] pci_enable_msi_block+0x1b8/0x2c0
>> [<ffffffffa0226ce5>] e1000_open+0x225/0x5b0 [e1000e]
>> [<ffffffff815785af>] __dev_open+0xbf/0x140
>> [<ffffffff815788bd>] __dev_change_flags+0x9d/0x170
>> [<ffffffff815789b9>] dev_change_flags+0x29/0x60
>> [<ffffffff81585482>] do_setlink+0x312/0x9e0
>> [<ffffffff81587958>] rtnl_newlink+0x508/0x710
>> [<ffffffff81584199>] rtnetlink_rcv_msg+0x99/0x260
>> [<ffffffff815a3269>] netlink_rcv_skb+0xa9/0xc0
>> [<ffffffff815840f8>] rtnetlink_rcv+0x28/0x30
>> [<ffffffff815a2bd8>] netlink_unicast+0x168/0x250
>> [<ffffffff815a2fa1>] netlink_sendmsg+0x2e1/0x3f0
>> [<ffffffff8155cc6b>] sock_sendmsg+0x8b/0xc0
>> unreferenced object 0xffff8800c4ac17a0 (size 32):
>> comm "NetworkManager", pid 409, jiffies 4294693366 (age 1102.161s)
>> hex dump (first 32 bytes):
>> 20 19 ac c4 00 88 ff ff 24 01 00 00 00 00 00 00 .......$.......
>> f0 aa 35 81 ff ff ff ff 00 00 00 00 00 00 00 00 ..5.............
>> backtrace:
>> [<ffffffff8166609e>] kmemleak_alloc+0x4e/0xb0
>> [<ffffffff8119f547>] kmem_cache_alloc_trace+0xd7/0x220
>> [<ffffffff8135ad48>] populate_msi_sysfs+0x128/0x220
>> [<ffffffff8135b4b8>] pci_enable_msi_block+0x1b8/0x2c0
>> [<ffffffffa0226ce5>] e1000_open+0x225/0x5b0 [e1000e]
>> [<ffffffff815785af>] __dev_open+0xbf/0x140
>> [<ffffffff815788bd>] __dev_change_flags+0x9d/0x170
>> [<ffffffff815789b9>] dev_change_flags+0x29/0x60
>> [<ffffffff81585482>] do_setlink+0x312/0x9e0
>> [<ffffffff81587958>] rtnl_newlink+0x508/0x710
>> [<ffffffff81584199>] rtnetlink_rcv_msg+0x99/0x260
>> [<ffffffff815a3269>] netlink_rcv_skb+0xa9/0xc0
>> [<ffffffff815840f8>] rtnetlink_rcv+0x28/0x30
>> [<ffffffff815a2bd8>] netlink_unicast+0x168/0x250
>> [<ffffffff815a2fa1>] netlink_sendmsg+0x2e1/0x3f0
>> [<ffffffff8155cc6b>] sock_sendmsg+0x8b/0xc0
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: kmemleak through e1000?
2014-03-04 21:55 ` Daniel Borkmann
@ 2014-03-04 22:49 ` Bjorn Helgaas
2014-03-05 8:23 ` Daniel Borkmann
0 siblings, 1 reply; 7+ messages in thread
From: Bjorn Helgaas @ 2014-03-04 22:49 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Jeff Kirsher, Jesse Brandeburg, linux-pci@vger.kernel.org,
e1000-devel@lists.sourceforge.net
On Tue, Mar 4, 2014 at 2:55 PM, Daniel Borkmann <dborkman@redhat.com> wrote:
> On 03/04/2014 09:58 PM, Bjorn Helgaas wrote:
>>
>> On Tue, Mar 4, 2014 at 8:55 AM, Daniel Borkmann <dborkman@redhat.com>
>> wrote:
>>>
>>> Hi all, I'm not very familiar with the e1000 code, but on the latest
>>> net.git kernel I get reliably the following (not sure if it's actually
>>> caused by e1000 though):
>>
>>
>> Thanks a lot for the report. What kernel is this exactly (URL and
>> SHA-1 hash)? We have fixes for a couple leaks already queued up [1,
>> 2], so possibly you're seeing those leaks. If you already have those
>> fixes in net.git, then we should investigate further.
>
>
> Great, good to know Bjorn.
>
> I was using [1] with 8b4703e9bd117 ("macvlan: Add support for 'always_on'
> offload features") as HEAD.
>
> [1] https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/
Thanks, Daniel. I confirmed that the two MSI fixes are not in the
tree you're testing, so that's probably what you're seeing.
>> [1]
>> http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/msi&id=13f81c099bee8141f764fd41a1f4b68b93be3296
>> [2]
>> http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/msi&id=b3bac8e57c82e8d3e05f4abcb18c4f0a40656655
>>
>>> unreferenced object 0xffff8800361a7d80 (size 32):
>>> comm "systemd-udevd", pid 246, jiffies 4294677997 (age 1117.522s)
>>> hex dump (first 32 bytes):
>>> 60 7d 1a 36 00 88 ff ff 24 01 00 00 00 00 00 00 `}.6....$.......
>>> f0 aa 35 81 ff ff ff ff 00 00 00 00 00 00 00 00 ..5.............
>>> backtrace:
>>> [<ffffffff8166609e>] kmemleak_alloc+0x4e/0xb0
>>> [<ffffffff8119f547>] kmem_cache_alloc_trace+0xd7/0x220
>>> [<ffffffff8135ad48>] populate_msi_sysfs+0x128/0x220
>>> [<ffffffff8135b4b8>] pci_enable_msi_block+0x1b8/0x2c0
>>> [<ffffffffa0221781>] e1000e_set_interrupt_capability+0x41/0x120
>>> [e1000e]
>>> [<ffffffffa0226047>] e1000_probe+0x3a7/0xe20 [e1000e]
>>> [<ffffffff81343805>] local_pci_probe+0x45/0xa0
>>> [<ffffffff81344b89>] pci_device_probe+0xd9/0x130
>>> [<ffffffff813fc317>] driver_probe_device+0x87/0x390
>>> [<ffffffff813fc6f3>] __driver_attach+0x93/0xa0
>>> [<ffffffff813fa323>] bus_for_each_dev+0x63/0xa0
>>> [<ffffffff813fbd6e>] driver_attach+0x1e/0x20
>>> [<ffffffff813fb950>] bus_add_driver+0x180/0x250
>>> [<ffffffff813fcd04>] driver_register+0x64/0xf0
>>> [<ffffffff813431ab>] __pci_register_driver+0x4b/0x50
>>> [<ffffffffa0240041>] iptable_filter_hook+0x41/0x70 [iptable_filter]
>>> unreferenced object 0xffff8800c4ac1920 (size 32):
>>> comm "NetworkManager", pid 409, jiffies 4294693366 (age 1102.161s)
>>> hex dump (first 32 bytes):
>>> 34 34 00 c4 00 88 ff ff 00 00 00 00 00 00 00 00 44..............
>>> 00 00 00 00 00 00 00 00 6f 2e 32 00 00 00 00 00 ........o.2.....
>>> backtrace:
>>> [<ffffffff8166609e>] kmemleak_alloc+0x4e/0xb0
>>> [<ffffffff8119f547>] kmem_cache_alloc_trace+0xd7/0x220
>>> [<ffffffff8135ad2f>] populate_msi_sysfs+0x10f/0x220
>>> [<ffffffff8135b4b8>] pci_enable_msi_block+0x1b8/0x2c0
>>> [<ffffffffa0226ce5>] e1000_open+0x225/0x5b0 [e1000e]
>>> [<ffffffff815785af>] __dev_open+0xbf/0x140
>>> [<ffffffff815788bd>] __dev_change_flags+0x9d/0x170
>>> [<ffffffff815789b9>] dev_change_flags+0x29/0x60
>>> [<ffffffff81585482>] do_setlink+0x312/0x9e0
>>> [<ffffffff81587958>] rtnl_newlink+0x508/0x710
>>> [<ffffffff81584199>] rtnetlink_rcv_msg+0x99/0x260
>>> [<ffffffff815a3269>] netlink_rcv_skb+0xa9/0xc0
>>> [<ffffffff815840f8>] rtnetlink_rcv+0x28/0x30
>>> [<ffffffff815a2bd8>] netlink_unicast+0x168/0x250
>>> [<ffffffff815a2fa1>] netlink_sendmsg+0x2e1/0x3f0
>>> [<ffffffff8155cc6b>] sock_sendmsg+0x8b/0xc0
>>> unreferenced object 0xffff8800c4ac17a0 (size 32):
>>> comm "NetworkManager", pid 409, jiffies 4294693366 (age 1102.161s)
>>> hex dump (first 32 bytes):
>>> 20 19 ac c4 00 88 ff ff 24 01 00 00 00 00 00 00 .......$.......
>>> f0 aa 35 81 ff ff ff ff 00 00 00 00 00 00 00 00 ..5.............
>>> backtrace:
>>> [<ffffffff8166609e>] kmemleak_alloc+0x4e/0xb0
>>> [<ffffffff8119f547>] kmem_cache_alloc_trace+0xd7/0x220
>>> [<ffffffff8135ad48>] populate_msi_sysfs+0x128/0x220
>>> [<ffffffff8135b4b8>] pci_enable_msi_block+0x1b8/0x2c0
>>> [<ffffffffa0226ce5>] e1000_open+0x225/0x5b0 [e1000e]
>>> [<ffffffff815785af>] __dev_open+0xbf/0x140
>>> [<ffffffff815788bd>] __dev_change_flags+0x9d/0x170
>>> [<ffffffff815789b9>] dev_change_flags+0x29/0x60
>>> [<ffffffff81585482>] do_setlink+0x312/0x9e0
>>> [<ffffffff81587958>] rtnl_newlink+0x508/0x710
>>> [<ffffffff81584199>] rtnetlink_rcv_msg+0x99/0x260
>>> [<ffffffff815a3269>] netlink_rcv_skb+0xa9/0xc0
>>> [<ffffffff815840f8>] rtnetlink_rcv+0x28/0x30
>>> [<ffffffff815a2bd8>] netlink_unicast+0x168/0x250
>>> [<ffffffff815a2fa1>] netlink_sendmsg+0x2e1/0x3f0
>>> [<ffffffff8155cc6b>] sock_sendmsg+0x8b/0xc0
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-03-05 8:23 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-04 15:55 kmemleak through e1000? Daniel Borkmann
2014-03-04 20:58 ` Bjorn Helgaas
2014-03-04 21:11 ` [E1000-devel] " Nelson, Shannon
2014-03-04 21:33 ` Bjorn Helgaas
2014-03-04 21:55 ` Daniel Borkmann
2014-03-04 22:49 ` Bjorn Helgaas
2014-03-05 8:23 ` Daniel Borkmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).