Skip to contentSkip to conversation

fix net/rxrpc/proc.c

PATCH In review Chris Wright 4 participants 9 messages May 13, 2003

Subsystems (2)
Networking Rxrpc sockets (AF_RXRPC)
lore
Share & tools
lore

Chris Wright

author
#0 lore raw

PATCH 1/1 fix net/rxrpc/proc.c

A recent change in 2.5.69-bk from Yoshfuji broke compilation of rxrpc code. It erroneously adds an owner field to the rxrpc_proc_peers_ops seq_operations. Fix below.

thanks,
-chris

Signature · 13 lines
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

===== net/rxrpc/proc.c 1.3 vs edited =====
--- 1.3/net/rxrpc/proc.c	Sat May 10 11:46:35 2003
+++ edited/net/rxrpc/proc.c	Mon May 12 17:25:12 2003
@@ -52,7 +52,6 @@
 static int rxrpc_proc_peers_show(struct seq_file *m, void *v);
 
 static struct seq_operations rxrpc_proc_peers_ops = {
-	.owner	= THIS_MODULE,
 	.start	= rxrpc_proc_peers_start,
 	.next	= rxrpc_proc_peers_next,
 	.stop	= rxrpc_proc_peers_stop,
#1 lore raw
Quoted 3 lines · Chris Wright

A recent change in 2.5.69-bk from Yoshfuji broke compilation of rxrpc code. It erroneously adds an owner field to the rxrpc_proc_peers_ops seq_operations. Fix below.

Why is it "erroneous"? Just add the proper linux/module.h include to net/rxrpc/proc.c instead of spewing baseless claims.

Signature · 1 line
David S. Miller <[email protected]>
author
#2 lore raw
Quoted 7 lines · * David S. Miller ([email protected]) wrote:
Quoted 3 lines · Chris Wright

A recent change in 2.5.69-bk from Yoshfuji broke compilation of rxrpc code. It erroneously adds an owner field to the rxrpc_proc_peers_ops seq_operations. Fix below.

Why is it "erroneous"? Just add the proper linux/module.h include to net/rxrpc/proc.c instead of spewing baseless claims.

Sorry, if I'm missing the obvious, but looking at my current bk tree I see this:

include/linux/seq_file.h

struct seq_operations {
	void * (*start) (struct seq_file *m, loff_t *pos);
	void (*stop) (struct seq_file *m, void *v);
	void * (*next) (struct seq_file *m, void *v, loff_t *pos);
	int (*show) (struct seq_file *m, void *v);
};

It looks to me like there is a simple mistake of seq_operations != file_operations when adding .owner = THIS_MODULE to the file_operations.

thanks,
-chris

Signature · 1 line
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
#3 lore raw

In article <[email protected]> (at Mon, 12 May 2003 19:00:36 -0700), Chris Wright <[email protected]> says:

Quoted 21 lines · * David S. Miller ([email protected]) wrote:
Quoted 7 lines · Chris Wright
Quoted 3 lines

A recent change in 2.5.69-bk from Yoshfuji broke compilation of rxrpc code. It erroneously adds an owner field to the rxrpc_proc_peers_ops seq_operations. Fix below.

Why is it "erroneous"? Just add the proper linux/module.h include to net/rxrpc/proc.c instead of spewing baseless claims.

Sorry, if I'm missing the obvious, but looking at my current bk tree I see this:

include/linux/seq_file.h

struct seq_operations {
	void * (*start) (struct seq_file *m, loff_t *pos);
	void (*stop) (struct seq_file *m, void *v);
	void * (*next) (struct seq_file *m, void *v, loff_t *pos);
	int (*show) (struct seq_file *m, void *v);
};
Quoted 2 lines

It looks to me like there is a simple mistake of seq_operations != file_operations when adding .owner = THIS_MODULE to the file_operations.

Sorry, it's my mistake. David, please apply his patch.

--yoshfuji

author
#4 lore raw
Quoted 2 lines · * YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B ([email protected]) wrote:

Sorry, it's my mistake. David, please apply his patch.

Thanks, sorry, I should have Cc:'d you in the first place, my apology. Seems like the rxrpc_proc_calls_fops should get an owner as well? (relative to the last patch)

thanks,
-chris

===== net/rxrpc/proc.c 1.3 vs edited =====

net/rxrpc/proc.c +1 -0
@@ -102,6 +101,7 @@
 };
 
 static struct file_operations rxrpc_proc_calls_fops = {
+	.owner		= THIS_MODULE,
 	.open		= rxrpc_proc_calls_open,
 	.read		= seq_read,
 	.llseek		= seq_lseek,
#5 lore raw

In article <[email protected]> (at Mon, 12 May 2003 20:05:30 -0700), Chris Wright <[email protected]> says:

Quoted 7 lines · * YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B ([email protected]) wrote:
Quoted 2 lines

Sorry, it's my mistake. David, please apply his patch.

Thanks, sorry, I should have Cc:'d you in the first place, my apology. Seems like the rxrpc_proc_calls_fops should get an owner as well? (relative to the last patch)

Yes. Thanks for pointing out.

Signature · 2 lines
Hideaki YOSHIFUJI @ USAGI Project <[email protected]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
#6 lore raw
In reply to Chris Wright

From: Chris Wright <[email protected]>
Date: Mon, 12 May 2003 20:05:30 -0700

Quoted 2 lines · * YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B ([email protected]) wrote:

Sorry, it's my mistake. David, please apply his patch.

Thanks, sorry, I should have Cc:'d you in the first place, my apology. Seems like the rxrpc_proc_calls_fops should get an owner as well? (relative to the last patch)

Thanks for working all of this out, both changes applied to my tree.

#7 lore raw
In reply to Chris Wright
Quoted 4 lines

Thanks, sorry, I should have Cc:'d you in the first place, my apology. Seems like the rxrpc_proc_calls_fops should get an owner as well? (relative to the last patch)

Should all file_operations tables associated with this be "owned" in this manner?

David

#8 lore raw
Quoted 7 lines
Quoted 4 lines

Thanks, sorry, I should have Cc:'d you in the first place, my apology. Seems like the rxrpc_proc_calls_fops should get an owner as well? (relative to the last patch)

Should all file_operations tables associated with this be "owned" in this manner?

Hmmm... actually, looking at the code, it ought to be unnecessary as the proc entries are "owned", eg:

	int rxrpc_proc_init(void)
	{
		struct proc_dir_entry *p;

		proc_rxrpc = proc_mkdir("rxrpc",proc_net);
		if (!proc_rxrpc)
			goto error;
		proc_rxrpc->owner = THIS_MODULE;

	...
	}

David