[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] xen/blkfront: Only check REQ_FUA for writes
- To: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Tue, 2 May 2023 17:57:54 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/QaIJbAvvaRh5Q90NiE5lmpweIBxxS9Nnf6nV7wK/SM=; b=d9fNLDW7+RpPR9dIp2ln/p3e6qODtN8CwUotzM3u51766kRzXux15W/oRUQm12ecxBTb8mgropqb19+xPP+HV9XEt0Y8lmCQk5ZDfFAX5GJW3HVzpgnWgRCCHKqNuMW0wZewLzABhFVGAOzq/sZwvNqEvaAp/4ReSzjA1AoCHYT/On7WFVL7aYNxskwBIxGvAwc6nNdPdVKu4SQ/Ed6lJxHkNKnE3m3/BPHGUL7NPeBxtBGCLJkZ2uOQ12c5xuavCyv3CR2L90NXnFy+aBEVae+6Wb6ueDRiNrqYOSHGXmPP4Lkvt32HDC5NDf1GRqgt3+mPnlFyO6xx00/5w/Jwyg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lo8U/uUvEB2ha2pgKN9vjq0+YRDvxQZVObgj6yJiMjJGwAvBarm+m9xtTOOi1JPhIUJJ/BXiNHofuaH74vKDaOKD2nB2nMN13Q+B6COn/bFnjiqCP7AtGnWdno6wWW49s72hNeRUB+0bA2bKTGTMdVWdAaA3FOVbpi39n7bGg7AlIAK9gkUHZr1Ra1ZEwAjDtcli3s9Dw5yzAE0aOD0KRL5edgUNYMDcUgU0FhsCBp7SLyalwsuxtZcfPxNH9yZnaMX8pvXEUFErg2li7Bk83SRdlc59bschA2zh2pXgPvlZZcVnsPPszxLFNCfE5hx8jPVqKT2bgbbgOd1qj/s+4g==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, jgross@xxxxxxxx, sstabellini@xxxxxxxxxx, oleksandr_tyshchenko@xxxxxxxx, axboe@xxxxxxxxx
- Delivery-date: Tue, 02 May 2023 15:58:20 +0000
- Ironport-data: A9a23:7FKgqqo7gnbY1C1D+urO8uX5ByBeBmLAZBIvgKrLsJaIsI4StFCzt garIBnVbvjZYDb2L9Aia9/j9UpT65bWndFlSFRsrypnQyNE8ZuZCYyVIHmrMnLJJKUvbq7FA +Y2MYCccZ9uHhcwgj/3b9ANeFEljfngqoLUUbKCYWYpA1c/Ek/NsDo788YhmIlknNOlNA2Ev NL2sqX3NUSsnjV5KQr40YrawP9UlKm06WJwUmAWP6gR5weDzyNNVvrzGInqR5fGatgMdgKFb 76rIIGRpgvx4xorA9W5pbf3GmVirmn6ZFXmZtJ+AsBOszAazsAA+v9T2Mk0MC+7vw6hjdFpo OihgLTrIesf0g8gr8xGO/VQO3kW0aSrY9YrK1Dn2SCY5xWun3cBX5yCpaz5VGEV0r8fPI1Ay RAXABIEcCCfpPOT+6i6FOpvuOIMLNvBGapK7xmMzRmBZRonabbqZvySoPN9gnI3jM0IGuvCb c0EbzYpdA7HfxBEJlYQDtQ5gfusgX78NTZfrTp5p4JuuzSVkFM3jeiraYKNEjCJbZw9ckKwv GXJ8n6/GhgHHNee1SCE4jSngeqncSbTAdpCTOXop6466LGV7lIVLBoTaXuUmqSat2iwYslPK RRL1DV7+MDe82TuFLERRSaQsHOC+xIRRddUO+k78x2WjLrZ5R6DAWoJRSIHb8Yp3Oc0SiYtz UShhM7yCHpkt7j9YWmG6r6eoDe2OC4UBWwPfykJSU0C+daLiIY3gxHUR9BvCpmpn8b1EjH9x TONhCUmjrBVhskOv42y7VrAjhqvq4LPQwpz6ga/Y46+xgZwZYrga4n271HetK5ENNzAFgHHu 2UYkc+D6uxIFYuKiCGGXOQKGveu+uqBNzrfx1VoGvHN6giQxpJqRqgIiBkWGaujGpxslePBC KMLhT5s2Q==
- Ironport-hdrordr: A9a23:6xcJG6t5EXH8F1FhSsRe4IlT7skCF4Aji2hC6mlwRA09TyXGra 2TdaUgvyMc1gx7ZJhBo7+90We7MBbhHLpOkPEs1NaZLXDbUQ6TQL2KgrGD/9SNIVycygcZ79 YaT0EcMqyNMbEZt7ec3ODQKb9Jrri6GeKT9IHjJh9WPHxXgspbnmNE42igYy9LrF4sP+tCKH PQ3Lswm9LmEk5nHviTNz0gZazuttfLnJXpbVovAAMm0hCHiXeF+aP3CB+R2zYZSndqza05+W bIvgTl7uH72svLgCP05iv21dB7idHhwtxMCIiljdUUECzljkKFdZlsQLqLuREyuaWK5EwxmN fBjh88N4BY6m/XfEuyvRzxsjOQmwoG2jvH8xu1kHHjqcv2SHYTDNdAv5tQdl/851A7tN9x/a pX1ybB3qAnRS/orWDY3ZzlRhtqnk27rT4LlvMStWVWVc87ZKVKpYIS0UtJGNMrHT786qogDO 5yZfusrcp+QBe/VTT0r2NvyNujUjAaGQqHeFELvoiv3z1fjBlCvj4l7f1auk1F2IM2SpFC6e iBGL9vjqtyQsgfar84LPsdQOOsY1a9Dy7kASa3GxDKBasHM3XCp9rc+7Mu/tynf5QO0d8bhI nBalVFrmQ/EnieRvFm5Kc7siwlfV/NHggEkqplltpEU/zHNfbW2BS4ORETe5DKmYRbPiXZM8 zDSq6+TcWTaVcGIrw5rjEWa6MiVkX2b/dlxOrTe2j+1v4jebeawdDzQbL0GIfHNwoCdyfWPk YjNQKDV/moqHrbF0PFvA==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Wed, Apr 26, 2023 at 05:40:05PM +0100, Ross Lagerwall wrote:
> The existing code silently converts read operations with the
> REQ_FUA bit set into write-barrier operations. This results in data
> loss as the backend scribbles zeroes over the data instead of returning
> it.
>
> While the REQ_FUA bit doesn't make sense on a read operation, at least
> one well-known out-of-tree kernel module does set it and since it
> results in data loss, let's be safe here and only look at REQ_FUA for
> writes.
Do we know what's the intention of the out-of-tree kernel module with
it's usage of FUA for reads?
Should this maybe be translated to a pair of flush cache and read
requests?
> Signed-off-by: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
> ---
> drivers/block/xen-blkfront.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 23ed258b57f0..c1890c8a9f6e 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -780,7 +780,8 @@ static int blkif_queue_rw_req(struct request *req, struct
> blkfront_ring_info *ri
> ring_req->u.rw.handle = info->handle;
> ring_req->operation = rq_data_dir(req) ?
> BLKIF_OP_WRITE : BLKIF_OP_READ;
> - if (req_op(req) == REQ_OP_FLUSH || req->cmd_flags & REQ_FUA) {
> + if (req_op(req) == REQ_OP_FLUSH ||
> + (req_op(req) == REQ_OP_WRITE && (req->cmd_flags &
> REQ_FUA))) {
Should we print some kind of warning maybe once that we have received
a READ request with the FUA flag set, and the FUA flag will have no
effect?
Thanks, Roger.
|