Em Thu, May 01, 2003 at 04:09:35AM -0700, David S. Miller escreveu:
> From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
> Date: Thu, 01 May 2003 22:01:19 +1000
>
> There are 70 calls to dev_hold() in the kernel. The vast majority of
> them already have a reference, they just want another one: dev_hold()
> can do __module_get().
>
> Rusty, this is precisely the what Alexey and myself want to avoid. On
> the surface, it looks fine, only 70 dev_get's in the kernel right?
> But think further...
>
> So you propose to add this kind of thing for every ARP entry, every
> route cache entry, every IPSEC policy, every socket, every struct
> sock, every networking dynamic object ever created?
ALERT: brainstorming and expecting for comments from the people who knows this
better.
Well, I think that because there are a graph of relationships here we perhaps
can be safe by protecting just some of the higher level objects (e.g. struct
sock, struct socket, struct net_device) while leaving some other lower level
objects managed by those higher level ones, e.g. struct sk_buff managed by
struct sock.
This came to me while discussing the struct socket and struct sock module
infrastructure with Max, specifically when net family modules (e.g. AF_INET)
doesn't requires protecting for each and every struct socket created, as the
protocol modules (e.g.: udp, raw, tcp) have to somehow register with the net
family module and by just using one exported function (register_protocol type
functions: register_pppox_proto, bt_sock_register, register_8022_client,
register_snap_client, llc_sap_open, etc) makes the net family module/lower
level protocol protected.
So we need to have a graph of these relationships to see what we have to
protect at a higher level, reducing the overhead of otherwise having to call
try_module_get/__module_get & module_put on _all_ objects creation/use.
- Arnaldo
|