Re: kern/127213: [tmpfs] sendfile on tmpfs data corruption
The following reply was made to PR kern/127213; it has been noted by GNATS.
From: Maxim Konovalov <firstname.lastname@example.org>
To: Nate Eldredge <email@example.com>
Cc: [email]firstname.lastname@example.org[/email], JH <email@example.com>
Subject: Re: kern/127213: [tmpfs] sendfile on tmpfs data corruption
Date: Tue, 7 Oct 2008 07:43:17 +0400 (MSD)
On Mon, 6 Oct 2008, 15:22-0700, Nate Eldredge wrote:
> On Mon, 6 Oct 2008, Maxim Konovalov wrote:
> > Hello,
> > On Mon, 6 Oct 2008, 06:40-0000, Nate Eldredge wrote:
> > [...][color=darkred]
> > > Incidentally, to the initial reporter, what application do you have
> > > that requires sendfile? In my experience, most things will fall
> > > back to a read/write loop if sendfile fails, since sendfile isn't
> > > available on all systems or under all circumstances. So if you
> > > apply the quick fix so that sendfile always fails, it might at
> > > least get your application working again.
> > >[/color]
> > As stated in the PR Andrey used nginx (ports/www/nginx). But I could
> > easily reproduce the bug with the stock ftpd(8) with the ftproot on
> > tmpfs.[/color]
> To simplify matters further, here is the testcase I used when
> testing this, which uses sendfile to send some data over a unix
> domain socket. Do:
> ./server /tmpfs/data mysocket &
> ./client mysocket >data.out
> cmp /tmpfs/data data.out
> If things work right, data and data.out should be identical. But if
> data is a file on a tmpfs, data.out contains apparently random
> kernel memory contents.
It'd be really nice if you extend
src/tools/regression/sockets/sendfile regression test for this bug.
Now it doesn't detect this case.
[email]firstname.lastname@example.org[/email] mailing list
To unsubscribe, send any mail to "email@example.com"