linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>, linux-block@vger.kernel.org
Subject: Re: [PATCH v2] loop: avoid EAGAIN, if offset or block_size are changed
Date: Tue, 26 Nov 2019 16:26:23 -0800	[thread overview]
Message-ID: <3ca36251-57c4-b62c-c029-77b643ddea77@acm.org> (raw)
In-Reply-To: <20191127000407.GC20652@jaegeuk-macbookpro.roam.corp.google.com>

On 11/26/19 4:04 PM, Jaegeuk Kim wrote:
> Subject: [PATCH] loop: avoid EAGAIN, if offset or block_size are changed
> 
> This patch tries to avoid EAGAIN due to nrpages!=0 that was originally trying
> to drop stale pages resulting in wrong data access.

Does this patch remove all code that returns EAGAIN from the code paths 
used for changing the offset and block size? If so, please make the 
commit message more affirmative.

>   	if (lo->lo_offset != info->lo_offset ||
> -	    lo->lo_sizelimit != info->lo_sizelimit) {
> -		sync_blockdev(lo->lo_device);
> -		kill_bdev(lo->lo_device);
> -	}
> +	    lo->lo_sizelimit != info->lo_sizelimit)
> +		drop_caches = true;

If the offset is changed and dirty pages are only flushed after the loop 
device offset has been changed, can that cause data to be written at a 
wrong LBA? In other words, I'd like to keep a sync_blockdev() call here.

> +	/* truncate stale pages cached by previous operations */
> +	if (!err && drop_caches) {
> +		sync_blockdev(lo->lo_device);
> +		invalidate_bdev(lo->lo_device);
> +	}

Is the invalidate_bdev() call necessary here?

Thanks,

Bart.

  reply	other threads:[~2019-11-27  0:26 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-18  0:47 [PATCH] loop: avoid EAGAIN, if offset or block_size are changed Jaegeuk Kim
2019-05-18  0:53 ` [PATCH v2] " Jaegeuk Kim
2019-06-17 21:08   ` [f2fs-dev] " Jaegeuk Kim
2019-11-18 18:36     ` Andrew Norrie
2019-11-19  4:00       ` Greg KH
2019-11-19 23:40   ` [PATCH v2] " Bart Van Assche
2019-11-25 17:59     ` Jaegeuk Kim
2019-11-25 18:35       ` Bart Van Assche
2019-11-25 19:22         ` Jaegeuk Kim
2019-11-25 19:41           ` Bart Van Assche
2019-11-25 22:27             ` Bart Van Assche
2019-11-26 18:29               ` Jaegeuk Kim
2019-11-26 18:59                 ` Bart Van Assche
2019-11-26 22:32                   ` Jaegeuk Kim
2019-11-26 22:54                     ` Bart Van Assche
2019-11-27  0:04                       ` Jaegeuk Kim
2019-11-27  0:26                         ` Bart Van Assche [this message]
2019-11-27  1:09                           ` Jaegeuk Kim
2019-11-27 16:35                             ` Bart Van Assche
2019-11-27 18:17                               ` Jaegeuk Kim
2019-11-27 18:18   ` [f2fs-dev] [PATCH v3] " Jaegeuk Kim
2019-11-27 18:54     ` Bart Van Assche
2020-02-19 19:58       ` Andrew Norrie
2020-03-05 21:04 ` [PATCH] " Jan Kara
2019-06-10 21:49 [PATCH v2] loop: avoid EAGAIN, if offset or block size " Francesco Ruggeri

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=3ca36251-57c4-b62c-c029-77b643ddea77@acm.org \
    --to=bvanassche@acm.org \
    --cc=axboe@kernel.dk \
    --cc=jaegeuk@kernel.org \
    --cc=linux-block@vger.kernel.org \
    /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).