Messages in this thread | | | Date | Mon, 6 Sep 2004 13:54:28 +0200 | From | Jörn Engel <> | Subject | Re: [PATCH 1/3] copyfile: generic_sendpage |
| |
On Sat, 4 September 2004 15:39:02 -0700, Andrew Morton wrote: > Jörn Engel <joern@wohnheim.fh-wedel.de> wrote: > > > > o Add sendfile() support for file targets to normal mm/filemap.c. > > This comes up fairly regularly. See, for example, > http://lwn.net/Articles/88751/ for what appears to be a much simpler > implementation.
Yes, I saw it and commented on it. Al didn't seem to like the set_fs very much, so that specific implementation appears to be dead.
> I discussed file->file sendfile with Linus a while back and he said > > > I think it was about doing a 2GB file-file sendfile, and see your system > > grind to a halt without being able to kill it. > > > > That said, we have some of the same problems with just regular read/write > > too. sendfile just makes it easier. > > > > We should probably make read/write be interruptible by _fatal_ signals. > > It would require a new task state, though (TASK_KILLABLE or something, and > > it would show up as a normal 'D' state). > > I don't know how much of a problem this is in practice - there are all > sorts of nasty things which unprivileged apps can do to the system by > overloading filesystems. Although most of them can be killed off by the > sysadmin. > > (My infamous bash-shared-mappings stresstest can spend ten or more minutes > within a single write() call, but you have to try hard to do this).
Sure, a 2GB copyfile(2) is nasty (sendfile can at least return a short count), esp. with slow media like a usb1 attached hard drive. Might be a reasonable short-term solution to return -EFBIG whenever a user tries to copy a file >$PRETTY_LARGE and doesn't have CAP_WHATNOT.
Would you accept such a solution? And if you would, which magic constants should I use?
Jörn
-- When you close your hand, you own nothing. When you open it up, you own the whole world. -- Li Mu Bai in Tiger & Dragon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |