linux-kernel - Re: [QUEUED v20180920 04/16] stm class: Introduce framing protocol drivers

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] [day] [month] [year] [list]

Date:   Wed, 03 Oct 2018 16:03:59 +0300
From:   Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:     Mathieu Poirier <mathieu.poirier@...aro.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [QUEUED v20180920 04/16] stm class: Introduce framing protocol drivers

Mathieu Poirier <mathieu.poirier@...aro.org> writes:

>> +	err = stm_lookup_protocol(proto, &pdrv, &pdrv_node_type);
>>  	kfree(devname);
>>  
>> -	if (!stm)
>> +	if (err) {
>> +		stm_put_device(stm);
>>  		return ERR_PTR(-ENODEV);
>> +	}
>
> This condition prevent the subsystem from being used until patch 06/16 is added.

Good catch, I completely missed that.

> I would also suggest automatically compiling in the functionality provided by
> p_basic if p_sys-t is not selected.

That's kind of the intention; in Kconfig the PROTO_BASIC should default
to the same thing as CONFIG_STM, so it should be present unless the user
specifically interfered and disabled it.

> That way we preserve the original
> behaviour.  I would also use p_basic if no protocol driver is selected rather
> than leaving it to the insertion order to make things more
> deterministic.

Agreed, more deterministic is good.

Thanks,
--
Alex