Re: Understanding mutual exclusion between rtnl_lock and rcu_read_lock

2017-02-03 Thread Joel Cunningham
> On Feb 3, 2017, at 3:40 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > > On Thu, Feb 2, 2017 at 6:05 PM, Joel Cunningham <joel.cunning...@me.com> > wrote: >> >> In the case of SIOCSIFHWADDR, we get a pointer to the net_device through

Re: Understanding mutual exclusion between rtnl_lock and rcu_read_lock

2017-02-03 Thread Joel Cunningham
> On Feb 2, 2017, at 11:21 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > > On Thu, 2017-02-02 at 15:52 -0800, Alexander Duyck wrote: >> On Thu, Feb 2, 2017 at 3:47 PM, Joel Cunningham <joel.cunning...@me.com> >> wrote: >>> Hi, >>> >

Re: Understanding mutual exclusion between rtnl_lock and rcu_read_lock

2017-02-02 Thread Joel Cunningham
> On Feb 2, 2017, at 5:52 PM, Alexander Duyck <alexander.du...@gmail.com> wrote: > > On Thu, Feb 2, 2017 at 3:47 PM, Joel Cunningham <joel.cunning...@me.com> > wrote: >> Hi, >> >> I’m studying the synchronization used on different parts of struct >

Understanding mutual exclusion between rtnl_lock and rcu_read_lock

2017-02-02 Thread Joel Cunningham
Hi, I’m studying the synchronization used on different parts of struct net_device and I’m struggling to understand how structure member modifications in dev_ioctl are synchronized. Getters in dev_ifsioc_locked() are only holding rcu_read_lock() while setters in dev_ifsioc() are holding

Re: sk_buff and reference counting netdev pointers

2017-01-25 Thread Joel Cunningham
> On Jan 23, 2017, at 5:45 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > > On Mon, Jan 23, 2017 at 2:37 PM, Joel Cunningham <joel.cunning...@me.com> > wrote: >> Hi, >> >> I’m working on a research effort to understand the synchronization >>

sk_buff and reference counting netdev pointers

2017-01-23 Thread Joel Cunningham
Hi, I’m working on a research effort to understand the synchronization mechanisms for accessing and modifying a struct net_device object. One area that isn’t clear is the net device pointer (dev) stored in a struct sk_buff. From my investigation, the pointer appears to be assigned without