public inbox for [email protected]
 help / color / mirror / Atom feed
From: Bernd Schubert <[email protected]>
To: Luis Henriques <[email protected]>, Bernd Schubert <[email protected]>
Cc: 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, 7 Jan 2025 19:59:06 +0100	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>



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.

> 
>> +		}
>> +	}
>>   }
>>   
>>   /*
>> @@ -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 18:59 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 [this message]
2025-01-07 21:25       ` Luis Henriques
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