linux-kernel - Re: [PATCH 0/2] ALSA: nm256: Fine-tuning for three function implementations

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:   Thu, 16 Nov 2017 18:48:43 +0100
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     Takashi Iwai <tiwai@...e.de>, alsa-devel@...a-project.org
Cc:     Arvind Yadav <arvind.yadav.cs@...il.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Sakamoto <o-takashi@...amocchi.jp>,
        kernel-janitors@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] ALSA: nm256: Fine-tuning for three function
 implementations

>> Two update suggestions were taken into account
>> from static source code analysis.
> 
> Markus, I'd apply this kind of patches only when they are really
> tested on the hardware,

I can not test all software and hardware combinations (so far)
for which I dare to show change possibilities.

> or they were converted systematically by a script like spatch.

There is a general source code transformation pattern involved.
So I find that it is systematic.

But I did not dare to develop a script variant for the semantic patch
language (Coccinelle software) which can handle all special use cases
as a few of them are already demonstrated in this tiny patch series.

> The reason is that you might break something

There are the usual software development risks.

> (and you already broke things in the past).

I presented also some improvable update suggestions.

Another look on the corresponding circumstances might be interesting
for further clarification.

> The merit by such a patch is negligible in comparison of the risk of breakage.

I imagine that you might like a small object code reduction also for
this software module.

> These codes aren't too bad without fixing, after all;
> everyone can read it pretty well as is.

The script "checkpatch.pl" points implementation details out for
further considerations.

> If these patches were tested on a real hardware,

I assume that this aspect can become a big challenge.

> or at least on VM, so that you can show that they don't break anything,

Which test results would you trust (from me)?

> I'll happily apply them for the next (4.16) kernel.

Thanks for your general offer.

> Or, if you're really working on other real changes

I would find a bit more efficient exception handling useful.

> (no cosmetic coding style fixes nor the code shuffling,

I propose to apply also corresponding checkpatch cosmetic.

> but fixing a real bug)

I am trying to adjust the software situation a bit more for better
run time characteristics.

> *and* such a cleanup is mandatory as preliminary, it can be accepted, too.

There are change combinations needed for the proposed software
design direction.
Can you see positive effects here?

Regards,
Markus