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
| ||
|
Date: Tue, 4 Dec 2018 00:06:24 +0000 From: Paul Burton <paul.burton@...s.com> To: Jakub Kicinski <jakub.kicinski@...ronome.com> CC: "daniel@...earbox.net" <daniel@...earbox.net>, "ast@...nel.org" <ast@...nel.org>, Jiong Wang <jiong.wang@...ronome.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "oss-drivers@...ronome.com" <oss-drivers@...ronome.com>, Markos Chandras <markos.chandras@...tec.com>, Paul Burton <pburton@...ecomp.com>, "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org> Subject: Re: [PATCH v2 bpf] mips: bpf: fix encoding bug for mm_srlv32_op Hi Jakub, On Mon, Dec 03, 2018 at 03:55:45PM -0800, Jakub Kicinski wrote: > On Mon, 3 Dec 2018 22:42:04 +0000, Paul Burton wrote: > > Jiong Wang wrote: > > > For micro-mips, srlv inside POOL32A encoding space should use 0x50 > > > sub-opcode, NOT 0x90. > > > > > > Some early version ISA doc describes the encoding as 0x90 for both srlv and > > > srav, this looks to me was a typo. I checked Binutils libopcode > > > implementation which is using 0x50 for srlv and 0x90 for srav. > > > > > > v1->v2: > > > - Keep mm_srlv32_op sorted by value. > > > > > > Fixes: f31318fdf324 ("MIPS: uasm: Add srlv uasm instruction") > > > Cc: Markos Chandras <markos.chandras@...tec.com> > > > Cc: Paul Burton <paul.burton@...s.com> > > > Cc: linux-mips@...r.kernel.org > > > Acked-by: Jakub Kicinski <jakub.kicinski@...ronome.com> > > > Acked-by: Song Liu <songliubraving@...com> > > > Signed-off-by: Jiong Wang <jiong.wang@...ronome.com> > > > > Applied to mips-fixes. > > Newbie process related question - are the arch JIT patches routed via > arch trees or bpf-next? Jiong has more (slightly conflicting) JIT > patches to send - I wonder how they'll get applied and whether to wait > for the mips -> Linus -> net -> bpf merge chain. I'd expect that to be a case-by-case "what makes most sense this time?" sort of question. In this particular patch the code you're changing isn't specifically BPF-related code, it's part of the MIPS uasm assembler which MIPS BPF happens to use behind the scenes, so since it seemed like a pretty standalone patch taking it through the MIPS tree made sense to me. If you have related patches the best thing to do would be to submit them together as a series. Then after the maintainers involved can see the patches we can figure out the best way to apply them. Thanks, Paul
Powered by blists - more mailing lists