linux-kernel - Re: [PATCH 0/4] misc warning cleanup in arch/risc-v

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 19 Aug 2022 11:34:16 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <palmer@...belt.com>, <mail@...chuod.ie>
CC:     <anup@...infault.org>, <atishp@...shpatra.org>,
        <paul.walmsley@...ive.com>, <aou@...s.berkeley.edu>,
        <guoren@...nel.org>, <vincent.chen@...ive.com>,
        <xianting.tian@...ux.alibaba.com>, <heiko@...ech.de>,
        <wangkefeng.wang@...wei.com>, <tongtiangen@...wei.com>,
        <kvm@...r.kernel.org>, <kvm-riscv@...ts.infradead.org>,
        <linux-riscv@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] misc warning cleanup in arch/risc-v

On 19/08/2022 00:01, Palmer Dabbelt wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Sun, 14 Aug 2022 07:12:34 PDT (-0700), mail@...chuod.ie wrote:
>> From: Conor Dooley <conor.dooley@...rochip.com>
>>
>> Hey all,
>> Couple fixes here for most of what's left of the {sparse,} warnings in
>> arch/riscv that are still in need of patches. Ben has sent patches
>> for the VDSO issue already (although they seem to need rework).
>>
>> VDSO aside, With this patchset applied, we are left with:
>> - cpuinfo_ops missing prototype: this likely needs to go into an
>>   asm-generic header & I'll send a separate patch for that.
>> - Complaints about an error in mm/init.c:
>>   "error inarch/riscv/mm/init.c:819:2: error: "setup_vm() is <trunc>
>>   I think this can be ignored.
>> - 600+ -Woverride-init warnings for syscall table setup where
>>   overriding seems to be the whole point of the macro.
>> - Warnings about imported kvm core code.
>> - Flexible array member warnings that look like common KVM code
>>   patterns
>> - An unexpected unlock in kvm_riscv_check_vcpu_requests that was added
>>   intentionally:
>>   https://lore.kernel.org/all/20220710151105.687193-1-apatel@ventanamicro.com/
>>   Is it worth looking into whether that's a false positive or not?
>>
>> Thanks,
>> Conor.
>>
>> Conor Dooley (4):
>>   riscv: kvm: vcpu_timer: fix unused variable warnings
>>   riscv: kvm: move extern sbi_ext declarations to a header
>>   riscv: signal: fix missing prototype warning
>>   riscv: traps: add missing prototype
>>
>>  arch/riscv/include/asm/kvm_vcpu_sbi.h | 12 ++++++++++++
>>  arch/riscv/include/asm/signal.h       | 12 ++++++++++++
>>  arch/riscv/include/asm/thread_info.h  |  2 ++
>>  arch/riscv/kernel/signal.c            |  1 +
>>  arch/riscv/kernel/traps.c             |  3 ++-
>>  arch/riscv/kvm/vcpu_sbi.c             | 12 +-----------
>>  arch/riscv/kvm/vcpu_timer.c           |  4 ----
>>  7 files changed, 30 insertions(+), 16 deletions(-)
>>  create mode 100644 arch/riscv/include/asm/signal.h
> 
> These generally look good to me.  Anup handles the KVM bits so I'll let
> him chime in there, but
> 
> Reviewed-by: Palmer Dabbelt <palmer@...osinc.com>
> Acked-by: Palmer Dabbelt <palmer@...osinc.com>
> 
> on all of them.
> 
> Happy to do some sort of shared tag thing, but it looks like these are
> all independent enough that it'd be easier to just split them up.  I've
> put the non-KVM bits over at palmer/riscv-variable_fixes_without_kvm, if
> you guys are all OK splitting this up then I'll go take those onto
> riscv/fixes.

Yeah, I see no reason that the kvm patches can't just go via the riscv
kvm tree. I sent the patches as a single series mostly because I wanted
to mention what was left warning wise in the cover.

> I'll wait a bit for folks to get a chance to look, so it
> won't be for tomorrow morning.

They've been there a while and nothing has gone up in flames, I am sure
we will survive a few weeks more :)

Thanks,
Conor.