From: Henrique Carvalho <henrique.carvalho@suse.com>
To: David Howells <dhowells@redhat.com>
Cc: stable@vger.kernel.org, smfrench@gmail.com,
linux-cifs@vger.kernel.org, Laura Kerner <laura.kerner@ichaus.de>
Subject: Re: [PATCH 6.6.y] smb: client: support kvec iterators in async read path
Date: Fri, 11 Jul 2025 12:59:55 -0300 [thread overview]
Message-ID: <aHE0--yUyFJqK6lb@precision> (raw)
In-Reply-To: <2944136.1752224518@warthog.procyon.org.uk>
On Fri, Jul 11, 2025 at 10:01:58AM +0100, David Howells wrote:
> Henrique Carvalho <henrique.carvalho@suse.com> wrote:
>
> > Add cifs_limit_kvec_subset() and select the appropriate limiter in
> > cifs_send_async_read() to handle kvec iterators in async read path,
> > fixing the EIO bug when running executables in cifs shares mounted
> > with nolease.
> >
> > This patch -- or equivalent patch, does not exist upstream, as the
> > upstream code has suffered considerable API changes. The affected path
> > is currently handled by netfs lib and located under netfs/direct_read.c.
>
> Are you saying that you do see this upstream too?
>
No, the patch only targets the 6.6.y stable tree. Since version 6.8,
this path has moved into the netfs layer, so the original bug no longer
exists.
The bug was fixed at least since the commit referred in the commit
message -- 3ee1a1fc3981. In this commit, the call to cifs_user_readv()
is replaced by a call to netfs_unbuffered_read_iter(), inside the
function cifs_strict_readv().
netfs_unbuffered_read_iter() itself was introduced in commit
016dc8516aec8, along with other netfs api changes, present in kernel
versions 6.8+.
Backporting netfs directly would be non-trivial. Instead, I:
- add cifs_limit_kvec_subset(), modeled on the existing
cifs_limit_bvec_subset()
- choose between the kvec or bvec limiter function early in
cifs_write_from_iter().
The Fixes tag references d08089f649a0c, which implements
cifs_limit_bvec_subset() and uses it inside cifs_write_from_iter().
> > Reproducer:
> >
> > $ mount.cifs //server/share /mnt -o nolease
> > $ cat - > /mnt/test.sh <<EOL
> > echo hallo
> > EOL
> > $ chmod +x /mnt/test.sh
> > $ /mnt/test.sh
> > bash: /mnt/test.sh: /bin/bash: Defekter Interpreter: Eingabe-/Ausgabefehler
> > $ rm -f /mnt/test.sh
>
> Is this what you are expecting to see when it works or when it fails?
>
This is the reproducer for the observed bug. In english it reads "Bad
interpreter: Input/Output error".
FYI: I tried to follow Option 3 of the stable-kernel rules for submission:
<https://www.kernel.org/doc/html/v6.15/process/stable-kernel-rules.html>
Please let me know if you'd prefer a different approach or any further
changes.
Henrique
next prev parent reply other threads:[~2025-07-11 16:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-10 16:50 [PATCH 6.6.y] smb: client: support kvec iterators in async read path Henrique Carvalho
2025-07-11 9:01 ` David Howells
2025-07-11 15:59 ` Henrique Carvalho [this message]
2025-07-13 13:30 ` Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aHE0--yUyFJqK6lb@precision \
--to=henrique.carvalho@suse.com \
--cc=dhowells@redhat.com \
--cc=laura.kerner@ichaus.de \
--cc=linux-cifs@vger.kernel.org \
--cc=smfrench@gmail.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).