[PATCH v3 7/7] nvme-fabrics: Add FC LLDD loopback driver to test FC-NVME
James Smart
james.smart at broadcom.com
Wed Nov 2 13:51:39 PDT 2016
On 10/26/2016 1:00 PM, J Freyensee wrote:
>
> Nitpick- looks odd to use a pointer variable instead of *newnport for
> the sizeof parameter, especially when that is the way '*opts' is done a
> few lines above it.
yep - resolved.
> ...
>> + goto out_free_opts;
> It looks like if we ever get here, we will leak memory as newnport has
> been kzalloc'ed at this point but this will jump to the "out_free_opts"
> goto statement.
yes - fixed.
>
>> +static ssize_t
>> +fcloop_create_remote_port(struct device *dev, struct
>> device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct nvme_fc_remote_port *remoteport;
>> + struct fcloop_nport *nport;
>> + struct fcloop_rport *rport;
>> + struct nvme_fc_port_info pinfo;
>> + int ret;
>> +
>> + nport = fcloop_alloc_nport(buf, count, true);
>> + if (!nport)
>> + return -EIO;
>> +
>> + pinfo.node_name = nport->node_name;
>> + pinfo.port_name = nport->port_name;
>> + pinfo.port_role = nport->port_role;
>> + pinfo.port_id = nport->port_id;
>> +
>> + ret = nvme_fc_register_remoteport(nport->lport->localport,
>> + &pinfo,
>> &remoteport);
>> + if (ret || !remoteport) {
>> + fcloop_nport_put(nport);
>> + return ret;
> Possible memory leak for nport??
Nope. the alloc_nport() takes a reference (either allocation, or sharing
it with a targetport). Thus, the put releases it. If last reference,
it's freed.
>
>> +
>> +static ssize_t
>> +fcloop_create_target_port(struct device *dev, struct
>> device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> +...
> Possible memory leak by not de-allocating 'nport'?
Nope: same answer as last. The ref counting will manage it.
Thanks
-- james
More information about the Linux-nvme
mailing list