[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YzVIGuISTnIFSIs9@codewreck.org>
Date: Thu, 29 Sep 2022 16:24:10 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: Leon Romanovsky <leon@...nel.org>
Cc: v9fs-developer@...ts.sourceforge.net, linux_oss@...debyte.com,
linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
syzbot+67d13108d855f451cafc@...kaller.appspotmail.com
Subject: Re: [PATCH v3] 9p: client_create/destroy: only call trans_mod->close
after create
Leon Romanovsky wrote on Thu, Sep 29, 2022 at 08:54:10AM +0300:
> > + // ensure clnt->trans is initialized to call close() on destroy
> > + // if and only if create succeeded
> > + if (err < 0) {
> > + clnt->trans = ERR_PTR(err);
> > goto out;
> > + }
> > + if (IS_ERR(clnt->trans))
> > + clnt->trans = NULL;
> >
> > if (clnt->msize > clnt->trans_mod->maxsize) {
> > clnt->msize = clnt->trans_mod->maxsize;
> > @@ -1036,7 +1043,7 @@ void p9_client_destroy(struct p9_client *clnt)
> >
> > p9_debug(P9_DEBUG_MUX, "clnt %p\n", clnt);
> >
> > - if (clnt->trans_mod)
> > + if (clnt->trans_mod && !IS_ERR(clnt->trans))
>
> It is completely no-go to rely on internal value inside of structure after
> failure in ->create() callback.
We're overriding the value after ->create(), in both cases that might
pose problem (success without setting trans/failure); I can't see how
that would possibly fail.
But as you've seen in the other commit I am in no shape to write any
decent code and consider the implications of what I'm changing in this
untangled mess, so you know what: I'll just leave this broken.
Please send me a patch if you care, I'm done here.
--
Dominique
Powered by blists - more mailing lists