Re: [BUG] net_cls: Panic occured when net_cls subsystem use

[Jarek Poplawski <jarkao2@gmail.com>]

On Sat, May 30, 2009 at 08:31:23AM -0400, jamal wrote:
> On Sat, 2009-05-30 at 14:07 +0200, Jarek Poplawski wrote:
> > On Sat, May 30, 2009 at 07:56:34AM -0400, jamal wrote:
> 
> > > tp_created is the check
> > > n->nlmsg_type == RTM_NEWTFILTER && n->nlmsg_flags&NLM_F_CREATE
> > > replace will be
> > > n->nlmsg_type == RTM_NEWTFILTER && n->nlmsg_flags & NLM_F_EXCL
> > 
> > Hmm... Probably I miss something, but I've just seen this prink during
> > tc filter replace with:
> > 
> > err = tp->ops->change();
> > if (n->nlmsg_type == RTM_NEWTFILTER && (n->nlmsg_flags&NLM_F_CREATE))
> > 	printk(...);
> 
> That sounds right. 
> Remeber, you could have NLM_F_EXCL|NLM_F_CREATE to indicate "create this
> thing if it doesnt exist; if it exists  it is an error"
> If it doesnt exist we will enter that (tp == NULL) path
> also fh will be 0 ==> So you will never enter the code
> path you are refering to.
> If it exists (i.e you found it) and you enter the code path you refer
> to, then you surely dont want to destroy it if NLM_F_EXCL is set.

I mean we don't want to link it again or destroy after ->change() err
if we run replace (n->nlmsg_type == RTM_NEWTFILTER &&
(n->nlmsg_flags&NLM_F_CREATE)).

> 
> > > I think they are two separate issues.
> > > The fact that we dont destroy an allocated tp on failure is an issue
> > > regardless of what cls_group does. In the case of Minoru's issue
> > > it is because he is misconfiguring cls_group.
> > 
> > Sure, but we don't want people to get oops in such a case, I guess.
> > 
> 
> The ops is caused by the code fixed in the patch - did i miss something?

IMHO it could be fixed "old way" in cls_group code too.

Cheers,
Jarek P.