Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1412356 > unrolled thread

Re: linux-next memleak after IO on dax mountpoint

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: linux-next memleak after IO on dax mountpoint David Drysdale <drysdale@google.com> - 2016-06-02 17:30 +0200
    Re: linux-next/linux memleak after IO on dax mountpoint Xiong Zhou <xzhou@redhat.com> - 2016-06-03 08:40 +0200
    Re: linux-next/linux memleak after IO on dax mountpoint Xiong Zhou <xzhou@redhat.com> - 2016-06-07 12:30 +0200

#1412356 — Re: linux-next memleak after IO on dax mountpoint

On Sat, May 28, 2016 at 5:05 AM, Xiong Zhou <xzhou@redhat.com> wrote:
> On Fri, May 27, 2016 at 04:46:17PM +0800, Xiong Zhou wrote:
> ...
>> Still working on to id which commit in this merge causes this issuer,
>
> Narrowed down to:
>
> 37e5823 block: add offset in blk_add_request_payload()
> e048948 blk-mq: Export tagset iter function
> 58b4560 nvme: add helper nvme_map_len()
> 03b5929 nvme: rewrite discard support
> 8093f7c nvme: add helper nvme_setup_cmd()
> 21f033f NVMe: Skip async events for degraded controllers
> 82b4552 nvme: Use blk-mq helper for IO termination
> 93e9d8e block: add ability to flag write back caching on a device
> 519a7e1 dm: switch to using blk_queue_write_cache()
> bb8d261 nvme: introduce a controller state machine
> 92911a5 nvme: tighten up state check for namespace scanning
> 5955be2 nvme: move namespace scanning to core
> f866fc4 nvme: move AER handling to common code
> 0bf77e9 nvme: switch to RCU freeing the namespace
> 9082e87 block: remove struct bio_batch

FWIW, I'm also seeing kmemleak report a leak with v4.7-rc1, in
a different scenario (just normal desktop use).  Not done much
digging so far, but this commit (9082e87bf) looks like it might be
relevant -- lots of the following:

unreferenced object 0xffff8800c288e900 (size 256):
  comm "dconf-service", pid 1461, jiffies 4294895636 (age 48.028s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 c0 a4 c0 c6 00 88 ff ff  ................
    02 20 00 20 00 00 00 00 11 00 00 00 00 00 00 00  . . ............
  backtrace:
    [<ffffffff81955228>] kmemleak_alloc+0x28/0x50
    [<ffffffff81268bdc>] kmem_cache_alloc+0xfc/0x360
    [<ffffffff81203275>] mempool_alloc_slab+0x15/0x20
    [<ffffffff812030de>] mempool_alloc+0x6e/0x170
    [<ffffffff815014e8>] bio_alloc_bioset+0xb8/0x230
    [<ffffffff81514174>] next_bio+0x24/0x50
    [<ffffffff815145ef>] blkdev_issue_zeroout+0xdf/0x1d0
    [<ffffffff8132ce79>] ext4_issue_zeroout+0x39/0x50
    [<ffffffff81357abf>] ext4_ext_zeroout+0x2f/0x40
    [<ffffffff8135ece0>] ext4_ext_map_blocks+0x1870/0x2190
    [<ffffffff8132cfa1>] ext4_map_blocks+0x111/0x620
    [<ffffffff81330dc8>] ext4_writepages+0x7c8/0x10a0
    [<ffffffff81211851>] do_writepages+0x21/0x30
    [<ffffffff812012ba>] __filemap_fdatawrite_range+0xaa/0xf0
    [<ffffffff812013fd>] filemap_write_and_wait_range+0x2d/0x70
    [<ffffffff81326f6d>] ext4_sync_file+0x18d/0x500


> 38f2525 block: add __blkdev_issue_discard
> 57aac2f lightnvm: fix "warning: ‘ret’ may be used uninitialized"
> ecfb40c lightnvm: handle submit_io failure
> 1145e63 lightnvm: implement nvm_submit_ppa_list
> 22e8c97 lightnvm: move block fold outside of get_bb_tbl()
> 7f7c5d0 lightnvm: avoid memory leak when lun_map kcalloc fails
> 5136061 lightnvm: introduce nvm_for_each_lun_ppa() macro
> e11903f lightnvm: refactor device ops->get_bb_tbl()
> 5ebc7d9 lightnvm: make nvm_set_rqd_ppalist() aware of vblks
> a63d5cf lightnvm: move responsibility for bad blk mgmt to target
> 00ee6cc lightnvm: refactor set_bb_tbl for accepting ppa list
> 003fad3 lightnvm: enable metadata to be sent to device
> 04a8aa1 lightnvm: expose gennvm_mark_blk to targets
>
>
> These commits can not be reverted cleanly.

[toc] | [next] | [standalone]

#1412842 — Re: linux-next/linux memleak after IO on dax mountpoint

On Thu, Jun 02, 2016 at 04:22:37PM +0100, David Drysdale wrote:
> On Sat, May 28, 2016 at 5:05 AM, Xiong Zhou <xzhou@redhat.com> wrote:
> > On Fri, May 27, 2016 at 04:46:17PM +0800, Xiong Zhou wrote:
> > ...
> >> Still working on to id which commit in this merge causes this issuer,
> >
> > Narrowed down to:
> >
> > 37e5823 block: add offset in blk_add_request_payload()
...
> > 0bf77e9 nvme: switch to RCU freeing the namespace
> > 9082e87 block: remove struct bio_batch
> 
> FWIW, I'm also seeing kmemleak report a leak with v4.7-rc1, in
> a different scenario (just normal desktop use).  Not done much
> digging so far, but this commit (9082e87bf) looks like it might be
> relevant

<snip..>

Thanks for the tip, accelerated my searching in the block merge.

On top of v4.7-rc1 , in order to revert this commit cleanly:

	9082e87 block: remove struct bio_batch

, have to revert these two:

	bbd848e0f block: reinstate early return of -EOPNOTSUPP from blkdev_issue_discard
	38f2525 block: add __blkdev_issue_discard

, then have to revert these two dependances:

202bae5 dm thin: unroll issue_discard() to create longer discard bio chains
3dba53a9 dm thin: use __blkdev_issue_discard for async discard support

With all these five commits reverted, NO memleak happens.

Reverting other four commits while not reverting 9082e87, memleak
happens.

Thanks,
Xiong

[toc] | [prev] | [next] | [standalone]

#1415966 — Re: linux-next/linux memleak after IO on dax mountpoint

adding block-list

On Fri, Jun 03, 2016 at 09:48:27AM -0700, Bart Van Assche wrote:
> On 06/02/2016 08:22 AM, David Drysdale wrote:
> > FWIW, I'm also seeing kmemleak report a leak with v4.7-rc1, in
> > a different scenario (just normal desktop use).  Not done much
> > digging so far, but this commit (9082e87bf) looks like it might be
> > relevant -- lots of the following:
> > 
> > unreferenced object 0xffff8800c288e900 (size 256):
> >   comm "dconf-service", pid 1461, jiffies 4294895636 (age 48.028s)
> >   hex dump (first 32 bytes):
> >     00 00 00 00 00 00 00 00 c0 a4 c0 c6 00 88 ff ff  ................
> >     02 20 00 20 00 00 00 00 11 00 00 00 00 00 00 00  . . ............
> >   backtrace:
> >     [<ffffffff81955228>] kmemleak_alloc+0x28/0x50
> >     [<ffffffff81268bdc>] kmem_cache_alloc+0xfc/0x360
> >     [<ffffffff81203275>] mempool_alloc_slab+0x15/0x20
> >     [<ffffffff812030de>] mempool_alloc+0x6e/0x170
> >     [<ffffffff815014e8>] bio_alloc_bioset+0xb8/0x230
> >     [<ffffffff81514174>] next_bio+0x24/0x50
> >     [<ffffffff815145ef>] blkdev_issue_zeroout+0xdf/0x1d0
> >     [<ffffffff8132ce79>] ext4_issue_zeroout+0x39/0x50
> >     [<ffffffff81357abf>] ext4_ext_zeroout+0x2f/0x40
> >     [<ffffffff8135ece0>] ext4_ext_map_blocks+0x1870/0x2190
> >     [<ffffffff8132cfa1>] ext4_map_blocks+0x111/0x620
> >     [<ffffffff81330dc8>] ext4_writepages+0x7c8/0x10a0
> >     [<ffffffff81211851>] do_writepages+0x21/0x30
> >     [<ffffffff812012ba>] __filemap_fdatawrite_range+0xaa/0xf0
> >     [<ffffffff812013fd>] filemap_write_and_wait_range+0x2d/0x70
> >     [<ffffffff81326f6d>] ext4_sync_file+0x18d/0x500
> 
> (+Christoph)
> 
> With kernel v4.7-rc1 and XFS I see that the blkdev_issue_zeroout() calls
> triggered by xfstests make kmemleak complain. I hadn't seen this with any
> previous kernel version.
> 
> Bart.


unreferenced object 0xffff880c4bce2800 (size 2048):
  comm "dbench", pid 11389, jiffies 4294884573 (age 193.194s)
  hex dump (first 32 bytes):
    c0 1d 09 00 00 ea ff ff 00 10 00 00 00 00 00 00  ................
    c0 1d 09 00 00 ea ff ff 00 10 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff816d178e>] kmemleak_alloc+0x4e/0xb0
    [<ffffffff811f6fc3>] kmem_cache_alloc+0xc3/0x200
    [<ffffffff813197ec>] bvec_alloc+0x5c/0xf0
    [<ffffffff81319a4e>] bio_alloc_bioset+0x1ce/0x2d0
    [<ffffffff8132a574>] next_bio+0x24/0x50
    [<ffffffff8132aa00>] blkdev_issue_zeroout+0xe0/0x1d0
    [<ffffffffa08ebcc8>] ext4_issue_zeroout+0x38/0x50 [ext4]
    [<ffffffffa08ec07e>] ext4_map_blocks+0x39e/0x640 [ext4]
    [<ffffffffa08ec3b3>] _ext4_get_block+0x93/0xf0 [ext4]
    [<ffffffffa08eca6f>] ext4_get_block_trans+0xbf/0x110 [ext4]
    [<ffffffffa08eccc5>] ext4_dax_get_block+0x25/0x70 [ext4]
    [<ffffffff81270c96>] dax_do_io+0x446/0x610
    [<ffffffffa08f1d04>] ext4_direct_IO+0x494/0x750 [ext4]
    [<ffffffff81195590>] generic_file_direct_write+0xb0/0x180
    [<ffffffff8119571d>] __generic_file_write_iter+0xbd/0x1e0
    [<ffffffffa08e5e77>] ext4_file_write_iter+0xf7/0x330 [ext4]

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web