linux-kernel - Re: [PATCH 0/6] UDF cleanup and fixes

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] [day] [month] [year] [list]

Message-ID: <20070523074557.GA20625@duck.suse.cz>
Date:	Wed, 23 May 2007 09:45:57 +0200
From:	Jan Kara <jack@...e.cz>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/6] UDF cleanup and fixes

On Tue 22-05-07 15:39:31, Eric Sandeen wrote:
> Eric Sandeen wrote:
> 
> > Jan -
> > 
> > I ran 2.6.21 + your udf patches from -mm through some udf tests which,
> > oddly enough, can be found in the xfstests test suite in xfsprogs cvs
> > from sgi.
> > 
> > It looks much better than before, but I was able to trip some of your
> > asserts.  They were generated while fsx was running.  The good news,
> > though, is that fsx passed.  :)  I haven't looked into it much further
> > yet, but wanted to let you know.
> 
> Here's a short hacky testcase that trips the assert around line 123 of
> udf/truncate.c  I'm looking into it but you may immediately see what the
> problem is...?
  Yes, yesterday I've also managed to create a simple testcase - sorry for
not letting you know, I'd have saved you some time. I also know what the
problem is:
  1) discard_prealloc() shouldn't be called from udf_clear_inode() - at
that point inode won't be written any more and thus changes to it won't be
reflected. Actually, this bug is hidden by the fact that UDF calls
discard_prealloc() on each filp release but anyway.
  2) the second problem is extent rounding - when we discard prealloc we
also truncate the extent to match i_size. That is fine but if the buffer
remains in pagecache and is reused on second open, block_prepare_write()
won't call udf_get_block() (as the buffer is already mapped) and thus the
extent remains truncated even though we write after it's end. The easiest
way out would be to simply leave the extent length rounded to block
boundary but I have to check with the specification whether this is
allowed...

								Honza

-- 
Jan Kara <jack@...e.cz>
SuSE CR Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/