Received: by 10.213.65.68 with SMTP id h4csp1413669imn; Wed, 21 Mar 2018 10:03:41 -0700 (PDT) X-Google-Smtp-Source: AG47ELsKySExJSIGgPxmncYGtQpNWP35WHEwgl/DYaVdIj/pCGlm9/VYjQxHQ+yqxNHT2q0Zw9Hg X-Received: by 10.98.220.218 with SMTP id c87mr13551598pfl.198.1521651821191; Wed, 21 Mar 2018 10:03:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521651821; cv=none; d=google.com; s=arc-20160816; b=QakYimAhRUBMvLc9qa8Wcq4ocKxt+RLvSh6DWMy9bLqk8uvfgrLBJEdLcRZO/WbSPZ ZN2FMCi55BBnshHyJJzHIAvQ9EP5J4ooIeuKP8lIytg1/l4FU8Z2dKrJzkUvdHu8GM8e N2xEXB1f/4Ls5zWs5MYOwA/PwhUwVdTvqxYA8niomZ+ZZ0QsWMhp+9QuH07aB+fvta4C dI3AQ6OEgargxXoVHbMuC34jdjQwRlW8phDdhFK92gAPrx1FgZNRUXdDjEkX02QapnT6 bXFbdLT7ou/KZuEP/INtqOWR7vRwy+oCCGMzaVSYDxD5BQx5bO3W4nKtzNpp4jDyAxUd 3tig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=a62qXvRcoYIrJo2NOvpgxm3x4Cns5ZjYjpT4tT135uU=; b=VFalKLKfoU8ukvZQRpS4VDRFb3CK1yA7/vhNxbFfDvI7xy2nIDb1A9679ajQrBa7E/ EPtbs6wYsjG9+EbdAjQ/e6mkZQaOG1oGL8TQEK5RNtFh8t+Znk1kuhOVq9jDD9TMBa6Y f7kjbZiwk05nMw7ft9uGiZgjhQ60gE0/o1vp13eq87RbLugXaFRtrywak5h3P5yzcjl+ txR35hZ8TqpDCKuB/hQTpCc6XWIEwNh51AnWEZPDY8R1FmVf5aTQL9U3eyJiEQZSWGBi hleNDn2RM0ljDv6E+4y7DkYMZV2mAG4Er2FqeqCui/jgi6C14qTfjNuTGYeCdfHhgOni PiEg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n2-v6si4513443pls.497.2018.03.21.10.03.02; Wed, 21 Mar 2018 10:03:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752416AbeCURAt (ORCPT + 99 others); Wed, 21 Mar 2018 13:00:49 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:43126 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751641AbeCURAq (ORCPT ); Wed, 21 Mar 2018 13:00:46 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BC48FD4308; Wed, 21 Mar 2018 17:00:45 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (file01.intranet.prod.int.rdu2.redhat.com [10.11.5.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7AD089C073; Wed, 21 Mar 2018 17:00:43 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (localhost [127.0.0.1]) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4) with ESMTP id w2LH0hs6028381; Wed, 21 Mar 2018 13:00:43 -0400 Received: from localhost (mpatocka@localhost) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4/Submit) with ESMTP id w2LH0hLf028377; Wed, 21 Mar 2018 13:00:43 -0400 X-Authentication-Warning: file01.intranet.prod.int.rdu2.redhat.com: mpatocka owned process doing -bs Date: Wed, 21 Mar 2018 13:00:43 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: Jens Axboe cc: Richard Henderson , Ivan Kokshaysky , Matt Turner , Mike Snitzer , linux-block@vger.kernel.org, dm-devel@redhat.com, linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] block: use 32-bit blk_status_t on Alpha In-Reply-To: <502b7c1e-a95c-ff8d-64cd-9cbdd275fa1d@kernel.dk> Message-ID: References: <502b7c1e-a95c-ff8d-64cd-9cbdd275fa1d@kernel.dk> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 21 Mar 2018 17:00:45 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 21 Mar 2018 17:00:45 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'mpatocka@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 21 Mar 2018, Jens Axboe wrote: > On 3/21/18 10:42 AM, Mikulas Patocka wrote: > > Early alpha processors cannot write a single byte or word; they read 8 > > bytes, modify the value in registers and write back 8 bytes. > > > > The type blk_status_t is defined as one byte, it is often written > > asynchronously by I/O completion routines, this asynchronous modification > > can corrupt content of nearby bytes if these nearby bytes can be written > > simultaneously by another CPU. > > > > - one example of such corruption is the structure dm_io where > > "blk_status_t status" is written by an asynchronous completion routine > > and "atomic_t io_count" is modified synchronously > > - another example is the structure dm_buffer where "unsigned hold_count" > > is modified synchronously from process context and "blk_status_t > > write_error" is modified asynchronously from bio completion routine > > > > This patch fixes the bug by changing the type blk_status_t to 32 bits if > > we are on Alpha and if we are compiling for a processor that doesn't have > > the byte-word-extension. > > That's nasty. Is alpha the only problematic arch here? Yes. All the other architectures supported by Linux have byte writes. > As to the patch in question, normally I'd just say we should make it > unconditionally u32. But we pack so nicely in the bio, and I don't think > the bio itself has this issue as the rest of the members that share this > word are all set before the bio is submitted. But callers embedding > the status var in other structures don't necessarily have that > guarantee, as your dm examples show. > > -- > Jens Axboe Keeping blk_status_t 8-bit for most architectures will save a few bytes in some of device mapper structures. Mikulas