linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Bart Van Assche <bvanassche@acm.org>,
	Christian Brauner <brauner@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
	Avi Kivity <avi@scylladb.com>,
	Sandeep Dhavale <dhavale@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org
Subject: Re: [PATCH v2] fs, USB gadget: Rework kiocb cancellation
Date: Thu, 8 Feb 2024 16:05:28 -0700	[thread overview]
Message-ID: <184bf1b2-0626-4994-85f4-41fc4f71b956@kernel.dk> (raw)
In-Reply-To: <e71501ce-6fb9-42bc-89aa-fcf5d0384c9b@acm.org>

On 2/8/24 3:41 PM, Bart Van Assche wrote:
>> Just move the function higher up? It doesn't have any dependencies.
> 
> aio_cancel_and_del() calls aio_poll_cancel(). aio_poll_cancel() calls
> poll_iocb_lock_wq(). poll_iocb_lock_wq() is defined below the first call of
> aio_cancel_and_del(). It's probably possible to get rid of that function
> declaration but a nontrivial amount of code would have to be moved.

Ah yes, I mixed it up with the cancel add helper. Forward decl is fine
then, keeps the patch smaller for backporting too.

>>> +{
>>> +    void (*cancel_kiocb)(struct kiocb *) =
>>> +        req->rw.ki_filp->f_op->cancel_kiocb;
>>> +    struct kioctx *ctx = req->ki_ctx;
>>> +
>>> +    lockdep_assert_held(&ctx->ctx_lock);
>>> +
>>> +    switch (req->ki_opcode) {
>>> +    case IOCB_CMD_PREAD:
>>> +    case IOCB_CMD_PWRITE:
>>> +    case IOCB_CMD_PREADV:
>>> +    case IOCB_CMD_PWRITEV:
>>> +        if (cancel_kiocb)
>>> +            cancel_kiocb(&req->rw);
>>> +        break;
>>> +    case IOCB_CMD_FSYNC:
>>> +    case IOCB_CMD_FDSYNC:
>>> +        break;
>>> +    case IOCB_CMD_POLL:
>>> +        aio_poll_cancel(req);
>>> +        break;
>>> +    default:
>>> +        WARN_ONCE(true, "invalid aio operation %d\n", req->ki_opcode);
>>> +    }
>>> +
>>> +    list_del_init(&req->ki_list);
>>> +}
>>
>> Why don't you just keep ki_cancel() and just change it to a void return
>> that takes an aio_kiocb? Then you don't need this odd switch, or adding
>> an opcode field just for this. That seems cleaner.
> 
> Keeping .ki_cancel() means that it must be set before I/O starts and
> only if the I/O is submitted by libaio. That would require an approach
> to recognize whether or not a struct kiocb is embedded in struct
> aio_kiocb, e.g. the patch that you posted as a reply on version one of
> this patch. Does anyone else want to comment on this?

Maybe I wasn't clear, but this is in aio_req. You already add an opcode
in there, only to then add a switch here based on that opcode. Just have
a cancel callback which takes aio_req as an argument. For POLL, this can
be aio_poll_cancel(). Add a wrapper for read/write which then calls 
req->rw.ki_filp->f_op->cancel_kiocb(&req->rw); Then the above can
become:

aio_rw_cancel(req)
{
	void (*cancel_kiocb)(struct kiocb *) =
		req->rw.ki_filp->f_op->cancel_kiocb;

	cancel_kiocb(&req->rw);
}

aio_read()
{
	...
	req->cancel = aio_rw_cancel;
	...
}

static void aio_cancel_and_del(struct aio_kiocb *req)
{
	void (*cancel_kiocb)(struct kiocb *) =
		req->rw.ki_filp->f_op->cancel_kiocb;
	struct kioctx *ctx = req->ki_ctx;

	lockdep_assert_held(&ctx->ctx_lock);
	if (req->cancel)
		req->cancel(req);
	list_del_init(&req->ki_list);
}

or something like that. fsync/fdsync clears ->cancel() to NULL, poll
sets it to aio_poll_cancel(), and read/write like the above.

-- 
Jens Axboe


  reply	other threads:[~2024-02-08 23:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-08 21:55 [PATCH v2] fs, USB gadget: Rework kiocb cancellation Bart Van Assche
2024-02-08 22:14 ` Jens Axboe
2024-02-08 22:41   ` Bart Van Assche
2024-02-08 23:05     ` Jens Axboe [this message]
2024-02-08 23:16       ` Jens Axboe
2024-02-09  9:34   ` Christian Brauner
2024-02-09 18:12     ` Jens Axboe
2024-02-12 19:28       ` Bart Van Assche
2024-02-13 21:01         ` Bart Van Assche
2024-02-16 15:00           ` Christian Brauner

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=184bf1b2-0626-4994-85f4-41fc4f71b956@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=avi@scylladb.com \
    --cc=brauner@kernel.org \
    --cc=bvanassche@acm.org \
    --cc=dhavale@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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).