linux-kernel - Re: [PATCH 03/17] fpga: dfl: fme: support 512bit data width PR

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <29827fcdcdd4fb46b680a6bd184b44fca638666e.camel@redhat.com>
Date:   Wed, 27 Mar 2019 01:10:31 -0500
From:   Scott Wood <swood@...hat.com>
To:     Wu Hao <hao.wu@...el.com>
Cc:     Alan Tull <atull@...nel.org>, Moritz Fischer <mdf@...nel.org>,
        linux-fpga@...r.kernel.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-api@...r.kernel.org, Ananda Ravuri <ananda.ravuri@...el.com>,
        Xu Yilun <yilun.xu@...el.com>
Subject: Re: [PATCH 03/17] fpga: dfl: fme: support 512bit data width PR

On Wed, 2019-03-27 at 12:37 +0800, Wu Hao wrote:
> On Tue, Mar 26, 2019 at 04:22:34PM -0500, Scott Wood wrote:
> > On Tue, 2019-03-26 at 14:33 -0500, Alan Tull wrote:
> > > On Mon, Mar 25, 2019 at 5:58 PM Scott Wood <swood@...hat.com> wrote:
> > > > > 
> > > Hi Scott,
> > > 
> > > > On Mon, 2019-03-25 at 17:53 -0500, Scott Wood wrote:
> > > > > On Mon, 2019-03-25 at 11:07 +0800, Wu Hao wrote:
> > > > > > +#else
> > > > > > +static inline void copy512(void *src, void __iomem *dst)
> > > > > > +{
> > > > > > +   WARN_ON_ONCE(1);
> > > > > > +}
> > > > > > +#endif
> > > > > 
Likewise, this will be called if a revision 2 device is used on non-
> > > > > x86
> > > > > (or on x86 with an old binutils).  The driver should fall back to
> > > > > 32-
> > > > > bit
> > > > > in such cases.
> 
> Unfortunately revision 2 is only for integrated FPGA solution, and it
> doesn't
> support any fallback solution (original 32bit data partial reconfiguration
> is
> not supported any more), so driver has to WARN in such path.

>From the commit message it seemed like this was just an optimization, not
something necessary to support revision 2.

If there's no way to program the device without AVX512, then printing an
error message and returning an error to userspace would be better than
WARN_ON, since it's not actually a kernel bug.

-Scott