From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC59CC04AAD for ; Wed, 8 May 2019 09:57:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BC99C21479 for ; Wed, 8 May 2019 09:57:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726523AbfEHJ5g (ORCPT ); Wed, 8 May 2019 05:57:36 -0400 Received: from smtp.hosts.co.uk ([85.233.160.19]:13514 "EHLO smtp.hosts.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726281AbfEHJ5f (ORCPT ); Wed, 8 May 2019 05:57:35 -0400 X-Greylist: delayed 1688 seconds by postgrey-1.27 at vger.kernel.org; Wed, 08 May 2019 05:57:34 EDT Received: from [81.155.195.4] (helo=[192.168.1.118]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1hOItA-0006Nd-4w; Wed, 08 May 2019 10:29:24 +0100 Subject: Re: [PATCH 2/2] md/raid0: Do not bypass blocking queue entered for raid0 bios To: Song Liu , "Guilherme G. Piccoli" References: <20190430223722.20845-1-gpiccoli@canonical.com> <20190430223722.20845-2-gpiccoli@canonical.com> Cc: linux-block@vger.kernel.org, linux-raid , dm-devel@redhat.com, axboe@kernel.dk, Gavin Guo , Jay Vosburgh , kernel@gpiccoli.net, Ming Lei , Tetsuo Handa , stable@vger.kernel.org From: Wols Lists Message-ID: <5CD2A172.4010302@youngman.org.uk> Date: Wed, 8 May 2019 10:29:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On 06/05/19 22:07, Song Liu wrote: > Could you please run a quick test with raid5? I am wondering whether > some race condition could get us into similar crash. If we cannot easily > trigger the bug, we can process with this version. Bear in mind I just read the list and write documentation, but ... My gut feeling is that if it can theoretically happen for all raid modes, it should be fixed for all raid modes. What happens if code changes elsewhere and suddenly it really does happen for say raid-5? On the other hand, if fixing it in md.c only gets tested for raid-0, how do we know it will actually work for other raids if they do suddenly start falling through. Academic purity versus engineering practicality :-) Cheers, Wol