Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH 2/4] configfs: Fix writing at a non-zero offset
To:     Bart Van Assche <bvanassche@acm.org>,
        Christoph Hellwig <hch@lst.de>
Cc:     Joel Becker <jlbec@evilplan.org>, linux-kernel@vger.kernel.org,
        "Martin K . Petersen" <martin.petersen@oracle.com>,
        Yanko Kaneti <yaneti@declera.com>,
        Brendan Higgins <brendanhiggins@google.com>
References: <20210723212353.896343-1-bvanassche@acm.org>
 <20210723212353.896343-3-bvanassche@acm.org>
From:   Bodo Stroesser <bostroesser@gmail.com>
Message-ID: <7bee65ce-f5f1-a525-c72d-221b5d23cf3e@gmail.com>
Date:   Mon, 26 Jul 2021 16:58:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <20210723212353.896343-3-bvanassche@acm.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 23.07.21 23:23, Bart Van Assche wrote:
> Store data at the right offset when writing with a non-zero offset. I think
> this patch fixes behavior introduced in the initial configfs commit.

Unfortunately I think it does not.

Let's say user writes 5 times to configfs file while keeping it open.
On every write() call it writes 1 character only, e.g. first "A", then "B", ...

The original code before the changes 5 times called flush_write_buffer for the
strings "A\0", "B\0", ... (with the '\0' not included in the count parameter,
so count is 1 always, which is the length of the last write).

Since commit
     420405ecde06  "configfs: fix the read and write iterators"
flush_write_buffer is called for the strings "A\0", "AB\0", "ABC\0", ...
but count still is 1.

This fix changes just the count parameter, so it now is 1, 2, 3, ... in our
example. But it still sends on every call to flush_write_buffer all the write
data gathered since last open().

I think, a simple way to restore the original behavior would be to revert the
part of commit 420405ecde06 that changed write routines.

Bodo

 From a
> source code comment in the initial configfs commit: "There is no easy way
> for us to know if userspace is only doing a partial write, so we don't
> support them."
> 
> Cc: Bodo Stroesser <bostroesser@gmail.com>
> Cc: Martin K. Petersen <martin.petersen@oracle.com>
> Cc: Yanko Kaneti <yaneti@declera.com>
> Cc: Brendan Higgins <brendanhiggins@google.com>
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
>   fs/configfs/file.c | 10 ++++++----
>   1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/configfs/file.c b/fs/configfs/file.c
> index 8121bb1b2121..3b2ddc2e5d42 100644
> --- a/fs/configfs/file.c
> +++ b/fs/configfs/file.c
> @@ -226,14 +226,16 @@ static ssize_t configfs_write_iter(struct kiocb *iocb, struct iov_iter *from)
>   {
>   	struct file *file = iocb->ki_filp;
>   	struct configfs_buffer *buffer = file->private_data;
> -	ssize_t len;
> +	int len, written = 0;
>   
>   	mutex_lock(&buffer->mutex);
>   	len = fill_write_buffer(buffer, iocb->ki_pos, from);
>   	if (len > 0)
> -		len = flush_write_buffer(file, buffer, len);
> -	if (len > 0)
> -		iocb->ki_pos += len;
> +		written = flush_write_buffer(file, buffer, iocb->ki_pos + len);
> +	if (written > 0) {
> +		len = max_t(int, 0, written - iocb->ki_pos);
> +		iocb->ki_pos = written;
> +	}
>   	mutex_unlock(&buffer->mutex);
>   	return len;
>   }
>