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] [day] [month] [year] [list]
Message-ID: <20221025085601.gpxh5stotqx7to54@quack3>
Date:   Tue, 25 Oct 2022 10:56:01 +0200
From:   Jan Kara <jack@...e.cz>
To:     Jason Yan <yanaijie@...wei.com>
Cc:     Jan Kara <jack@...e.cz>, tytso@....edu, adilger.kernel@...ger.ca,
        ritesh.list@...il.com, lczerner@...hat.com,
        linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4: fix wrong return err in
 ext4_load_and_init_journal()

On Tue 25-10-22 11:27:01, Jason Yan wrote:
> 
> On 2022/10/24 23:29, Jan Kara wrote:
> > On Sat 22-10-22 21:07:39, Jason Yan wrote:
> > > The return value is wrong in ext4_load_and_init_journal(). The local
> > > variable 'err' need to be initialized before goto out. The original code
> > > in __ext4_fill_super() is fine because it has two return values 'ret'
> > > and 'err' and 'ret' is initialized as -EINVAL. After we factor out
> > > ext4_load_and_init_journal(), this code is broken. So fix it by directly
> > > returning -EINVAL in the error handler path.
> > > 
> > > Fixes: 9c1dd22d7422 (ext4: factor out ext4_load_and_init_journal())
> > 
> > We format the tag usually as:
> > 
> > Fixes: 9c1dd22d7422 ("ext4: factor out ext4_load_and_init_journal()")
> > 
> 
> Oh, sorry I didn't notice it. Thank you so much.
> 
> I generate this tag by the following script:
> 
> #cat .gitconfig
>  [alias]
>          fixes = log --abbrev=12 -1 --format='Fixes: %h ("%s")'
> 
> 
> #git fixes 9c1dd22d742249cfae7bbf3680a7c188d194d3ce
> Fixes: 9c1dd22d7422 (ext4: factor out ext4_load_and_init_journal())
> 
> This works fine before but it fails recently. I don't know what makes the
> behavior changed.

I guess something does one more round of expansion on the string. I guess
you could trace it with strace and see where the quotes get lost...

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ