On 01/28/2014 02:14 PM, Kay Sievers wrote: > On Tue, Jan 28, 2014 at 10:54 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote: >> But yes, alternatively classic systems may be able to get around the >> issues via tmpfs quotas and convincing applications to use O_TMPFILE >> there. But to me this seems less ideal then the Android approach, where >> the lifecycle of the tmpfs fds more limited and clear. > Tmpfs supports no quota, it's all a huge hole and unsafe in that > regard on every system today. But ashmem and kdbus, as they are today, > are not better. While its true ashmem and kdbus currently have no limitation on the amount of memory an application can consume via the unlinked tmpfs fds, they both do have the benefit that those unlinked files are cleaned up when the last user dies (or is killed). While adding quota to these approaches would improve things, tmpfs quota alone on writable tmpfs mounts only limits the DOS to the user (ie: one bad application could fill up the user's tmpfs and quit, then other applications would fail to work or have some sort of logic to figure out what tmpfs files could safely be cleaned up). Other then this minor point, I think I'm in agreement with the other points in your mail. thanks -john -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>