public inbox for [email protected]
 help / color / mirror / Atom feed
From: Pavel Begunkov <[email protected]>
To: Christoph Hellwig <[email protected]>
Cc: [email protected], Jens Axboe <[email protected]>,
	Conrad Meyer <[email protected]>,
	[email protected], [email protected]
Subject: Re: [PATCH v4 5/8] block: implement async discard as io_uring cmd
Date: Tue, 10 Sep 2024 21:22:37 +0100	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 9/10/24 15:17, Christoph Hellwig wrote:
> On Tue, Sep 10, 2024 at 11:58:23AM +0100, Pavel Begunkov wrote:
>>>> +
>>>> +	err = filemap_invalidate_pages(bdev->bd_mapping, start,
>>>> +					start + len - 1, nowait);
>>>> +	if (err)
>>>> +		return err;
>>>> +
>>>> +	while ((bio = blk_alloc_discard_bio(bdev, &sector, &nr_sects, gfp))) {
>>>> +		if (nowait)
>>>> +			bio->bi_opf |= REQ_NOWAIT;
>>>> +		prev = bio_chain_and_submit(prev, bio);
>>>> +	}
>>>> +	if (!prev)
>>>> +		return -EAGAIN;
>>>
>>> If a user changes the max_discard value between the check above and
>>> the loop here this is racy.
>>
>> If the driver randomly changes it, it's racy either way. What do
>> you want to protect against?
> 
> The discard limit shrinking and now this successfully returning while
> not actually discarding the range.  The fix is pretty simple in that

If it's shrinking then bios initialised and submitted with that
initial larger limit should fail, e.g. by the disk or driver, which
would be caught by bio_cmd_bio_end_io(). If nobody fails bios, then
nothing ever will help here, you can always first queue up bios
and change the limit afterwards while they're still in flight.

> the nowait case should simply break out of the loop after the first bio.

while ((bio = blk_alloc_discard_bio(bdev, &sector, &nr_sects, gfp))) {
	if (nowait)
		bio->bi_opf |= REQ_NOWAIT;
	prev = bio_chain_and_submit(prev, bio);
	if (nowait)
		break;
}

Like this? I need to add nr_sects==0 post loop checking either way,
but I don't see how this break would be better any better than
bio_put before the submit from v2.

>>>> +sector_t bio_discard_limit(struct block_device *bdev, sector_t sector);
>>>
>>> And to be honest, I'd really prefer to not have bio_discard_limit
>>> exposed.  Certainly not outside a header private to block/.
>>
>> Which is the other reason why first versions were putting down
>> a bio seeing that there is more to be done for nowait, which
>> you didn't like. I can return back to it or narrow the scopre.
> 
> The above should also take care of that.
> 
>>
>>> Also why start at 137?  A comment
>>> would generally be pretty useful as well.
>>
>> There is a comment, 2 lines above the new define.
>>
>> /*
>>   * A jump here: 130-136 are reserved for zoned block devices
>>   * (see uapi/linux/blkzoned.h)
>>   */
>>
>> Is that your concern?
> 
> But those are ioctls, this is not an ioctl and uses a different
> number space.  Take a look at e.g. nvme uring cmds which also
> don't try to use the same number space as the ioctl.

As far as I see nvme cmds are just dropped onto the 0x80- range. Not
continuing ioctls, right, but nevertheless random and undocumented. And
if we're arguing that IOC helps preventing people issuing ioctls to a
wrong file type, we can easily extend it to "what if someone passes BLK*
ioctl number to io_uring or vise versa? Not to mention that most of the
IOC selling points have zero sense for io_uring like struct size and
struct copy direction.

>>> Also can we have a include/uapi/linux/blkdev.h for this instead of
>>> bloating fs.h that gets included just about everywhere?
>> I don't think it belongs to this series.
> 
> How would adding a proper header instead of bloating fs.h not be
> part of the series adding the first ever block layer uring_cmds?

Because, apparently, no one have ever gave a damn about it.
I'll add it for you, but with header probing instead of a simple
ifdef I'd call it a usability downgrade.

> Just in case I wasn't clear - this isn't asking you to move anything
> existing as we can't do that without breaking existing applications.

We can, by including blkdev.h into fs.h, but that's a different
kind of a structure.

> It is about adding the new command to the proper place.

-- 
Pavel Begunkov

  reply	other threads:[~2024-09-10 20:22 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-06 22:57 [PATCH v4 0/8] implement async block discards and other ops via io_uring Pavel Begunkov
2024-09-06 22:57 ` [PATCH v4 1/8] io_uring/cmd: expose iowq to cmds Pavel Begunkov
2024-09-06 22:57 ` [PATCH v4 2/8] io_uring/cmd: give inline space in request " Pavel Begunkov
2024-09-06 22:57 ` [PATCH v4 3/8] filemap: introduce filemap_invalidate_pages Pavel Begunkov
2024-09-06 22:57 ` [PATCH v4 4/8] block: introduce blk_validate_byte_range() Pavel Begunkov
2024-09-10  7:55   ` Christoph Hellwig
2024-09-06 22:57 ` [PATCH v4 5/8] block: implement async discard as io_uring cmd Pavel Begunkov
2024-09-10  8:01   ` Christoph Hellwig
2024-09-10 10:58     ` Pavel Begunkov
2024-09-10 14:17       ` Christoph Hellwig
2024-09-10 20:22         ` Pavel Begunkov [this message]
2024-09-12  9:28           ` Christoph Hellwig
2024-09-06 22:57 ` [PATCH v4 6/8] block: implement async write zeroes command Pavel Begunkov
2024-09-06 22:57 ` [PATCH v4 7/8] block: add nowait flag for __blkdev_issue_zero_pages Pavel Begunkov
2024-09-06 22:57 ` [PATCH v4 8/8] block: implement async write zero pages command Pavel Begunkov
2024-09-10  8:02   ` Christoph Hellwig
2024-09-10 12:17     ` Pavel Begunkov
2024-09-10 14:20       ` Christoph Hellwig
2024-09-10 20:10         ` Pavel Begunkov
2024-09-12  9:26           ` Christoph Hellwig
2024-09-12 16:38             ` Pavel Begunkov
2024-09-08 22:25 ` [PATCH v4 0/8] implement async block discards and other ops via io_uring Jens Axboe
2024-09-09 14:51 ` Jens Axboe
2024-09-09 15:33   ` Jens Axboe
2024-09-09 15:09 ` Jens Axboe

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] \
    /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