On Wed, Sep 29, 2010 at 11:42 PM, Caspar Zhang <[email protected]> wrote:
>
> ----- "Caspar Zhang" <[email protected]> wrote:
>
>> ----- "Garrett Cooper" <[email protected]> wrote:
>>
>> > On Tue, Sep 7, 2010 at 8:13 AM, Caspar Zhang <[email protected]>
>> > wrote:
>> > >
>> > > ----- "Garrett Cooper" <[email protected]> wrote:
>> > >
>> > >> On Tue, Sep 7, 2010 at 5:18 AM, Caspar Zhang <[email protected]>
>> > >> wrote:
>> > >> > Hi all,
>> > >> > When I run testcases/network/nfs/nfsstress/ test, I found
>> > sometimes
>> > >> the
>> > >> > test failed due to buffered I/O, in detail, for example, there
>> > are
>> > >> the following
>> > >> > lines in make_tree.c :
>> > >> >
>> > >> > 544 numchar[0] = sprintf(prog_buf,
>> > >> > 545 "main()\n{\n\t printf(\"hello
>> > world\");\n}\n");
>> > >> >
>> > >> > sometimes the generated .c file will be:
>> > >> > ^...@ain() // <- strange ASCII char '^@' appears instead of 'm'
>> > >> > {
>> > >> > printf("hello world");
>> > >> > }
>> > >> >
>> > >> > And running with this .c file will cause error.
>> > >> >
>> > >> > That is to say, string 'prog_buf' gets a mistake during
>> sprintf.
>> > And
>> > >> there're
>> > >> > somewhere else using buffered I/O in this test as well. Do we
>> > have
>> > >> an
>> > >> > unbuffered solution to this test?
>> > >>
>> > >> That seems a bit odd. Is the NFS mount/server TCP or UDP?
>> > >
>> > > Hi Garrett, it's UDP.
>> >
>> > Ok. Something else that might be good to note is whether or not
>> > it's v2, v3, or v4 on the client and server side.
>> > Could you please try with TCP and see whether or not the issue
>> > persists? I'm just curious if it's a potentially real issue with
>> NFS
>> > code in the kernel, random networking infrastructure issues, etc.
>> > Thanks,
>>
>> Hi Garrett, sorry for late reply. I tried all combinations of TCP/UDP
>>
>> and v2/v3/v4 but the error still existed. I wrote a workaround patch
>> and re-tested with the combinations above, the issue seemed to be
>> solved.
>>
>> This patch have 2 fixes:
>>
>> a) extend malloc length from 1024 to 2048. If we keep both default dir
>> num
>> and file num as 100, the string length of dirname/filename length will
>> be
>> easily > 1024 bytes. This will cause string buffer overflow and the
>> main.c
>> may be filled with such wrong chars:
>> '19123.97/19123.98/19123.99/19123.99.0.cmain()...'
>>
>> b) add tmpdirname var in some sprintf sentences. According the man
>> page of
>> sprintf:
>>
>> NOTES
>> Some programs imprudently rely on code such as the following
>> sprintf(buf, "%s some further text", buf);
>> to append text to buf. However, the standards explicitly note
>> that the results are undefined if source and destination buffers
>> overlap when calling sprintf(), snprintf(), vsprintf(), and
>> vsnprintf(). Depending on the version of gcc(1) used, and the
>> compiler options employed, calls such as the above will not produce
>> the expected results.
>>
>> Signed-off-by: Caspar Zhang <[email protected]>
>
> Hi all, any comments on this?
>
> Patch was tested under RHEL5 and RHEL6 and passed.
Committed. BTW, I fixed the second `sync;' call.
Thanks,
-Garrett
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
