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/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:25 EST