linux-kernel - Re: [PATCH v4 4/5] s390/vfio-ap: Add write support to sysfs attr ap

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]

Date: Fri, 12 Apr 2024 08:29:44 -0400
From: "Jason J. Herne" <jjherne@...ux.ibm.com>
To: Alexander Gordeev <agordeev@...ux.ibm.com>
Cc: linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
        pasic@...ux.ibm.com, akrowiak@...ux.ibm.com, borntraeger@...ibm.com,
        gor@...ux.ibm.com, hca@...ux.ibm.com,
        Matthew Rosato <mjrosato@...ux.ibm.com>
Subject: Re: [PATCH v4 4/5] s390/vfio-ap: Add write support to sysfs attr
 ap_config

On 4/8/24 10:22 AM, Alexander Gordeev wrote:
> On Tue, Mar 26, 2024 at 12:47:05PM -0400, Jason J. Herne wrote:
> 
> Hi Jason,
> 
> This series still has some issues.
> 
>> +	newbuf = rest = kstrndup(buf, AP_CONFIG_STRLEN, GFP_KERNEL);
> 
> This line triggers a checkpatch warning. Would it make sense
> to turn it into below instead?
> 
> 	newbuf = kstrndup(buf, AP_CONFIG_STRLEN, GFP_KERNEL);
>> +	if (!newbuf)
>> +		return -ENOMEM;
> 	rest = newbuf;

Yes, I can make that change. My checkpatch.pl script does not point this
issue out with --strict. Should I be running checkpatch with --strict?

> Also, please address other checkpatch suggestions.
> 

Yep, I'll run with --strict and address everything.

>> +	/* Save old state */
>> +	/* The volatile cast here is to work around a gcc false positive
>> +	 * Wstringop-overread-warning.
>> +	 */
>> +	ap_matrix_copy(&m_old, (*(struct ap_matrix * volatile *)(&matrix_mdev->matrix)));
> 
> Could you please come up with a different workaround? This issue has already
> been resolved in the past in different ways. See commit 34186b48d29b ("ARM:
> sharpsl_param: work around -Wstringop-overread warning") for example.

Sure, I like this solution way better than using volatile. Thanks for
providing the pointer to this.