Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp734751ybg; Mon, 1 Jun 2020 13:01:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyuUG7T3rvl5hl1vztNlFYfdOpshgx6RZ3aoauhz6Sl3a7yJplT/5NWCZ/jzhhtCWC/CCWW X-Received: by 2002:a17:906:1c02:: with SMTP id k2mr14558463ejg.37.1591041681502; Mon, 01 Jun 2020 13:01:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591041681; cv=none; d=google.com; s=arc-20160816; b=Zm96BCuHL8z5gyQ0t1HwiUvHXmbTss+8SsEXLUFZsCXHheGeoGm9v/VAlllqXlTUyc scSMsIcU/6A/UM76A3fAlX9fUdpHPw5ni4WcxYFYsZMZKyhx0nJSffmQVG9OlV50JKen cXwJJWepLDKP0VQb4TjgY9gEVL38q8gtUQE4NA1HdtkmpvNgnp12juBXD5N8H3IAujew 7kWmfKNZyinNDeFzN7/PAV+kZnDkwyUqANYQHsem4w348FZr6arexpw4cwoffYF0bArR 9Yyj1dIwcoCPzIY2ZFvAM0+mh5jUVMM1/qcXYigSnRJkJCjW3BSGfPLoSemOPu3FdkNJ vyRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:date:cc:to:from:subject:message-id:dkim-signature; bh=HmLxgKHhSqoffCsMGJp7UW0iC0JJMz702xF6zdCQDcc=; b=azWcRucqcFAhwVJb/aG16SIwvBdjziExPJ6YhvhhpAT4nHRbBuNr/dSnj+NAid4oWj Q4R/ObZ+legobBSNofdhAGTjr/SPw04oV92sgail4lroaqiHmmCgIuzSoVdpjS6RdYR3 BxQG2lgP+oZcNuj2QieihLFTekIvJX6Pp/rOu1hbxsQ7UUTrprgiNo7zNG620EVdceNf V/4++OcpbEVsRjknrjUuq7Y/kM06+8JBE4DYva2+8e9ekWuDOhYpOeHfUx2lUQJe7Nxu hGiy5O7LY295Bqp8AZIgaCNmjs/DhzCEFDKGYFKL0e0kT8TiOfZxurzsJDNtZbCirCO+ 5QwA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QxUB1GbJ; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x15si288473ejv.88.2020.06.01.13.00.58; Mon, 01 Jun 2020 13:01:21 -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=pass header.i=@gmail.com header.s=20161025 header.b=QxUB1GbJ; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728214AbgFAT6m (ORCPT + 99 others); Mon, 1 Jun 2020 15:58:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726176AbgFAT6l (ORCPT ); Mon, 1 Jun 2020 15:58:41 -0400 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1073C061A0E; Mon, 1 Jun 2020 12:58:40 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id c3so1012881wru.12; Mon, 01 Jun 2020 12:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:user-agent:mime-version :content-transfer-encoding; bh=HmLxgKHhSqoffCsMGJp7UW0iC0JJMz702xF6zdCQDcc=; b=QxUB1GbJmPHvTixVnQgpr2TEllEb0ZpwdL3xdDJWmFPAVnmU65UtgQOxdhVZgyGnoY +eC515mbZ1zaHvn92iDWleU1XDwB3H5FJRYX/bzhCC/7MV0IV4gA6lssweR9I6zydLsR rQ1gB3z/1gNI+LWV6VflHyYdPJvpncXFqXu+Y0MLY47MfBegurwRL0I/Syj9P+B13FUn fLQ/U3kcrj2Sdg+8vFITl8OGuv5VkAgwGzZntN7kycD9PfH66QmeBWIw6pHGrxKt2IHn n9zZ/2RlDltaLjVBuqGTT3NMW2b3DSjCyoHmH1otEhEL/uRSzh1rcUzPcPNWkgtj0CJA zZ/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:user-agent :mime-version:content-transfer-encoding; bh=HmLxgKHhSqoffCsMGJp7UW0iC0JJMz702xF6zdCQDcc=; b=ZIAMWj+8DYYJpm2TEM7jATbWv7whSuSUhcNy1SYydki34h8EWh6s/2u8FLEenBAKoh Lgpe+oT0AozlJOVbxwOI2rTOFbu+qCFz/zqee7IEEirSqTdyoOkuNhOrSga/utPSktz5 BgBg1zRJrRvZFnH1FOR2xzT98HXtonihxR3vTyMPD0DEDrjYriFvnDgO/mN0cZRfBco4 q+8XGur51uAvI/UXlxL3aoQvsPYUPtNLuEQTAQnpioNLYXDijFd9xDPiiQK2wo8D4DTJ RvgRuDLw9BjvBIQAu4XPcZGjXXh/4EiMIBoppyNF1f2K46MHfrhYNy4OACXDeLXLV1Kf P18A== X-Gm-Message-State: AOAM5318zpV9iibr6gqtmaHVSH9x3UBH5+wgYAVVriLhFVhwL76CYucX xb9sqgekeICbzIKgbOHiRa5zeA2Kjho= X-Received: by 2002:adf:a51c:: with SMTP id i28mr22871392wrb.78.1591041519035; Mon, 01 Jun 2020 12:58:39 -0700 (PDT) Received: from 2a02-8388-1684-3280-30c7-7e1b-0096-f726.cable.dynamic.v6.surfer.at (2a02-8388-1684-3280-30c7-7e1b-0096-f726.cable.dynamic.v6.surfer.at. [2a02:8388:1684:3280:30c7:7e1b:96:f726]) by smtp.gmail.com with ESMTPSA id u74sm559837wmu.13.2020.06.01.12.58.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2020 12:58:38 -0700 (PDT) Message-ID: <2d735cb666872099b2c4c574e35aaeac2f7356ad.camel@gmail.com> Subject: cifs vs Go: EINTR and ENOENT errors from getdents64 From: Jakob Unterwurzacher To: linux-cifs@vger.kernel.org Cc: linux-kernel@vger.kernel.org Date: Mon, 01 Jun 2020 21:58:36 +0200 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.2 (3.36.2-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, author of gocryptfs here, an encrypted overlay filesystem written in Go. A gocryptfs user reported [1] hitting EINTR errors when gocryptfs is used on a cifs mount. I wrote a minimal reproducer, getdents.go [2], that runs getdents64 in a loop and I can reproduce the issue easily. I additionally see ENOENT errors. The errors can also be seen via the high-level Readdirnames() function that the Go stdlib provides [6]. I am running kernel 5.6.13 and Samba 4.12.2 for this test. I have a cifs share mounted as shown in [3], populated with 1001 empty files using touch $(seq 1000 2000) . When running getdents.go [2] against this mount, good cases look like this (output from getdents.go): --- example 0 --- unix.Getdents: n=4176; n=4176; n=4176; n=4176; n=4176; n=3192; n=0; err=; total 24072 bytes unix.Getdents: n=4176; n=4176; n=4176; n=4176; n=24; n=4152; n=3192; n=0; err=; total 24072 bytes INTR errors look like this (getdents.go output and corresponding kernel debug messages that were enabled acc. to [4]): --- example 1 --- unix.Getdents: n=-1; err=interrupted system call; total 0 bytes [168340.499471] fs/cifs/file.c: CIFS VFS: leaving cifs_closedir (xid = 24238) rc = 0 [168340.599686] fs/cifs/readdir.c: Full path: start at: 0 [168340.599696] fs/cifs/transport.c: signal is pending before sending any data [168340.599698] smb2_add_credits: 310 callbacks suppressed [168340.599699] fs/cifs/smb2ops.c: add 1 credits total=8192 [168340.599701] fs/cifs/smb2ops.c: query_dir_first: open failed rc=-4 [168340.599702] fs/cifs/readdir.c: initiate cifs search rc -4 [168340.599979] fs/cifs/file.c: Closedir inode = 0x0000000067f9a79c [168340.599981] fs/cifs/file.c: CIFS VFS: in cifs_closedir as Xid: 24240 with uid: 1026 [168340.599982] fs/cifs/file.c: Freeing private data in close dir [168340.599983] fs/cifs/file.c: CIFS VFS: leaving cifs_closedir (xid = 24240) rc = 0 --- example 2 --- unix.Getdents: n=-1; err=interrupted system call; total 0 bytes [168453.792894] Status code returned 0x80000006 STATUS_NO_MORE_FILES [168453.893360] fs/cifs/transport.c: signal is pending before sending any data [168453.893363] fs/cifs/smb2ops.c: query_dir_first: open failed rc=-4 ENOENT errors look like this: --- example 3 --- unix.Getdents: n=4176; n=4176; n=4176; n=4176; n=4176; n=-1; err=no such file or directory; total 20880 bytes [168517.187072] Status code returned 0x80000006 STATUS_NO_MORE_FILES [168517.300252] fs/cifs/transport.c: signal is pending before sending any data [168517.300255] fs/cifs/readdir.c: fce error -2 --- example 4 --- unix.Getdents: n=4176; n=4176; n=4176; n=1440; n=2736; n=-1; err=no such file or directory; total 16704 bytes [168650.603145] Status code returned 0x80000006 STATUS_NO_MORE_FILES [168650.713831] fs/cifs/transport.c: signal is pending before sending any data [168650.713835] fs/cifs/readdir.c: fce error -2 I have the same thing written in C does not show any problems [5]. The Go runtime uses signals heavily, could this be a reason for the behavoir I am seeing? I can trigger the problem more quickly when I resize the terminal window (causing SIGWINCH). Note that the Go runtime sets SA_RESTART on all signal handlers. I can handle the EINTR errors by retrying, no problem. Should I also retry when I get ENOENT? Thanks, Jakob [1] https://github.com/rfjakob/gocryptfs/issues/483 [2] https://github.com/rfjakob/gocryptfs/blob/master/contrib/getdents-debug/getdents/getdents.go [3] //127.0.0.1/samba-test on /mnt/samba-test type cifs (rw,relatime,vers=3.1.1,cache=strict,username=jakob,uid=1026,forceuid,gid=1026,forcegid,addr=127.0.0.1,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mappos ix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,user=jakob) [4] https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Enabling_Debugging [5] https://github.com/rfjakob/gocryptfs/blob/master/contrib/getdents-debug/getdents_c/getdents.c [6] https://github.com/golang/go/issues/39237