[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.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.