linux-kernel - Re: [PATCH] jffs2: implement mount option to configure endianness

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: <20181107192131.tf5ptjiccne3tzmq@zorba>
Date:   Wed, 7 Nov 2018 11:21:45 -0800
From:   Daniel Walker <danielwa@...co.com>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     Joakim Tjernlund <joakim.tjernlund@...inera.com>,
        "nkela@...co.com" <nkela@...co.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        "xe-linux-external@...co.com" <xe-linux-external@...co.com>
Subject: Re: [PATCH] jffs2: implement mount option to configure endianness

On Wed, Nov 07, 2018 at 05:58:53PM -0000, David Woodhouse wrote:
> 
> > On Wed, Nov 07, 2018 at 04:12:14PM -0000, David Woodhouse wrote:
> >>
> >> > Yes, this may slow things down. I am not sure I agree with the impl.
> >> > either.
> >> > Could one not make cpu_to_je_X/jeX_to_cpu a function ptr which is set
> >> to
> >> > a func. with the correct endian?
> >>
> >> On x86 retpoline would make that quite slow.
> >
> > Is x86 the largest consumer of jffs2 ?
> 
> Certainly not. I'm not sure which architectures do have Spectre V2
> mitigations which make indirect branches expensive now... perhaps there is
> no intersection with the cases where we really care about JFFS2 being
> CPU-bound?


How about we add the Kconfig option to enable the mount option. So if you enable
to mount option your accepting the performance impact and we'll note that in the
Kconfig description. Then we can do the performance testing in time, and maybe
make this always on at some later time when the performance impact is better
understood ?

We could also add likely()/unlikely() cause that's easy enough.

Daniel