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


On Fri, 13 Oct 2000, Alan Cox wrote:

> > 1) one process does read() on device, another does revoke()
> > followed by rmmod. Oops - nothing holds module in memory, the first
> > process is executing code from that module (->read(), that is) and
> > we unmap that code.
> >
> > 2) every access to ->f_op suddenly becomes unsafe. Basically the
> > same scenario, but here we have the window between fetching ->f_op and
> > calling ->f_op->foo. You have no exclusion here, and even if you had, you
> > still got #1 to deal with.
>
> Is #2 actually a problem if #1 is ok. We don't destroy f_ops tables except
> on a module unload. Another thing that is arguable is that revoke() should
> not return until the revocation is completed. That would solve #1 in the
> process I belive ?

The problem being: you have no way to tell when method returns. IOW,
there's nothing for revoke() to sleep on.

#2 is essentially the same as #1, but with an additional twist: call of
old method may happen after the new value of ->f_op is written to memory.
Some exclusion is obviously needed here. In principle, rw-semaphore with
all methods callers holding it for read and revoke() holding it for write
would be enough, but I suspect that overhead will be nasty. Something like
rw-semaphore with extremely light-weight readers and potentially slow
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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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