From: Kirill Smelkov <kirr@nexedi.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Miklos Szeredi <mszeredi@redhat.com>,
Brian Foster <bfoster@redhat.com>,
Maxim Patlasov <mpatlasov@parallels.com>,
Anatol Pomozov <anatol.pomozov@gmail.com>,
Pavel Emelyanov <xemul@openvz.org>,
Andrew Gallagher <andrewjcg@fb.com>,
"Anand V . Avati" <avati@redhat.com>,
Alexey Kuznetsov <kuznet@virtuozzo.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Kirill Tkhai <ktkhai@virtuozzo.com>,
Constantine Shulyupin <const@makelinux.com>,
Chad Austin <chadaustin@fb.com>,
Dan Schatzberg <dschatzberg@fb.com>,
<linux-fsdevel@vger.kernel.org>,
fuse-devel <fuse-devel@lists.sourceforge.net>,
<linux-kernel@vger.kernel.org>,
Han-Wen Nienhuys <hanwen@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: FUSE workflow=? (Re: [RESEND1, PATCH 1/2] fuse: convert printk -> pr_*)
Date: Wed, 24 Apr 2019 08:38:05 +0000 [thread overview]
Message-ID: <20190424083800.GA11722@deco.navytux.spb.ru> (raw)
In-Reply-To: <CAJfpegt9DRmwKksR0QSA7NzQP_=a=yJybdL9mOP1cw5goGkdgw@mail.gmail.com>
+torvalds
On Tue, Apr 23, 2019 at 04:57:58PM +0200, Miklos Szeredi wrote:
> On Wed, Mar 27, 2019 at 10:15 AM Kirill Smelkov <kirr@nexedi.com> wrote:
> >
> > Functions, like pr_err, are a more modern variant of printing compared to
> > printk. They could be used to denoise sources by using needed level in
> > the print function name, and by automatically inserting per-driver /
> > function / ... print prefix as defined by pr_fmt macro. pr_* are also
> > said to be used in Documentation/process/coding-style.rst and more
> > recent code - for example overlayfs - uses them instead of printk.
> >
> > Convert CUSE and FUSE to use the new pr_* functions.
> >
> > CUSE output stays completely unchanged, while FUSE output is amended a
> > bit for "trying to steal weird page" warning - the second line now comes
> > also with "fuse:" prefix. I hope it is ok.
>
> Yep. Applied, thanks.
Miklos, thanks for feedback. Could you please clarify where the patch is
applied? Here is what linux/MAINTAINERS says
FUSE: FILESYSTEM IN USERSPACE
M: Miklos Szeredi <miklos@szeredi.hu>
L: linux-fsdevel@vger.kernel.org
W: http://fuse.sourceforge.net/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git
S: Maintained
F: fs/fuse/
F: include/uapi/linux/fuse.h
F: Documentation/filesystems/fuse.txt
but git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git was
not updated for ~ 2 months. I see other "Applied, thanks" replies from
you on linux-fsdevel in recent days and it suggests that patches are
indeed applied, but where they are integrated is the question.
Linux-next also has no post-5.1 fuse patches at all, so I'm really
puzzled about what is going on.
Is there any reason not to keep for-next fuse branch publicly available?
Or am I missing something?
Could you please also have a look at other posted patches? I'm
struggling for months sending them to you and not getting feedback. It
is kind of frustrating to work in this mode. Here they are:
- FOPEN_STREAM to fix read/write deadlock on stream-like files:
https://lore.kernel.org/linux-fsdevel/20190424071316.11967-1-kirr@nexedi.com/
the basis for this patch was landed to master already:
git.kernel.org/linus/10dce8af3422
- FUSE_PRECISE_INVAL_DATA to allow filesystems to have precise control
over data cache and in particular not to loose the whole data cache on
file size change:
https://lore.kernel.org/linux-fsdevel/e0b43507976d6ea9010f1bacaef067f18de49f1f.1553677194.git.kirr@nexedi.com/
cover letter: https://lore.kernel.org/linux-fsdevel/cover.1553677194.git.kirr@nexedi.com/
this patch is essential for my filesystem which cares very deeply about
not loosing local file cache.
( "fuse: convert printk -> pr_*" was only a preparatory patch in that
series suggested by Kirill Tkhai )
- don't stuck clients on retrieve_notify with size > max_write
https://lore.kernel.org/linux-fsdevel/cover.1553680185.git.kirr@nexedi.com/
https://lore.kernel.org/linux-fsdevel/12f7d0d98555ee0d174d04bb47644f65c07f035a.1553680185.git.kirr@nexedi.com/
https://lore.kernel.org/linux-fsdevel/d74b17b9d33c3dcc7a1f2fa2914fb3c4e7cda127.1553680185.git.kirr@nexedi.com/
this is kind of no-op if server behaves sanely, but for slightly
misbehaving server changes kernel to return a regular error instead of
promising to userspace that it will send a reply and not doing so,
thus getting userspace stuck.
when I got my filesystem initially stuck it required to dig a lot to
understand what was going on
https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2
(starting from "I've hit this bug for real ...")
Even though go-fuse (the fuse library that was slightly misbehaving) is
now fixed https://github.com/hanwen/go-fuse/commit/58dcd77a24, it is a
big difference if userspace gets an error, or it gets "ok" return and
is further stuck waiting for promised message. Besides libfuse and
go-fuse there are several other fuse libraries and by fixing kernel
behaviour here we care about all fuse users. In February you set 10
lines budget for this "non-bug fix" and this budget is met with the
patches which cumulatively are 2 lines of code change and 7 lines of
comments.
Thanks beforehand,
Kirill
next prev parent reply other threads:[~2019-04-24 8:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-27 9:15 [RESEND1, PATCH 0/2] fuse: allow filesystems to have precise control over data cache Kirill Smelkov
2019-03-27 9:15 ` [RESEND1, PATCH 1/2] fuse: convert printk -> pr_* Kirill Smelkov
2019-04-23 14:57 ` Miklos Szeredi
2019-04-24 8:38 ` Kirill Smelkov [this message]
2019-04-24 8:57 ` FUSE workflow=? (Re: [RESEND1, PATCH 1/2] fuse: convert printk -> pr_*) Miklos Szeredi
2019-04-24 9:54 ` Kirill Smelkov
2019-03-27 10:14 ` [RESEND1, PATCH v2 2/2] fuse: allow filesystems to have precise control over data cache Kirill Smelkov
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=20190424083800.GA11722@deco.navytux.spb.ru \
--to=kirr@nexedi.com \
--cc=akpm@linux-foundation.org \
--cc=anatol.pomozov@gmail.com \
--cc=andrewjcg@fb.com \
--cc=aryabinin@virtuozzo.com \
--cc=avati@redhat.com \
--cc=bfoster@redhat.com \
--cc=chadaustin@fb.com \
--cc=const@makelinux.com \
--cc=dschatzberg@fb.com \
--cc=fuse-devel@lists.sourceforge.net \
--cc=hanwen@google.com \
--cc=ktkhai@virtuozzo.com \
--cc=kuznet@virtuozzo.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mpatlasov@parallels.com \
--cc=mszeredi@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=xemul@openvz.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).