Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3378558ybb; Tue, 31 Mar 2020 04:08:42 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtKCJS0h5JbZ39bf86dL6Q7tADw27vNEXJI4VfZzVxA56yd5Z/yTy4XL1o//REb/5+5K49J X-Received: by 2002:a9d:6ad2:: with SMTP id m18mr2857488otq.28.1585652921880; Tue, 31 Mar 2020 04:08:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585652921; cv=none; d=google.com; s=arc-20160816; b=Rbp6zC1atbfEJM3/wY7Y76h0zh5zM4rq/nyn2DbuGK8blOGpawoelD8SpvbWsnC5jU wdbDrXSwHeOWV+KTAP77XU8JLaMemxn6rd2riOpD1EYwu9VY63PIEDVUXydZB8arIaFe nw1hw0Dx8FYz64+8h13PImuHCzdPN3EFVuQqqXLNx79VUrscPTAdqsGr11t+lz4K8qh2 iM31xjR/KSnJBJjm6DSYOVdxZTFQRyA8EXcSsUuMg8p3mILgoZec4Fd98jUzZ5QWhAXA km9LUqqHMvDDux7VRFT6AE+EPTnErdO+RISxTVT7nrCZWVqzaglT3aNZ2YReT9WoJeP4 2peg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=6SunLuBMe+vgQlgqXWJyjNVJBKuLw4yF/i3GJkKwbCk=; b=kU+WzHxlUktUHhUMMOyGl9gTQhJrL6ehy+WAyYYwRVar+679Wq0eSnFD/erMVgFLox yvI6RS5msE1PMd9nbrxAVm/IkY5u3NJmVAgqgEi9UX5UgLOnclZzVOXEFBkR5a9Tnjay wlm6ekL9sFAL2sesynbnLfKwSBZCwzMT7dOzvs1ErJ5VmmI1cC5fc3AFqbHWh3fRR5ed 2KXxF8voJ0g/dmCs8peY7brXDctkDO6I20DLKOfB1GVE4vOfHEA7HA8OrvyzfT4Q7NH3 mLotqsq+MzzaQw3km4sJhsOwXl/q+RrCjWcU3zqKu3/wUvYBbjqLRZ8G01vMlZ7K/Edt xUbA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f23si608295oti.69.2020.03.31.04.08.29; Tue, 31 Mar 2020 04:08: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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730540AbgCaLGt (ORCPT + 99 others); Tue, 31 Mar 2020 07:06:49 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:57186 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730436AbgCaLGt (ORCPT ); Tue, 31 Mar 2020 07:06:49 -0400 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id E8ED3DB02715B946D6D2; Tue, 31 Mar 2020 19:06:43 +0800 (CST) Received: from [127.0.0.1] (10.67.102.197) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.487.0; Tue, 31 Mar 2020 19:06:34 +0800 Subject: Re: [PATCH v4] mtd: clear cache_state to avoid writing to bad blocks repeatedly To: Greg KH CC: , , , , , , , , References: <1585618319-119741-1-git-send-email-nixiaoming@huawei.com> <20200331100526.GC1204199@kroah.com> From: Xiaoming Ni Message-ID: <045c988f-4106-1c5c-f33a-8c2617eddbb1@huawei.com> Date: Tue, 31 Mar 2020 19:06:28 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <20200331100526.GC1204199@kroah.com> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.102.197] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/3/31 18:05, Greg KH wrote: > On Tue, Mar 31, 2020 at 09:31:59AM +0800, Xiaoming Ni wrote: >> The function call process is as follows: >> mtd_blktrans_work() >> while (1) >> do_blktrans_request() >> mtdblock_writesect() >> do_cached_write() >> write_cached_data() /*if cache_state is STATE_DIRTY*/ >> erase_write() >> >> write_cached_data() returns failure without modifying cache_state >> and cache_offset. So when do_cached_write() is called again, >> write_cached_data() will be called again to perform erase_write() >> on the same cache_offset. >> >> But if this cache_offset points to a bad block, erase_write() will >> always return -EIO. Writing to this mtdblk is equivalent to losing >> the current data, and repeatedly writing to the bad block. >> >> Repeatedly writing a bad block has no real benefits, >> but brings some negative effects: >> 1 Lost subsequent data >> 2 Loss of flash device life >> 3 erase_write() bad blocks are very time-consuming. For example: >> the function do_erase_oneblock() in chips/cfi_cmdset_0020.c or >> chips/cfi_cmdset_0002.c may take more than 20 seconds to return >> >> Therefore, when erase_write() returns -EIO in write_cached_data(), >> clear cache_state to avoid writing to bad blocks repeatedly. >> >> Signed-off-by: Xiaoming Ni >> Reviewed-by: Miquel Raynal >> --- >> drivers/mtd/mtdblock.c | 11 +++++++---- >> 1 file changed, 7 insertions(+), 4 deletions(-) > > $ ./scripts/get_maintainer.pl --file drivers/mtd/mtdblock.c > Miquel Raynal (maintainer:MEMORY TECHNOLOGY DEVICES (MTD)) > Richard Weinberger (maintainer:MEMORY TECHNOLOGY DEVICES (MTD)) > Vignesh Raghavendra (maintainer:MEMORY TECHNOLOGY DEVICES (MTD)) > linux-mtd@lists.infradead.org (open list:MEMORY TECHNOLOGY DEVICES (MTD)) > linux-kernel@vger.kernel.org (open list) > > > No where on there is my name/email, so why am I getting these? > > confused, > > greg k-h At v3, I added Cc: stable@vger.kernel.org and emailed you, At v4, Cc: stable@vger.kernel.org was deleted, but forgot to remove you from the recipient list I'm very sorry to bother you Thanks Xiaoming Ni