Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp3427733pxb; Mon, 4 Apr 2022 16:40:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwSB3gBhdzc6STqmd3mGnXRzo+dx92OverQ6DbO21vO4PeKzt0ezoikiyNXZEarCQIec8qN X-Received: by 2002:a17:902:e9d3:b0:154:6dd6:2533 with SMTP id 19-20020a170902e9d300b001546dd62533mr499725plk.31.1649115653846; Mon, 04 Apr 2022 16:40:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649115653; cv=none; d=google.com; s=arc-20160816; b=y3KSJ6WwGmfgl5MiZvOLSZjnJZuIPDIwIFFXuY9Jie/IdUNSjiAKFrhDs4rDve4deH kIAC3fSWg0E6p0W7ryvwfY6ZjIJOJx7i/x5aZKSt5TKJ2UdD0AgvQS8OzHo86r3YKAwS CV87P5kg5RZ6e5w9GeubrB1QxxMrNXpzqe26Z/H9TveKN4BU2kXr1NQtvzW64ckeSB6T D7AwNQ54nr3I7ytLH1DrNz3dzx/+t8YcrLXZHDVunuYjJpyyawDhfDItiwzguBlMu7qI LBDVQ19gjhrbENlS+5Pidr7Y3b5PD7p/68JHnT6jfz4BKD0CtKNNLqAp4eR+8UxCMlxM 4OYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=AW2odUn8nTWoWaqFUYDnM+G2cPt9hGIHz0eSd4qW9DQ=; b=ylGz2+2SbNZGGQyCrZq9dbQx+v++79L/nsHVBxAUV5hQ8RYGk5V/yKoLu3/3rP1zSB 1Q1pyPo9jsZvF1t5Q7wGKxYZi9kDJhFIYIfbkmeVlPfWMyZ3xSLESnL/zm/h/rGFyLTp a04uwvFjKT5kWqCTTuugggZkvAH1ObPXuSw3O/icKLT67H4l+3Uc33bR3ZYd67kW+7Tl Vmm3JnyEj4YO2XDtR2V0IZdUSPFqg7NHNtL5H1f4+FnHh4w0lhFHQoMqWsMZYKTuPG1s wUvXLocipB0RW/KLmqLK6/Ao8VbBFqElxOWakAiwVwX+V7SDWeLxdxyvZGg66VHc4fZ9 pd9A== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id t13-20020a17090a448d00b001ca8652ae03si533526pjg.116.2022.04.04.16.40.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 16:40:53 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4759A53A4D; Mon, 4 Apr 2022 16:32:36 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357096AbiDDFOk (ORCPT + 99 others); Mon, 4 Apr 2022 01:14:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58418 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239685AbiDDFOh (ORCPT ); Mon, 4 Apr 2022 01:14:37 -0400 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EFAFE381AA; Sun, 3 Apr 2022 22:12:41 -0700 (PDT) Received: from fsav119.sakura.ne.jp (fsav119.sakura.ne.jp [27.133.134.246]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 2345CHiA029025; Mon, 4 Apr 2022 14:12:17 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav119.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav119.sakura.ne.jp); Mon, 04 Apr 2022 14:12:17 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav119.sakura.ne.jp) Received: from [192.168.1.9] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 2345CGDP029017 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Apr 2022 14:12:17 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <67179a84-8be7-4c93-e355-2ca50666f960@I-love.SAKURA.ne.jp> Date: Mon, 4 Apr 2022 14:12:14 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [syzbot] INFO: task can't die in blkdev_common_ioctl Content-Language: en-US To: Christoph Hellwig Cc: syzbot , axboe@kernel.dk, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com, Jan Kara References: <0000000000007a4a2d05dba6baa6@google.com> From: Tetsuo Handa In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/04/04 13:58, Christoph Hellwig wrote: > On Sat, Apr 02, 2022 at 08:26:23PM +0900, Tetsuo Handa wrote: >>> git tree: linux-next >>> console output: https://syzkaller.appspot.com/x/log.txt?x=168d578db00000 >>> kernel config: https://syzkaller.appspot.com/x/.config?x=be9183de0824e4d7 >>> dashboard link: https://syzkaller.appspot.com/bug?extid=4f1a237abaf14719db49 >>> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 >>> >>> Unfortunately, I don't have any reproducer for this issue yet. >> >> This is a known problem, and Christoph does not like a mitigation patch. >> https://lkml.kernel.org/r/YgoQBTzb3b0l1SzP@infradead.org > > And this report shows why: your patch makes the lock acquisition in > blkdev_fallocate killable. Which would not help with this problem at > all, as it does not come through blkdev_fallocate. My patch proposes filemap_invalidate_lock_killable() and converts only blkdev_fallocate() case as a starting point. Nothing prevents us from converting e.g. blk_ioctl_zeroout() case as well. The "not come through blkdev_fallocate" is bogus. > The problem is that > the loop writing actual zeroes to the disk can take forever, and we > hold the invalidate_lock over that. There can be several locations which cannot be converted to filemap_invalidate_lock_killable() (like we had to use mutex_lock(&lo->lo_mutex) for lo_release() case). But many locations can be converted to filemap_invalidate_lock_killable() (like we use mutex_lock_killable(&lo->lo_mutex) for almost all locations). Being responsive to SIGKILL is good (even if we cannot afford making all locks killable). I made many locations killable. Therefore, I wonder why not?