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] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 19 Oct 2023 21:16:20 +0300
From:   Andy Shevchenko <andriy.shevchenko@...el.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Josh Poimboeuf <jpoimboe@...nel.org>, Jan Kara <jack@...e.cz>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        Ferry Toth <ftoth@...londelft.nl>,
        linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: [GIT PULL] ext2, quota, and udf fixes for 6.6-rc1

On Thu, Oct 19, 2023 at 09:10:25PM +0300, Andy Shevchenko wrote:
> On Thu, Oct 19, 2023 at 10:51:18AM -0700, Linus Torvalds wrote:
> > On Thu, 19 Oct 2023 at 10:26, Linus Torvalds
> > <torvalds@...ux-foundation.org> wrote:
> > >
> > > That said, the quota dependency is quite odd, since normally I
> > > wouldn't expect the quota code to really even trigger much during
> > > boot. When it triggers that consistently, and that early during boot,
> > > I would expect others to have reported more of this.
> > >
> > > Strange.
> > 
> > Hmm. I do think the quota list handling has some odd things going on.
> > And it did change with the whole ->dq_free thing.
> > 
> > Some of it is just bad:
> > 
> >   #ifdef CONFIG_QUOTA_DEBUG
> >           /* sanity check */
> >           BUG_ON(!list_empty(&dquot->dq_free));
> >   #endif
> > 
> > is done under a spinlock, and if it ever triggers, the machine is
> > dead. Dammit, I *hate* how people use BUG_ON() for assertions. It's a
> > disgrace. That should be a WARN_ON_ONCE().
> 
> In my configuration
> 
> CONFIG_QUOTA=y
> CONFIG_QUOTA_NETLINK_INTERFACE=y
> # CONFIG_QUOTA_DEBUG is not set
> CONFIG_QUOTA_TREE=y
> # CONFIG_QFMT_V1 is not set
> CONFIG_QFMT_V2=y
> CONFIG_QUOTACTL=y
> 
> > And it does have quite a bit of list-related changes, with the whole
> > series from Baokun Li changing how the ->dq_free list works.
> > 
> > The fact that it consistently bisects to the merge is still odd.
> 
> Exactly! Imre suggested to test the merge point itself, so
> far I tested the result of the merge in the upstream, but not
> the branch/tag that has been merged.
> 
> Let's see if I have time this week for that. This hunting is a bit exhaustive.

Meanwhile a wild idea, can it be some git (automatic) conflict resolution that
makes that merge affect another (not related to the main contents of the merge)
files? Like upstream has one base, the merge has another which is older/newer
in the history?

-- 
With Best Regards,
Andy Shevchenko


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ