[lkml]   [2019]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectFUSE workflow=? (Re: [RESEND1, PATCH 1/2] fuse: convert printk -> pr_*)

On Tue, Apr 23, 2019 at 04:57:58PM +0200, Miklos Szeredi wrote:
> On Wed, Mar 27, 2019 at 10:15 AM Kirill Smelkov <> 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

M: Miklos Szeredi <>
T: git git://
S: Maintained
F: fs/fuse/
F: include/uapi/linux/fuse.h
F: Documentation/filesystems/fuse.txt

but 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:

the basis for this patch was landed to master already:

- 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:
cover letter:

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

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
(starting from "I've hit this bug for real ...")

Even though go-fuse (the fuse library that was slightly misbehaving) is
now fixed, 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

Thanks beforehand,

 \ /
  Last update: 2019-04-24 10:54    [W:0.054 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site