Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Jann Horn <jannh@google.com>, Alessio Balsini <balsini@android.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	Nikhilesh Reddy <reddyn@codeaurora.org>,
	Akilesh Kailash <akailash@google.com>,
	David Anderson <dvander@google.com>,
	Eric Yan <eric.yan@oneplus.com>,
	Martijn Coenen <maco@android.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Lawrence <paullawrence@google.com>,
	Stefano Duo <stefanoduo@google.com>,
	Zimuzo Ezeozue <zezeozue@google.com>,
	kernel-team <kernel-team@android.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v6] fuse: Add support for passthrough read/write
Date: Thu, 13 Aug 2020 12:41:55 -0600	[thread overview]
Message-ID: <c135d701-4455-95c7-e58a-82e8075d2ea7@kernel.dk> (raw)
In-Reply-To: <CAG48ez17uXtjCTa7xpa=JWz3iBbNDQTKO2hvn6PAZtfW3kXgcA@mail.gmail.com>

On 8/12/20 12:29 PM, Jann Horn wrote:
>> +       passthrough_inode = file_inode(passthrough_filp);
>> +
>> +       iocb->ki_filp = passthrough_filp;
> 
> Hmm... so we're temporarily switching out the iocb's ->ki_filp here? I
> wonder whether it is possible for some other code to look at ->ki_filp
> concurrently... maybe Jens Axboe knows whether that could plausibly
> happen?

I looked into the io_uring use case, and we're using req->file (which is
the same as kiocb->ki_filp) after submission for the polled-IO case.
That's IOCB_HIPRI, not poll(2) related. So it's not safe for that case,
but that probably isn't supported by fuse. But something to keep in
mind...

In general, kiocb->ki_filp is used for setup, and then at IO completion.
That use case appears safe, as long as the ki_filp is restored before
->ki_complete() is called.

Only other exception should be the poll handlers. They arm at setup
time, which is still fine, but re-arm if we get triggered and the file
is still not ready. I _think_ this case is still fine without having
seen all of the bits for this use case, as we haven't actually called
read/write_iter at that point on it.

But in general, I'd say it looks a bit iffy to be fiddling with ki_filp.
Maybe use a new kiocb and stack them like that instead?

-- 
Jens Axboe


      parent reply	other threads:[~2020-08-13 18:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-12 16:14 Alessio Balsini
2020-08-12 18:29 ` Jann Horn
2020-08-13 13:28   ` Alessio Balsini
2020-08-13 18:30     ` Jann Horn
2020-08-18 13:53       ` Alessio Balsini
2020-08-19  6:01         ` Nikolaus Rath
2020-08-19  9:24           ` Amir Goldstein
2020-08-24 12:48             ` Miklos Szeredi
2020-09-11 16:23               ` Alessio Balsini
2020-08-19 10:04         ` Jann Horn
2020-09-08 21:42           ` Alessio Balsini
2020-08-13 18:41   ` Jens Axboe [this message]

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=c135d701-4455-95c7-e58a-82e8075d2ea7@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=akailash@google.com \
    --cc=balsini@android.com \
    --cc=dvander@google.com \
    --cc=eric.yan@oneplus.com \
    --cc=jannh@google.com \
    --cc=kernel-team@android.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maco@android.com \
    --cc=miklos@szeredi.hu \
    --cc=palmer@dabbelt.com \
    --cc=paullawrence@google.com \
    --cc=reddyn@codeaurora.org \
    --cc=stefanoduo@google.com \
    --cc=zezeozue@google.com \
    --subject='Re: [PATCH v6] fuse: Add support for passthrough read/write' \
    /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

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).