Changelog
1. Be consistent, use the C style of returning 0 on success and negative
values on failure
2. Change and document the locking used by the controller
(I hope I got it right this time :-))
3. Remove memctlr_double_(un)lock routines
4. Comment the usage of MEMCONTROL_DONT_CHECK_LIMI
Changelog
1. Be consistent, use the C style of returning 0 on success and negative
values on failure
2. Change and document the locking used by the controller
(I hope I got it right this time :-))
3. Remove memctlr_double_(un)lock routines
4. Comment the usage of MEMCONTROL_DONT_CHECK_LIMI
Balbir Singh wrote:
> Vaidyanathan Srinivasan wrote:
>> Balbir Singh wrote:
>>> Paul Menage wrote:
On 2/19/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>> More worrisome is the potential for use-after-free. What prevents the
>> pointer at mm->container from referring to freed memory
Vaidyanathan Srinivasan wrote:
Balbir Singh wrote:
Paul Menage wrote:
On 2/19/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
More worrisome is the potential for use-after-free. What prevents the
pointer at mm->container from referring to freed memory after we're dropped
the lock?
The containe
Balbir Singh wrote:
> Paul Menage wrote:
>> On 2/19/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
More worrisome is the potential for use-after-free. What prevents the
pointer at mm->container from referring to freed memory after we're dropped
the lock?
>>> The container cannot
Paul Menage wrote:
On 2/19/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
More worrisome is the potential for use-after-free. What prevents the
pointer at mm->container from referring to freed memory after we're dropped
the lock?
The container cannot be freed unless all tasks holding references
On 2/19/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> More worrisome is the potential for use-after-free. What prevents the
> pointer at mm->container from referring to freed memory after we're dropped
> the lock?
>
The container cannot be freed unless all tasks holding references to it are
g
Andrew Morton wrote:
On Mon, 19 Feb 2007 16:39:33 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
On Mon, 19 Feb 2007 16:07:44 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
+void memctlr_mm_free(struct mm_struct *mm)
+{
+ kfree(mm->counter);
+}
+
+static inline void
On Mon, 19 Feb 2007 16:39:33 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Mon, 19 Feb 2007 16:07:44 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
> >
> +void memctlr_mm_free(struct mm_struct *mm)
> +{
> +kfree(mm->counter);
> +}
> +
On Mon, 19 Feb 2007 16:07:44 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
> >> +void memctlr_mm_free(struct mm_struct *mm)
> >> +{
> >> + kfree(mm->counter);
> >> +}
> >> +
> >> +static inline void memctlr_mm_assign_container_direct(struct mm_struct
> >> *mm,
> >> +
Andrew Morton wrote:
On Mon, 19 Feb 2007 16:07:44 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
+void memctlr_mm_free(struct mm_struct *mm)
+{
+ kfree(mm->counter);
+}
+
+static inline void memctlr_mm_assign_container_direct(struct mm_struct *mm,
+
Andrew Morton wrote:
On Mon, 19 Feb 2007 12:20:34 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
This patch adds the basic accounting hooks to account for pages allocated
into the RSS of a process. Accounting is maintained at two levels, in
the mm_struct of each task and in the memory controller
On Mon, 19 Feb 2007 12:20:34 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> This patch adds the basic accounting hooks to account for pages allocated
> into the RSS of a process. Accounting is maintained at two levels, in
> the mm_struct of each task and in the memory controller data structure
This patch adds the basic accounting hooks to account for pages allocated
into the RSS of a process. Accounting is maintained at two levels, in
the mm_struct of each task and in the memory controller data structure
associated with each node in the container.
When the limit specified for the conta
14 matches
Mail list logo
