lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 1 Jul 2009 19:49:48 -0700
From:	Paul Menage <menage@...gle.com>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc:	lizf@...fujitsu.com, balbir@...ux.vnet.ibm.com,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	containers@...ts.linux-foundation.org
Subject: Re: [PATCH 1/9] [RFC] Support named cgroups hierarchies

On Wed, Jul 1, 2009 at 7:28 PM, KAMEZAWA
Hiroyuki<kamezawa.hiroyu@...fujitsu.com> wrote:
>> Open issues:
>>
>> - should the specification be via a name= option as in this patch, or
>>   should we simply use the "device name" as passed to the mount()
>>   system call?  Using the device name is more conceptually clean and
>>   consistent with the filesystem API; however, given that the device
>>   name is currently ignored by cgroups, this would lead to a
>>   user-visible behaviour change.
>>
>
> IMHO, name= option is good because people think device name for pseudo file
> system has no meanings. I think just leaving it as "no meaning" is better.
>

Yes, I guess that makes sense. That was Li Zefan's opinion too.

>>
>> +#define MAX_CGROUP_ROOT_NAMELEN 64
>> +
>
> I don't like long names but....isn't this too short ? How about NAME_MAX ?
>


>
>>  /*
>>   * A cgroupfs_root represents the root of a cgroup hierarchy,
>>   * and may be associated with a superblock to form an active
>> @@ -93,6 +95,9 @@ struct cgroupfs_root {
>>
>>       /* The path to use for release notifications. */
>>       char release_agent_path[PATH_MAX];
>> +
>> +     /* The name for this hierarchy - may be empty */
>> +     char name[MAX_CGROUP_ROOT_NAMELEN];
>>  };
>>
> If you don't want to make cgroupfs_root bigger,
>
>        cgroupfs_root {
>                ......
>                /* this must be the bottom of struct */
>                char name[0];
>        }
>
> Is a choice.

I'd rather avoid something like that since I think it's less readable
- I'd probably just make the name into a pointer in that case.

>
> BTW, reading a patch, any kind of charactors are allowed ?

Yes, other than \000 of course. I guess maybe I should use
seq_escape() to print the name to avoid confusion in the event that
people put whitespace in there, or else just ban whitespace (or maybe
all non-alphanumeric chars).

Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists