lkml.org 
[lkml]   [2019]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectFUSE workflow=? (Re: [RESEND1, PATCH 1/2] fuse: convert printk -> pr_*)
Date
+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

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