netdev - Re: [PATCH v3] net: #ifdef inet_bind_bucket::ib

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <491D0482.1030706@cosmosbay.com>
Date:	Fri, 14 Nov 2008 05:54:26 +0100
From:	Eric Dumazet <dada1@...mosbay.com>
To:	David Miller <davem@...emloft.net>
CC:	adobriyan@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH v3] net: #ifdef inet_bind_bucket::ib_net

David Miller a écrit :
> From: Eric Dumazet <dada1@...mosbay.com>
> Date: Fri, 14 Nov 2008 05:36:15 +0100
> 
>> This is better because :
>>
>> 1) No #ifdef CONFIG_NET_NS
>>
>> 2) The magic about &init_net is not duplicated in ten different include files, but
>>    centralized in the right file : include/net/net_namespace.h
> 
> I %100 agree.

Speaking of those functions, what do you think of this one ?

static inline
void dev_net_set(struct net_device *dev, struct net *net)
{
#ifdef CONFIG_NET_NS
        release_net(dev->nd_net);
        dev->nd_net = hold_net(net);
#endif
}

I believe that its safer to hold a reference on "new" *before*
releasing reference on "old" object.

Also, release_net() and hold_net() can be defined to do
the use_count refcounting regardless of CONFIG_NET_NS
(Its a different NETNS_REFCNT_DEBUG #ifdef)

Yet another example where read_pnet() and write_pnet()
are the right answer : Its cleaner and fixes *bugs*.

static inline
void dev_net_set(struct net_device *dev, struct net *net)
{
	hold_net(net);
	release_net(read_pnet(&dev->nd_net);
        write_pnet(&dev->nd_net, net);
}


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