Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <154151286725.17550.12307253489084032792.stgit@localhost.localdomain>
In-Reply-To: <154151286725.17550.12307253489084032792.stgit@localhost.localdomain>
From:   Miklos Szeredi <miklos@szeredi.hu>
Date:   Wed, 23 Jan 2019 10:37:18 +0100
Message-ID: <CAJfpegvaRGD3qT0qjAW76_MFNOUDTMgBJR+H+WeVWBivAppzrQ@mail.gmail.com>
Subject: Re: [PATCH RFC] fuse: Prevent background write requests increase
 inode size
To:     Kirill Tkhai <ktkhai@virtuozzo.com>
Cc:     linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Nov 6, 2018 at 3:03 PM Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>
> Hi, Miklos,
>
> this is not a well-tested patch, this is a concept,
> showing the places, where it looks we have a problem.
>
> Commit 7879c4e58b7c made io->async careless about inode size,
> and this is wrong. Asyncronuos background requests may be sent
> to userspace after inode becomes unlocked, when background
> queue is throttled. In this case we execute a write request
> extending inode size without any protection, and this ruines
> everything. Fix that.
>
> Also, some write background requests do not increment fi->writectr,
> e.g.:
>         fuse_direct_IO()
>           fuse_direct_io()
>             fuse_send_write()
>               fuse_async_req_send()
>                 fuse_request_send_background()

inode_lock should prevent mischief for sync DIO.  For AIO DIO the
order of operations is not deterministic, so it's fine if truncate and
an extending AIO write race, as far as I understand.

Thanks,
Miklos