Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp5662988ybh; Wed, 7 Aug 2019 09:22:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqx/V6YAvqmCK9YWPqepxhP/CBnc1vmbwZ5p+YWq5tir2cJp9/8MHBOMLJwta81RONHSp6Sz X-Received: by 2002:a63:2bd2:: with SMTP id r201mr8270569pgr.193.1565194976405; Wed, 07 Aug 2019 09:22:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565194976; cv=none; d=google.com; s=arc-20160816; b=nTmjPXUFOdJPmUwmmn74EjTDmIdLon8de9hT+DRFiwDP2HuLcJ+G/riLqXy5147tWe Koq9aXgDSjF8A3IARCrpYGfBgQ2Jt/Uoa7k3PSBC/vWayOdpSwI7SdroRTJ6XkmFq77Y RpG4tOIm0FFqgTDkqjqRYeY2TyldfNH82mc5XInJX1WFdpP+A9NOGPSM+I8gsXN/F4b1 wjtUw/SWvLtWVXebBNw4+/WYrIVWGn6JfcmmryejuLa0+i86Ufzqc4goJFzuB9Yjmy31 1nmYGeuznbtKcgYXpYwLfyf88/0pFZ06lpH66gBekiBqmqYdjvnZBHEMJPAjPsiNOPQE qEQA== 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=9rRv2tdDYAME0jDzjUd41r2Q/7zEQd+eMUzoCt6a3gM=; b=qGRnSDZpCG/4FKIqYD19nlzHQOp/rUujNHMAH/78KRNr1vkwwFpa3ZlBNiECxRRQDy CUO/Uc5fq5+SmjwrmnKEPUiHyUppvOCl59cocMjDGlZ6il+l8/zk5uEXZ91Qbi+q6s5w QyPu4aqBuaCIRGPfdkYM5wLRC7KND4S0JnRj76oOpMeMwgXnoBzypKCW7LKL1iJ4chv+ q46whmbnUJyCfudeM6LpKTW/UeAufYQ4o82MSFSxZRmnc7XRVDKO3PFODevn9jcQQuVu xrgB0wQY/r8c3qfcer4Qlq3WU9t3fcKbk02TRANAiX33vhIkFhN2nkxZt7q4q+SbXiX3 x4uw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b=fpFm9SNc; 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 x12si31794731pgq.220.2019.08.07.09.22.41; Wed, 07 Aug 2019 09:22:56 -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=fpFm9SNc; 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 S2388880AbfHGQBf (ORCPT + 99 others); Wed, 7 Aug 2019 12:01:35 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:52862 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729745AbfHGQBe (ORCPT ); Wed, 7 Aug 2019 12:01:34 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x77FhvPt186095; Wed, 7 Aug 2019 16:01:32 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=9rRv2tdDYAME0jDzjUd41r2Q/7zEQd+eMUzoCt6a3gM=; b=fpFm9SNc7siFT9SdDqaYqcb0xOqyXr8Di+OXrRB4eLAbiEBxNqUULPYbDBSleZiAUWqE XtcjPMkgDm4RZcaXb0bOqSLq4NWefmgFTg2BJmQSP5ksAfKdv07ctayR1L+pdh122Alg Bjk3p2Yc/sFCSjW/rvbugCTcvQJymRUXD2y7OmVtGkL/ypABtyyuVS8+ZcqeO+S5kg+O tZZzzwUpqZdN2pjJgG3Tepz+OcwM/q4wHpuZclfmb0mpagM9nYDvlVySafzYg0oLxB7A jXB57spZlyy9089ZB8F7OwXKV268CJxTpHxQtzsLNzclW5bmgPgb9ztoVea1HQWCUdGj oA== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 2u51pu5dvh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 07 Aug 2019 16:01:32 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x77Fh2ok080593; Wed, 7 Aug 2019 15:59:32 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3020.oracle.com with ESMTP id 2u763j1uht-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 07 Aug 2019 15:59:31 +0000 Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x77FxV8c000807; Wed, 7 Aug 2019 15:59:31 GMT Received: from Junxiaos-MacBook-Pro.local (/10.11.16.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Aug 2019 08:59:30 -0700 Subject: Re: [PATCH] block: fix RO partition with RW disk To: linux-block@vger.kernel.org Cc: linux-kernel@vger.kernel.org, axboe@kernel.dk, martin.petersen@oracle.com References: <20190805200138.28098-1-junxiao.bi@oracle.com> From: Junxiao Bi Message-ID: Date: Wed, 7 Aug 2019 08:59:27 -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: <20190805200138.28098-1-junxiao.bi@oracle.com> 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=9342 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 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-1908070162 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9342 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 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-1908070162 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Anybody could help review this bug? thanks, Junxiao. On 8/5/19 1:01 PM, 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;