[lkml]   [2000]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] For 2.4: syscall revoke.

On Fri, 13 Oct 2000, Alan Cox wrote:

> > writer might be OK, but AFAICS there is nothing of that sort in the
> > tree. We have such spinlocks, but I don't see how to apply that idea to
> > semaphores. Besides, it ought to be small - every struct file will have to
> > contain such beast.
> It would mean a check when putting a file handle, which would be unpleasant
> if not handled very carefully.

I.e. you would have to unlock before doing fput(). Happens all by itself
if we hold the lock only across the actual method call. I'm not saying
that it's a good way, but correctenss problems are not going to be all
that terrible.

> How about doing this in fput ?
> if(IS_REVOKED(file) && file->f_ops != &revoked_ops)
> {
> file->f_ops = &revoked_ops;
> wake_up(&fop_wait);
> }
> that would mean that the ops change is done by the code paths that care about
> the handle at the point it becomes unused. We could use a poll_table like
> setup to handle the multi-fd wait if need be

fput() has zero serialization wrt methods. The only case when resetting
->f_op in fput() is safe is when ->f_count hits zero. Precisely because
there's no references left. But at that point you don't need to bother at

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.055 / U:1.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site