Skip to contentSkip to conversation

2.6.15-rc1: NET_CLS_U32 not working?

PATCH In review Christian 7 participants 14 messages Nov 16, 2005 – Nov 24, 2005

Subsystems (3)
lore
Share & tools
lore

Christian

author
#0 lore raw

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

Signature · 3 lines
BOFH excuse #245:

The Borg tried to assimilate your system. Resistance is futile.
#1 lore raw
Quoted 17 lines · Christian

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 :-(

Quoted 7 lines

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.

Quoted 3 lines

thanks for looking into that,
Christian.
...

cu
Adrian

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

Signature · 4 lines
       "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
author
#2 lore raw
Quoted 2 lines · Adrian Bunk

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

Quoted 1 line

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.

Quoted 1 line

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

ok, will do that.

thank you,
Christian.

Signature · 3 lines
BOFH excuse #442:

Trojan horse ran out of hay
author
#3 lore raw
Quoted 3 lines · Christian
Quoted 2 lines · Adrian Bunk

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.

Quoted 1 line
Quoted 1 line

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.

Signature · 3 lines
BOFH excuse #24:

network packets travelling uphill (use a carrier pigeon)
#4 lore raw

PATCH 1/1 do not select NET_CLS

In reply to Adrian Bunk
Quoted 6 lines

...
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.

---

 net/sched/Kconfig |   25 ++++++++++++++++---------
 1 file changed, 16 insertions(+), 9 deletions(-)
net/sched/Kconfig renamed from net/sched/Kconfig.old +16 -9
@@ -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
#5 lore raw

Re: [2.6 patch] do not select NET_CLS

Quoted 5 lines · Adrian Bunk

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.

maintainer
#6 lore raw

Re: [2.6 patch] do not select NET_CLS

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

Quoted 11 lines
Quoted 2 lines · Adrian Bunk

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.

#7 lore raw

Re: [2.6 patch] do not select NET_CLS

Quoted 5 lines · David S. Miller

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

maintainer
#8 lore raw

Re: [2.6 patch] do not select NET_CLS

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

Quoted 8 lines · David S. Miller
Quoted 5 lines

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.

#9 lore raw

Re: [2.6 patch] do not select NET_CLS

Quoted 10 lines · David S. Miller

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

Quoted 7 lines · David S. Miller
Quoted 5 lines

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.

Quoted 6 lines
Quoted 1 line

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

#10 lore raw

Re: [2.6 patch] do not select NET_CLS

Quoted 27 lines · On Wed, 23 Nov 2005 06:57:35 +0100 Sam Ravnborg wrote:
Quoted 10 lines · David S. Miller

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

Quoted 7 lines · David S. Miller
Quoted 5 lines

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.

Quoted 6 lines
Quoted 1 line

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..

Quoted 1 line

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

#11 lore raw

Re: [2.6 patch] do not select NET_CLS

Quoted 3 lines · Randy.Dunlap

So -q means "quick" ?
From make help:

-q, --question Run no commands; exit status says if up to date

Quoted 6 lines

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

#12 lore raw

Re: [2.6 patch] do not select NET_CLS

In reply to David S. Miller
Quoted 6 lines · David S. Miller

...
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

Signature · 4 lines
       "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
#13 lore raw

Re: [2.6 patch] do not select NET_CLS

In reply to David S. Miller

* David S. Miller <[email protected]> 2005-11-22 14:37

Quoted 15 lines

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

Quoted 11 lines
Quoted 2 lines · Adrian Bunk

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.

Quoted 1 line

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.