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]
Message-ID: <4FC769C9.3040300@oracle.com>
Date:	Thu, 31 May 2012 20:53:29 +0800
From:	Jeff Liu <jeff.liu@...cle.com>
To:	Glauber Costa <glommer@...allels.com>
CC:	containers@...ts.linux-foundation.org, cgroups@...r.kernel.org,
	jack@...e.cz, daniel.lezcano@...e.fr, tytso@....edu, bpm@....com,
	chris.mason@...cle.com, hch@...radead.org,
	christopher.jones@...cle.com, david@...morbit.com,
	tinguely@....com, tm@....ma, linux-ext4@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 04/12] container quota: introduce container disk quota
 data header file.

On 05/31/2012 05:10 PM, Glauber Costa wrote:

>> +
>> +/* Operations for quota control */
>> +struct ns_quotactl_ops {
>> +    int (*quota_on)(struct mnt_namespace *, int);
>> +    int (*quota_off)(struct mnt_namespace *, int);
>> +    int (*get_info)(struct mnt_namespace *, int, struct if_dqinfo *);
>> +    int (*set_info)(struct mnt_namespace *, int, struct if_dqinfo *);
>> +    int (*get_dqblk)(struct mnt_namespace *, int, qid_t,
>> +             struct fs_disk_quota *);
>> +    int (*set_dqblk)(struct mnt_namespace *, int, qid_t,
>> +             struct fs_disk_quota *);
>> +};
>> +
> 
> That is quite bad. Just have the same signature. Which namespace you
> belong to can *always* be derived from the calling process, you should
> never need to specify that in any interface. It is of course fine to do
> that in functions internal to the kernel, but not this.

Exactly, "struct mnt_namespace" should not be presented at any quota
operation interface, retrieve it through current->nsproxy->mnt_ns should
be fine.

> You should rethink the whole ns_quota thing. Some of it I believe will
> have to stay, I doubt we'll be able to be completely transparent. But
> the core of your changes have to be making sure a hierarchical walk over
> the valid quotas work well, finding out what are those valid quotas, etc.

> The interface should be kept as unchanged as possible, and this can be
> achieved by things like automatic discover of the current namespace, and
> pre-operational container setup for the relevant files.

Thanks for teaching me that,  let me try to refactor ns_quota to make
the change as little as possible.

-Jeff

> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ