Re: [PATCH 00/17] fs, btrfs refcount conversions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 07, 2017 at 03:49:52PM +0800, Qu Wenruo wrote:
> >>> If the patches pass all tests on your side, could you please take them in and
> >> propagate further?
> >>> I will continue with other kernel subsystems.
> >>
> >> The patchset itself looks like a common cleanup, while I did encounter
> >> several cases (almost all scrub tests) causing kernel warning due to
> >> underflow.
> >
> > Oh, could you please send me the warning outputs? I can hopefully analyze and fix them.
> 
> Attached. Which is the generated by running btrfs/070 test case.
> And I canceled the case almost instantly, so output is not much, but 
> still contains enough info.
> 
> Both refcount_inc() and refcount_sub_and_test() are causing warning.
> 
> So now I'm not sure which is the cause, btrfs or bad use of refcount?

We we do atomic_inc to get the first reference after initialization in
scrub_pages, instead of atomic_set (or an equivalent):

2266                 spage = kzalloc(sizeof(*spage), GFP_KERNEL);
2267                 if (!spage) {
...
2274                 }
...
2276                 scrub_page_get(spage);

so the references are 0 and refcount_inc will catch that, the fix is simple.

The refcount_sub_and_test reports seem to catch a bug in refcounting, I'm
analyzing it right now.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux