From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail-it1-f174.google.com ([209.85.166.174]:39670 "EHLO
        mail-it1-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1728112AbfAIIHp (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Wed, 9 Jan 2019 03:07:45 -0500
Received: by mail-it1-f174.google.com with SMTP id a6so9788569itl.4
        for <linux-fsdevel@vger.kernel.org>; Wed, 09 Jan 2019 00:07:44 -0800 (PST)
MIME-Version: 1.0
References: <87o998m0a7.fsf@vostro.rath.org> <CAJfpegtQic0v+9G7ODXEzgUPAGOz+3Ay28uxqbafZGMJdqL-zQ@mail.gmail.com>
 <87ef9omb5f.fsf@vostro.rath.org> <CAJfpegu_qxcaQToDpSmcW_ncLb_mBX6f75RTEn6zbsihqcg=Rw@mail.gmail.com>
 <87ef9nighv.fsf@thinkpad.rath.org>
In-Reply-To: <87ef9nighv.fsf@thinkpad.rath.org>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Wed, 9 Jan 2019 09:07:32 +0100
Message-ID: <CAJfpegtiXDgSBWN8MRubpAdJFxy95X21nO_yycCZhpvKLVePRA@mail.gmail.com>
Subject: Re: [fuse-devel] fuse: trying to steal weird page
To: fuse-devel <fuse-devel@lists.sourceforge.net>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Miklos Szeredi <mszeredi@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Tue, Jan 8, 2019 at 11:35 AM Nikolaus Rath <Nikolaus@rath.org> wrote:
>
> On Jan 08 2019, Miklos Szeredi <miklos@szeredi.hu> wrote:
> > On Mon, Jan 7, 2019 at 10:05 PM Nikolaus Rath <Nikolaus@rath.org> wrote:
> >>
> >> On Jan 07 2019, Miklos Szeredi <miklos@szeredi.hu> wrote:
> >> > On Wed, Dec 26, 2018 at 10:44 PM Nikolaus Rath <Nikolaus@rath.org> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> I am seeing relatively regular occurences of
> >> >>
> >> >> $ sudo dmesg | tail
> >> >> [21929.138815] fuse: trying to steal weird page
> >> >> [21929.138821] page=00000000a7dd2617 index=64 flags=17fffc0000000ad,
> >> >> count=1, mapcount=0, mapping= (null)
> >> >> [21930.647338] fuse: trying to steal weird page
> >> >> [21930.647345] page=00000000a07f32af index=2848
> >> >> flags=17fffc0000000ad, count=1, mapcount=0, mapping= (null)
> >> >> [21932.338873] fuse: trying to steal weird page
> >> >> [21932.338879] page=0000000067e3a012 index=64 flags=17fffc0000000ad,
> >> >> count=1, mapcount=0, mapping= (null)
> >> >> [21933.930703] fuse: trying to steal weird page
> >> >> [21933.930710] page=00000000046feb25 index=845
> >> >> flags=17fffc0000000ad, count=1, mapcount=0, mapping= (null)
> >> >> [21936.163174] fuse: trying to steal weird page
> >> >> [21936.163180] page=00000000fb80fe27 index=0 flags=17fffc0000000ad,
> >> >> count=1, mapcount=0, mapping= (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.

Next question: is file opened with O_DIRECT or is filesystem mounted
with DAX, or anything fancy?

Thanks,
Miklos