linux-kernel - Re: chrome-platform/for-kernelci bisection: baseline.bootrr.rockchip-dp-probed on rk3399-gru-kevin

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: <55cb5ce6-4ecb-1203-807f-c24648c0e989@collabora.com>
Date:   Thu, 9 Jul 2020 11:17:59 +0200
From:   Enric Balletbo i Serra <enric.balletbo@...labora.com>
To:     Guenter Roeck <linux@...ck-us.net>,
        "kernelci.org bot" <bot@...nelci.org>, gtucker@...labora.com,
        kernelci-results@...ups.io
Cc:     linux-kernel@...r.kernel.org, Benson Leung <bleung@...omium.org>,
        Guenter Roeck <groeck@...omium.org>
Subject: Re: chrome-platform/for-kernelci bisection:
 baseline.bootrr.rockchip-dp-probed on rk3399-gru-kevin

Hi,

On 8/7/20 22:32, Guenter Roeck wrote:
> On 7/8/20 11:59 AM, kernelci.org bot wrote:
>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>> * This automated bisection report was sent to you on the basis  *
>> * that you may be involved with the breaking commit it has      *
>> * found.  No manual investigation has been done to verify it,   *
>> * and the root cause of the problem may be somewhere else.      *
>> *                                                               *
>> * If you do send a fix, please include this trailer:            *
>> *   Reported-by: "kernelci.org bot" <bot@...nelci.org>          *
>> *                                                               *
>> * Hope this helps!                                              *
>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>
>> chrome-platform/for-kernelci bisection: baseline.bootrr.rockchip-dp-probed on rk3399-gru-kevin
>>
>> Summary:
>>   Start:      154353417996 KERNELCI: x86_64_defconfig: Enable support for Chromebooks devices
>>   Plain log:  https://storage.kernelci.org/chrome-platform/for-kernelci/v5.8-rc1-20-g154353417996/arm64/defconfig/gcc-8/lab-collabora/baseline-rk3399-gru-kevin.txt
>>   HTML log:   https://storage.kernelci.org/chrome-platform/for-kernelci/v5.8-rc1-20-g154353417996/arm64/defconfig/gcc-8/lab-collabora/baseline-rk3399-gru-kevin.html
>>   Result:     8c9a6ef40bf4 platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes
>>
>> Checks:
>>   revert:     PASS
>>   verify:     PASS
>>
>> Parameters:
>>   Tree:       chrome-platform
>>   URL:        https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
>>   Branch:     for-kernelci
>>   Target:     rk3399-gru-kevin
>>   CPU arch:   arm64
>>   Lab:        lab-collabora
>>   Compiler:   gcc-8
>>   Config:     defconfig
>>   Test case:  baseline.bootrr.rockchip-dp-probed
>>
>> Breaking commit found:
>>
>> -------------------------------------------------------------------------------
>> commit 8c9a6ef40bf400c64c9907031bd32b59f9d4aea2
>> Author: Guenter Roeck <linux@...ck-us.net>
>> Date:   Sat Jul 4 07:26:07 2020 -0700
>>
>>     platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes
>>     
>>     The EC reports a variety of error codes. Most of those, with the exception
>>     of EC_RES_INVALID_VERSION, are converted to -EPROTO. As result, the actual
>>     error code gets lost. Convert all EC errors to Linux error codes to report
>>     a more meaningful error to the caller to aid debugging.
>>     
>>     Cc: Yu-Hsuan Hsu <yuhsuan@...omium.org>
>>     Cc: Prashant Malani <pmalani@...omium.org>
>>     Signed-off-by: Guenter Roeck <linux@...ck-us.net>
>>     Signed-off-by: Enric Balletbo i Serra <enric.balletbo@...labora.com>
>>

So, as Guenter pointed I dropped this patch now.

> 
> So, just FTR, turns out that there are callers which specifically check for
> -EPROTO and examine the EC error code if it is returned, or just accept
> -EPROTO as generic failure (but nothing else). Example is drivers/pwm/pwm-cros-ec.c:
> cros_ec_num_pwms(). Such commands now fail, in this case because
> EC_RES_INVALID_PARAM is now returned as -EINVAL and cros_ec_num_pwms()
> doesn't expect that.
> 

Right, that's interesting, and I'll take in consideration for future reworks of
the above patch and also take a deeper look at those specific cases reported.

BTW, Guillaume, I queued that patch to give a try and test 3 days ago. Is the
bisection job expected to take that time to run? In this case I think it also
took some time to receive the build test, so probably is just a matter of having
lot of jobs in the queue?

I am not complaining at all, just curious, and just want to know to improve my
maintainer workflow.

Thanks,
  Enric

> drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c has a similar problem;
> it only accepts -EPROTO as "valid" error, but nothing else. I didn't check
> for others.
> 
> Guenter
>