From: Wang Chen <hidden> Date: 2008-02-28 10:58:09
Use proc_create() to make sure that ->proc_fops be setup before gluing
PDE to main tree.
Signed-off-by: Wang Chen <redacted>
---
net/sunrpc/cache.c | 14 ++++++--------
net/sunrpc/stats.c | 3 +--
2 files changed, 7 insertions(+), 10 deletions(-)
For this case it appears that ent->data has the same kind of
visibility problem that ent->proc_fops does.
Thanks Dave, I will check whether ->data also has the visibility problem.
I have looked at the proc_create().
The reason for why we need to setup pde->proc_fops in proc_create() before
the pde be visible, is that proc_fops will be setuped in proc_register() and
and NULL of proc_fops will make proc_register() give pde an improper fops.
But, ->data and ->owner will not be affected by this instance.
So, it's safe to setup ->data and ->owner after visibility of pde.
For this case it appears that ent->data has the same kind of
visibility problem that ent->proc_fops does.
Thanks Dave, I will check whether ->data also has the visibility problem.
I have looked at the proc_create().
The reason for why we need to setup pde->proc_fops in proc_create() before
the pde be visible, is that proc_fops will be setuped in proc_register() and
and NULL of proc_fops will make proc_register() give pde an improper fops.
But, ->data and ->owner will not be affected by this instance.
So, it's safe to setup ->data and ->owner after visibility of pde.
->owner is buggy, believed to be unnecessary and will thus die so don't
bother with it. ;-)
->data looks safe to setup separately while module is loading:
before ->data will be used by code which is unprepared to it being NULL,
VFS will pin module, which can't be done during module load.
I think the existence of proc_create_data() depends entirely on
cases which do all the above from code that is not module_init hook.
Does anyone know some?