Chris Wright wrote:
You missed one subtle point. That failure case actually unaccts 0 pages
(note the use of charge). Not the nicest, but I believe correct.
Right. I did miss that. Thanks for the explanations, Chris and Hugh, I
appreciate it.
Mark F. Haigh
[EMAIL PROTECTED]
-
To unsubscribe
On Wed, 9 Feb 2005, Chris Wright wrote:
> * Hugh Dickins ([EMAIL PROTECTED]) wrote:
> > dup_mmap's charge starts out at 0 and gets added to each time around
> > the loop through vmas; if security_vm_enough_memory fails at any point
> > in that loop, we need to vm_unacct_memory the charge already
* Hugh Dickins ([EMAIL PROTECTED]) wrote:
> dup_mmap's charge starts out at 0 and gets added to each time around
> the loop through vmas; if security_vm_enough_memory fails at any point
> in that loop, we need to vm_unacct_memory the charge already accumulated.
If that's the requirement, then
On Tue, 8 Feb 2005, Chris Wright wrote:
> * Mark F. Haigh ([EMAIL PROTECTED]) wrote:
> >
> > If security_vm_enough_memory() fails there, then we vm_unacct_memory()
> > that we never accounted (if security_vm_enough_memory() fails, no memory
> > is accounted).
>
> You missed one subtle point.
On Tue, 8 Feb 2005, Chris Wright wrote:
* Mark F. Haigh ([EMAIL PROTECTED]) wrote:
If security_vm_enough_memory() fails there, then we vm_unacct_memory()
that we never accounted (if security_vm_enough_memory() fails, no memory
is accounted).
You missed one subtle point. That failure
* Hugh Dickins ([EMAIL PROTECTED]) wrote:
dup_mmap's charge starts out at 0 and gets added to each time around
the loop through vmas; if security_vm_enough_memory fails at any point
in that loop, we need to vm_unacct_memory the charge already accumulated.
If that's the requirement, then it's
On Wed, 9 Feb 2005, Chris Wright wrote:
* Hugh Dickins ([EMAIL PROTECTED]) wrote:
dup_mmap's charge starts out at 0 and gets added to each time around
the loop through vmas; if security_vm_enough_memory fails at any point
in that loop, we need to vm_unacct_memory the charge already
Chris Wright wrote:
snip
You missed one subtle point. That failure case actually unaccts 0 pages
(note the use of charge). Not the nicest, but I believe correct.
Right. I did miss that. Thanks for the explanations, Chris and Hugh, I
appreciate it.
Mark F. Haigh
[EMAIL PROTECTED]
-
To
Hi Mark,
* Mark F. Haigh ([EMAIL PROTECTED]) wrote:
> [Aargh! Missing Signed-off-by.]
>
> Unless I'm missing something, in kernel/fork.c, dup_mmap():
>
> if (security_vm_enough_memory(len))
> goto fail_nomem;
> /* ... */
> fail_nomem:
>
[Aargh! Missing Signed-off-by.]
Unless I'm missing something, in kernel/fork.c, dup_mmap():
if (security_vm_enough_memory(len))
goto fail_nomem;
/* ... */
fail_nomem:
retval = -ENOMEM;
vm_unacct_memory(charge);
/* ... */
If
Unless I'm missing something, in kernel/fork.c, dup_mmap():
if (security_vm_enough_memory(len))
goto fail_nomem;
/* ... */
fail_nomem:
retval = -ENOMEM;
vm_unacct_memory(charge);
/* ... */
If security_vm_enough_memory() fails
Unless I'm missing something, in kernel/fork.c, dup_mmap():
if (security_vm_enough_memory(len))
goto fail_nomem;
/* ... */
fail_nomem:
retval = -ENOMEM;
vm_unacct_memory(charge);
/* ... */
If security_vm_enough_memory() fails
[Aargh! Missing Signed-off-by.]
Unless I'm missing something, in kernel/fork.c, dup_mmap():
if (security_vm_enough_memory(len))
goto fail_nomem;
/* ... */
fail_nomem:
retval = -ENOMEM;
vm_unacct_memory(charge);
/* ... */
If
Hi Mark,
* Mark F. Haigh ([EMAIL PROTECTED]) wrote:
[Aargh! Missing Signed-off-by.]
Unless I'm missing something, in kernel/fork.c, dup_mmap():
if (security_vm_enough_memory(len))
goto fail_nomem;
/* ... */
fail_nomem:
retval =
14 matches
Mail list logo
