linux-kernel - Re: [PATCH 1/1] FUSE: Allow parallel direct writes on the same file

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:   Mon, 25 Apr 2022 10:40:46 +0200
From:   Miklos Szeredi <miklos@...redi.hu>
To:     Bernd Schubert <bschubert@....com>
Cc:     Dharmendra Hans <dharamhans87@...il.com>,
        linux-fsdevel@...r.kernel.org,
        fuse-devel <fuse-devel@...ts.sourceforge.net>,
        linux-kernel@...r.kernel.org, Dharmendra Singh <dsingh@....com>
Subject: Re: [PATCH 1/1] FUSE: Allow parallel direct writes on the same file

On Fri, 22 Apr 2022 at 17:20, Bernd Schubert <bschubert@....com> wrote:
>
>
>
> On 4/22/22 16:48, Miklos Szeredi wrote:
> > On Fri, 22 Apr 2022 at 16:30, Dharmendra Hans <dharamhans87@...il.com> wrote:
> >>
> >> On Thu, Apr 21, 2022 at 8:52 PM Miklos Szeredi <miklos@...redi.hu> wrote:
> >>>
> >>> On Fri, 8 Apr 2022 at 08:18, Dharmendra Singh <dharamhans87@...il.com> wrote:
> >>>>
> >
> > That's true, but I still worry...  Does your workload include
> > non-append extending writes?  Seems to me making those run in parallel
> > is asking for trouble.
>
> Our main use case is MPIIO for now and I don't think it first sets the
> file size and would then write to these sparse files. Fixing all the
> different MPI implementations including closed source stacks is probably
> out of question.

Okay.

> Given that MPIIO also supports direct calls into its stack we also do
> support that for some MPIs, but not all stacks. Direct calls bypassing
> the vfs also haas  it's own issues, including security. So it would be
> really great if we could find a way to avoid the inode lock.
>
> Would you mind to share what you worry about in detail?

I worry about breaking the assumption about i_size does not change if
inode lock is held (exclusive of shared).

Maybe that's not an issue, but we'd need to look very carefully.

Thanks,
Miklos