Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <03d46708ca8adaf2fe98689e04c98541.pc@manguebit.com>
From:   Paulo Alcantara <pc@manguebit.com>
To:     David Howells <dhowells@redhat.com>,
        Steve French <smfrench@gmail.com>
Cc:     dhowells@redhat.com,
        =?utf-8?B?SsOpcsO0bWU=?= Glisse <jglisse@redhat.com>,
        Long Li <longli@microsoft.com>,
        Enzo Matsumiya <ematsumiya@suse.de>,
        Shyam Prasad N <nspmangalore@gmail.com>,
        Rohith Surabattula <rohiths.msft@gmail.com>,
        Jeff Layton <jlayton@kernel.org>, linux-cifs@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cifs: Fix unbuffered read
In-Reply-To: <1692048.1681857607@warthog.procyon.org.uk>
References: <1692048.1681857607@warthog.procyon.org.uk>
Date:   Tue, 18 Apr 2023 23:16:45 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

David Howells <dhowells@redhat.com> writes:

> If read() is done in an unbuffered manner, such that, say,
> cifs_strict_readv() goes through cifs_user_readv() and thence
> __cifs_readv(), it doesn't recognise the EOF and keeps indicating to
> userspace that it returning full buffers of data.
>
> This is due to ctx->iter being advanced in cifs_send_async_read() as the
> buffer is split up amongst a number of rdata objects.  The iterator count
> is then used in collect_uncached_read_data() in the non-DIO case to set t=
he
> total length read - and thus the return value of sys_read().  But since t=
he
> iterator normally gets used up completely during splitting, ctx->total_len
> gets overridden to the full amount.
>
> However, prior to that in collect_uncached_read_data(), we've gone through
> the list of rdatas and added up the amount of data we actually received
> (which we then throw away).
>
> Fix this by removing the bit that overrides the amount read in the non-DIO
> case and just going with the total added up in the aforementioned loop.
>
> This was observed by mounting a cifs share with multiple channels, e.g.:
>
> 	mount //192.168.6.1/test /test/ -o user=3Dshares,pass=3D...,max_channels=
=3D6
>
> and then reading a 1MiB file on the share:
>
> 	strace cat /xfstest.test/1M  >/dev/null
>
> Through strace, the same data can be seen being read again and again.
>=20=20=20=20=20
> Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rathe=
r than a page list")
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Steve French <smfrench@gmail.com>
> cc: Paulo Alcantara <pc@manguebit.com>
> cc: J=C3=A9r=C3=B4me Glisse <jglisse@redhat.com>
> cc: Long Li <longli@microsoft.com>
> cc: Enzo Matsumiya <ematsumiya@suse.de>
> cc: Shyam Prasad N <nspmangalore@gmail.com>
> cc: Rohith Surabattula <rohiths.msft@gmail.com>
> cc: Jeff Layton <jlayton@kernel.org>
> cc: linux-cifs@vger.kernel.org
> ---
>  fs/cifs/file.c |    4 ----
>  1 file changed, 4 deletions(-)

Acked-by: Paulo Alcantara (SUSE) <pc@manguebit.com>