From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com ([66.111.4.25]:55263 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727368AbfAHKfo (ORCPT ); Tue, 8 Jan 2019 05:35:44 -0500 From: Nikolaus Rath To: Miklos Szeredi Cc: fuse-devel , linux-fsdevel , Miklos Szeredi Subject: Re: [fuse-devel] fuse: trying to steal weird page References: <87o998m0a7.fsf@vostro.rath.org> <87ef9omb5f.fsf@vostro.rath.org> Date: Tue, 08 Jan 2019 10:35:40 +0000 In-Reply-To: (Miklos Szeredi's message of "Tue, 8 Jan 2019 09:27:35 +0100") Message-ID: <87ef9nighv.fsf@thinkpad.rath.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Jan 08 2019, Miklos Szeredi wrote: > On Mon, Jan 7, 2019 at 10:05 PM Nikolaus Rath wrote: >> >> On Jan 07 2019, Miklos Szeredi wrote: >> > On Wed, Dec 26, 2018 at 10:44 PM Nikolaus Rath wro= te: >> >> >> >> Hi, >> >> >> >> I am seeing relatively regular occurences of >> >> >> >> $ sudo dmesg | tail >> >> [21929.138815] fuse: trying to steal weird page >> >> [21929.138821] page=3D00000000a7dd2617 index=3D64 flags=3D17fffc00000= 00ad, >> >> count=3D1, mapcount=3D0, mapping=3D (null) >> >> [21930.647338] fuse: trying to steal weird page >> >> [21930.647345] page=3D00000000a07f32af index=3D2848 >> >> flags=3D17fffc0000000ad, count=3D1, mapcount=3D0, mapping=3D (null) >> >> [21932.338873] fuse: trying to steal weird page >> >> [21932.338879] page=3D0000000067e3a012 index=3D64 flags=3D17fffc00000= 00ad, >> >> count=3D1, mapcount=3D0, mapping=3D (null) >> >> [21933.930703] fuse: trying to steal weird page >> >> [21933.930710] page=3D00000000046feb25 index=3D845 >> >> flags=3D17fffc0000000ad, count=3D1, mapcount=3D0, mapping=3D (null) >> >> [21936.163174] fuse: trying to steal weird page >> >> [21936.163180] page=3D00000000fb80fe27 index=3D0 flags=3D17fffc000000= 0ad, >> >> count=3D1, mapcount=3D0, mapping=3D (null) >> > >> > The page has the PG_dity and PG_waiters flags set which are >> > incompatible with stealing. page_cache_pipe_buf_steal() does >> > apparently filter out dirty ones, so it's not a regular file that we >> > are trying to streal the page from. So the question is: what is the >> > source of the splice()? >> >> Hmm. I think it has to be a regular file. But as I mentioned in my other >> email, I did have a race condition where fd's were closed >> incorrectly. Is it possible that this also triggered the above, >> i.e. that the fd was closed sometime during splice? > > Close during a syscall that uses the fd is not an issue, because a ref > to the file is acquired. So the race is between the close() and the > internal fget(); if the close() wins then fget() will fail and the > syscall will return EBADF. If the fget() wins, then the syscall can > run normally despite the fact that the fd was closed. > > Can you tell me what filesystem is the regular file (the one being > spliced into fuse) is on? It's ext4. > It actually has to be a regular file, since AFAIK nothing else has > dirty pages. It could be using something other than > page_cache_pipe_buf_steal(), or there's some other mechanism that lets > the page be dirtied after being unmapped, though that looks > impossible... I can't meaningfully comment on that, sorry... Best, -Nikolaus --=20 GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F =C2=BBTime flies like an arrow, fruit flies like a Banana.=C2= =AB