From patchwork Wed Oct 25 09:38:09 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Miklos Szeredi X-Patchwork-Id: 10026213 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id B8D2C6032C for ; Wed, 25 Oct 2017 09:38:17 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A90A828AFB for ; Wed, 25 Oct 2017 09:38:17 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9D76F28B3F; Wed, 25 Oct 2017 09:38:17 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 44C2328AFB for ; Wed, 25 Oct 2017 09:38:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932346AbdJYJiP (ORCPT ); Wed, 25 Oct 2017 05:38:15 -0400 Received: from mail-wr0-f169.google.com ([209.85.128.169]:47173 "EHLO mail-wr0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932300AbdJYJiN (ORCPT ); Wed, 25 Oct 2017 05:38:13 -0400 Received: by mail-wr0-f169.google.com with SMTP id y39so23343468wrd.4 for ; Wed, 25 Oct 2017 02:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=1n6SqDCI04iO64fox5OJoddDrXLdltJzg/hWyy9j6jY=; b=qtj/UT8W/ExZPqVpL32W7jh+9hcWOF3pEjWuYcPIcJ08opeCySu2jx/lBMggOZ2x+5 wueeogn0XF1v2gBPbgfRRZ0tRxjpuPuWAju1Xb6ApFbGhIiZfpReu3/xAubuSFiXF0He JOlAO8+Z6H3HNMz/QHoinrgrXnJsaKpJbzJSU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=1n6SqDCI04iO64fox5OJoddDrXLdltJzg/hWyy9j6jY=; b=Rswmjdm0U1u5sM3eOYio5Q274rjyxGT3+8CmJBekhU9aAnWpOcy69Zho2aH5pzLEcx wKqi1p/Fq6ngraMLYZNu4VBJe2A1M5Y32EV/y/jp+wDIkhtADrfk+lrUoeV5HiiYekmX T2vwvsZ0p8yI36nhLK+BATZhQxNhhmvHlN8iSnMrCUN6P9UPM3NExVQJsvY5M3J9l67O w87NqCII5nvAEiDpWh9O+I6lgnEikm/kxuAYTt4nF/r7S8jbERPCY352HAC0ybwrY0MH T9o84UoWX94CA6fVItE1iUCR4IMhFOFsiGyA/T+3g62b6eIEz31eYNtLJl1XyaqNTteo og5A== X-Gm-Message-State: AMCzsaWV+NT6EIrp/5+vlI8TFBtCDiiI1+NKffEic9Matzmx5HKhC4eY jnn3O3ztxscchdxQf2HFevQF1Q== X-Google-Smtp-Source: ABhQp+SReL04LYHVz+MeRsUGqJ1HmY9RhNAwoUXtrefjeL+4GR5tYczq4ug0vQx5IqVO1FxxwyB7bw== X-Received: by 10.223.129.41 with SMTP id 38mr1656988wrm.57.1508924292402; Wed, 25 Oct 2017 02:38:12 -0700 (PDT) Received: from veci.piliscsaba.szeredi.hu (C2B0E321.catv.pool.telekom.hu. [194.176.227.33]) by smtp.gmail.com with ESMTPSA id q74sm2630235wrb.51.2017.10.25.02.38.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Oct 2017 02:38:11 -0700 (PDT) Date: Wed, 25 Oct 2017 11:38:09 +0200 From: Miklos Szeredi To: Jakob Unterwurzacher Cc: linux-fsdevel@vger.kernel.org, Kernel Mailing List Subject: Re: fuse readdirplus skip one entry when interrupted by signal Message-ID: <20171025093809.GB32700@veci.piliscsaba.szeredi.hu> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, Oct 24, 2017 at 08:10:49PM +0200, Jakob Unterwurzacher wrote: > A user running a Haskell program [1] noticed a problem with fuse's > readdirplus: when it is interrupted by a signal, it skips one > directory entry. > > The problem is most apparent with Haskell as it uses > SIGVTALRM to interrupt it's own green threads. > > A minimal reproducer in C, "ls-count.c", is available [2]. The problem > has been reproduced against libfuse's "passthrough_fh.c", but also against > gocryptfs, which uses go-fuse instead of libfuse. This suggest > that the bug is in kernel-space, which also the opinion of libfuse > upstream [3]. > > What "ls-count.c" does is that it loops over readdir while sending itself > SIGVTALRM. When the count of directory entries changes, it exits: > > $ ./ls-count b > ls-count: counts do not match: 2 vs 1 > > strace against ls-count shows that we get one entry, when we should get > two ("." and ".."): > > getdents(3, /* 1 entries */, 32768) = 24 > --- SIGVTALRM --- > rt_sigreturn({mask=[]}) = 24 > getdents(3, /* 0 entries */, 32768) = 0 > > The debug output from go-fuse [4] shows what seems to be happening: > > Dispatch 548: READDIRPLUS, NodeId: 1. data: {Fh 3 off 0 sz 4096} > Serialize 548: READDIRPLUS code: OK value: 320 bytes data > Dispatch 549: READDIRPLUS, NodeId: 1. data: {Fh 3 off 2 sz 4096} > Serialize 549: READDIRPLUS code: OK value: > > The kernel starts reading the directory from "off 0", where it is > interrupted, and only returns one entry to userspace. Then it continues > reading at "off 2". Offset 1 is skipped. > > I can reliably reproduce this within 1 second against kernel 4.12.5. Thanks for the report. The patch below should fix it. Thanks, Miklos --- From: Miklos Szeredi Subject: fuse: fix READDIRPLUS skipping an entry A user running a Haskell program noticed a problem with fuse's readdirplus: when it is interrupted by a signal, it skips one directory entry. The reason is that fuse erronously updates ctx->pos after a failed dir_emit(). The issue originates from the patch adding readdirplus support. Reported-by: Jakob Unterwurzacher Signed-off-by: Miklos Szeredi Fixes: 0b05b18381ee ("fuse: implement NFS-like readdirplus support") Cc: # v3.9 --- fs/fuse/dir.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/fuse/dir.c +++ b/fs/fuse/dir.c @@ -1308,7 +1308,8 @@ static int parse_dirplusfile(char *buf, */ over = !dir_emit(ctx, dirent->name, dirent->namelen, dirent->ino, dirent->type); - ctx->pos = dirent->off; + if (!over) + ctx->pos = dirent->off; } buf += reclen;