linux-ext4 - Re: [v4.14-rc1 regression] ext4 failed fstests generic/233 quota test

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 10 Oct 2017 14:49:51 +0200
From:   Jan Kara <jack@...e.cz>
To:     Eryu Guan <eguan@...hat.com>
Cc:     linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        Jan Kara <jack@...e.cz>, Eric Whitney <enwlinux@...il.com>
Subject: Re: [v4.14-rc1 regression] ext4 failed fstests generic/233 quota test

On Tue 10-10-17 13:43:23, Jan Kara wrote:
> Hi Eryu,
> 
> On Sun 08-10-17 13:42:36, Eryu Guan wrote:
> > After generic/232 failure has been reported and resolved[1], I still
> > could see fstests generic/233 failure on ext4 with v4.14-rc3 kernel.
> > This is not 100% reproduced (block usage needs to exceed soft limit) but
> > reliably.
> > 
> >  seed = S
> >  Comparing user usage
> > -Comparing group usage
> > +4c4
> > +< #1001     +-   32064   32000   32000            998  1000  1000       
> > +---
> > +> #1001     +-   32064   32000   32000  7days     998  1000  1000
> > 
> > Grace time was not printed by repquota right after the fsstress run when
> > we exceeded the block soft limit, and only printed after a quotacheck
> > was run.  With v4.13 kernel, block grace time could be printed
> > immediately after the fsstress run.
> 
> Well, I'd rather interpret the results as "the grace time didn't get set by
> the failing kernel, only quotacheck would set it". This configuration with
> softlimit == hardlimit is a bit ambiguous (as effectively softlimit and
> grace time are unused) and I might have shortcut setting of grace time in
> this case somewhere (which would be harmless). But still it warrants closer
> investigation. I'll have a look.
> 
> > git bisect pointed the first bad to commit 7b9ca4c61bc2 ("quota: Reduce
> > contention on dq_data_lock"). And I've confirmed the bisection result by
> > converting the commit in question and running generic/233 for 20
> > iterations without a failure.
> 
> Thanks for digging into this!

OK, I've reproduced the issue (although it took me several xfstests run to
hit this) and it is a real bug in handling of DQUOT_ALLOC_NOFAIL quota
allocations. I'll send a fix shortly once testing completes.

								Honza

-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR