public inbox for [email protected]
 help / color / mirror / Atom feed
From: Luis Henriques <[email protected]>
To: Bernd Schubert <[email protected]>
Cc: Luis Henriques <[email protected]>,
	 Bernd Schubert <[email protected]>,
	Miklos Szeredi <[email protected]>,  Jens Axboe <[email protected]>,
	 Pavel Begunkov <[email protected]>,
	 [email protected], [email protected],
	 Joanne Koong <[email protected]>,
	 Josef Bacik <[email protected]>,
	 Amir Goldstein <[email protected]>,
	 Ming Lei <[email protected]>,  David Wei <[email protected]>
Subject: Re: [PATCH v9 13/17] fuse: Allow to queue fg requests through io-uring
Date: Tue, 07 Jan 2025 21:25:49 +0000	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]> (Bernd Schubert's message of "Tue, 7 Jan 2025 19:59:06 +0100")

On Tue, Jan 07 2025, Bernd Schubert wrote:

> On 1/7/25 16:54, Luis Henriques wrote:
>
> [...]
>
>>> @@ -785,10 +830,22 @@ static void fuse_uring_do_register(struct fuse_ring_ent *ring_ent,
>>>   				   unsigned int issue_flags)
>>>   {
>>>   	struct fuse_ring_queue *queue = ring_ent->queue;
>>> +	struct fuse_ring *ring = queue->ring;
>>> +	struct fuse_conn *fc = ring->fc;
>>> +	struct fuse_iqueue *fiq = &fc->iq;
>>>     	spin_lock(&queue->lock);
>>>   	fuse_uring_ent_avail(ring_ent, queue);
>>>   	spin_unlock(&queue->lock);
>>> +
>>> +	if (!ring->ready) {
>>> +		bool ready = is_ring_ready(ring, queue->qid);
>>> +
>>> +		if (ready) {
>>> +			WRITE_ONCE(ring->ready, true);
>>> +			fiq->ops = &fuse_io_uring_ops;
>> Shouldn't we be taking the fiq->lock to protect the above operation?
>
> I switched the order and changed it to WRITE_ONCE. fiq->lock would
> require that doing the operations would also hold lock.
> Also see "[PATCH v9 16/17] fuse: block request allocation until",
> there should be no races anyone.

OK, great.  I still need to go read the code a few more times, I guess.
Thank you for your help understanding this code, Bernd.

Cheers,
-- 
Luís

>> 
>>> +		}
>>> +	}
>>>   }
>>>     /*
>>> @@ -979,3 +1036,119 @@ int __maybe_unused fuse_uring_cmd(struct io_uring_cmd *cmd,
>>>     	return -EIOCBQUEUED;
>>>   }
>>> +
>>> +/*
>>> + * This prepares and sends the ring request in fuse-uring task context.
>>> + * User buffers are not mapped yet - the application does not have permission
>>> + * to write to it - this has to be executed in ring task context.
>>> + */
>>> +static void
>>> +fuse_uring_send_req_in_task(struct io_uring_cmd *cmd,
>>> +			    unsigned int issue_flags)
>>> +{
>>> +	struct fuse_ring_ent *ent = uring_cmd_to_ring_ent(cmd);
>>> +	struct fuse_ring_queue *queue = ent->queue;
>>> +	int err;
>>> +
>>> +	if (unlikely(issue_flags & IO_URING_F_TASK_DEAD)) {
>>> +		err = -ECANCELED;
>>> +		goto terminating;
>>> +	}
>>> +
>>> +	err = fuse_uring_prepare_send(ent);
>>> +	if (err)
>>> +		goto err;
>> Suggestion: simplify this function flow.  Something like:
>> 	int err = 0;
>> 	if (unlikely(issue_flags & IO_URING_F_TASK_DEAD))
>> 		err = -ECANCELED;
>> 	else if (fuse_uring_prepare_send(ent)) {
>> 		fuse_uring_next_fuse_req(ent, queue, issue_flags);
>> 		return;
>> 	}
>> 	spin_lock(&queue->lock);
>>          [...]
>
> That makes it look like fuse_uring_prepare_send is not an
> error, but expected. How about like this?
>
> static void
> fuse_uring_send_req_in_task(struct io_uring_cmd *cmd,
> 			    unsigned int issue_flags)
> {
> 	struct fuse_ring_ent *ent = uring_cmd_to_ring_ent(cmd);
> 	struct fuse_ring_queue *queue = ent->queue;
> 	int err;
>
> 	if (!(issue_flags & IO_URING_F_TASK_DEAD)) {
> 		err = fuse_uring_prepare_send(ent);
> 		if (err) {
> 			fuse_uring_next_fuse_req(ent, queue, issue_flags);
> 			return;
> 		}
> 	} else {
> 		err = -ECANCELED;
> 	}
>
> 	spin_lock(&queue->lock);
> 	ent->state = FRRS_USERSPACE;
> 	list_move(&ent->list, &queue->ent_in_userspace);
> 	spin_unlock(&queue->lock);
>
> 	io_uring_cmd_done(cmd, err, 0, issue_flags);
> 	ent->cmd = NULL;
> }
>
>
>
> Thanks,
> Bernd

  reply	other threads:[~2025-01-07 21:25 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-07  0:25 [PATCH v9 00/17] fuse: fuse-over-io-uring Bernd Schubert
2025-01-07  0:25 ` [PATCH v9 01/17] fuse: rename to fuse_dev_end_requests and make non-static Bernd Schubert
2025-01-07  0:25 ` [PATCH v9 02/17] fuse: Move fuse_get_dev to header file Bernd Schubert
2025-01-07  0:25 ` [PATCH v9 03/17] fuse: Move request bits Bernd Schubert
2025-01-07  0:25 ` [PATCH v9 04/17] fuse: Add fuse-io-uring design documentation Bernd Schubert
2025-01-07  0:25 ` [PATCH v9 05/17] fuse: make args->in_args[0] to be always the header Bernd Schubert
2025-01-07  0:25 ` [PATCH v9 06/17] fuse: {io-uring} Handle SQEs - register commands Bernd Schubert
2025-01-07  9:56   ` Luis Henriques
2025-01-07 12:07     ` Bernd Schubert
2025-01-17 11:06   ` Pavel Begunkov
2025-01-19 22:47     ` Bernd Schubert
2025-01-07  0:25 ` [PATCH v9 07/17] fuse: Make fuse_copy non static Bernd Schubert
2025-01-07  0:25 ` [PATCH v9 08/17] fuse: Add fuse-io-uring handling into fuse_copy Bernd Schubert
2025-01-10 22:18   ` Joanne Koong
2025-01-07  0:25 ` [PATCH v9 09/17] fuse: {io-uring} Make hash-list req unique finding functions non-static Bernd Schubert
2025-01-07  0:25 ` [PATCH v9 10/17] fuse: Add io-uring sqe commit and fetch support Bernd Schubert
2025-01-07 14:42   ` Luis Henriques
2025-01-07 15:59     ` Bernd Schubert
2025-01-07 16:21       ` Luis Henriques
2025-01-13 22:44   ` Joanne Koong
2025-01-20  0:33     ` Bernd Schubert
2025-01-17 11:18   ` Pavel Begunkov
2025-01-17 11:20     ` Bernd Schubert
2025-01-07  0:25 ` [PATCH v9 11/17] fuse: {io-uring} Handle teardown of ring entries Bernd Schubert
2025-01-07 15:31   ` Luis Henriques
2025-01-17 11:23   ` Pavel Begunkov
2025-01-07  0:25 ` [PATCH v9 12/17] fuse: {io-uring} Make fuse_dev_queue_{interrupt,forget} non-static Bernd Schubert
2025-01-07  0:25 ` [PATCH v9 13/17] fuse: Allow to queue fg requests through io-uring Bernd Schubert
2025-01-07 15:54   ` Luis Henriques
2025-01-07 18:59     ` Bernd Schubert
2025-01-07 21:25       ` Luis Henriques [this message]
2025-01-17 11:47   ` Pavel Begunkov
2025-01-17 21:52   ` Bernd Schubert
2025-01-07  0:25 ` [PATCH v9 14/17] fuse: Allow to queue bg " Bernd Schubert
2025-01-17 11:49   ` Pavel Begunkov
2025-01-07  0:25 ` [PATCH v9 15/17] fuse: {io-uring} Prevent mount point hang on fuse-server termination Bernd Schubert
2025-01-07 16:14   ` Luis Henriques
2025-01-07 19:03     ` Bernd Schubert
2025-01-17 11:52   ` Pavel Begunkov
2025-01-07  0:25 ` [PATCH v9 16/17] fuse: block request allocation until io-uring init is complete Bernd Schubert
2025-01-07  0:25 ` [PATCH v9 17/17] fuse: enable fuse-over-io-uring Bernd Schubert
2025-01-17 11:52   ` Pavel Begunkov
2025-01-17  9:07 ` [PATCH v9 00/17] fuse: fuse-over-io-uring Miklos Szeredi
2025-01-17  9:12   ` Bernd Schubert
2025-01-17 12:01     ` Pavel Begunkov

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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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