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
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
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
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
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
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
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
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
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
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
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
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,
+
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,
+
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
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 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
gone,
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 to
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 be freed unless all
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 container
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 after we're
dropped
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
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
28 matches
Mail list logo
