linux-kernel - FUSE workflow=? (Re: [RESEND1, PATCH 1/2] fuse: convert printk -> pr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190424083800.GA11722@deco.navytux.spb.ru>
Date:   Wed, 24 Apr 2019 08:38:05 +0000
From:   Kirill Smelkov <kirr@...edi.com>
To:     Miklos Szeredi <miklos@...redi.hu>
Cc:     Miklos Szeredi <mszeredi@...hat.com>,
        Brian Foster <bfoster@...hat.com>,
        Maxim Patlasov <mpatlasov@...allels.com>,
        Anatol Pomozov <anatol.pomozov@...il.com>,
        Pavel Emelyanov <xemul@...nvz.org>,
        Andrew Gallagher <andrewjcg@...com>,
        "Anand V . Avati" <avati@...hat.com>,
        Alexey Kuznetsov <kuznet@...tuozzo.com>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Kirill Tkhai <ktkhai@...tuozzo.com>,
        Constantine Shulyupin <const@...elinux.com>,
        Chad Austin <chadaustin@...com>,
        Dan Schatzberg <dschatzberg@...com>,
        <linux-fsdevel@...r.kernel.org>,
        fuse-devel <fuse-devel@...ts.sourceforge.net>,
        <linux-kernel@...r.kernel.org>,
        Han-Wen Nienhuys <hanwen@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: FUSE workflow=? (Re: [RESEND1, PATCH 1/2] fuse: convert printk -> pr_*)

+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@...edi.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@...redi.hu>
	L:      linux-fsdevel@...r.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