tmpfs + sendfile bug ?

tmpfs + sendfile bug ?

[Pierre Etchemaite]

        Hi all,

I just found a problem GETting a file stored in tmpfs using proftpd; I always
get a "426 Transfer aborted. Data connection closed."

That could be a bug with tmpfs and sendfile in 2.4.5-pre4 :

[...]
read(8, "%PDF-1.4\r%\342\343\317\323\r\n870 0 obj\r<< \r/L"..., 8192) = 8192
shmat(11, 0x4cfe65, 0x3)                = 0xbffff4d4
sendfile(11, 8, [0], 5045861)           = -1 EINVAL (Invalid argument)
[...]

Any idea ?

Best regards,
Pierre.



-- 
We are the dot in 0.2 Kb/s

Re: tmpfs + sendfile bug ?

[Christoph Rohland]

Hi Pierre,

On Mon, 21 May 2001, Pierre Etchemaite wrote:
> I just found a problem GETting a file stored in tmpfs using proftpd;
> I always get a "426 Transfer aborted. Data connection closed."
> 
> That could be a bug with tmpfs and sendfile in 2.4.5-pre4 :
> 
> [...]
> read(8, "%PDF-1.4\r%\342\343\317\323\r\n870 0 obj\r<< \r/L"..., 8192) = 8192
> shmat(11, 0x4cfe65, 0x3)                = 0xbffff4d4
> sendfile(11, 8, [0], 5045861)           = -1 EINVAL (Invalid argument)
> [...]
> 
> Any idea ?

That's probably the same reason why tmpfs and loopback do not work
together:

tmpfs does not provide the necessary functions for sendfile and lo:
readpage, prepare_write and commitwrite.

And I do not see a way how to provide readpage in tmpfs :-(

Greetings
		Christoph

Re: tmpfs + sendfile bug ?

[Linus Torvalds]

In article <m3bsomwsgs.fsf@linux.local>, Christoph Rohland  <cr@sap.com> wrote:
>
>tmpfs does not provide the necessary functions for sendfile and lo:
>readpage, prepare_write and commitwrite.
>
>And I do not see a way how to provide readpage in tmpfs :-(

Why not just do it the same way ramfs does?

If you don't have any backing store, you know that the page is empty. If
you _do_ have backing store, a readpage() won't be called. Ergo:

	static int ramfs_readpage(struct file *file, struct page * page)
	{
		if (!Page_Uptodate(page)) {
			memset(kmap(page), 0, PAGE_CACHE_SIZE);
			kunmap(page);
			flush_dcache_page(page);   
			SetPageUptodate(page);
		}
		UnlockPage(page);
		return 0;
	}

while the writepage ones just do a "SetPageDirty(page)" (with
prepare_write() needing to do the same "Page_Uptodate()" checks to see
if we need to clear stuff first).

		Linus

Re: tmpfs + sendfile bug ?

[Christoph Rohland]

Hi Linus,

On Mon, 21 May 2001, Linus Torvalds wrote:
> In article <m3bsomwsgs.fsf@linux.local>, Christoph Rohland
> <cr@sap.com> wrote:
>>
>>tmpfs does not provide the necessary functions for sendfile and lo:
>>readpage, prepare_write and commitwrite.
>>
>>And I do not see a way how to provide readpage in tmpfs :-(
> 
> Why not just do it the same way ramfs does?
> 
> If you don't have any backing store, you know that the page is
> empty. If you _do_ have backing store, a readpage() won't be
> called. Ergo:

AFAIU readpage is fine as long as there is no backing store. But if
the page is in the swap cache, the lookup of the page in the page
cache will fail; generic_file_read, loop, sendfile will allocate a
page and call readpage with that. Now readpage has to copy the swap
cache page over to this page :-(

IMHO Copying on swapin is really not worth the additional
functionality.

Did I miss something?

		Christoph

RE: tmpfs + sendfile bug ?

[David Schwartz]

> That could be a bug with tmpfs and sendfile in 2.4.5-pre4 :
>
> [...]
> read(8, "%PDF-1.4\r%\342\343\317\323\r\n870 0 obj\r<< \r/L"...,
> 8192) = 8192
> shmat(11, 0x4cfe65, 0x3)                = 0xbffff4d4
> sendfile(11, 8, [0], 5045861)           = -1 EINVAL (Invalid argument)
> [...]
>
> Any idea ?

	Looks like a bug in the program. If 'sendfile' returns 'EINVAL', that means
you can't use 'sendfile' to send this particular file, and should default to
read/write or mmap/write. If this program doesn't, it doesn't understand
Linux's 'sendfile' semantics.

	DS

RE: tmpfs + sendfile bug ?

[Pierre Etchemaite]

On 21-May-2001 David Schwartz wrote:
> 
>> Any idea ?
> 
>       Looks like a bug in the program. If 'sendfile' returns 'EINVAL', that
means
> you can't use 'sendfile' to send this particular file, and should default to
> read/write or mmap/write. If this program doesn't, it doesn't understand
> Linux's 'sendfile' semantics.

Agreed, I came up to the same conclusion. Applications shouldn't assume that
sendfile will always work, and be ready to fall back to the traditional DIY
way of sending data.

I just downloaded more recent sources of proftpd (1.2.2rc2), and it looks
fixed, already... Time to upgrade :)

Regards,
Pierre.