linux-kernel - Re: [PATCH] fuse: make foffset alignment opt-in for optimum backend performance

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: <09c09a93-d3c3-45c6-bc6a-780423e07b5c@linux.alibaba.com>
Date: Fri, 30 Aug 2024 10:10:21 +0800
From: Jingbo Xu <jefflexu@...ux.alibaba.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: Bernd Schubert <bernd.schubert@...tmail.fm>,
 linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fuse: make foffset alignment opt-in for optimum backend
 performance

On 8/29/24 3:51 PM, Miklos Szeredi wrote:
> On Fri, 5 Jul 2024 at 14:00, Jingbo Xu <jefflexu@...ux.alibaba.com> wrote:
>> I'm okay with resuing max_pages as the alignment constraint.  They are
>> the same in our internal scenarios.  But I'm not sure if it is the case
>> in other scenarios.
> 
> max_pages < alignment makes little sense.
> 
> max_pages = n * alignment could make sense, i.e. allow writes that are
> whole multiples of the alignment.

Agreed.

> 
> I'm not against adding a separate alignment, but it could be just
> uint8_t to take up less space in init_out.   We could have done that
> with max_stack_depth too.   Oh well...

Make sense, as the new added fuse_init_out.opt_alignment is already
log2(byte alignment).  I think uint8_t is already adequate in this case.
(Actually I'm going to rename @opt_alignment field of fuse_init_out to
something like @log_opt_align to indicate it's actually a log2() value
as Berned previously suggested)

Besides, I'm not sure if it's worth adding a new init flag, i.e.
FUSE_OPT_ALIGNMENT, as the init flag bits are continually consumed.
Maybe we could stipulate that a zero log_opt_align indicates no
alignment constraint (the default behavior), while a non-zero
log_opt_align indicates an alignment constraint.  However IIUC the user
daemon may or may not zero the unused fields of fuse_init_out.  Thus if
a fuse server not supporting opt_alignment doesn't zero
fuse_init_out.unused, then the kernel side will enforce an alignment
constraint unexpectedly.

-- 
Thanks,
Jingbo