linux-kernel - Re: [RFC V6 2/3] arm:add bitrev.h file to support rbit instruction

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: <20141114011832.GE4042@n2100.arm.linux.org.uk>
Date:	Fri, 14 Nov 2014 01:18:32 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Joe Perches <joe@...ches.com>
Cc:	Takashi Iwai <tiwai@...e.de>,
	"Wang, Yalin" <Yalin.Wang@...ymobile.com>,
	'Will Deacon' <will.deacon@....com>,
	'Ard Biesheuvel' <ard.biesheuvel@...aro.org>,
	"'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
	"'akinobu.mita@...il.com'" <akinobu.mita@...il.com>,
	"'linux-mm@...ck.org'" <linux-mm@...ck.org>,
	"'linux-arm-kernel@...ts.infradead.org'" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC V6 2/3] arm:add bitrev.h file to support rbit instruction

On Thu, Nov 13, 2014 at 04:45:43PM -0800, Joe Perches wrote:
> On Fri, 2014-11-14 at 00:17 +0000, Russell King - ARM Linux wrote:
> > On Thu, Nov 13, 2014 at 04:05:30PM -0800, Joe Perches wrote:
> > > On Thu, 2014-11-13 at 23:53 +0000, Russell King - ARM Linux wrote:
> > > > On Fri, Oct 31, 2014 at 01:42:44PM +0800, Wang, Yalin wrote:
> > > > > This patch add bitrev.h file to support rbit instruction,
> > > > > so that we can do bitrev operation by hardware.
> > > > > Signed-off-by: Yalin Wang <yalin.wang@...ymobile.com>
> > > > > ---
> > > > >  arch/arm/Kconfig              |  1 +
> > > > >  arch/arm/include/asm/bitrev.h | 21 +++++++++++++++++++++
> > > > >  2 files changed, 22 insertions(+)
> > > > >  create mode 100644 arch/arm/include/asm/bitrev.h
> > > > > 
> > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > > > index 89c4b5c..be92b3b 100644
> > > > > --- a/arch/arm/Kconfig
> > > > > +++ b/arch/arm/Kconfig
> > > > > @@ -28,6 +28,7 @@ config ARM
> > > > >  	select HANDLE_DOMAIN_IRQ
> > > > >  	select HARDIRQS_SW_RESEND
> > > > >  	select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
> > > > > +	select HAVE_ARCH_BITREVERSE if (CPU_V7M || CPU_V7)
> > > > 
> > > > Looking at this, this is just wrong.  Take a moment to consider what
> > > > happens if we build a kernel which supports both ARMv6 _and_ ARMv7 CPUs.
> > > > What happens if an ARMv6 CPU tries to execute an rbit instruction?
> > > > 
> > > > Second point (which isn't obvious from your submissions on-list) is that
> > > > you've loaded the patch system up with patches for other parts of the
> > > > kernel tree for which I am not responsible for.  As such, I can't take
> > > > those patches without the sub-tree maintainer acking them.  Also, the
> > > > commit text in those patches look weird:
> > > > 
> > > > 6fire: Convert byte_rev_table uses to bitrev8
> > > > 
> > > > Use the inline function instead of directly indexing the array.
> > > > 
> > > > This allows some architectures with hardware instructions for bit
> > > > reversals to eliminate the array.
> > > > 
> > > > Signed-off-by: Joe Perches <(address hidden)>
> > > > Signed-off-by: Yalin Wang <(address hidden)>
> > > > 
> > > > Why is Joe signing off on these patches?
> > > > Shouldn't his entry be an Acked-by: ?
> > > 
> > > I didn't sign off on or ack the "add bitrev.h" patch.
> > 
> > Correct, I never said you did.  Please read my message a bit more carefully
> > next time, huh?
> 
> You've no reason to write that Russell.

Absolutely I have, but I'm not going to discuss it because I'll just
end up flaming you because in my mind you are the one who is completely
mistaken with your comments.

In case it hasn't been realised, I hardly read this mailing list anymore,
or messages that I'm Cc'd on.  I do read most messages that I'm in the
To: line, but generally not if they're DT changes (which always end up
being marked To: me.)

> > Great, so I can just discard these that were incorrectly submitted to me
> > then.
> 
> I think you shouldn't apply these patches or updated
> ones either until all the current uses are converted.

Where are the dependencies mentioned?  How do I get to know when all
the dependencies are met?  Who is tracking the dependencies?

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
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/