| From | Subject | Date |
|---|---|---|
| Conrad Meyer | [Tux3] [PATCH] Add check for valid attr encodings
diff -r bc704c9af6d6 user/test/iattr.c
--- a/user/test/iattr.c Tue Sep 02 10:17:39 2008 -0700
+++ b/user/test/iattr.c Tue Sep 02 11:47:08 2008 -0700
@@ -32,11 +32,28 @@
return need;
}
+int attr_check(void *attrs, unsigned size)
+{
+ void *limit = attrs + size;
+ unsigned head;
+ while (attrs < limit - 1)
+ {
+ attrs = decode16(attrs, &head);
+ kind = head >> 12;
+ if (kind < ATTR_MINIMUM || kind > ATTR_MAXIMUM)
+ return 0;
+ if (attrs + atsize[kind] > limit)
+ return ...
| Sep 2, 11:57 am 2008 |
| Daniel Phillips | Re: [Tux3] [PATCH] Add check for valid attr encodings
The typical form for this would be ATTR_LIMIT or MAX_ATTR_KINDS, one
larger than the highest kind.
Regards,
Daniel
_______________________________________________
Tux3 mailing list
Tux3@tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3
| Sep 2, 12:07 pm 2008 |
| Daniel Phillips | Re: [Tux3] [PATCH] Add check for valid attr encodings
Didn't build initially:
In file included from ileaf.c:19:
iattr.c: In function 'attr_check':
iattr.c:42: error: 'kind' undeclared (first use in this function)
iattr.c:42: error: (Each undeclared identifier is reported only once
iattr.c:42: error: for each function it appears in.)
Fixed and applied.
Regards,
Daniel
_______________________________________________
Tux3 mailing list
Tux3@tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3
| Sep 2, 12:02 pm 2008 |
| Daniel Phillips | Re: [Tux3] [PATCH] Add check for ileaf dict ordering
Right, it-s gnu-99 even, which means we can additionally use typeof. I
decided to go with the additional flexibility, just for the user space
code. We are going to have to brutalize the code pretty heavily for
the kernel port, moving all the variable decls up to the tops of
functions etc in accordance with Linus's taste.
I haven't decided whether we will then fork the kernel and userspace
versions. Probably fork, but we will ...
| Sep 2, 9:58 am 2008 |
| Conrad Meyer | Re: [Tux3] [PATCH] Add check for ileaf dict ordering
--nextPart6530124.Oa4aAAYTQX
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
It's C99 IIRC.
Regards,
--=20
Conrad Meyer <konrad@tylerc.org>
--nextPart6530124.Oa4aAAYTQX
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 ...
| Sep 2, 9:47 am 2008 |
| Daniel Phillips | Re: [Tux3] [PATCH] Add check for ileaf dict ordering
Applied, thanks.
Daniel
_______________________________________________
Tux3 mailing list
Tux3@tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3
| Sep 2, 9:39 am 2008 |
| Conrad Meyer | [Tux3] [PATCH] Add check for ileaf dict ordering
diff -r fd5ca07f03dd user/test/ileaf.c
--- a/user/test/ileaf.c Tue Sep 02 00:06:45 2008 -0700
+++ b/user/test/ileaf.c Tue Sep 02 06:47:17 2008 -0700
@@ -124,11 +124,23 @@
return attrs;
}
+int isinorder(BTREE, struct ileaf *leaf)
+{
+ u16 *dict = (void *)leaf + btree->sb->blocksize;
+ for (int i = 0, offset = 0, limit; i > -leaf->count; i--, offset = limit)
+ if ((limit = dict[i]) < offset)
+ return 0;
+ return 1;
+}
+
int ileaf_check(BTREE, struct ileaf *leaf)
{
char ...
| Sep 2, 6:47 am 2008 |
| Daniel Phillips | Re: [Tux3] [PATCH] Make sure ileaf offsets are in non-de ...
Your negative for loop is stylish. Let's try crunching down the loop
body a little:
int isinorder(BTREE, struct ileaf *leaf)
{
u16 *dict = (void *)leaf + btree->sb->blocksize;
for (int i = 0, offset = 0, limit; i > -leaf->count; i--, offset = limit)
if ((limit = dict[i]) < offset)
return 0;
return 1;
}
Wow, it compresses nicely :-)
It is still your nice clear and correct algorithm, just poked a little.
You can integrate it with the existing (lame) check like this:
int ...
| Sep 2, 2:27 am 2008 |
| Conrad Meyer | [Tux3] [PATCH] Make sure ileaf offsets are in non-descen ...
diff -r 6621df29d406 user/test/ileaf.c
--- a/user/test/ileaf.c Mon Sep 01 21:18:45 2008 -0700
+++ b/user/test/ileaf.c Mon Sep 01 23:54:23 2008 -0700
@@ -299,6 +299,24 @@
attrs = ileaf_resize(btree, inum, leaf, size - less);
}
+int isinorder(BTREE, struct ileaf *leaf)
+{
+ int offset = 0;
+ u16 *dict = (void *)leaf + btree->sb->blocksize;
+ int correct = 1;
+ for (int i = 0; i > -leaf->count; i--)
+ {
+ int limit = dict[i];
+ if (limit < offset)
+ {
+ correct = ...
| Sep 1, 11:56 pm 2008 |
| Conrad Meyer | Re: [Tux3] [PATCH] Make sure ileaf offsets are in non-de ...
--nextPart7140683.zDLOMV79lj
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Sorry, didn't notice ileaf_check earlier. New patch coming up in a minute o=
r=20
two.
Regards,
--=20
Conrad Meyer <konrad@tylerc.org>
--nextPart7140683.zDLOMV79lj
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: ...
| Sep 2, 6:36 am 2008 |
| Conrad Meyer | [Tux3] [PATCH] More 64 bit format string cleanups (again)
diff -r dc0f4243e276 user/test/inode.c
--- a/user/test/inode.c Mon Sep 01 12:51:37 2008 -0700
+++ b/user/test/inode.c Mon Sep 01 16:56:37 2008 -0700
@@ -418,7 +418,7 @@
/* Always 8K regardless of blocksize */
int reserve = 1 << (sb->blockbits > 13 ? 0 : 13 - sb->blockbits);
for (int i = 0; i < reserve; i++)
- printf("reserve %Lx\n", balloc_from_range(sb->bitmap, i, 1));
+ printf("reserve %Lx\n", (L)balloc_from_range(sb->bitmap, i, 1));
printf("---- create inode table ----\n");
...
| Sep 1, 8:54 pm 2008 |
| Daniel Phillips | [Tux3] Time to truncate
The last burst of checkins has brought Tux3 to the point where it
undeniably acts like a filesystem: one can write files, go away,
come back later and read those files by name. We can see some of the
hoped for attractiveness starting to emerge: Tux3 clearly does scale
from the very small to the very big at the same time. We have our
Exabyte file with 4K blocksize and we can also create 64 Petabyte
files using 256 byte blocks. How cool is that? Not much chance for
internal fragmentation with ...
| Sep 1, 6:24 pm 2008 |
| Daniel Phillips | [Tux3] Time to truncate
The last burst of checkins has brought Tux3 to the pointer where it
undeniably acts like a filesystem: one can write files, go away,
come back later and read those files by name. We can see some of the
hoped for attractiveness starting to emerge: Tux3 clearly does scale
from the very small to the very big at the same time. We have our
Exabyte file with 4K blocksize and we can also create 64 Petabyte
files using 256 byte blocks. How cool is that? Not much chance for
internal fragmentation with ...
| Sep 1, 6:15 pm 2008 |
| previous day | today | next day |
|---|---|---|
| September 1, 2008 | September 2, 2008 | September 3, 2008 |
