From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bruens Date: Mon, 12 Sep 2016 23:48:50 +0200 Subject: [U-Boot] [PATCH 2/3] test/fs: Check ext4 behaviour if dirent is first entry in directory block In-Reply-To: References: <20160911204606.4146-1-stefan.bruens@rwth-aachen.de> <05f3981db3c14326ad8dac10c2f500be@rwthex-w2-b.rwth-ad.de> Message-ID: <2226976.g3eT7JGZN8@pebbles.site> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Montag, 12. September 2016 12:39:35 CEST you wrote: > On 09/11/2016 02:46 PM, Stefan Br?ns wrote: > > This is a regression test for a crash happening if the first dirent > > in the block matches. Code tried to access a predecessor entry which > > does not exist. > > The crash happened for any block, but "." is always the first entry in > > the first directory block and thus easy to check for. > > > > diff --git a/test/fs/fs-test.sh b/test/fs/fs-test.sh > > > > +# Next test case checks writing a file whose dirent > > +# is the first in the block, which is always true for "." > > +# The write should fail, but the lookup should work > > +# Test Case 12 - Check directory traversal > > +${PREFIX}${WRITE} host${SUFFIX} $addr ${FPATH}. 0x10 > > Doesn't that attempt to write a file named ".", which would end up > over-writing the directory content? Unless I'm misunderstanding, that > doesn't seem like a good idea. > > Also, ${FPATH} might be "", "/", "something", or "something/". Appending > "." to some of those won't work the same way as some others. "something" can not happen. The other three cases are exactly what is wanted here, as fat currently needs a relative path, with CWD being "/", and ext explicitly wants an absolute path. > > @@ -471,6 +477,11 @@ function check_results() { > > > > + # Check lookup of 'dot' directory > > + grep -A5 "Test Case 12 " "$1" | \ > > + egrep -q 'Unable to write file' > > + pass_fail "TC12: 1MB write to . - write denied" > > Oh, I see; this expects the write to be denied since the destination is > a directory. Perhaps that's OK. I'd rather see a read attempt though, to > guarantee that even if the access does end up being allowed, the FS > isn't trashed for any future tests that may be added afterwards. U-Boot master/2016-09 crashes here without the pending ext4 fixes. IMHO after a failed test case, everything afterwards is invalid anyway, if the same fs image is used. As soon as the image is modified, tests are no longer idempotent. Block allocation order may change, anything that allocates any resource changes the image. Atempting a write here is done as it actually exercises a different code path. "ext4load host 0:0 0 /." reports "File not found", "ext4write host 0:0 0 /." crashes. Kind regards, Stefan -- Stefan Br?ns / Bergstra?e 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424