Re: [PATCH 1/2] Revert "9p: p9_client_create: use p9_client_destroy on failure"

From: Leon Romanovsky <leon@kernel.org>
To: Dominique Martinet <asmadeus@codewreck.org>,
	Christian Schoenebeck <linux_oss@crudebyte.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	v9fs-developer@lists.sourceforge.net, linux_oss@crudebyte.com,
	linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
	syzbot+67d13108d855f451cafc@syzkaller.appspotmail.com,
	davem@davemloft.net, edumazet@google.com, ericvh@gmail.com,
	kuba@kernel.org, lucho@ionkov.net, netdev@vger.kernel.org
Subject: Re: [PATCH 1/2] Revert "9p: p9_client_create: use p9_client_destroy on failure"
Date: Thu, 6 Oct 2022 19:19:08 +0300	[thread overview]
Message-ID: <Yz7//EA4mfR7KL3D@unreal> (raw)
In-Reply-To: <YzyfM1rJrmT1Qe4N@codewreck.org>

On Wed, Oct 05, 2022 at 06:01:39AM +0900, Dominique Martinet wrote:
> Dan Carpenter wrote on Tue, Oct 04, 2022 at 04:10:44PM +0300:
> > On Thu, Sep 29, 2022 at 12:37:55PM +0300, Leon Romanovsky wrote:
> > > Rely on proper unwind order.
> > > 
> > > This reverts commit 3ff51294a05529d0baf6d4b2517e561d12efb9f9.
> > > 
> > > Reported-by: syzbot+67d13108d855f451cafc@syzkaller.appspotmail.com
> > > Signed-off-by: Leon Romanovsky <leon@kernel.org>
> > 
> > The commit message doesn't really say what the problem is to the user.
> > Is this just to make the next patch easier?
> 
> Yes (and perhaps a bit of spite from the previous discussion), and the
> next patch was not useable so I am not applying this as is.
> 
> The next patch was meant as an alternative implementation to this fix:
> https://lore.kernel.org/all/20220928221923.1751130-1-asmadeus@codewreck.org/T/#u
> 
> At this point I have the original fix in my -next branch but it hasn't
> had any positive review (and well, I myself agree it's ugly), so unless
> Leon sends a v2 I'll need to think of a better way of tracking if
> clnt->trans_mod->create has been successfully called.
> I'm starting to think that since we don't have so many clnt I can
> probably just fit a bool/bitfield in one of the holes of the struct
> and just keep track of it; that'll be less error-prone than relying on
> clnt->trans (which -is- initialized in create() most of the time, but
> not in a way we can rely on) or reworking create() to return it as I
> originally wanted to do (rdma still needs to populate clnt->trans behind
> the scenees before create() returns, so the abstraction is also quite
> ugly)
> 
> The current breakage is actually quite bad so I'll try to send that
> today or tomorrow for merging next week unless Leon resends something we
> can work with... Conceptually won't be different than the patch
> currently in next so hopefully can pretend it's had a couple of weeks of
> testing...

I can't resend anything in near future and most of the time have very
limited access to computer due to holidays here.

Thanks

> -- 
> Dominique