Re: 4.4rc3 nfsd/btrfs kasan warning.

[Chris Mason]

On Wed, Dec 02, 2015 at 09:32:34PM +0300, Andrey Ryabinin wrote:
> 2015-12-02 20:14 GMT+03:00 Chris Mason :
> > On Wed, Dec 02, 2015 at 11:09:43AM -0500, Dave Jones wrote:
> >> On Wed, Dec 02, 2015 at 10:11:28AM -0500, Josef Bacik wrote:
> >>  > On 12/02/2015 09:59 AM, Dave Jones wrote:
> >>  > > Got a few of these in the logs this morning after an overnight rsync 
> >> over nfs
> >>  > > to an exported btrfs volume.
> >>  >
> >>  > That's probably us and not NFS, what line is that in
> >>  > setup_cluster_bitmap?  Thanks,
> >>
> >> If my math is correct, it's this..
> >>
> >> if (entry->offset != bitmap_offset)
> >>
> >> I don't seem to be able to trigger it on demand unfortunatly.
> >
> > Is it possible we're blowing the stack?  It seems pretty tricky to get a
> > stack out of bounds out of this code without flat out blowing through
> > it.
> >
> 
> I think it just empty bitmaps list.
>  list_first_entry() can't be used on empty list.

Ohh, I was so busy looking for free'd entries I missed that.  Good
point.

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

Re: 4.4rc3 nfsd/btrfs kasan warning.

[Andrey Ryabinin]

2015-12-02 20:14 GMT+03:00 Chris Mason :
> On Wed, Dec 02, 2015 at 11:09:43AM -0500, Dave Jones wrote:
>> On Wed, Dec 02, 2015 at 10:11:28AM -0500, Josef Bacik wrote:
>>  > On 12/02/2015 09:59 AM, Dave Jones wrote:
>>  > > Got a few of these in the logs this morning after an overnight rsync 
>> over nfs
>>  > > to an exported btrfs volume.
>>  >
>>  > That's probably us and not NFS, what line is that in
>>  > setup_cluster_bitmap?  Thanks,
>>
>> If my math is correct, it's this..
>>
>> if (entry->offset != bitmap_offset)
>>
>> I don't seem to be able to trigger it on demand unfortunatly.
>
> Is it possible we're blowing the stack?  It seems pretty tricky to get a
> stack out of bounds out of this code without flat out blowing through
> it.
>

I think it just empty bitmaps list.
 list_first_entry() can't be used on empty list.

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

Re: 4.4rc3 nfsd/btrfs kasan warning.

[Dave Jones]

On Wed, Dec 02, 2015 at 12:14:56PM -0500, Chris Mason wrote:
 > On Wed, Dec 02, 2015 at 11:09:43AM -0500, Dave Jones wrote:
 > > On Wed, Dec 02, 2015 at 10:11:28AM -0500, Josef Bacik wrote:
 > >  > On 12/02/2015 09:59 AM, Dave Jones wrote:
 > >  > > Got a few of these in the logs this morning after an overnight rsync 
 > > over nfs
 > >  > > to an exported btrfs volume.
 > >  > 
 > >  > That's probably us and not NFS, what line is that in 
 > >  > setup_cluster_bitmap?  Thanks,
 > > 
 > > If my math is correct, it's this..
 > > 
 > > if (entry->offset != bitmap_offset)
 > > 
 > > I don't seem to be able to trigger it on demand unfortunatly.
 > 
 > Is it possible we're blowing the stack?  It seems pretty tricky to get a
 > stack out of bounds out of this code without flat out blowing through
 > it.

Hm, there is a lot of debug crap on the stack from lockdep etc, though I didn't
get any warnings from the other stack overflow checks.

Dave

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

Re: 4.4rc3 nfsd/btrfs kasan warning.

[Chris Mason]

On Wed, Dec 02, 2015 at 11:09:43AM -0500, Dave Jones wrote:
> On Wed, Dec 02, 2015 at 10:11:28AM -0500, Josef Bacik wrote:
>  > On 12/02/2015 09:59 AM, Dave Jones wrote:
>  > > Got a few of these in the logs this morning after an overnight rsync 
> over nfs
>  > > to an exported btrfs volume.
>  > 
>  > That's probably us and not NFS, what line is that in 
>  > setup_cluster_bitmap?  Thanks,
> 
> If my math is correct, it's this..
> 
> if (entry->offset != bitmap_offset)
> 
> I don't seem to be able to trigger it on demand unfortunatly.

Is it possible we're blowing the stack?  It seems pretty tricky to get a
stack out of bounds out of this code without flat out blowing through
it.

-chris

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

Re: 4.4rc3 nfsd/btrfs kasan warning.

[Dave Jones]

On Wed, Dec 02, 2015 at 10:11:28AM -0500, Josef Bacik wrote:
 > On 12/02/2015 09:59 AM, Dave Jones wrote:
 > > Got a few of these in the logs this morning after an overnight rsync over 
 > > nfs
 > > to an exported btrfs volume.
 > 
 > That's probably us and not NFS, what line is that in 
 > setup_cluster_bitmap?  Thanks,

If my math is correct, it's this..

if (entry->offset != bitmap_offset)

I don't seem to be able to trigger it on demand unfortunatly.

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

Re: 4.4rc3 nfsd/btrfs kasan warning.

[Josef Bacik]

On 12/02/2015 09:59 AM, Dave Jones wrote:

Got a few of these in the logs this morning after an overnight rsync over nfs
to an exported btrfs volume.


That's probably us and not NFS, what line is that in 
setup_cluster_bitmap?  Thanks,


Josef

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

4.4rc3 nfsd/btrfs kasan warning.

[Dave Jones]

Got a few of these in the logs this morning after an overnight rsync over nfs
to an exported btrfs volume.

Dave

==
BUG: KASAN: stack-out-of-bounds in setup_cluster_bitmap+0xc4/0x5a0 at addr 
88039bef6828
Read of size 8 by task nfsd/1009
page:ea000e6fbd80 count:0 mapcount:0 mapping:  (null) index:0x0
flags: 0x8000()
page dumped because: kasan: bad access detected
CPU: 1 PID: 1009 Comm: nfsd Tainted: GW   4.4.0-rc3-backup-debug+ #1
 880065647b50 6bb712c2 88039bef6640 a680a43e
 004559c0 88039bef66c8 a62638d1 a61121c0
 8803a5769de8 0296 8803a5769df0 00046280
Call Trace:
 [] dump_stack+0x4b/0x6d
 [] kasan_report_error+0x501/0x520
 [] ? debug_show_all_locks+0x1e0/0x1e0
 [] kasan_report+0x58/0x60
 [] ? rb_last+0x10/0x40
 [] ? setup_cluster_bitmap+0xc4/0x5a0
 [] __asan_load8+0x5d/0x70
 [] setup_cluster_bitmap+0xc4/0x5a0
 [] ? setup_cluster_no_bitmap+0x6a/0x400
 [] btrfs_find_space_cluster+0x4b6/0x640
 [] ? btrfs_alloc_from_cluster+0x4e0/0x4e0
 [] ? btrfs_return_cluster_to_free_space+0x9e/0xb0
 [] ? _raw_spin_unlock+0x27/0x40
 [] find_free_extent+0xba1/0x1520
 [] ? btrfs_delalloc_reserve_space+0x70/0x70
 [] ? do_raw_spin_lock+0x116/0x1a0
 [] ? do_raw_spin_unlock+0x97/0x130
 [] ? _raw_spin_unlock+0x27/0x40
 [] ? get_alloc_profile+0x1c5/0x320
 [] ? btrfs_reserve_extent+0x70/0x1d0
 [] btrfs_reserve_extent+0xc0/0x1d0
 [] btrfs_alloc_tree_block+0x3bf/0x680
 [] ? debug_show_all_locks+0x1e0/0x1e0
 [] ? btrfs_reserve_extent+0x1d0/0x1d0
 [] ? memcpy+0x36/0x40
 [] ? read_extent_buffer+0xe7/0x160
 [] __btrfs_cow_block+0x28f/0x9b0
 [] ? mark_page_accessed+0x18/0xd0
 [] ? update_ref_for_cow+0x540/0x540
 [] ? debug_lockdep_rcu_enabled+0x35/0x40
 [] ? btrfs_try_tree_write_lock+0x5f/0xe0
 [] ? btrfs_set_lock_blocking_rw+0x110/0x160
 [] btrfs_cow_block+0x1cf/0x380
 [] btrfs_search_slot+0x413/0x11e0
 [] ? split_leaf+0xc50/0xc50
 [] ? btrfs_alloc_path+0x26/0x30
 [] ? set_track+0x83/0x140
 [] ? mark_lock+0x6d/0x8a0
 [] btrfs_lookup_csum+0xba/0x260
 [] ? __lock_is_held+0x84/0xc0
 [] ? truncate_one_csum+0x1c0/0x1c0
 [] ? rcu_read_lock_sched_held+0x8a/0xa0
 [] ? kmem_cache_alloc+0x1c3/0x280
 [] btrfs_csum_file_blocks+0x2bd/0xac0
 [] ? btrfs_del_csums+0x490/0x490
 [] ? kfree+0xb7/0x230
 [] ? copy_items+0x6ab/0xd2d
 [] ? copy_items+0x6ab/0xd2d
 [] copy_items+0x6da/0xd2d
 [] ? btrfs_set_lock_blocking_rw+0x21/0x160
 [] ? assfail.constprop.22+0x1e/0x1e
 [] ? btrfs_search_forward+0x541/0x600
 [] ? read_extent_buffer+0xe7/0x160
 [] ? btrfs_item_key_to_cpu+0xb7/0xf0
 [] ? check_parent_dirs_for_sync+0x200/0x200
 [] btrfs_log_inode+0x7a9/0x11fa
 [] ? btrfs_log_changed_extents+0x883/0x883
 [] ? mark_lock+0x6d/0x8a0
 [] ? mark_held_locks+0x8e/0xc0
 [] ? mutex_lock_nested+0x3a5/0x510
 [] ? trace_hardirqs_on_caller+0x192/0x290
 [] ? mark_lock+0x6d/0x8a0
 [] ? debug_lockdep_rcu_enabled+0x35/0x40
 [] ? mark_held_locks+0x8e/0xc0
 [] ? __mutex_unlock_slowpath+0xe0/0x1c0
 [] ? trace_hardirqs_on_caller+0x192/0x290
 [] ? trace_hardirqs_on+0xd/0x10
 [] btrfs_log_inode_parent+0x404/0x1440
 [] ? debug_show_all_locks+0x1e0/0x1e0
 [] ? debug_show_all_locks+0x1e0/0x1e0
 [] ? btrfs_end_log_trans+0x50/0x50
 [] ? debug_lockdep_rcu_enabled+0x35/0x40
 [] ? debug_lockdep_rcu_enabled.part.36+0x1a/0x30
 [] ? debug_lockdep_rcu_enabled+0x35/0x40
 [] ? dget_parent+0x8e/0x2f0
 [] ? dget_parent+0xbe/0x2f0
 [] btrfs_log_dentry_safe+0x6a/0x90
 [] btrfs_sync_file+0x4df/0x690
 [] ? start_ordered_ops+0x30/0x30
 [] ? __fsnotify_update_child_dentry_flags+0x30/0x30
 [] vfs_fsync_range+0x5d/0x120
 [] ? start_ordered_ops+0x30/0x30
 [] nfsd_vfs_write+0x356/0x650
 [] ? nfsd_readv+0xa0/0xa0
 [] ? debug_lockdep_rcu_enabled+0x35/0x40
 [] nfsd_write+0xff/0x120
 [] ? __list_add+0x74/0xf0
 [] nfsd3_proc_write+0x1c7/0x2d0
 [] ? nfsd_cache_lookup+0x6ef/0xa90
 [] ? nfsd3_proc_symlink+0x1f0/0x1f0
 [] nfsd_dispatch+0x185/0x370
 [] ? nfsd3_proc_symlink+0x1f0/0x1f0
 [] svc_process_common+0x8c6/0xda0
 [] ? nfsd_svc+0x770/0x770
 [] ? svc_printk+0x180/0x180
 [] ? __lock_is_held+0x25/0xc0
 [] svc_process+0x22b/0x450
 [] nfsd+0x23c/0x370
 [] ? nfsd+0x5/0x370
 [] ? nfsd_destroy+0x1f0/0x1f0
 [] kthread+0x196/0x1c0
 [] ? __kthread_parkme+0xe0/0xe0
 [] ? mark_held_locks+0x23/0xc0
 [] ? __kthread_parkme+0xe0/0xe0
 [] ret_from_fork+0x3f/0x70
 [] ? __kthread_parkme+0xe0/0xe0
Memory state around the buggy address:
 88039bef6700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 88039bef6780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>88039bef6800: 00 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4 f3 f3 f3
  ^
 88039bef6880: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 88039bef6900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo 

Re: 4.4rc3 nfsd/btrfs kasan warning.

[Dave Jones]

On Wed, Dec 02, 2015 at 10:11:28AM -0500, Josef Bacik wrote:
 > On 12/02/2015 09:59 AM, Dave Jones wrote:
 > > Got a few of these in the logs this morning after an overnight rsync over 
 > > nfs
 > > to an exported btrfs volume.
 > 
 > That's probably us and not NFS, what line is that in 
 > setup_cluster_bitmap?  Thanks,

If my math is correct, it's this..

if (entry->offset != bitmap_offset)

I don't seem to be able to trigger it on demand unfortunatly.

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

4.4rc3 nfsd/btrfs kasan warning.

[Dave Jones]

Got a few of these in the logs this morning after an overnight rsync over nfs
to an exported btrfs volume.

Dave

==
BUG: KASAN: stack-out-of-bounds in setup_cluster_bitmap+0xc4/0x5a0 at addr 
88039bef6828
Read of size 8 by task nfsd/1009
page:ea000e6fbd80 count:0 mapcount:0 mapping:  (null) index:0x0
flags: 0x8000()
page dumped because: kasan: bad access detected
CPU: 1 PID: 1009 Comm: nfsd Tainted: GW   4.4.0-rc3-backup-debug+ #1
 880065647b50 6bb712c2 88039bef6640 a680a43e
 004559c0 88039bef66c8 a62638d1 a61121c0
 8803a5769de8 0296 8803a5769df0 00046280
Call Trace:
 [] dump_stack+0x4b/0x6d
 [] kasan_report_error+0x501/0x520
 [] ? debug_show_all_locks+0x1e0/0x1e0
 [] kasan_report+0x58/0x60
 [] ? rb_last+0x10/0x40
 [] ? setup_cluster_bitmap+0xc4/0x5a0
 [] __asan_load8+0x5d/0x70
 [] setup_cluster_bitmap+0xc4/0x5a0
 [] ? setup_cluster_no_bitmap+0x6a/0x400
 [] btrfs_find_space_cluster+0x4b6/0x640
 [] ? btrfs_alloc_from_cluster+0x4e0/0x4e0
 [] ? btrfs_return_cluster_to_free_space+0x9e/0xb0
 [] ? _raw_spin_unlock+0x27/0x40
 [] find_free_extent+0xba1/0x1520
 [] ? btrfs_delalloc_reserve_space+0x70/0x70
 [] ? do_raw_spin_lock+0x116/0x1a0
 [] ? do_raw_spin_unlock+0x97/0x130
 [] ? _raw_spin_unlock+0x27/0x40
 [] ? get_alloc_profile+0x1c5/0x320
 [] ? btrfs_reserve_extent+0x70/0x1d0
 [] btrfs_reserve_extent+0xc0/0x1d0
 [] btrfs_alloc_tree_block+0x3bf/0x680
 [] ? debug_show_all_locks+0x1e0/0x1e0
 [] ? btrfs_reserve_extent+0x1d0/0x1d0
 [] ? memcpy+0x36/0x40
 [] ? read_extent_buffer+0xe7/0x160
 [] __btrfs_cow_block+0x28f/0x9b0
 [] ? mark_page_accessed+0x18/0xd0
 [] ? update_ref_for_cow+0x540/0x540
 [] ? debug_lockdep_rcu_enabled+0x35/0x40
 [] ? btrfs_try_tree_write_lock+0x5f/0xe0
 [] ? btrfs_set_lock_blocking_rw+0x110/0x160
 [] btrfs_cow_block+0x1cf/0x380
 [] btrfs_search_slot+0x413/0x11e0
 [] ? split_leaf+0xc50/0xc50
 [] ? btrfs_alloc_path+0x26/0x30
 [] ? set_track+0x83/0x140
 [] ? mark_lock+0x6d/0x8a0
 [] btrfs_lookup_csum+0xba/0x260
 [] ? __lock_is_held+0x84/0xc0
 [] ? truncate_one_csum+0x1c0/0x1c0
 [] ? rcu_read_lock_sched_held+0x8a/0xa0
 [] ? kmem_cache_alloc+0x1c3/0x280
 [] btrfs_csum_file_blocks+0x2bd/0xac0
 [] ? btrfs_del_csums+0x490/0x490
 [] ? kfree+0xb7/0x230
 [] ? copy_items+0x6ab/0xd2d
 [] ? copy_items+0x6ab/0xd2d
 [] copy_items+0x6da/0xd2d
 [] ? btrfs_set_lock_blocking_rw+0x21/0x160
 [] ? assfail.constprop.22+0x1e/0x1e
 [] ? btrfs_search_forward+0x541/0x600
 [] ? read_extent_buffer+0xe7/0x160
 [] ? btrfs_item_key_to_cpu+0xb7/0xf0
 [] ? check_parent_dirs_for_sync+0x200/0x200
 [] btrfs_log_inode+0x7a9/0x11fa
 [] ? btrfs_log_changed_extents+0x883/0x883
 [] ? mark_lock+0x6d/0x8a0
 [] ? mark_held_locks+0x8e/0xc0
 [] ? mutex_lock_nested+0x3a5/0x510
 [] ? trace_hardirqs_on_caller+0x192/0x290
 [] ? mark_lock+0x6d/0x8a0
 [] ? debug_lockdep_rcu_enabled+0x35/0x40
 [] ? mark_held_locks+0x8e/0xc0
 [] ? __mutex_unlock_slowpath+0xe0/0x1c0
 [] ? trace_hardirqs_on_caller+0x192/0x290
 [] ? trace_hardirqs_on+0xd/0x10
 [] btrfs_log_inode_parent+0x404/0x1440
 [] ? debug_show_all_locks+0x1e0/0x1e0
 [] ? debug_show_all_locks+0x1e0/0x1e0
 [] ? btrfs_end_log_trans+0x50/0x50
 [] ? debug_lockdep_rcu_enabled+0x35/0x40
 [] ? debug_lockdep_rcu_enabled.part.36+0x1a/0x30
 [] ? debug_lockdep_rcu_enabled+0x35/0x40
 [] ? dget_parent+0x8e/0x2f0
 [] ? dget_parent+0xbe/0x2f0
 [] btrfs_log_dentry_safe+0x6a/0x90
 [] btrfs_sync_file+0x4df/0x690
 [] ? start_ordered_ops+0x30/0x30
 [] ? __fsnotify_update_child_dentry_flags+0x30/0x30
 [] vfs_fsync_range+0x5d/0x120
 [] ? start_ordered_ops+0x30/0x30
 [] nfsd_vfs_write+0x356/0x650
 [] ? nfsd_readv+0xa0/0xa0
 [] ? debug_lockdep_rcu_enabled+0x35/0x40
 [] nfsd_write+0xff/0x120
 [] ? __list_add+0x74/0xf0
 [] nfsd3_proc_write+0x1c7/0x2d0
 [] ? nfsd_cache_lookup+0x6ef/0xa90
 [] ? nfsd3_proc_symlink+0x1f0/0x1f0
 [] nfsd_dispatch+0x185/0x370
 [] ? nfsd3_proc_symlink+0x1f0/0x1f0
 [] svc_process_common+0x8c6/0xda0
 [] ? nfsd_svc+0x770/0x770
 [] ? svc_printk+0x180/0x180
 [] ? __lock_is_held+0x25/0xc0
 [] svc_process+0x22b/0x450
 [] nfsd+0x23c/0x370
 [] ? nfsd+0x5/0x370
 [] ? nfsd_destroy+0x1f0/0x1f0
 [] kthread+0x196/0x1c0
 [] ? __kthread_parkme+0xe0/0xe0
 [] ? mark_held_locks+0x23/0xc0
 [] ? __kthread_parkme+0xe0/0xe0
 [] ret_from_fork+0x3f/0x70
 [] ? __kthread_parkme+0xe0/0xe0
Memory state around the buggy address:
 88039bef6700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 88039bef6780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>88039bef6800: 00 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4 f3 f3 f3
  ^
 88039bef6880: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 88039bef6900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo 

Re: 4.4rc3 nfsd/btrfs kasan warning.

[Josef Bacik]

On 12/02/2015 09:59 AM, Dave Jones wrote:

Got a few of these in the logs this morning after an overnight rsync over nfs
to an exported btrfs volume.


That's probably us and not NFS, what line is that in 
setup_cluster_bitmap?  Thanks,


Josef

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

Re: 4.4rc3 nfsd/btrfs kasan warning.

[Chris Mason]

On Wed, Dec 02, 2015 at 11:09:43AM -0500, Dave Jones wrote:
> On Wed, Dec 02, 2015 at 10:11:28AM -0500, Josef Bacik wrote:
>  > On 12/02/2015 09:59 AM, Dave Jones wrote:
>  > > Got a few of these in the logs this morning after an overnight rsync 
> over nfs
>  > > to an exported btrfs volume.
>  > 
>  > That's probably us and not NFS, what line is that in 
>  > setup_cluster_bitmap?  Thanks,
> 
> If my math is correct, it's this..
> 
> if (entry->offset != bitmap_offset)
> 
> I don't seem to be able to trigger it on demand unfortunatly.

Is it possible we're blowing the stack?  It seems pretty tricky to get a
stack out of bounds out of this code without flat out blowing through
it.

-chris

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

Re: 4.4rc3 nfsd/btrfs kasan warning.

[Dave Jones]

On Wed, Dec 02, 2015 at 12:14:56PM -0500, Chris Mason wrote:
 > On Wed, Dec 02, 2015 at 11:09:43AM -0500, Dave Jones wrote:
 > > On Wed, Dec 02, 2015 at 10:11:28AM -0500, Josef Bacik wrote:
 > >  > On 12/02/2015 09:59 AM, Dave Jones wrote:
 > >  > > Got a few of these in the logs this morning after an overnight rsync 
 > > over nfs
 > >  > > to an exported btrfs volume.
 > >  > 
 > >  > That's probably us and not NFS, what line is that in 
 > >  > setup_cluster_bitmap?  Thanks,
 > > 
 > > If my math is correct, it's this..
 > > 
 > > if (entry->offset != bitmap_offset)
 > > 
 > > I don't seem to be able to trigger it on demand unfortunatly.
 > 
 > Is it possible we're blowing the stack?  It seems pretty tricky to get a
 > stack out of bounds out of this code without flat out blowing through
 > it.

Hm, there is a lot of debug crap on the stack from lockdep etc, though I didn't
get any warnings from the other stack overflow checks.

Dave

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

Re: 4.4rc3 nfsd/btrfs kasan warning.

[Andrey Ryabinin]

2015-12-02 20:14 GMT+03:00 Chris Mason :
> On Wed, Dec 02, 2015 at 11:09:43AM -0500, Dave Jones wrote:
>> On Wed, Dec 02, 2015 at 10:11:28AM -0500, Josef Bacik wrote:
>>  > On 12/02/2015 09:59 AM, Dave Jones wrote:
>>  > > Got a few of these in the logs this morning after an overnight rsync 
>> over nfs
>>  > > to an exported btrfs volume.
>>  >
>>  > That's probably us and not NFS, what line is that in
>>  > setup_cluster_bitmap?  Thanks,
>>
>> If my math is correct, it's this..
>>
>> if (entry->offset != bitmap_offset)
>>
>> I don't seem to be able to trigger it on demand unfortunatly.
>
> Is it possible we're blowing the stack?  It seems pretty tricky to get a
> stack out of bounds out of this code without flat out blowing through
> it.
>

I think it just empty bitmaps list.
 list_first_entry() can't be used on empty list.

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

Re: 4.4rc3 nfsd/btrfs kasan warning.

[Chris Mason]

On Wed, Dec 02, 2015 at 09:32:34PM +0300, Andrey Ryabinin wrote:
> 2015-12-02 20:14 GMT+03:00 Chris Mason :
> > On Wed, Dec 02, 2015 at 11:09:43AM -0500, Dave Jones wrote:
> >> On Wed, Dec 02, 2015 at 10:11:28AM -0500, Josef Bacik wrote:
> >>  > On 12/02/2015 09:59 AM, Dave Jones wrote:
> >>  > > Got a few of these in the logs this morning after an overnight rsync 
> >> over nfs
> >>  > > to an exported btrfs volume.
> >>  >
> >>  > That's probably us and not NFS, what line is that in
> >>  > setup_cluster_bitmap?  Thanks,
> >>
> >> If my math is correct, it's this..
> >>
> >> if (entry->offset != bitmap_offset)
> >>
> >> I don't seem to be able to trigger it on demand unfortunatly.
> >
> > Is it possible we're blowing the stack?  It seems pretty tricky to get a
> > stack out of bounds out of this code without flat out blowing through
> > it.
> >
> 
> I think it just empty bitmaps list.
>  list_first_entry() can't be used on empty list.

Ohh, I was so busy looking for free'd entries I missed that.  Good
point.

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