Re: [RFC] shmgetfd idea

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 29, 2014 at 1:20 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> On 01/28/2014 04:14 PM, Kay Sievers wrote:
>>>
>>> If the "single owner" is determined by the file structure (e.g. via a
>>> fcntl as opposed to a ioctl), then presumably we would simply deny an
>>> attempt to open the inode and create a new file structure for it.
>>>
>>> On Linux, /proc/$PID/fd is an open as opposed to a dup (as much as I
>>> personally don't like those semantics, they are well set in stone at
>>> this point) so it satisfies your requirements.
>>
>> If that all could be made working, for the kdbus case we would be fine
>> with requiring *any* tmpfs mount, create a new memfd from there with
>> O_TMPFILE, and use new fcntl() definitios to protect/seal/unseal and
>> identify that fd.
>>
>> For the more restricted cases like Android that tmpfs mount could get
>> a mount option to not allow the creation of any non-unlinked file, I
>> guess.
>>
>
> Right, that would be the idea.

I like your idea. Sounds worth trying, if you think we can make the
protection/sealing work without too much ugly workarounds.

With the filesystem as a "domain" / the root for all the unlinked
shmem files, we could even mount a separate tmpfs for every logged-in
user, and put the quota on the user that way.

It will still not solve the /dev/shm/ or /tmp quota problem, but it
would at least not get bigger with every new shmem user we invent. :)

Kay

--
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>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]