linux-ext4 - Re: ext4: fix reference counting bug on block allocation error

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 14 Aug 2016 21:09:19 +0200
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Vegard Nossum <vegard.nossum@...cle.com>
Cc:	Theodore Ts'o <tytso@....edu>, adilger.kernel@...ger.ca,
	linux-ext4@...r.kernel.org,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Subject: Re: ext4: fix reference counting bug on block allocation error

On Sun, Aug 14, 2016 at 09:02:48PM +0200, Vegard Nossum wrote:
> On 08/14/2016 08:58 PM, Greg KH wrote:
> > On Sun, Aug 14, 2016 at 08:51:25PM +0200, Greg KH wrote:
> > > On Sun, Aug 14, 2016 at 08:37:56PM +0200, Vegard Nossum wrote:
> > > > On 08/14/2016 08:32 PM, Greg KH wrote:
> > > > > Hi Vegard and ext4 developers,
> > > > > 
> > > > > The patch below, in Linus's tree, references a patch in the Fixes: line
> > > > > that is not in Linus's tree (neither the git commit id, nor the subject
> > > > > line.)
> > > > > 
> > > > 
> > > > It seems to exist?
> > > > 
> > > > > > Fixes: 8556e8f3b6 ("ext4: Don't allow new groups to be added during block
> > > > allocation")
> > > > 
> > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8556e8f3b6c4c11601ce1e9ea8090a6d8bd5daae
> > > > 
> > > > > That's a bit confusing, what is this patch supposed to be fixing up?
> > > > > What stable tree(s) should it go to if the original patch it fixes isn't
> > > > > even in any tree?
> > > > 
> > > > The referenced commit adds the ext4_mb_release_context(ac); line which
> > > > is what is causing problems because that releases the context which is
> > > > still in fact in use.
> > > 
> > > Oh doh, sorry for the noise, I was only looking at 4.8-rc1 and older, my
> > > fault.
> > 
> > Hm, wait.  Commit 8556e8f3b6 didn't show up in my filters for some
> > reason (which it not good, and makes me worry), but also, it doesn't
> > apply to the stable trees at all.
> > 
> > So can you please send backports of that commit, and this one, if you
> > want them both queued up to any stable kernel tree?
> 
> The commit which is being fixed is ancient:
> 
> $ git describe 8556e8f3b6
> v2.6.28-5758-g8556e8f3
> 
> It's probably already in the base of every current stable tree, no?

Huh?  Ok, this odd:
	$ git describe --contains 8556e8f3b6
	fatal: cannot describe '8556e8f3b6c4c11601ce1e9ea8090a6d8bd5daae'

Yet just a plain 'git describe' does work...

That's what threw me off, I only use --contains as that shows the
release the commit is in.

Ok, that makes me feel a bit better (that my scripts didn't miss the
patch, it was just old), but I wonder what is going on with git...

thanks again,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html