[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1440512689.8932.9.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Tue, 25 Aug 2015 07:24:49 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: "Zhangjie (HZ)" <zhangjie14@...wei.com>
Cc: Jason Wang <jasowang@...hat.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Qinchuanyu <qinchuanyu@...wei.com>, Yewudi <yewudi@...wei.com>,
liuyongan 00175866 <l00175866@...esmail.huawei.com.cn>,
Wangbicheng <wangbicheng@...wei.com>,
Yan Chen <Y.Chen@...wei.com>
Subject: Re: [Question] Usage of dev_hold()/dev_put()
On Tue, 2015-08-25 at 08:28 +0000, Zhangjie (HZ) wrote:
> Hi,
>
> The comment of function dev_hold() and dev_put() are really simple.
>
> Actually, I can’t find a rule to follow.
>
> Where should I call dev_hold()/dev_put()?
>
> Are they necessary during xmit or receive or only in register/release?
>
> I find that, for tap, it calls dev_hold()/dev_put() for every
> tun_sendmsg/tun_recvmsg:
>
> So, should I call dev_hold()/dev_put() for each quote, such like:
> “skb->dev = dev” ?
>
> But, for physical nic, I can’t find dev_hold()/dev_put() during xmit
> or receive.
>
> What kind of scene is it necessary to call dev_hold()/dev_put()?
>
>
>
> Look forward for your feedback.
>
> Thank you ! J
>
> Zhangjie
>
>
Please do not send HTML mails, otherwise they do not reach netdev
mailing list
In general, you need to use dev_hold() for every reference on 'dev'
stored in the object.
However they are some paths were you do not need that : For example in
transmit path, skb are stored either in a qdisc or device driver
internal queue/ring. At device dismantle we properly delete all these
skb, so we do not have to worry about used dev_hold()/dev_put() in
transmit.
In drivers/net/tun.c, the dev_hold()/dev_put() only is required so that
device doesnt disappear between tun_get() and actual use of it after a
potentially long copy from user space (that might trigger page faults)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists