[PATCH] Fix cuse ENOMEM ioctl breakage in 4.20.0

[PATCH] Fix cuse ENOMEM ioctl breakage in 4.20.0

[Andreas Steinmetz]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

This must have happened somewhen after 4.17.2 and I did find it in
4.20.0:

cuse_process_init_reply() doesn't initialize fc->max_pages and thus all
cuse bases ioctls fail with ENOMEM.

Patch which fixes this is attached.
-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

[-- Attachment #2: cuse-4.20.0.patch --]
[-- Type: text/x-patch, Size: 424 bytes --]

--- linux.orig/fs/fuse/cuse.c	2018-12-30 09:52:47.479717022 +0100
+++ linux/fuse/cuse.c	2018-12-30 09:53:22.944128852 +0100
@@ -324,6 +324,7 @@
 	fc->minor = arg->minor;
 	fc->max_read = max_t(unsigned, arg->max_read, 4096);
 	fc->max_write = max_t(unsigned, arg->max_write, 4096);
+	fc->max_pages = FUSE_DEFAULT_MAX_PAGES_PER_REQ;
 
 	/* parse init reply */
 	cc->unrestricted_ioctl = arg->flags & CUSE_UNRESTRICTED_IOCTL;

Re: [PATCH] Fix cuse ENOMEM ioctl breakage in 4.20.0

[Miklos Szeredi]

On Sun, Dec 30, 2018 at 10:52 AM Andreas Steinmetz <ast@domdv.de> wrote:
>
> This must have happened somewhen after 4.17.2 and I did find it in
> 4.20.0:
>
> cuse_process_init_reply() doesn't initialize fc->max_pages and thus all
> cuse bases ioctls fail with ENOMEM.
>
> Patch which fixes this is attached.

Thanks.  Pushed a slightly different patch:

https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git/commit/?h=for-next&id=666a40e87038221d45d47aa160b26410fd67c1d2

Miklos

Re: [PATCH] Fix cuse ENOMEM ioctl breakage in 4.20.0

[Miklos Szeredi]

On Sat, May 18, 2019 at 3:58 PM Andreas Steinmetz <ast@domdv.de> wrote:

> > On Sun, Dec 30, 2018 at 10:52 AM Andreas Steinmetz <ast@domdv.de> wrote:
> > > This must have happened somewhen after 4.17.2 and I did find it in
> > > 4.20.0:
> > >
> > > cuse_process_init_reply() doesn't initialize fc->max_pages and thus all
> > > cuse bases ioctls fail with ENOMEM.
> > >
> > > Patch which fixes this is attached.
> >
> > Thanks.  Pushed a slightly different patch:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git/commit/?h=for-next&id=666a40e87038221d45d47aa160b26410fd67c1d2
> >

> It got broken again, ENONEM.
> I do presume that commit 5da784cce4308ae10a79e3c8c41b13fb9568e4e0 is the
> culprit. Could you please fix this and, please, could somebody do a cuse
> regression test after changes to fuse?

Hi,

Can you please tell us which kernel is broken?

Thanks,
Miklos

>
> On Mon, 2019-01-14 at 10:58 +0100, Miklos Szeredi wrote:

Re: [PATCH] Fix cuse ENOMEM ioctl breakage in 4.20.0

[Greg Kroah-Hartman]

On Tue, May 28, 2019 at 03:12:28PM +0200, Miklos Szeredi wrote:
> On Sat, May 18, 2019 at 3:58 PM Andreas Steinmetz <ast@domdv.de> wrote:
> 
> > > On Sun, Dec 30, 2018 at 10:52 AM Andreas Steinmetz <ast@domdv.de> wrote:
> > > > This must have happened somewhen after 4.17.2 and I did find it in
> > > > 4.20.0:
> > > >
> > > > cuse_process_init_reply() doesn't initialize fc->max_pages and thus all
> > > > cuse bases ioctls fail with ENOMEM.
> > > >
> > > > Patch which fixes this is attached.
> > >
> > > Thanks.  Pushed a slightly different patch:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git/commit/?h=for-next&id=666a40e87038221d45d47aa160b26410fd67c1d2
> > >
> 
> > It got broken again, ENONEM.
> > I do presume that commit 5da784cce4308ae10a79e3c8c41b13fb9568e4e0 is the
> > culprit. Could you please fix this and, please, could somebody do a cuse
> > regression test after changes to fuse?
> 
> Hi,
> 
> Can you please tell us which kernel is broken?

Did this ever get resolved?

totally confused,

greg k-h

Re: [PATCH] Fix cuse ENOMEM ioctl breakage in 4.20.0

[Miklos Szeredi]

On Fri, Aug 2, 2019 at 10:15 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Tue, May 28, 2019 at 03:12:28PM +0200, Miklos Szeredi wrote:
> > On Sat, May 18, 2019 at 3:58 PM Andreas Steinmetz <ast@domdv.de> wrote:
> >
> > > > On Sun, Dec 30, 2018 at 10:52 AM Andreas Steinmetz <ast@domdv.de> wrote:
> > > > > This must have happened somewhen after 4.17.2 and I did find it in
> > > > > 4.20.0:
> > > > >
> > > > > cuse_process_init_reply() doesn't initialize fc->max_pages and thus all
> > > > > cuse bases ioctls fail with ENOMEM.
> > > > >
> > > > > Patch which fixes this is attached.
> > > >
> > > > Thanks.  Pushed a slightly different patch:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git/commit/?h=for-next&id=666a40e87038221d45d47aa160b26410fd67c1d2
> > > >
> >
> > > It got broken again, ENONEM.
> > > I do presume that commit 5da784cce4308ae10a79e3c8c41b13fb9568e4e0 is the
> > > culprit. Could you please fix this and, please, could somebody do a cuse
> > > regression test after changes to fuse?
> >
> > Hi,
> >
> > Can you please tell us which kernel is broken?
>
> Did this ever get resolved?

Apparently yes, in v4.20.8 (f191c028cc33).  No other kernel was
affected, AFAICS.

Thanks,
Miklos

Re: [PATCH] Fix cuse ENOMEM ioctl breakage in 4.20.0

[Greg Kroah-Hartman]

On Fri, Aug 02, 2019 at 09:44:20PM +0200, Miklos Szeredi wrote:
> On Fri, Aug 2, 2019 at 10:15 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, May 28, 2019 at 03:12:28PM +0200, Miklos Szeredi wrote:
> > > On Sat, May 18, 2019 at 3:58 PM Andreas Steinmetz <ast@domdv.de> wrote:
> > >
> > > > > On Sun, Dec 30, 2018 at 10:52 AM Andreas Steinmetz <ast@domdv.de> wrote:
> > > > > > This must have happened somewhen after 4.17.2 and I did find it in
> > > > > > 4.20.0:
> > > > > >
> > > > > > cuse_process_init_reply() doesn't initialize fc->max_pages and thus all
> > > > > > cuse bases ioctls fail with ENOMEM.
> > > > > >
> > > > > > Patch which fixes this is attached.
> > > > >
> > > > > Thanks.  Pushed a slightly different patch:
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git/commit/?h=for-next&id=666a40e87038221d45d47aa160b26410fd67c1d2
> > > > >
> > >
> > > > It got broken again, ENONEM.
> > > > I do presume that commit 5da784cce4308ae10a79e3c8c41b13fb9568e4e0 is the
> > > > culprit. Could you please fix this and, please, could somebody do a cuse
> > > > regression test after changes to fuse?
> > >
> > > Hi,
> > >
> > > Can you please tell us which kernel is broken?
> >
> > Did this ever get resolved?
> 
> Apparently yes, in v4.20.8 (f191c028cc33).  No other kernel was
> affected, AFAICS.

Wonderful, thanks for letting me know.

greg k-h