On Fri, 23 Mar 2001, Danilov Nikita wrote:
> Alexander Viro writes:
> >
> >
> > On Fri, 23 Mar 2001, Danilov Nikita wrote:
> >
> > > > Not enough. You'll need to deal with invalidation of procfs entries on
>umount
> > > > and that will be rather painful.
> > >
> > > What's wrong with remove_proc_entry()?
> >
> > The fact that in can be called in the middle of read() (or write(), for that
> > matter).
>
> Can you clarify this? I thought remove_proc_entry() takes care of this.
> As an experiment I created simple stub function (follows).
>
> If I umount fs while read is sleeping, remove_proc_entry() complains
> that entry is busy, and after read completes, deletes it (the same holds
> for directories).
Yes. And if after sleeping in read() you try to access the superblock again
you will find that it's not there.
remove_proc_entry() prevents further read() from going into fs code,
but it doesn't help the operations in progress. And making read() that
would never sleep is not a pretty thing - think of page faults if buffer
is unmapped, for one thing. Or allocating the buffer if you want to
get all data first and then copy them to userland without caring about
underlying object.
You certainly can do a bunch of ad-hoc tricks that will preserve the
internals of your methods. It won't be easy, it won't be pretty and
it will be constant source of PITA.
Cheers,
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
