linux-kernel - Re: [patch] autogain support for bayer10 format (was Re: [patch] propagating controls in libv4l2)

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: <20170503190556.GT23750@n2100.armlinux.org.uk>
Date:   Wed, 3 May 2017 20:05:56 +0100
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>
Cc:     Pavel Machek <pavel@....cz>,
        Mauro Carvalho Chehab <mchehab@...pensource.com>,
        abcloriens@...il.com, linux-media@...r.kernel.org,
        khilman@...nel.org, tony@...mide.com, aaro.koskinen@....fi,
        kernel list <linux-kernel@...r.kernel.org>, sre@...nel.org,
        Sakari Ailus <sakari.ailus@....fi>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        pali.rohar@...il.com, linux-omap@...r.kernel.org,
        patrikbachan@...il.com,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        serge@...lyn.com
Subject: Re: [patch] autogain support for bayer10 format (was Re: [patch]
 propagating controls in libv4l2)

On Wed, Apr 26, 2017 at 06:43:54PM +0300, Ivaylo Dimitrov wrote:
> >+static int get_luminosity_bayer10(uint16_t *buf, const struct v4l2_format *fmt)
> >+{
> >+	long long avg_lum = 0;
> >+	int x, y;
> >+	
> >+	buf += fmt->fmt.pix.height * fmt->fmt.pix.bytesperline / 4 +
> >+		fmt->fmt.pix.width / 4;
> >+
> >+	for (y = 0; y < fmt->fmt.pix.height / 2; y++) {
> >+		for (x = 0; x < fmt->fmt.pix.width / 2; x++)
> 
> That would take some time :). AIUI, we have NEON support in ARM kernels
> (CONFIG_KERNEL_MODE_NEON), I wonder if it makes sense (me) to convert the
> above loop to NEON-optimized when it comes to it? Are there any drawbacks in
> using NEON code in kernel?

Using neon without the VFP state saved and restored corrupts userspace's
FP state.  So, you have to save the entire VFP state to use neon in kernel
mode.  There are helper functions for this: kernel_neon_begin() and
kernel_neon_end().

You can't build C code with the compiler believing that neon is available
as the compiler could emit neon instructions in unprotected kernel code.

Note that kernel_neon_begin() is only allowed to be called outside
interrupt context and with preemption disabled.

Given that, do we really want to be walking over multi-megabytes of image
data in the kernel with preemption disabled - it sounds like a recipe for
a very sluggish system.  I think this should (and can only sensibly be
done) in userspace.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.