On 2013/01/28 18:36, Daniel P. Berrange wrote:
> On Mon, Jan 28, 2013 at 02:37:11PM +0800, Gao feng wrote:
>> Now we mount /dev as tmpfs and haven't created directory
>> /dev/shm,so the glibc api such as shm_open/sem_open will
>> create files under dir /dev.(since /dev is mounted as tmpfs)
>>
>> Through these api still useable in container,but this cause
>> directory /dev looks a little chaos.
>>
>> This patch create directory /dev/shm automatically,the files
>> created by shm_open/sem_open will stay in this directroy.
>>
>> Signed-off-by: Gao feng <gaofeng@xxxxxxxxxxxxxx>
>> ---
>> src/lxc/lxc_container.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c
>> index 497539c..5150564 100644
>> --- a/src/lxc/lxc_container.c
>> +++ b/src/lxc/lxc_container.c
>> @@ -586,6 +586,13 @@ static int lxcContainerMountBasicFS(bool pivotRoot,
>> "devfs", "/dev", "tmpfs", opts);
>> goto cleanup;
>> }
>> +
>> + VIR_DEBUG("create directory /dev/shm for POSIX shared memory and named semphore");
>> + if (virFileMakePath("/dev/shm") < 0) {
>> + virReportSystemError(errno, "%s",
>> + _("Failed to mkdir /dev/shm"));
>> + goto cleanup;
>> + }
>> }
>>
>> rc = 0;
>
> I we probably want to mount a separate tmpfs on /dev/shm really, so we can
> do resource limits on /dev and /dev/shm separately.
>
Yes, will update this patch.
> I wonder if /dev should be devtmpfs instead of plain tmpfs too.
>
It seems mounting /dev as devtmpfs will make host's devices leak to
container,devtmpfs only has one super-block.it's need kernel to support
this feature.
I think this is a long term plan.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list