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] [day] [month] [year] [list]
Date:   Fri, 25 Nov 2022 16:30:08 +1100
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Christophe Leroy <christophe.leroy@...roup.eu>,
        "zhang.songyi@....com.cn" <zhang.songyi@....com.cn>,
        "arnd@...db.de" <arnd@...db.de>
Cc:     "npiggin@...il.com" <npiggin@...il.com>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        <deng.changcheng@....com.cn>
Subject: Re: [PATCH linux-next] powerpc/cell/axon_msi: replace
 DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE

Christophe Leroy <christophe.leroy@...roup.eu> writes:
> Hi,
>
> Le 23/11/2022 à 10:06, zhang.songyi@....com.cn a écrit :
>> From: zhang songyi <zhang.songyi@....com.cn>
>> 
>> Fix the following coccicheck warning:
>> /arch/powerpc/platforms/cell/axon_msi.c:457:0-23: WARNING:
>> fops_msic should be defined with DEFINE_DEBUGFS_ATTRIBUTE
>
> What's the difference between this new patch and the one that is already 
> awaiting application here : 
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20211222090655.484551-1-deng.changcheng@zte.com.cn/ 
> ?
>
> The only difference I see it that the already existing patch has a more 
> complete description of the change, so unless I'm missing something it 
> would be nice to avoid sending the same changes again and again.

Both patches switch the code to use a function called "unsafe" without
adequately explaining why that is OK.

The commit that added the cocci check script says:

  If the original struct file_operations are known to be safe against removal
  races by themselves already, the proxy creation may be bypassed by creating
  the files through debugfs_create_file_unsafe().

None of these conversion patches ever contain any explanation which
speaks to that.

In this case I *think* the change is OK and there is no race because the
debugfs file is never removed. But I really wish the submitter would
tell me that in the change log.

cheers

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ