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=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 319E5C2B9F2 for ; Sat, 22 May 2021 07:45:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EC506611CB for ; Sat, 22 May 2021 07:45:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230000AbhEVHqt (ORCPT ); Sat, 22 May 2021 03:46:49 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:57051 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229990AbhEVHqt (ORCPT ); Sat, 22 May 2021 03:46:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621669524; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=h2vI6qAlLV/+LbtWLIAbep8Td7DB8/nLdLSULmPCA2k=; b=b3cs08NeXoA03gwp+4ysQdwvxTd0H5IXGCy73z+twC6M/jPzHgSzPyuZXULYJG89UhQrqT cU/bm9eXspJF3QEnrqnLjAjm7CgI3cH8SptRRJdrnzT1KatBhn/Ms5tHqmZr4QXj5dIaDo VZl0mv4zwAxescCnYCTXmn89arH390E= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-58-tC9wFz4xPm2K-paW3QMXaw-1; Sat, 22 May 2021 03:45:22 -0400 X-MC-Unique: tC9wFz4xPm2K-paW3QMXaw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 62E98180FD60; Sat, 22 May 2021 07:45:21 +0000 (UTC) Received: from T590 (ovpn-12-34.pek2.redhat.com [10.72.12.34]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D9D4560D4B; Sat, 22 May 2021 07:45:15 +0000 (UTC) Date: Sat, 22 May 2021 15:45:11 +0800 From: Ming Lei To: Brian Foster Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v3 1/3] iomap: resched ioend completion when in non-atomic context Message-ID: References: <20210517171722.1266878-1-bfoster@redhat.com> <20210517171722.1266878-2-bfoster@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210517171722.1266878-2-bfoster@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org On Mon, May 17, 2021 at 01:17:20PM -0400, Brian Foster wrote: > The iomap ioend mechanism has the ability to construct very large, > contiguous bios and/or bio chains. This has been reported to lead to BTW, it is actually wrong to complete a large bio chains in iomap_finish_ioend(), which may risk in bio allocation deadlock, cause bio_alloc_bioset() relies on bio submission to make forward progress. But it becomes not true when all chained bios are freed just after the whole ioend is done since all chained bios(except for the one embedded in ioend) are allocated from same bioset(fs_bio_set). Thanks, Ming