2005-11-16 23:11:42

by Christian Kujau

[permalink] [raw]
Subject: 2.6.15-rc1: NET_CLS_U32 not working?

hi,

i noticed that some of my QoS rules are not working any more. oh, i
forgot to enable CONFIG_NET_CLS_U32. but when enabled, i got the
following errors when compiling / installing the module:

* Warning: "unregister_tcf_proto_ops" [net/sched/cls_u32.ko] undefined!
* Warning: "register_tcf_proto_ops" [net/sched/cls_u32.ko] undefined!
* Warning: "tcf_exts_dump" [net/sched/cls_u32.ko] undefined!
* Warning: "tcf_exts_dump_stats" [net/sched/cls_u32.ko] undefined!
* Warning: "tcf_exts_change" [net/sched/cls_u32.ko] undefined!
* Warning: "tcf_exts_validate" [net/sched/cls_u32.ko] undefined!
* Warning: "tcf_exts_destroy" [net/sched/cls_u32.ko] undefined!

modprobe...

cls_u32: Unknown symbol unregister_tcf_proto_ops
cls_u32: Unknown symbol tcf_exts_destroy
cls_u32: Unknown symbol tcf_exts_change
cls_u32: Unknown symbol tcf_exts_dump
cls_u32: Unknown symbol tcf_exts_dump_stats
cls_u32: Unknown symbol register_tcf_proto_ops
cls_u32: Unknown symbol tcf_exts_validate
cls_u32: Unknown symbol unregister_tcf_proto_ops
cls_u32: Unknown symbol tcf_exts_destroy
cls_u32: Unknown symbol tcf_exts_change
cls_u32: Unknown symbol tcf_exts_dump
cls_u32: Unknown symbol tcf_exts_dump_stats
cls_u32: Unknown symbol register_tcf_proto_ops
cls_u32: Unknown symbol tcf_exts_validate

when i disabled CONFIG_NET_CLS_U32, everything compiles fine, but
cls_u32 is missing of course :-(

all the missing symbols seem to be defined in include/net/pkt_cls.h. but
this file is #included by net/sched/cls_u32.c and other too, so i
don't really know, why it doesn't work.

FWIW, i see EXPORT_SYMBOLs at the very end of net/sched/cls_api.c, but i
can't see if/when cls_api.c is used (included?) at all.

undoing the PKT_SCHED patch [1] does not really help. the config-file is
a bit different due to CONFIG_NET_QOS, the errors don't go away.

.config, .config.diff, dmesg, verbose output and more is here:
http://nerdbynature.de/bits/sheep/2.6.15-rc1/

thanks for looking into that,
Christian.

[1] http://lkml.org/lkml/2005/11/1/141
--
BOFH excuse #245:

The Borg tried to assimilate your system. Resistance is futile.


2005-11-16 23:58:14

by Adrian Bunk

[permalink] [raw]
Subject: Re: 2.6.15-rc1: NET_CLS_U32 not working?

On Thu, Nov 17, 2005 at 12:10:17AM +0100, Christian wrote:
> hi,
>
> i noticed that some of my QoS rules are not working any more. oh, i
> forgot to enable CONFIG_NET_CLS_U32. but when enabled, i got the
> following errors when compiling / installing the module:
>
> * Warning: "unregister_tcf_proto_ops" [net/sched/cls_u32.ko] undefined!
> * Warning: "register_tcf_proto_ops" [net/sched/cls_u32.ko] undefined!
> * Warning: "tcf_exts_dump" [net/sched/cls_u32.ko] undefined!
> * Warning: "tcf_exts_dump_stats" [net/sched/cls_u32.ko] undefined!
> * Warning: "tcf_exts_change" [net/sched/cls_u32.ko] undefined!
> * Warning: "tcf_exts_validate" [net/sched/cls_u32.ko] undefined!
> * Warning: "tcf_exts_destroy" [net/sched/cls_u32.ko] undefined!
>...
> when i disabled CONFIG_NET_CLS_U32, everything compiles fine, but
> cls_u32 is missing of course :-(
>
> all the missing symbols seem to be defined in include/net/pkt_cls.h. but
> this file is #included by net/sched/cls_u32.c and other too, so i
> don't really know, why it doesn't work.
>
> FWIW, i see EXPORT_SYMBOLs at the very end of net/sched/cls_api.c, but i
> can't see if/when cls_api.c is used (included?) at all.
>...


I'm assuming you are trying to insert the new module in your old kernel?

This is one of the unfortunate but hardly avoidable cases where adding a
module requires installing a new kernel.


But there's a change in 2.6.15-rc1 that makes this issue much worse:
It is no longer user-visible.

tristate's select'ing bool's that do not change parts of the (modular)
driver but compile additional code into the kernel are simply wrong.


> thanks for looking into that,
> Christian.
>...


cu
Adrian

BTW: Please Cc [email protected] on networking issues.

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2005-11-17 00:07:53

by Christian Kujau

[permalink] [raw]
Subject: Re: 2.6.15-rc1: NET_CLS_U32 not working?

Adrian Bunk schrieb:
>
> I'm assuming you are trying to insert the new module in your old kernel?

yes, i tried to "modprobe" the compiled cls_u32 module. but the "make
modules" errors are there anyway. i tried to compile a fresh 2.6.15-rc1
on a different machine (where i can't do "modprobe") and the errors were
there too: http://nerdbynature.de/bits/sheep/2.6.15-rc1/make-modules.log

> This is one of the unfortunate but hardly avoidable cases where adding a
> module requires installing a new kernel.

despite of the errors on "make modules" i'll reboot with the "new"
kernel asap.

> BTW: Please Cc [email protected] on networking issues.

ok, will do that.


thank you,
Christian.
--
BOFH excuse #442:

Trojan horse ran out of hay

2005-11-17 15:58:26

by Christian Kujau

[permalink] [raw]
Subject: Re: 2.6.15-rc1: NET_CLS_U32 not working?

Christian schrieb:
> Adrian Bunk schrieb:
>>
>> I'm assuming you are trying to insert the new module in your old kernel?

yes, rebuilding the whole kernel (after just enabling NET_CLS_U32 as a
module) makes the warnings go away.

>> This is one of the unfortunate but hardly avoidable cases where adding
>> a module requires installing a new kernel.

i wonder why/if this is really needed. although not critical, this
behaviour is pretty annoying....

thanks,
Christian.
--
BOFH excuse #24:

network packets travelling uphill (use a carrier pigeon)

2005-11-21 15:59:57

by Adrian Bunk

[permalink] [raw]
Subject: [2.6 patch] do not select NET_CLS

>...
> But there's a change in 2.6.15-rc1 that makes this issue much worse:
> It is no longer user-visible.
>
> tristate's select'ing bool's that do not change parts of the (modular)
> driver but compile additional code into the kernel are simply wrong.

The patch below (should apply against 2.6.15-rc2) fixes this issue.

cu
Adrian


<-- snip -->


2.6.15-rc changes NET_CLS to being automatically select'ed when needed.

This patch confuses users since NET_CLS is a bool, and compiling an
additional module that select's NET_CLS causes unresolved symbols since
it's not user-visible that adding a module changes the kernel image.

This patch therefore changes NET_CLS back to the 2.6.14 status quo of
being an user-visible option.


Signed-off-by: Adrian Bunk <[email protected]>

---

net/sched/Kconfig | 25 ++++++++++++++++---------
1 file changed, 16 insertions(+), 9 deletions(-)

--- linux-2.6.15-rc1-mm2-full/net/sched/Kconfig.old 2005-11-21 16:39:04.000000000 +0100
+++ linux-2.6.15-rc1-mm2-full/net/sched/Kconfig 2005-11-21 16:41:59.000000000 +0100
@@ -254,11 +254,23 @@
comment "Classification"

config NET_CLS
- boolean
+ bool "Packet classifier API"
+ help
+ The CBQ scheduling algorithm requires that network packets which are
+ scheduled to be sent out over a network device be classified
+ according to some criterion. If you say Y here, you will get a
+ choice of several different packet classifiers with the following
+ questions.
+
+ This will enable you to use Differentiated Services (diffserv) and
+ Resource Reservation Protocol (RSVP) on your Linux router.
+ Documentation and software is at
+ <http://diffserv.sourceforge.net/>.
+
+if NET_CLS

config NET_CLS_BASIC
tristate "Elementary classification (BASIC)"
- select NET_CLS
---help---
Say Y here if you want to be able to classify packets using
only extended matches and actions.
@@ -268,7 +280,6 @@

config NET_CLS_TCINDEX
tristate "Traffic-Control Index (TCINDEX)"
- select NET_CLS
---help---
Say Y here if you want to be able to classify packets based on
traffic control indices. You will want this feature if you want
@@ -280,7 +291,6 @@
config NET_CLS_ROUTE4
tristate "Routing decision (ROUTE)"
select NET_CLS_ROUTE
- select NET_CLS
---help---
If you say Y here, you will be able to classify packets
according to the route table entry they matched.
@@ -293,7 +303,6 @@

config NET_CLS_FW
tristate "Netfilter mark (FW)"
- select NET_CLS
---help---
If you say Y here, you will be able to classify packets
according to netfilter/firewall marks.
@@ -303,7 +312,6 @@

config NET_CLS_U32
tristate "Universal 32bit comparisons w/ hashing (U32)"
- select NET_CLS
---help---
Say Y here to be able to classify packetes using a universal
32bit pieces based comparison scheme.
@@ -326,7 +334,6 @@

config NET_CLS_RSVP
tristate "IPv4 Resource Reservation Protocol (RSVP)"
- select NET_CLS
select NET_ESTIMATOR
---help---
The Resource Reservation Protocol (RSVP) permits end systems to
@@ -341,7 +348,6 @@

config NET_CLS_RSVP6
tristate "IPv6 Resource Reservation Protocol (RSVP6)"
- select NET_CLS
select NET_ESTIMATOR
---help---
The Resource Reservation Protocol (RSVP) permits end systems to
@@ -356,7 +362,6 @@

config NET_EMATCH
bool "Extended Matches"
- select NET_CLS
---help---
Say Y here if you want to use extended matches on top of classifiers
and select the extended matches below.
@@ -541,6 +546,8 @@
automaticaly selected if needed but can be selected manually for
statstical purposes.

+endif # NET_CLS
+
endif # NET_SCHED

endmenu

2005-11-21 16:16:43

by Patrick McHardy

[permalink] [raw]
Subject: Re: [2.6 patch] do not select NET_CLS

Adrian Bunk wrote:
> 2.6.15-rc changes NET_CLS to being automatically select'ed when needed.
>
> This patch confuses users since NET_CLS is a bool, and compiling an
> additional module that select's NET_CLS causes unresolved symbols since
> it's not user-visible that adding a module changes the kernel image.
>
> This patch therefore changes NET_CLS back to the 2.6.14 status quo of
> being an user-visible option.

I disagree with this patch. NET_CLS enables the infrastructure support
for classifiers. Users generally don't care about infrastructure but
directly usable things, so I'd prefer to have it automatically selected.
And there are lots of other cases where enabling a module causes changes
in the kernel image. Some examples include some of the netfilter stuff,
the IPsec transforms, NET_CLS_ROUTE4, the ieee80211 stuff, and a lot
more.

2005-11-22 22:37:14

by David Miller

[permalink] [raw]
Subject: Re: [2.6 patch] do not select NET_CLS

From: Patrick McHardy <[email protected]>
Date: Mon, 21 Nov 2005 17:16:18 +0100

> Adrian Bunk wrote:
> > This patch therefore changes NET_CLS back to the 2.6.14 status quo of
> > being an user-visible option.
>
> I disagree with this patch. NET_CLS enables the infrastructure support
> for classifiers. Users generally don't care about infrastructure but
> directly usable things, so I'd prefer to have it automatically selected.
> And there are lots of other cases where enabling a module causes changes
> in the kernel image. Some examples include some of the netfilter stuff,
> the IPsec transforms, NET_CLS_ROUTE4, the ieee80211 stuff, and a lot
> more.

I agree with Patrick.

Changing config options of any kind can result in the main kernel
image needing to be rebuilt. One thing we can do to prevent human
mistakes, is to make the "make modules" pass do a quick "is vmlinux
uptodate?" check, and if not print out an error message explaining the
situation and aborting the "make modules" attempt.

2005-11-22 22:49:08

by Sam Ravnborg

[permalink] [raw]
Subject: Re: [2.6 patch] do not select NET_CLS

On Tue, Nov 22, 2005 at 02:37:13PM -0800, David S. Miller wrote:
>
> One thing we can do to prevent human
> mistakes, is to make the "make modules" pass do a quick "is vmlinux
> uptodate?" check, and if not print out an error message explaining the
> situation and aborting the "make modules" attempt.


I do not quite follow you here.

For a while I have considered implementing something that told why a
given file was compiled - like:

CC net/ipv4/ip_gre.o due to net/dsfield.h, net/xfrm.h
CC net/ipv4/raw.c due to include/config/ip/mroute.h

The latter is a config option that I do not see a possibility to change
back to a config option syntax (at least not without doing some effort).

My thinking was that 'make V=2' would give above printout.

But what you request is something that keep the dense printout without
building the kernel - right?

Any suggestion for an intuitive syntax to enable that?
'make -n V=2' will not do it.

Sam

2005-11-22 23:00:23

by David Miller

[permalink] [raw]
Subject: Re: [2.6 patch] do not select NET_CLS

From: Sam Ravnborg <[email protected]>
Date: Tue, 22 Nov 2005 23:49:14 +0100

> On Tue, Nov 22, 2005 at 02:37:13PM -0800, David S. Miller wrote:
> >
> > One thing we can do to prevent human
> > mistakes, is to make the "make modules" pass do a quick "is vmlinux
> > uptodate?" check, and if not print out an error message explaining the
> > situation and aborting the "make modules" attempt.
>
> I do not quite follow you here.

If the user tries to do a "make modules" without first rebuilding
their kernel image, then the make will fail if the dependencies
are not satisfied for the main kernel image and it is thus not
up to date.

2005-11-22 23:12:42

by Adrian Bunk

[permalink] [raw]
Subject: Re: [2.6 patch] do not select NET_CLS

On Tue, Nov 22, 2005 at 02:37:13PM -0800, David S. Miller wrote:
>...
> Changing config options of any kind can result in the main kernel
> image needing to be rebuilt. One thing we can do to prevent human
> mistakes, is to make the "make modules" pass do a quick "is vmlinux
> uptodate?" check, and if not print out an error message explaining the
> situation and aborting the "make modules" attempt.

This won't work with CONFIG_IKCONFIG=y.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2005-11-23 05:57:27

by Sam Ravnborg

[permalink] [raw]
Subject: Re: [2.6 patch] do not select NET_CLS

On Tue, Nov 22, 2005 at 03:00:41PM -0800, David S. Miller wrote:
> From: Sam Ravnborg <[email protected]>
> Date: Tue, 22 Nov 2005 23:49:14 +0100
>
> > On Tue, Nov 22, 2005 at 02:37:13PM -0800, David S. Miller wrote:
> > >
> > > One thing we can do to prevent human
> > > mistakes, is to make the "make modules" pass do a quick "is vmlinux
> > > uptodate?" check, and if not print out an error message explaining the
> > > situation and aborting the "make modules" attempt.
> >
> > I do not quite follow you here.
>
> If the user tries to do a "make modules" without first rebuilding
> their kernel image, then the make will fail if the dependencies
> are not satisfied for the main kernel image and it is thus not
> up to date.

OK - so a simple 'make -q vmlinux' check, except that the way we utilise
make will let it fail at first build command.
That will obscufate things even more in kbuild - but I will give it a
try sometime. It will be easy to cover 95% but to reach 100%
predictability will be though.
- file dependencies is easy
- command line changes is relatively easy
- but the various scripts and user commands will be tricky..

Not on the top of the TODO list though.

Sam

2005-11-23 10:26:51

by Thomas Graf

[permalink] [raw]
Subject: Re: [2.6 patch] do not select NET_CLS

* David S. Miller <[email protected]> 2005-11-22 14:37
> From: Patrick McHardy <[email protected]>
> Date: Mon, 21 Nov 2005 17:16:18 +0100
>
> > Adrian Bunk wrote:
> > > This patch therefore changes NET_CLS back to the 2.6.14 status quo of
> > > being an user-visible option.
> >
> > I disagree with this patch. NET_CLS enables the infrastructure support
> > for classifiers. Users generally don't care about infrastructure but
> > directly usable things, so I'd prefer to have it automatically selected.
> > And there are lots of other cases where enabling a module causes changes
> > in the kernel image. Some examples include some of the netfilter stuff,
> > the IPsec transforms, NET_CLS_ROUTE4, the ieee80211 stuff, and a lot
> > more.
>
> I agree with Patrick.

In fact Patrick's explanation was exactly the motivation for me to
change it in the first place a few weeks back.

I thought about making cls_api aware to be built as module but then
the same would apply for ematches and the generic scheduling code
and it gets real complicated. It is possible with some heavy code
shuffling but not worth it I think.

2005-11-24 02:13:04

by Randy Dunlap

[permalink] [raw]
Subject: Re: [2.6 patch] do not select NET_CLS

On Wed, 23 Nov 2005 06:57:35 +0100 Sam Ravnborg wrote:

> On Tue, Nov 22, 2005 at 03:00:41PM -0800, David S. Miller wrote:
> > From: Sam Ravnborg <[email protected]>
> > Date: Tue, 22 Nov 2005 23:49:14 +0100
> >
> > > On Tue, Nov 22, 2005 at 02:37:13PM -0800, David S. Miller wrote:
> > > >
> > > > One thing we can do to prevent human
> > > > mistakes, is to make the "make modules" pass do a quick "is vmlinux
> > > > uptodate?" check, and if not print out an error message explaining the
> > > > situation and aborting the "make modules" attempt.
> > >
> > > I do not quite follow you here.
> >
> > If the user tries to do a "make modules" without first rebuilding
> > their kernel image, then the make will fail if the dependencies
> > are not satisfied for the main kernel image and it is thus not
> > up to date.
>
> OK - so a simple 'make -q vmlinux' check, except that the way we utilise
> make will let it fail at first build command.
> That will obscufate things even more in kbuild - but I will give it a
> try sometime. It will be easy to cover 95% but to reach 100%
> predictability will be though.
> - file dependencies is easy
> - command line changes is relatively easy
> - but the various scripts and user commands will be tricky..
>
> Not on the top of the TODO list though.

So -q means "quick" ?

I wouldn't mind seeing a -quiet (even less quiet than V=0),
not even printing the CC, AS, LD, etc. commands -- just let the
tools print errors & warnings. I always redirect output to a
disk file and filter it for errors and warnings anyway, so I
want hold my breath for this, but ISTM that V=0 could be even
quieter than it is right now.

---
~Randy

2005-11-24 05:40:05

by Sam Ravnborg

[permalink] [raw]
Subject: Re: [2.6 patch] do not select NET_CLS

On Wed, Nov 23, 2005 at 06:13:32PM -0800, Randy.Dunlap wrote:
>
> So -q means "quick" ?
>From make help:
-q, --question Run no commands; exit status says if up to date

> I wouldn't mind seeing a -quiet (even less quiet than V=0),
> not even printing the CC, AS, LD, etc. commands -- just let the
> tools print errors & warnings. I always redirect output to a
> disk file and filter it for errors and warnings anyway, so I
> want hold my breath for this, but ISTM that V=0 could be even
> quieter than it is right now.

make -s shuld give you this. I've not used it for long though...

Sam