linux-kernel - Re: [PATCH 4/5] drm: ssd130x: Reduce temporary buffer sizes

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]

Message-ID: <CAMuHMdXisdGd2QWPEpi0sUMP3ZZr1S82=S9A=BSYmeYHySGemQ@mail.gmail.com>
Date:   Tue, 15 Mar 2022 15:01:23 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Javier Martinez Canillas <javierm@...hat.com>,
        Noralf Trønnes <noralf@...nnes.org>,
        DRI Development <dri-devel@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/5] drm: ssd130x: Reduce temporary buffer sizes

Hi Andy,

On Tue, Mar 15, 2022 at 2:50 PM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
> On Tue, Mar 15, 2022 at 12:07:06PM +0100, Geert Uytterhoeven wrote:
> > ssd130x_clear_screen() allocates a temporary buffer sized to hold one
> > byte per pixel, while it only needs to hold one bit per pixel.
> >
> > ssd130x_fb_blit_rect() allocates a temporary buffer sized to hold one
> > byte per pixel for the whole frame buffer, while it only needs to hold
> > one bit per pixel for the part that is to be updated.
> > Pass dst_pitch to drm_fb_xrgb8888_to_mono_reversed(), as we have already
> > calculated it anyway.
>
> Can we use bitmap API? bitmap_zalloc() / etc ?

Why? There is no need to operate on an array of longs, only on an
array of bytes. Going to longs would expose us to endianness.
There's also no need to use any of the bitmap operations to modify the data.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds