linux-kernel - Re: vga and 64-bit memcpy's

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: <CA+55aFzqUsdjyE4ZHLyKwCm-SsV4NvFNyy7FTpROTg-J9+kZmg@mail.gmail.com>
Date:	Fri, 12 Sep 2014 08:11:07 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Airlie <airlied@...il.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: vga and 64-bit memcpy's

On Fri, Sep 12, 2014 at 3:48 AM, Dave Airlie <airlied@...il.com> wrote:
>
> Well I'm not shocked that an SMI GPU is out of spec, just not sure how
> we can workaround it.

Try just removing the

  #define scr_memcpyw(d, s, c) memcpy(d, s, c)
  #define VT_BUF_HAVE_MEMCPYW

(and perhaps MEMMOVEW case too) from the default implementation, and
see if doing things 16-bit words at a time using the fallbacks ends up
working. As Alan said, write combining might defeat that, but quite
frankly, we already do this for the MEMSETW case (probably because we
forgot, possibly because it's not as performance-sensitive)

My gut feel is that we don't care deeply about performance here,
because (a) true text-modes are less common anyway and (b) true text
modes are pretty damn fast anyway compared to the more usual "write
the whole glyph as graphics" fbcon case.

And *maybe* it works. And maybe that SMI GPU is a piece of shit that
isn't worth worrying about in VGA text-mode. Where the hell are they
found anyway?

               Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/