linuxolator problem on i386

[Roman Divacky]

> There is nothing wrong with 4084. The magic 4096 is the
> answer. I.e. the first case (when a buffer is equal to that
> has been really read) is wrongly processed.
> 
> Ex. in C strings ends with 0x0. If a buffer 4096 bytes long was
> assigned a string 4096 bytes long then the 0x0 will become a 4097
> byte. And this string will cause a fault of the program.
> 
> PS. I don't say that I gave a strict example of the case. Of cause it
> may be something else. But definitely there is a bug in processing of
> 4096 bytes log strings by our linuxulator code (somewhere at the
> linux_getdents area, linux_getdents64 used by linux_base-fc4 is not
> affected by _at least_ 4096 bytes long strings).

1) what makes you think the 4096 buffer is wrongly processed? I still dont
see it

2) the getdents64 and getdents use exactly the same code :) the fact is
that the structures copied out are of different size so there might be
a corner case for th getdents

3) you seem to be confused.. getdents does NOT return strings it returns
structures "somehow" fitted in a buffer

anyway... I looked at the sources and I found a strange thing so here's a
patch...

@@ -442,8 +443,7 @@

        off = fp->f_offset;

-       buflen = max(LINUX_DIRBLKSIZ, nbytes);
-       buflen = min(buflen, MAXBSIZE);
+       buflen = max(buflen, MAXBSIZE);
        buf = malloc(buflen, M_TEMP, M_WAITOK);
        vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);


I am quite interested if this changes anything because the code is imho obviously wrong.
it first limits buflen < 512 and then to buflen = 64K. I dont see how this could affect
only 4096 bytes long buffers but its worth a try.

thnx, roman