How can I detect that open() has been called on a file in procfs that a
module provides? If I modprobe my module, open one or more if its proc
entries, then rmmod the module while the proc files are still open, then
the deletion of those entries is deferred. When I close the file(s), the
kernel oopses. I need to be able to detect open() and close() in order
to increment/decrement the reference count for my module, to prevent it
from being rmmoded when in use. Any tips?
Thanks!
Michael Rothwell wrote:
>
> How can I detect that open() has been called on a file in procfs that a
> module provides? If I modprobe my module, open one or more if its proc
> entries, then rmmod the module while the proc files are still open, then
> the deletion of those entries is deferred. When I close the file(s), the
> kernel oopses. I need to be able to detect open() and close() in order
> to increment/decrement the reference count for my module, to prevent it
> from being rmmoded when in use. Any tips?
>
> Thanks!
Really, the procfs needs a pointer to the module so it can do the
reference before calling the code in the module.
--
Brian Gerst
Figured it out -- I think. This appears to be the answer:
In struct proc_dir_entry,set the fill_inode function pointer to a
callback to handle refcounts.
struct proc_dir_entry
{
...
void (*fill_inode)(struct inode *, int);
...
};
void fill_inode_cb(struct inode *i, int v)
{
if (v==0)
{
MOD_DEC_USE_COUNT;
return;
};
if (v==1)
{
MOD_INC_USE_COUNT;
return;
};
};
... right? :)
On 08 Mar 2001 11:01:28 -0500, Michael Rothwell wrote:
> How can I detect that open() has been called on a file in procfs that a
> module provides? If I modprobe my module, open one or more if its proc
> entries, then rmmod the module while the proc files are still open, then
> the deletion of those entries is deferred. When I close the file(s), the
> kernel oopses. I need to be able to detect open() and close() in order
> to increment/decrement the reference count for my module, to prevent it
> from being rmmoded when in use. Any tips?
>
> Thanks!
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On 8 Mar 2001, Michael Rothwell wrote:
> Figured it out -- I think. This appears to be the answer:
>
> In struct proc_dir_entry,set the fill_inode function pointer to a
> callback to handle refcounts.
>
> struct proc_dir_entry
> {
> ...
> void (*fill_inode)(struct inode *, int);
> ...
> };
[snip]
> ... right? :)
Right for 2.2, wrong for 2.4. There you just set ->owner to THIS_MODULE
and forget about the whole mess with callbacks.
Cheers,
Al
Sweet! Thanks!
I'm working on 2.2 for now, but the 2.4 API looks nicer... :)
-M
On 08 Mar 2001 11:43:24 -0500, Alexander Viro wrote:
>
>
> On 8 Mar 2001, Michael Rothwell wrote:
>
> > Figured it out -- I think. This appears to be the answer:
> >
> > In struct proc_dir_entry,set the fill_inode function pointer to a
> > callback to handle refcounts.
> >
> > struct proc_dir_entry
> > {
> > ...
> > void (*fill_inode)(struct inode *, int);
> > ...
> > };
> [snip]
> > ... right? :)
>
> Right for 2.2, wrong for 2.4. There you just set ->owner to THIS_MODULE
> and forget about the whole mess with callbacks.
> Cheers,
> Al