Received-SPF: pass (google.com: domain of linux-kernel+bounces-77711-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <CAPKjjnrYvzH8hEk9boaBt-fETX3VD2cjjN-Z6iNgwZpHqYUjWw@mail.gmail.com>
 <77a58302766cb6c8fac45682ede63569df80cd5d.camel@hammerspace.com> <1179779e2f74e3e5cb2be30cf89e6362aaab706d.camel@kernel.org>
In-Reply-To: <1179779e2f74e3e5cb2be30cf89e6362aaab706d.camel@kernel.org>
From: Zhitao Li <zhitao.li@smartx.com>
Date: Fri, 23 Feb 2024 11:20:37 +0800
Message-ID: <CAPKjjnrir1C8YYhhW10Nj6bAOTiz_YwWUOynEwXbjetMAuA1UA@mail.gmail.com>
Subject: Re: PROBLEM: NFS client IO fails with ERESTARTSYS when another mount
 point with the same export is unmounted with force [NFS] [SUNRPC]
To: Jeff Layton <jlayton@kernel.org>
Cc: Trond Myklebust <trondmy@hammerspace.com>, 
	"chuck.lever@oracle.com" <chuck.lever@oracle.com>, "tom@talpey.com" <tom@talpey.com>, 
	"anna@kernel.org" <anna@kernel.org>, "Dai.Ngo@oracle.com" <Dai.Ngo@oracle.com>, "neilb@suse.de" <neilb@suse.de>, 
	"kolga@netapp.com" <kolga@netapp.com>, "huangping@smartx.com" <huangping@smartx.com>, 
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for Jeff's reply.

I did see  ERESTARTSYS in userland. As described in the above
"Reproduction" chapter, "dd" fails with "dd: error writing
'/mnt/test1/1G': Unknown error 512".

After strace "dd", it turns out that syscall WRITE fails with:
write(1, "4\303\31\211\316\237\333\r-\275g\370\233\374X\277\374Tb\202\24\36=
5\220\320\16\27o3\331q\344\364"...,
1048576) =3D ? ERESTARTSYS (To be restarted if SA_RESTART is set)

In fact, other syscalls related to file systems can also fail with
ERESTARTSYS in our cases, for example: mount, open, read, write and so
on.

Maybe the reason is that on forced unmount, rpc_killall_tasks() in
net/sunrpc/clnt.c will set all inflight IO with ERESTARTSYS, while no
signal gets involved. So ERESTARTSYS is not handled before entering
userspace.

Best regards,
Zhitao Li at SmartX.

On Thu, Feb 22, 2024 at 7:05=E2=80=AFPM Jeff Layton <jlayton@kernel.org> wr=
ote:
>
> On Wed, 2024-02-21 at 13:48 +0000, Trond Myklebust wrote:
> > On Wed, 2024-02-21 at 16:20 +0800, Zhitao Li wrote:
> > > [You don't often get email from zhitao.li@smartx.com. Learn why this
> > > is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > Hi, everyone,
> > >
> > > - Facts:
> > > I have a remote NFS export and I mount the same export on two
> > > different directories in my OS with the same options. There is an
> > > inflight IO under one mounted directory. And then I unmount another
> > > mounted directory with force. The inflight IO ends up with "Unknown
> > > error 512", which is ERESTARTSYS.
> > >
> >
> > All of the above is well known. That's because forced umount affects
> > the entire filesystem. Why are you using it here in the first place? It
> > is not intended for casual use.
> >
>
> While I agree Trond's above statement, the kernel is not supposed to
> leak error codes that high into userland. Are you seeing ERESTARTSYS
> being returned to system calls? If so, which ones?
> --
> Jeff Layton <jlayton@kernel.org>