Re: [PATCH 9/12] ipv4: assign PDE->data before gluing PDE into /proc tree

["Denis V. Lunev" <den@openvz.org>]

On Fri, 2008-07-11 at 22:12 -0500, Stoyan Gaydarov wrote:
> First off, sorry to bring such an old email back but I can seem to get
> a bad feeling when looking back over it.
> 
> On Tue, Apr 29, 2008 at 6:13 AM, Denis V. Lunev <den@openvz.org> wrote:
> > The check for PDE->data != NULL becomes useless after the replacement
> > of proc_net_fops_create with proc_create_data.
> >
> > Signed-off-by: Denis V. Lunev <den@openvz.org>
> > Cc: Alexey Dobriyan <adobriyan@openvz.org>
> > Cc: Eric W. Biederman <ebiederm@xmission.com>
> > Cc: David S. Miller <davem@davemloft.net>
> > ---
> >  net/ipv4/tcp_ipv4.c |   10 +++-------
> >  net/ipv4/udp.c      |    7 +++----
> >  2 files changed, 6 insertions(+), 11 deletions(-)
> >
> > diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> > index 7766151..4d97b28 100644
> > --- a/net/ipv4/tcp_ipv4.c
> > +++ b/net/ipv4/tcp_ipv4.c
> > @@ -2214,9 +2214,6 @@ static int tcp_seq_open(struct inode *inode, struct file *file)
> >        struct tcp_iter_state *s;
> >        int err;
> >
> > -       if (unlikely(afinfo == NULL))
> > -               return -EINVAL;
> I think that this check needs to stay in some form, reason below.
> > -
> >        err = seq_open_net(inode, file, &afinfo->seq_ops,
> >                          sizeof(struct tcp_iter_state));
> >        if (err < 0)
> > @@ -2241,10 +2238,9 @@ int tcp_proc_register(struct net *net, struct tcp_seq_afinfo *afinfo)
> >        afinfo->seq_ops.next            = tcp_seq_next;
> >        afinfo->seq_ops.stop            = tcp_seq_stop;
> >
> > -       p = proc_net_fops_create(net, afinfo->name, S_IRUGO, &afinfo->seq_fops);
> > -       if (p)
> > -               p->data = afinfo;
> > -       else
> > +       p = proc_create_data(afinfo->name, S_IRUGO, net->proc_net,
> 
> When you try to pass in afinfo->name (and also the seq_fops) you are
> assuming that afinfo is not null meaning in the unlikely(as shown
> above) even that it is null you get a very bad null pointer problem.
> If I am just way off do let me know because this just seams to me like
> a bad idea. This is also still present in 2.6.26-rc9.

The reason to remove the check is simple - afinfo comes in the form of
the static pointer during init time. It is impossible to face NULL
pointer the problem in the reality. It can come as the programmer
mistake, but the OOPS will be immediate and straightforward. Namely, the
kernel will not boot/work at all.

Regards,
	Den