From: Christian Brauner <brauner@kernel.org>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jens Axboe <axboe@kernel.dk>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
Avi Kivity <avi@scylladb.com>,
Sandeep Dhavale <dhavale@google.com>,
stable@vger.kernel.org
Subject: Re: [PATCH v2] fs, USB gadget: Rework kiocb cancellation
Date: Fri, 16 Feb 2024 16:00:05 +0100 [thread overview]
Message-ID: <20240216-kannen-spanplatten-e08999ebb884@brauner> (raw)
In-Reply-To: <3304d956-9273-4701-91ce-08248ffd5007@acm.org>
On Tue, Feb 13, 2024 at 01:01:51PM -0800, Bart Van Assche wrote:
> On 2/12/24 11:28, Bart Van Assche wrote:
> > On 2/9/24 10:12, Jens Axboe wrote:
> > > Greg, can you elaborate on how useful cancel is for gadgets? Is it one
> > > of those things that was wired up "just because", or does it have
> > > actually useful cases?
> >
> > I found two use cases in the Android Open Source Project and have submitted
> > CLs that request to remove the io_cancel() calls from that code. Although I
> > think I understand why these calls were added, the race conditions that
> > these io_cancel() calls try to address cannot be addressed completely by
> > calling io_cancel().
>
> (replying to my own e-mail) The adb daemon (adbd) maintainers asked me to
> preserve the I/O cancellation code in adbd because it was introduced recently
> in that code to fix an important bug. Does everyone agree with the approach of
> the untested patches below?
But I mean, the cancellation code has seemingly been broken since
forever according to your patch description. So their fix which relies
on it actually fixes nothing? And they seemingly didn't notice until you
told them that it's broken. Can we get a link to that stuff, please?
Btw, you should probably provide that context in your patch series you
sent that Christoph and I responded too. Because I just stumbled upon
this here and it provided context I was missing.
prev parent reply other threads:[~2024-02-16 15:00 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
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 [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=20240216-kannen-spanplatten-e08999ebb884@brauner \
--to=brauner@kernel.org \
--cc=avi@scylladb.com \
--cc=axboe@kernel.dk \
--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