linux-kernel - Re: [PATCH v3 1/1] bcachefs: Move BCACHEFS_STATFS

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]

Message-Id: <37665ED1-9929-444F-B9A0-3CC7EADBC064@suse.com>
Date: Thu, 9 May 2024 15:01:33 +0800
From: Glass Su <glass.su@...e.com>
To: Petr Vorel <pvorel@...e.cz>
Cc: Kent Overstreet <kent.overstreet@...ux.dev>,
 linux-bcachefs@...r.kernel.org,
 Su Yue <l@...enly.org>,
 Brian Foster <bfoster@...hat.com>,
 Coly Li <colyli@...e.de>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/1] bcachefs: Move BCACHEFS_STATFS_MAGIC value to UAPI
 magic.h



> On May 9, 2024, at 14:17, Petr Vorel <pvorel@...e.cz> wrote:
> 
> Hi Kent,
> 
>> On Wed, May 08, 2024 at 11:17:59PM +0200, Petr Vorel wrote:
>>> Hi Su, Kent,
> 
>>>>> On May 7, 2024, at 23:37, Petr Vorel <pvorel@...e.cz> wrote:
> 
>>>>> Move BCACHEFS_STATFS_MAGIC value to UAPI <linux/magic.h> under
>>>>> BCACHEFS_SUPER_MAGIC definition (use common approach for name) and reuse the
>>>>> definition in bcachefs_format.h BCACHEFS_STATFS_MAGIC.
> 
>>>>> There are other bcachefs magic definitions: BCACHE_MAGIC, BCHFS_MAGIC,
>>>>> which use UUID_INIT() and are used only in libbcachefs. Therefore move
>>>>> only BCACHEFS_STATFS_MAGIC value, which can be used outside of
>>>>> libbcachefs for f_type field in struct statfs in statfs() or fstatfs().
> 
>>>>> Suggested-by: Su Yue <l@...enly.org>
> 
>>>> Would you kindly amend it to Su Yue <glass.su@...e.com> or
>>>> Kent can help if the patch is going to be applied.
> 
>>> Unfortunately Kent was faster, it's already merged without your SUSE address
>>> (and your RBT you added in the end):
> 
>>> https://evilpiepirate.org/git/bcachefs.git/commit/?h=for-next&id=ce8f9355f23be9756e499682d0d642a741db6c3a
> 
>>> @Kent: Maybe it can be even now amended (with Su Yue's RBT).
> 
>> ...sure, make me invalidate my test results :)
> 
> Thank you! FYI there was also his RBT (Reviewed-by: Su Yue <glass.su@...e.com>)
> 
Thanks both for you Petr and Kent :- )  Sorry for inconvenience due to my email quirk...

— 
Su
> https://lore.kernel.org/linux-bcachefs/6D9FCB08-480D-4CA0-82E2-284B1F2BF8FD@suse.com/
> 
> Kind regards,
> Petr
> 
>>>>> Signed-off-by: Petr Vorel <pvorel@...e.cz>
>>>>> ---
>>>>> Changes v2->v3:
>>>>> * Align tab with other entries.
>>> ...
>>>>> #include <linux/uuid.h>
>>>>> +#include <uapi/linux/magic.h>
>>>>> #include "vstructs.h"
> 
>>>>> #ifdef __KERNEL__
>>>>> @@ -1275,7 +1276,7 @@ enum bch_compression_opts {
>>>>> UUID_INIT(0xc68573f6, 0x66ce, 0x90a9, \
>>>>> 0xd9, 0x6a, 0x60, 0xcf, 0x80, 0x3d, 0xf7, 0xef)
> 
>>>>> -#define BCACHEFS_STATFS_MAGIC 0xca451a4e
>>>>> +#define BCACHEFS_STATFS_MAGIC BCACHEFS_SUPER_MAGIC
> 
>>>>> #define JSET_MAGIC __cpu_to_le64(0x245235c1a3625032ULL)
>>>>> #define BSET_MAGIC __cpu_to_le64(0x90135c78b99e07f5ULL)
>>>>> diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h
>>>>> index 1b40a968ba91..bb575f3ab45e 100644
>>>>> --- a/include/uapi/linux/magic.h
>>>>> +++ b/include/uapi/linux/magic.h
>>>>> @@ -37,6 +37,7 @@
>>>>> #define HOSTFS_SUPER_MAGIC 0x00c0ffee
>>>>> #define OVERLAYFS_SUPER_MAGIC 0x794c7630
>>>>> #define FUSE_SUPER_MAGIC 0x65735546
>>>>> +#define BCACHEFS_SUPER_MAGIC 0xca451a4e
> 
>>>> IIUC, due to some historical reasons bcachefs used to switched
>>>> ondisk sb magic from BCACHE_MAGIC to BCHFS_MAGIC.
>>>> Other major fses uses  *_SUPER_MAGIC both for ondisk 
>>>> sb magic, kstatfs::f_type and super_block::s_magic.
>>>> However, for bcacehfs there are three magic numbers.
> 
>>> Thanks for info. But for struct statfs in statfs() or fstatfs() only 0xca451a4e
>>> is needed, right? I would not expose the other(s) unless it's really needed.
>>> Also we'd need to backport UUID_INIT() into UAPI :(.
> 
>>>> Anyway, it looks good to me so far:
>>>> Reviewed-by: Su Yue <glass.su@...e.com> 
> 
>>> And also without your RBT.
> 
>>> Kind regards,
>>> Petr
> 
>>>> — 
>>>> Su