All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolaus Rath <Nikolaus@rath.org>
To: linux-fsdevel@vger.kernel.org
Cc: fuse-devel <fuse-devel@lists.sourceforge.net>,
	linux-mm <linux-mm@kvack.org>, miklos <mszeredi@redhat.com>,
	"Gabriel Krisman Bertazi" <krisman@collabora.com>,
	"André Almeida" <andrealmeid@collabora.com>
Subject: Re: fuse: trying to steal weird page
Date: Sat, 02 May 2020 20:52:48 +0100	[thread overview]
Message-ID: <877dxut8q7.fsf@vostro.rath.org> (raw)
In-Reply-To: <87a72qtaqk.fsf@vostro.rath.org> (Nikolaus Rath's message of "Sat, 02 May 2020 20:09:23 +0100")

On May 02 2020, Nikolaus Rath <Nikolaus@rath.org> wrote:
> Hello,
>
> I have recently noticed that a FUSE filesystem regularly produces many
> kernel messages like this:
>
> [ 2333.009931] fuse: trying to steal weird page
> [ 2333.009937] fuse: page=00000000dd1750e3 index=2022240 flags=17ffffc0000097, count=1,
> mapcount=0, mapping=00000000125079ad
> [ 2334.595835] fuse: trying to steal weird page
> [ 2334.595841] fuse: page=000000009e8626ac index=2052288 flags=17ffffc0000097, count=1,
> mapcount=0, mapping=00000000125079ad
> [ 2334.983568] fuse: trying to steal weird page
> [ 2334.983572] fuse: page=0000000013fdd9e4 index=2059392 flags=17ffffc0000097, count=1,
> mapcount=0, mapping=00000000125079ad
> [ 2335.979905] fuse: trying to steal weird page
> [ 2335.979911] fuse: page=00000000a7057848 index=2078588 flags=17ffffc0000097, count=1,
> mapcount=0, mapping=00000000125079ad
>
> They do not seem to correlate with userspace errors, but I noticed that
> there is no significant performance difference between libfuse using
> splice, splice with SPLICE_MOVE, and not using splice. This is somewhat
> unexpected, so maybe it is related to the kernel messages?
>
> What are the implications of the above kernel message? Is there a way to
> provide more debugging information?
>
> (I have reported a similar issue before
> (https://marc.info/?l=linux-mm&m=155290847909996&w=2) and the patch may
> not be present in the kernel that I'm using. However, the previous time
> the warning had a different set of flags and a null mapping, so I think
> this one is different).
>
> $ uname -a
> Linux valve 5.3.0-46-generic #38-Ubuntu SMP Fri Mar 27 17:37:05 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux


I have now reproduced this with a vanilla 5.6 kernel.

I also found that the "mapping" and "flags" parameters always have the
same values - even across different workloads and when re-mounting the
filesystem. The "page" parameter varies.


Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

  reply	other threads:[~2020-05-02 19:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-02 19:09 fuse: trying to steal weird page Nikolaus Rath
2020-05-02 19:52 ` Nikolaus Rath [this message]
2020-05-03  3:26   ` Matthew Wilcox
2020-05-03  8:43     ` [fuse-devel] " Nikolaus Rath
2020-05-03 10:27       ` Matthew Wilcox
2020-05-03 18:28         ` Gabriel Krisman Bertazi
2020-05-03 20:06           ` Matthew Wilcox
2020-05-03 20:25           ` Nikolaus Rath
2020-05-06 13:57             ` Vlastimil Babka
2020-05-03 21:34         ` Hugh Dickins
2020-05-18 12:45         ` Miklos Szeredi
2020-05-18 14:48           ` Matthew Wilcox
2020-05-18 14:58             ` Miklos Szeredi
2020-05-18 15:26               ` Matthew Wilcox
  -- strict thread matches above, loose matches on Subject: below --
2018-12-26 21:43 Nikolaus Rath
2019-01-07  8:28 ` [fuse-devel] " Miklos Szeredi
2019-01-07 21:05   ` Nikolaus Rath
2019-01-08  8:27     ` Miklos Szeredi
2019-01-08 10:35       ` Nikolaus Rath
2019-01-09  8:07         ` Miklos Szeredi
     [not found]           ` <CAJfpegtiXDgSBWN8MRubpAdJFxy95X21nO_yycCZhpvKLVePRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-01-11 15:39             ` Nikolaus Rath

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877dxut8q7.fsf@vostro.rath.org \
    --to=nikolaus@rath.org \
    --cc=andrealmeid@collabora.com \
    --cc=fuse-devel@lists.sourceforge.net \
    --cc=krisman@collabora.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mszeredi@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.