archive mirror
 help / color / mirror / Atom feed
From: Kirill Smelkov <>
To: Miklos Szeredi <>
Cc: Miklos Szeredi <>,
	Brian Foster <>,
	Maxim Patlasov <>,
	Anatol Pomozov <>,
	Pavel Emelyanov <>,
	Andrew Gallagher <>,
	"Anand V . Avati" <>,
	Alexey Kuznetsov <>,
	Andrey Ryabinin <>,
	Kirill Tkhai <>,
	Constantine Shulyupin <>,
	Chad Austin <>,
	Dan Schatzberg <>,
	fuse-devel <>,
	Han-Wen Nienhuys <>,
	Andrew Morton <>,
	Linus Torvalds <>
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: <> (raw)
In-Reply-To: <>


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,

  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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).