[Top] [All Lists]

Re: request_module while holding rtnl semaphore

To: Patrick McHardy <kaber@xxxxxxxxx>
Subject: Re: request_module while holding rtnl semaphore
From: Thomas Graf <tgraf@xxxxxxx>
Date: Wed, 10 Nov 2004 02:22:51 +0100
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <41916A91.3080107@xxxxxxxxx>
References: <41899DCF.3050804@xxxxxxxxx> <E1CQDcP-0003ff-00@xxxxxxxxxxxxxxxxxxxxxxxx> <20041109161126.376f755c.davem@xxxxxxxxxxxxx> <20041110010113.GJ31969@xxxxxxxxxxxxxx> <41916A91.3080107@xxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
* Patrick McHardy <41916A91.3080107@xxxxxxxxx> 2004-11-10 02:10
> Thomas Graf wrote:
> >Sounds reasonable for the sch_api.c and cls_api.c case but
> >will get very nasty for act_api as you noted and any further sub
> >layers that might be added in the future. (The classifier I'm
> >working on is such a case.)
> >
> Can you please show an example of a case where this is needed ?
> Just to help me understand.

The action code might load modules in the middle of a classifier
configuration and it will be very hard to reverse those changes.
Right now we could move it to the top of all configurations and it
would probably be possible to get back where we fetch the device
but it will get impossible once a classifier requires module
loading which is not unlikely.

Well, it's not impossible but it would mean to have the action
code parse the TLV and just try to load the module, then report
to the classifier so it can try to load its own modules and then do
the actual action and classifier configuration. I don't even want to
think of how nasty it gets once a action module requests modules itself ;->

<Prev in Thread] Current Thread [Next in Thread>