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: <c69eb8f4-3054-17f2-f0b4-860208509ca6@loongson.cn>
Date:   Thu, 13 Apr 2023 09:55:03 +0800
From:   Tiezhu Yang <yangtiezhu@...ngson.cn>
To:     Xi Ruoyao <xry111@...111.site>,
        Huacai Chen <chenhuacai@...nel.org>,
        WANG Xuerui <kernel@...0n.name>
Cc:     loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org,
        loongson-kernel@...ts.loongnix.cn
Subject: Re: [PATCH v1 1/4] LoongArch: Move three functions from kprobes.c to
 inst.h



On 04/12/2023 06:39 PM, Xi Ruoyao wrote:
> On Wed, 2023-04-12 at 18:04 +0800, Tiezhu Yang wrote:
>> +static inline bool insns_not_supported(union loongarch_instruction insn)
>
> This function seems long enough (to me) not to use "static inline".
> Note that most part of this function belongs to a cold path, and IMO
> it's bad to inline a cold path into every caller.

OK, I will move the three functions from kprobes.c to inst.c.

>
>> +{
>> +       switch (insn.reg2i14_format.opcode) {
>> +       case llw_op:
>> +       case lld_op:
>> +       case scw_op:
>> +       case scd_op:
>> +               pr_notice("kprobe: ll and sc instructions are not supported\n");
>> +               return true;
>> +       }
>> +
>> +       switch (insn.reg1i21_format.opcode) {
>> +       case bceqz_op:
>> +               pr_notice("kprobe: bceqz and bcnez instructions are not supported\n");
>> +               return true;
>> +       }
>> +
>> +       return false;
>> +}
>> +
>> +static inline bool insns_need_simulation(union loongarch_instruction insn)
>> +{
>> +       if (is_pc_ins(&insn))
>> +               return true;
>> +
>> +       if (is_branch_ins(&insn))
>> +               return true;
>> +
>> +       return false;
>
> I'd write "return is_pc_ins(&insn) || is_branch_ins(&insn);" here, but
> there is no behavioral difference anyway.

I prefer leave it as it is.

Thanks,
Tiezhu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ