Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To:     Theodore Ts'o <tytso@mit.edu>
Cc:     adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
        syzkaller-bugs@googlegroups.com,
        syzbot <syzbot+4acc7d910e617b360859@syzkaller.appspotmail.com>
Subject: Re: [syzbot] [ext4?] BUG: sleeping function called from invalid context in
 ext4_update_super
Date:   Wed, 14 Jun 2023 21:38:00 +0200
Message-ID: <1830721.atdPhlSkOF@suse>
In-Reply-To: <20230612001921.GG1436857@mit.edu>
References: <20230611131829.GA1584772@mit.edu> <7741416.gsGJI6kyIV@suse>
 <20230612001921.GG1436857@mit.edu>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk

On luned=EC 12 giugno 2023 02:19:21 CEST Theodore Ts'o wrote:
> On Sun, Jun 11, 2023 at 09:15:56PM +0200, Fabio M. De Francesco wrote:
> > Thanks!
> >=20
> > Let me summarize, just to be sure we don't misunderstand each other...
> >=20
> > To start off, I'll send out _only_ the patch for the bug reported by=20
Syzbot,
> > the one about dropping the call to ext_error() in ext4_get_group_info().
> >=20
> > I'll do this by Tuesday. (Sorry, I cannot do it by Monday because I must
> > pass
> > an exam and an interview for a job).

Ted,

Sorry, I sent the patch this morning (local time), that is one day later :-(

It's at https://lore.kernel.org/lkml/20230614100446.14337-1-fmdefrancesco@g=
mail.com/

> Sure, that'll be fine.
>=20
> > However, on the other problems with ext4_grp_locked_error() that you=20
noticed
> > in the final part of your first message in this thread I'll need some d=
ays
> > more to better understand the context I'm working in.
>=20
> Um, I'm not sure what problems you're referring to.  What I said is
> that it works, but you just have to be careful in how you use it (and
> the current callers in mballoc.c are careful).

My poor English made me misunderstanding what you wrote in the final part o=
f=20
you first email. My fault, again sorry.

> And similarly, I don't think it's a problem that you need to be
> careful not to call ext4_error() from an atomic context.  You need to
> be careful, and sometimes we screw up.  But in this particular case,
> it's pretty obvious how to fix it, and we don't even need a syzkaller
> reproducer.  :-)

Sure.

> > > I would strongly recommend that you use gce-xfstests or kvm-xfstests
> > > before submitting ext4 patches.

I'll surely do next time, but this was too trivial to necessitate any test.=
 Do=20
you agree with me?

> > > In this particular case, it's a
> > > relatively simple patch, but it's a good habit to get into.  See [1]
> > > for more details.
> > >=20
> > > [1] https://thunk.org/gce-xfstests
> >=20
> > Thanks also for these information.
> >=20

Well, I think that this means that you indeed agree for this particular cas=
e=20
:-)

> > I'm still in search of a reliable way to let atomic context
> > run idle waiting for a status change.

[...]

> So the question is not how to find a "reliable way to let atomic
> context run > idle waiting for a status change".  That's the wrong
> question.  The better question is: "how do you restructure code
> running in an atomic context so it doesn't need to wait for a status
> change"?
>=20
> Cheers,
>=20
> 					- Ted

Very interesting discussion.=20
I skipped the details only for shortening this email.

Again thanks for your precious help,

=46abio