On Friday 09 March 2007 17:11, Benjamin LaHaise wrote:
> On Fri, Mar 09, 2007 at 12:13:35PM +0100, Eric Dumazet wrote:
> > Then just drop the fget_light() 'optimisation' and always take a
> > reference (atomic on f_count) regardless of single-thread or not. Instead
> > of dirtying f_light, just do
On Fri, Mar 09, 2007 at 12:13:35PM +0100, Eric Dumazet wrote:
> Then just drop the fget_light() 'optimisation' and always take a reference
> (atomic on f_count) regardless of single-thread or not. Instead of dirtying
> f_light, just do the straightforward thing and be with it.
>
> (that is :
On Fri, Mar 09, 2007 at 12:13:35PM +0100, Eric Dumazet wrote:
> Then just drop the fget_light() 'optimisation' and always take a reference
> (atomic on f_count) regardless of single-thread or not. Instead of dirtying
> f_light, just do the straightforward thing and be with it.
>
> (that is :
At some point in time, I wrote:
> > Btw, what we can do is delay closing the actual revoked file until the
> > task terminates. This has the unfortunate side-effect that a task has
> > no way of freeing the resources now. But, I am beginning to think it's
> > not a big problem because the inode
> Btw, what we can do is delay closing the actual revoked file until the
> task terminates. This has the unfortunate side-effect that a task has
> no way of freeing the resources now. But, I am beginning to think it's
> not a big problem because the inode mapping will be zapped immediately
> upon
On 3/9/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
> Then just drop the fget_light() 'optimisation' and always take a reference
> (atomic on f_count) regardless of single-thread or not. Instead of dirtying
> f_light, just do the straightforward thing and be with it.
On 3/9/07, Pekka Enberg
On 3/9/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Then just drop the fget_light() 'optimisation' and always take a reference
(atomic on f_count) regardless of single-thread or not. Instead of dirtying
f_light, just do the straightforward thing and be with it.
That's what I did first but akpm
On Friday 09 March 2007 11:43, Pekka Enberg wrote:
> On 3/9/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
> > Cannot we use a flag in 'struct files_struct', set to one when the task
> > is mono-thread (at task creation in fact), and set to 0 when it creates a
> > new thread (or when someone
On 3/9/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Cannot we use a flag in 'struct files_struct', set to one when the task is
mono-thread (at task creation in fact), and set to 0 when it creates a new
thread (or when someone remotely access to this "struct files_struct"
in /proc/pid/fd/... )
On Friday 09 March 2007 09:14, Pekka J Enberg wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> This adds a f_light flag to struct file to indicate that the file was
> looked up with fget_light(). Needed by revoke to ensure we don't
> close a file pointer while someone is using it without
From: Pekka Enberg <[EMAIL PROTECTED]>
This adds a f_light flag to struct file to indicate that the file was
looked up with fget_light(). Needed by revoke to ensure we don't
close a file pointer while someone is using it without actually
holding a reference.
These bits were taken from the
From: Pekka Enberg [EMAIL PROTECTED]
This adds a f_light flag to struct file to indicate that the file was
looked up with fget_light(). Needed by revoke to ensure we don't
close a file pointer while someone is using it without actually
holding a reference.
These bits were taken from the forced
On Friday 09 March 2007 09:14, Pekka J Enberg wrote:
From: Pekka Enberg [EMAIL PROTECTED]
This adds a f_light flag to struct file to indicate that the file was
looked up with fget_light(). Needed by revoke to ensure we don't
close a file pointer while someone is using it without actually
On 3/9/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Cannot we use a flag in 'struct files_struct', set to one when the task is
mono-thread (at task creation in fact), and set to 0 when it creates a new
thread (or when someone remotely access to this struct files_struct
in /proc/pid/fd/... )
How
On Friday 09 March 2007 11:43, Pekka Enberg wrote:
On 3/9/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Cannot we use a flag in 'struct files_struct', set to one when the task
is mono-thread (at task creation in fact), and set to 0 when it creates a
new thread (or when someone remotely access
On 3/9/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Then just drop the fget_light() 'optimisation' and always take a reference
(atomic on f_count) regardless of single-thread or not. Instead of dirtying
f_light, just do the straightforward thing and be with it.
That's what I did first but akpm
On 3/9/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Then just drop the fget_light() 'optimisation' and always take a reference
(atomic on f_count) regardless of single-thread or not. Instead of dirtying
f_light, just do the straightforward thing and be with it.
On 3/9/07, Pekka Enberg [EMAIL
At some point in time, I wrote:
Btw, what we can do is delay closing the actual revoked file until the
task terminates. This has the unfortunate side-effect that a task has
no way of freeing the resources now. But, I am beginning to think it's
not a big problem because the inode mapping
Btw, what we can do is delay closing the actual revoked file until the
task terminates. This has the unfortunate side-effect that a task has
no way of freeing the resources now. But, I am beginning to think it's
not a big problem because the inode mapping will be zapped immediately
upon
On Fri, Mar 09, 2007 at 12:13:35PM +0100, Eric Dumazet wrote:
Then just drop the fget_light() 'optimisation' and always take a reference
(atomic on f_count) regardless of single-thread or not. Instead of dirtying
f_light, just do the straightforward thing and be with it.
(that is :
On Fri, Mar 09, 2007 at 12:13:35PM +0100, Eric Dumazet wrote:
Then just drop the fget_light() 'optimisation' and always take a reference
(atomic on f_count) regardless of single-thread or not. Instead of dirtying
f_light, just do the straightforward thing and be with it.
(that is :
On Friday 09 March 2007 17:11, Benjamin LaHaise wrote:
On Fri, Mar 09, 2007 at 12:13:35PM +0100, Eric Dumazet wrote:
Then just drop the fget_light() 'optimisation' and always take a
reference (atomic on f_count) regardless of single-thread or not. Instead
of dirtying f_light, just do the
22 matches
Mail list logo
