Alexander Viro writes:
>
>
> 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.
Ok, so it wouldn't work for the complex entries providing services like
plan9 file servers, but use for simple statistics reports, etc. is ok as
far as they write data into kernel page allocated by proc_file_read()
and don't sleep, right? (I just need your sanction :).
>
> 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
Nikita.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
