netdev - Re: [patch net-next v3 11/15] netdevsim: implement proper devlink reload

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: <20191004204944.GC2247@nanopsycho>
Date:   Fri, 4 Oct 2019 22:49:44 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, idosch@...lanox.com,
        dsahern@...il.com, tariqt@...lanox.com, saeedm@...lanox.com,
        kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org, shuah@...nel.org,
        mlxsw@...lanox.com
Subject: Re: [patch net-next v3 11/15] netdevsim: implement proper devlink
 reload

Fri, Oct 04, 2019 at 07:42:17PM CEST, jakub.kicinski@...ronome.com wrote:
>On Fri, 4 Oct 2019 08:19:14 +0200, Jiri Pirko wrote:
>> >> @@ -84,20 +82,10 @@ int nsim_fib_set_max(struct nsim_fib_data *fib_data,
>> >>  		entry = &fib_data->ipv6.rules;
>> >>  		break;
>> >>  	default:
>> >> -		return 0;
>> >> -	}
>> >> -
>> >> -	/* not allowing a new max to be less than curren occupancy
>> >> -	 * --> no means of evicting entries
>> >> -	 */
>> >> -	if (val < entry->num) {
>> >> -		NL_SET_ERR_MSG_MOD(extack, "New size is less than current occupancy");
>> >> -		err = -EINVAL;  
>> >
>> >This change in behaviour should perhaps be mentioned in the commit
>> >message. The reload will no longer fail if the resources are
>> >insufficient.   
>> 
>> Reload is going to fail if the resources are insufficient. I have a
>> selftest for that, please see the last patch.
>
>Oh, because re-registering the fib notifier itself will fail? 

Yep.


>All good then, thanks.
>
>> >Since we want to test reload more widely than just for the FIB limits
>> >that does make sense to me. Is that the thinking?