Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Sep 2007 13:15:57 +0200
From:      Roman Divacky <rdivacky@freebsd.org>
To:        Boris Samorodov <bsam@ipt.ru>
Cc:        freebsd-emulation@freebsd.org, sam <samflanker@gmail.com>
Subject:   Re: linuxolator problem on i386
Message-ID:  <20070919111557.GA28377@freebsd.org>
In-Reply-To: <18395962@srv.sem.ipt.ru>
References:  <46EF62C5.5090704@gmail.com> <00483937@srv.sem.ipt.ru> <46EF7E05.5040405@gmail.com> <20070918074332.GA30053@freebsd.org> <88000019@srv.sem.ipt.ru> <20070918082119.GA30932@freebsd.org> <89768331@srv.sem.ipt.ru> <41596338@srv.sem.ipt.ru> <20070919085405.GA24442@freebsd.org> <18395962@srv.sem.ipt.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070919111557.GA28377>