Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp3472038ybh; Mon, 5 Aug 2019 19:33:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqx1HAECpjMraKgCPa1nRAbRGmfsRhSg+db66WtJbh+8PcfccJamTxcV5f+KUUg68Dkwz+/a X-Received: by 2002:a62:1b0c:: with SMTP id b12mr1149841pfb.17.1565058786330; Mon, 05 Aug 2019 19:33:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565058786; cv=none; d=google.com; s=arc-20160816; b=VSGiw7ZQRxfsmw39MIbe9hHkLOhQzcEKFX8iGdcIw86oDzBnw6K8FYQkaoKL3p4YdG eAAd5C8o3a0KD1A6keYIn0kW1rYmhLlFTzAbJxEI6RWAmUuFZvmoVZ1G9w9GbDNVKyiv NA01uydL9SbpWAKvya1u75vQH8kJTN33OAFM2p0UeFQce5chgkzV63Fbq4IIRhrE0kRy 0Q0q6zLnX6ipVAjXjtO8avRH2Kh12lUfJOnc7PtkULYjB1Dmh9o61iejwRFlZnpIHEEG RTquF/lbfYqSduBok7mpHQdSraxFaZ5a88GRE27HkkPzJwSgInnHskPsW0/mckxadtml sGWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=9KLz+Sc5dsZcF8orhw4jY6EFCHjSbF9Gw+gngodgj+c=; b=UaoMhguXaIpXUzBL+HpREw749JhTl05qHkewgmitKFab/OfiwvP+9P+soM7Lkvj8pe U219FBi3SOTjIz4chY8Nl+g8sdk9XYr9NNxCewWFXjryMSEx8FgBCPEP2T72c6HKeREr XLb/Xux4kVooYLI8CciQpAGETdRvcTXBklxoAVHZWTIgeEM5gAVjsIchqxOwRIDrPzmY i5M9yvGBonm/2eu3GW8u9A7lPKCF0h2/1fqhxIjjqVm3q1zLZTUUP2ECS+Ts061dVeT0 Ovgga/+RG86BI7wYKJG9XdtcRxIlyH08KJRIFHOtQX4KjV5JW8neK+iwkSau6/J5t0WR 8BnA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b=uMpfetkW; 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=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 69si4107167pgc.40.2019.08.05.19.32.50; Mon, 05 Aug 2019 19:33:06 -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; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b=uMpfetkW; 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=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731526AbfHFCbU (ORCPT + 99 others); Mon, 5 Aug 2019 22:31:20 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:42874 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731506AbfHFCbT (ORCPT ); Mon, 5 Aug 2019 22:31:19 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x762SiQR113891; Tue, 6 Aug 2019 02:31:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=9KLz+Sc5dsZcF8orhw4jY6EFCHjSbF9Gw+gngodgj+c=; b=uMpfetkW0JMWjd5oQxmvQyoRnfc5PWZyu2p4NtVW6J2HRMB4sDTiphQsIqtmd88v+EYy 8/wkAeg4O40GI4oRVgR6IJX1khbyT3RdC09DTFhCMIcoH6bKeYM3nbHtvqUGuqphnTdP NJZxeMQ/PyFWT4I51n9m7qbotAnB8WDrqCU0LxUqpxCWjtx/edsLRiF541+sNftBuMcZ tC1Y225oH9zJVGcyHs94oOA7Ce7ttP6XhJktsza8wdI4SWlzTv+bMUXwdvUp+m7Uj6gK 8vNdU4MuVfW41jyA9my0LPcrLTbtPRRhwXOfe8R/Oi5nyBe2Zy5PAaGB2NCWkZ9oUawq 3Q== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 2u52wr2r59-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 06 Aug 2019 02:31:15 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x762SM1M018985; Tue, 6 Aug 2019 02:31:15 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 2u4ycuc61s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 06 Aug 2019 02:31:15 +0000 Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x762VDoN025978; Tue, 6 Aug 2019 02:31:13 GMT Received: from dhcp-10-159-244-74.vpn.oracle.com (/10.159.244.74) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Aug 2019 19:31:13 -0700 Subject: Re: [PATCH] block: fix RO partition with RW disk To: Dongli Zhang Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, axboe@kernel.dk, martin.petersen@oracle.com, "osandov@fb.com" References: <20190805200138.28098-1-junxiao.bi@oracle.com> From: Junxiao Bi Message-ID: <2f424a79-059b-be41-8f60-1397e2f9fdcf@oracle.com> Date: Mon, 5 Aug 2019 19:31:10 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9340 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=3 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908060028 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9340 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=3 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908060028 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Dongli, I think it's possible. A rough test case i can think is to create one loop device, one process issued BLKRRPART ioctl to re-read partition table(this will drop all partitions and recreate again) and another process set disk ro then rw. Let them race and check whether ro partition was left. Thanks, Junxiao. On 8/5/19 6:22 PM, Dongli Zhang wrote: > Hi Junxiao, > > While this is reported by md, is it possible to reproduce the error on purpose > with other device (e.g., loop) and add a test to blktests? > > Dongli Zhang > > On 8/6/19 4:01 AM, Junxiao Bi wrote: >> When md raid1 was used with imsm metadata, during the boot stage, >> the raid device will first be set to readonly, then mdmon will set >> it read-write later. When there were some partitions in this device, >> the following race would make some partition left ro and fail to mount. >> >> CPU 1: CPU 2: >> add_partition() set_disk_ro() //set disk RW >> //disk was RO, so partition set to RO >> p->policy = get_disk_ro(disk); >> if (disk->part0.policy != flag) { >> set_disk_ro_uevent(disk, flag); >> // disk set to RW >> disk->part0.policy = flag; >> } >> // set all exit partition to RW >> while ((part = disk_part_iter_next(&piter))) >> part->policy = flag; >> // this part was not yet added, so it was still RO >> rcu_assign_pointer(ptbl->part[partno], p); >> >> Move RO status setting of partitions after they were added into partition >> table and introduce a mutex to sync RO status between disk and partitions. >> >> Signed-off-by: Junxiao Bi >> --- >> block/genhd.c | 3 +++ >> block/partition-generic.c | 5 ++++- >> include/linux/genhd.h | 1 + >> 3 files changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/block/genhd.c b/block/genhd.c >> index 54f1f0d381f4..f3cce1d354cf 100644 >> --- a/block/genhd.c >> +++ b/block/genhd.c >> @@ -1479,6 +1479,7 @@ struct gendisk *__alloc_disk_node(int minors, int node_id) >> } >> ptbl = rcu_dereference_protected(disk->part_tbl, 1); >> rcu_assign_pointer(ptbl->part[0], &disk->part0); >> + mutex_init(&disk->part_lock); >> >> /* >> * set_capacity() and get_capacity() currently don't use >> @@ -1570,6 +1571,7 @@ void set_disk_ro(struct gendisk *disk, int flag) >> struct disk_part_iter piter; >> struct hd_struct *part; >> >> + mutex_lock(&disk->part_lock); >> if (disk->part0.policy != flag) { >> set_disk_ro_uevent(disk, flag); >> disk->part0.policy = flag; >> @@ -1579,6 +1581,7 @@ void set_disk_ro(struct gendisk *disk, int flag) >> while ((part = disk_part_iter_next(&piter))) >> part->policy = flag; >> disk_part_iter_exit(&piter); >> + mutex_unlock(&disk->part_lock); >> } >> >> EXPORT_SYMBOL(set_disk_ro); >> diff --git a/block/partition-generic.c b/block/partition-generic.c >> index aee643ce13d1..63cb6fb996ff 100644 >> --- a/block/partition-generic.c >> +++ b/block/partition-generic.c >> @@ -345,7 +345,6 @@ struct hd_struct *add_partition(struct gendisk *disk, int partno, >> queue_limit_discard_alignment(&disk->queue->limits, start); >> p->nr_sects = len; >> p->partno = partno; >> - p->policy = get_disk_ro(disk); >> >> if (info) { >> struct partition_meta_info *pinfo = alloc_part_info(disk); >> @@ -401,6 +400,10 @@ struct hd_struct *add_partition(struct gendisk *disk, int partno, >> /* everything is up and running, commence */ >> rcu_assign_pointer(ptbl->part[partno], p); >> >> + mutex_lock(&disk->part_lock); >> + p->policy = get_disk_ro(disk); >> + mutex_unlock(&disk->part_lock); >> + >> /* suppress uevent if the disk suppresses it */ >> if (!dev_get_uevent_suppress(ddev)) >> kobject_uevent(&pdev->kobj, KOBJ_ADD); >> diff --git a/include/linux/genhd.h b/include/linux/genhd.h >> index 8b5330dd5ac0..df6ddca8a92c 100644 >> --- a/include/linux/genhd.h >> +++ b/include/linux/genhd.h >> @@ -201,6 +201,7 @@ struct gendisk { >> */ >> struct disk_part_tbl __rcu *part_tbl; >> struct hd_struct part0; >> + struct mutex part_lock; >> >> const struct block_device_operations *fops; >> struct request_queue *queue; >>