lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 29 Feb 2008 12:32:32 +0300
From:	Alexey Dobriyan <adobriyan@...ru>
To:	Wang Chen <wangchen@...fujitsu.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH 03/15] [SUNRPC]: Use proc_create() to setup ->proc_fops first

On Fri, Feb 29, 2008 at 04:35:17PM +0800, Wang Chen wrote:
> Wang Chen said the following on 2008-2-29 13:26:
> > David Miller said the following on 2008-2-29 6:02:
> >> From: Wang Chen <wangchen@...fujitsu.com>
> >> Date: Thu, 28 Feb 2008 18:55:40 +0800
> >>
> >>> Use proc_create() to make sure that ->proc_fops be setup before gluing
> >>> PDE to main tree.
> >>>
> >>> Signed-off-by: Wang Chen <wangchen@...fujitsu.com>
> >> Applied.
> >>
> >>> @@ -229,9 +229,8 @@ do_register(const char *name, void *data, const struct file_operations *fops)
> >>>  	rpc_proc_init();
> >>>  	dprintk("RPC:       registering /proc/net/rpc/%s\n", name);
> >>>  
> >>> -	ent = create_proc_entry(name, 0, proc_net_rpc);
> >>> +	ent = proc_create(name, 0, proc_net_rpc, fops);
> >>>  	if (ent) {
> >>> -		ent->proc_fops = fops;
> >>>  		ent->data = data;
> >>>  	}
> >>>  	return ent;
> >> 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?

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ