Messages in this thread |  | | Date | Fri, 13 Oct 2000 15:02:03 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [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/
|  |