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]
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/

Powered by blists - more mailing lists