netdev - Re: [patch net-next RFC v2 03/11] devlink: Add support for 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: <80b9f559-54f1-6a20-0133-a0a6b5064296@mellanox.com>
Date:   Wed, 15 Nov 2017 13:33:17 +0200
From:   Arkadi Sharshevsky <arkadis@...lanox.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Jiri Pirko <jiri@...nulli.us>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, mlxsw@...lanox.com,
        andrew@...n.ch, vivien.didelot@...oirfairelinux.com,
        f.fainelli@...il.com, michael.chan@...adcom.com,
        ganeshgr@...lsio.com, saeedm@...lanox.com, matanb@...lanox.com,
        leonro@...lanox.com, idosch@...lanox.com, ast@...nel.org,
        daniel@...earbox.net, simon.horman@...ronome.com,
        pieter.jansenvanvuuren@...ronome.com, john.hurley@...ronome.com,
        alexander.h.duyck@...el.com, linville@...driver.com,
        gospo@...adcom.com, steven.lin1@...adcom.com, yuvalm@...lanox.com,
        ogerlitz@...lanox.com, dsa@...ulusnetworks.com,
        roopa@...ulusnetworks.com
Subject: Re: [patch net-next RFC v2 03/11] devlink: Add support for reload



On 11/15/2017 10:03 AM, Jakub Kicinski wrote:
> On Tue, 14 Nov 2017 17:18:44 +0100, Jiri Pirko wrote:
>> +static int devlink_nl_cmd_reload(struct sk_buff *skb, struct genl_info *info)
>> +{
>> +	struct devlink *devlink = info->user_ptr[0];
>> +	int err;
>> +
>> +	if (!devlink->ops->reload)
>> +		return -EOPNOTSUPP;
>> +
>> +	err = devlink_resources_validate(devlink, NULL, info);
>> +	if (err)
>> +		return err;
>> +
>> +	mutex_unlock(&devlink->lock);
>> +	err = devlink->ops->reload(devlink);
>> +	mutex_lock(&devlink->lock);
>> +
>> +	return err;
>> +}
> 
> I'm a bit confused with the locking, why is devlink->lock not held
> around the validation?
> 

As Jiri mentioned it is held. The per devlink instance lock is taken
by default for each doit operation in the pre_doit(), because it operates
on a specific devlink instance.

The lock is released before performing the reload itself because during
the reload the driver register/unregisters devlink objects like sb/dpipe
/ports, which require the lock again, so this is done in order to avoid
recursive locking.