Date: Wed, 19 Sep 2007 14:35:49 +0400 From: Boris Samorodov <bsam@ipt.ru> To: Roman Divacky <rdivacky@freebsd.org> Cc: freebsd-emulation@freebsd.org, sam <samflanker@gmail.com> Subject: Re: linuxolator problem on i386 Message-ID: <18395962@srv.sem.ipt.ru> In-Reply-To: <20070919085405.GA24442@freebsd.org> (Roman Divacky's message of "Wed\, 19 Sep 2007 10\:54\:05 %2B0200") References: <20070917152625.GA507@freebsd.org> <64815375@srv.sem.ipt.ru> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Sep 2007 10:54:05 +0200 Roman Divacky wrote: > > It so happened that here we get a deal with magic (number). Let me > > show you the broken behaviour one more time: > > 14594 hlds_i686 CALL linux_getdents(0x6,0x8da5b44,0x1000) > > 14594 hlds_i686 RET linux_getdents 4096/0x1000 > > Look at the first linux_getdents() line. The third parameter (buffer > > length?) equals to 0x1000 which is 4096. The second line with > > linux_getdents shows that it has read precisely 4096 (bytes?). What if > > we face here a (so called at our high school) border-case > > (border-problem)? > > > > OK, the program reads the directory contents. Lets touch a new file > > at this directory. What does happen? Follow me: > > 14579 hlds_i686 CALL linux_getdents(0x6,0x8da574c,0x1000) > > 14579 hlds_i686 RET linux_getdents 4084/0xff4 > > > That's it! <loud long applauses> > > > > Roman, I hope now you may create the needed patch. > > As for me I'm too tied (and too proud :-) ) today and 'm going to have > > a little sleep. > I am sorry but I dont understand at all.. what are you trying to show? > whats wrong with returning 4084? Sorry to be laconic. 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). Hm, is my current explanation more understandable? WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18395962>