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
--
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,
On Mon, 2003-05-12 at 17:38, Chris Wright wrote:
> 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.
--
David S. Miller <[email protected]>
* David S. Miller ([email protected]) wrote:
> On Mon, 2003-05-12 at 17:38, Chris Wright wrote:
> > 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
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
In article <[email protected]> (at Mon, 12 May 2003 19:00:36 -0700), Chris Wright <[email protected]> says:
> * David S. Miller ([email protected]) wrote:
> > On Mon, 2003-05-12 at 17:38, Chris Wright wrote:
> > > 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.
Sorry, it's my mistake. David, please apply his patch.
--yoshfuji
* 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 =====
--- 1.3/net/rxrpc/proc.c Sat May 10 11:46:35 2003
+++ edited/net/rxrpc/proc.c Mon May 12 19:56:20 2003
@@ -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,
In article <[email protected]> (at Mon, 12 May 2003 20:05:30 -0700), Chris Wright <[email protected]> says:
> * 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)
Yes. Thanks for pointing out.
--
Hideaki YOSHIFUJI @ USAGI Project <[email protected]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
From: Chris Wright <[email protected]>
Date: Mon, 12 May 2003 20:05:30 -0700
* 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.
> 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
> > 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