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  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:   Thu, 6 Oct 2022 19:19:08 +0300
From:   Leon Romanovsky <>
To:     Dominique Martinet <>,
        Christian Schoenebeck <>
Cc:     Dan Carpenter <>,,,,,,,,,,,
Subject: Re: [PATCH 1/2] Revert "9p: p9_client_create: use p9_client_destroy
 on failure"

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:
> > > Signed-off-by: Leon Romanovsky <>
> > 
> > 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:
> 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.


> -- 
> Dominique

Powered by blists - more mailing lists