Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp39754pxb; Wed, 14 Apr 2021 08:58:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzLSnMXqeJwkaGvRbQC4s/2HXUMMOE0aUTeChK7UgY+X1ZX1xBildl0l6W4b/rn85Zt+OP4 X-Received: by 2002:aa7:9f48:0:b029:249:c2d7:b7d1 with SMTP id h8-20020aa79f480000b0290249c2d7b7d1mr6041123pfr.81.1618415881593; Wed, 14 Apr 2021 08:58:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618415881; cv=none; d=google.com; s=arc-20160816; b=TylkGTA1lMNHEZGRBC2WreK7LpnTNLVr2K1rT3sYsd+t0kukHqKQr2LndpHi5awFQP jyDzg7i+/cPC9RS1CWxUpxIfygz+zfOpF+gfffzobpL213eZ24qBHpUNqmu+nVbxW24Q ZkQHjEtWPTYGgHcD35keAlR2USgMnMUTpyhFmF3QM/JhtDV9Jj0g98AtrTkOIBSUx0lQ NnMu8hGtjLBP91Myr+ArnnOKKZz9N0If9U0Oq8LJ8bPj5MFyaYPxNpPKBD3KQHcD02qP PcCcNotD9iUFHn4K+vu1OVNDCkf+4fityCC22hS+mXk4JJwZkunf8X7AFB2iQVZMCDME hq9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=IX7qcrEu6HFQSyp3w8KMyWeid0wzPn8mCOmpMPv5Pjs=; b=HaQHx/ZQQfZfN0ggFcd84ML66dL8Q9N7Nq+buPJbUSOYXqC/TaTepKX+711J3p1fOa oL7bFNE65xNnZwnOv4jacE+VLeFD1zPH4xMuBCvg46HYyYTd9KlRtgb39YLbiEmsw5rC BXVgafbwwLX8rDP0nYViHZKHSnrCqwOcD7XMR+JM8NpwBmHTVt/wHD+jfF/Yg3zUZKop WAaDBZgOvPdjoZfi4xmGGrLfWwkZamFzJ84psaQJtarMVfKOc19uxYmJWRsGf4m9vIh/ aLNRneABxpJyC1RqBIratT2IXK1oBIv7+leDTAU82o0av2cuhRChhl3wVo362gE85bON taaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=ntdQ5YG1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g17si1790pjv.19.2021.04.14.08.57.46; Wed, 14 Apr 2021 08:58:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=ntdQ5YG1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351257AbhDNNUi (ORCPT + 99 others); Wed, 14 Apr 2021 09:20:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47158 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229450AbhDNNUh (ORCPT ); Wed, 14 Apr 2021 09:20:37 -0400 Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9DDE7C061574 for ; Wed, 14 Apr 2021 06:20:16 -0700 (PDT) Received: by mail-vk1-xa29.google.com with SMTP id u200so1797916vku.3 for ; Wed, 14 Apr 2021 06:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IX7qcrEu6HFQSyp3w8KMyWeid0wzPn8mCOmpMPv5Pjs=; b=ntdQ5YG1Gr5915B2/+DC5gbp2HzxCQkyXazZ+/W0Lfn/znpyilVyJvxBJO2wGCOJLD s1hxzdX+wZfmByqC1JppV6mb2abxvk8BFw96p6Gph1yfoBtZCDFnbdJq5UlcIY9IkBc5 bNOZwXfKXnisVQ0i5xV4CqTO1g3rgnF0Oet0E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IX7qcrEu6HFQSyp3w8KMyWeid0wzPn8mCOmpMPv5Pjs=; b=Dk3FivWXgygJ9Pc/YUwOxV0ZKSDkx8ocyx7dnCQ4XuBfapLGP2tFiFEWQNCnyrg6gy SGGfajc0EmWC2RdpbZfrv1mWNQ/sA269KWdjYcOGkS5Sz5ciGEUUsrtevb/DMcKZ+yBG AMSPtA4B6WQakoYXT7sKJyk/hYWMyqNlsmV3GdfYLVQXtZxyPFoQ/zmmh0dGvVWtztZp fxF6h0GSy4J9C6bzC70JeowATmbVlaPh9EECo74ngc9F56ft/LiShq22FjsB9YD39KYq wc0FMeXOKTQRBI9sFF79V0nDwrWCs8RaRtGxzlSwYIeUSdKVxUMXI+TcUf55R+USRJr+ bBzA== X-Gm-Message-State: AOAM531cq9QliykqBFMfXwG1xxmhIWrTi7wp62DvArf+RnUPEs4SNdZF wA/IVVBatvl22tv1GRGRdCvRZELr4k8KVV42tCQU9A== X-Received: by 2002:a1f:99cc:: with SMTP id b195mr5541459vke.19.1618406415804; Wed, 14 Apr 2021 06:20:15 -0700 (PDT) MIME-Version: 1.0 References: <807bb470f90bae5dcd80a29020d38f6b5dd6ef8e.1616826872.git.baolin.wang@linux.alibaba.com> In-Reply-To: From: Miklos Szeredi Date: Wed, 14 Apr 2021 15:20:04 +0200 Message-ID: Subject: Re: [PATCH v2 1/2] fuse: Fix possible deadlock when writing back dirty pages To: Peng Tao Cc: Baolin Wang , Peng Tao , "linux-fsdevel@vger.kernel.org" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 14, 2021 at 2:22 PM Peng Tao wrote: > > > --- a/fs/fuse/file.c > > +++ b/fs/fuse/file.c > > @@ -1117,17 +1117,12 @@ static ssize_t fuse_send_write_pages(str > > count = ia->write.out.size; > > for (i = 0; i < ap->num_pages; i++) { > > struct page *page = ap->pages[i]; > > + bool page_locked = ap->page_locked && (i == ap->num_pages - 1); > Any reason for just handling the last locked page in the page array? > To be specific, it look like the first page in the array can also be > partial dirty and locked? In that case the first partial page will be locked, and it'll break out of the loop... > > > > - if (!err && !offset && count >= PAGE_SIZE) > > - SetPageUptodate(page); > > - > > - if (count > PAGE_SIZE - offset) > > - count -= PAGE_SIZE - offset; > > - else > > - count = 0; > > - offset = 0; > > - > > - unlock_page(page); > > + if (err) > > + ClearPageUptodate(page); > > + if (page_locked) > > + unlock_page(page); > > put_page(page); > > } > > > > @@ -1191,6 +1186,16 @@ static ssize_t fuse_fill_write_pages(str > > if (offset == PAGE_SIZE) > > offset = 0; > > > > + /* If we copied full page, mark it uptodate */ > > + if (tmp == PAGE_SIZE) > > + SetPageUptodate(page); > > + > > + if (PageUptodate(page)) { > > + unlock_page(page); > > + } else { > > + ap->page_locked = true; > > + break; ... here, and send it as a separate WRITE request. So the multi-page case with a partial & non-uptodate head page will always result in the write request being split into two (even if there's no partial tail page). Thanks, Miklos