linux-kernel - Re: [PATCH] [v3] drm: amd: dc: don't use FP math when Kcov is enabled

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:   Thu, 16 Aug 2018 23:01:09 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     sunpeng.li@....com
Cc:     Alex Deucher <alexander.deucher@....com>,
        Christian König <christian.koenig@....com>,
        "David (ChunMing) Zhou" <David1.Zhou@....com>,
        David Airlie <airlied@...ux.ie>, michel.daenzer@....com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        amd-gfx@...ts.freedesktop.org, Shirish S <shirish.s@....com>,
        Jerry.Zuo@....com, dri-devel <dri-devel@...ts.freedesktop.org>,
        Jordan Lazare <Jordan.Lazare@....com>,
        Harry Wentland <harry.wentland@....com>
Subject: Re: [PATCH] [v3] drm: amd: dc: don't use FP math when Kcov is enabled

On Thu, Aug 16, 2018 at 9:56 PM Leo Li <sunpeng.li@....com> wrote:
> On 2018-08-11 11:54 AM, Arnd Bergmann wrote:
> >
> > I tried implementing the two functions in KCOV: __sanitizer_cov_trace_cmpd
> > and __sanitizer_cov_trace_cmpf, but that fails to build on architectures
> > that do not support any floating-point functions, or would require making
> > that code x86 specific as well.  I also looked at what it would take to
>
> Hi Arnd,
>
> Is there a reason why we can't make __sanitizer_cov_trace_cmpd and
> __sanitizer_cov_trace_cmpf X86 dependent?
>
> I sent out two patches to disable DCN1, but would prefer implementing
> these two functions as opposed to disabling a component.

I think it should be possible to implement them, perhaps not even hard
to do it in an architecture independent way. I tried this at some point
and couldn't figure it out, but I suppose it would fix the problem nicely.

This would assume that the two functions can only ever be called
from a context that already has access to the fpu, which I think is
the case here.

         Arnd