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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 24 Dec 2014 12:53:13 -0400
From:	Marc Dionne <>
To:	Miklos Szeredi <>
Cc:	Linux Kernel Mailing List <>,
Subject: Re: [GIT PULL] fuse update for 3.19

On Wed, Dec 17, 2014 at 6:02 AM, Miklos Szeredi <> wrote:
> Hi Linus,
> Please pull from:
>   git:// for-linus
> First part makes sure we don't hold up umount with pending async requests.  In
> addition to being a cleanup, this is a small behavioral change (for the better)
> and unlikely to break anything.  Second part prepares for a cleanup of the fuse
> device I/O code by adding a helper for simple request submission, with some
> savings in line numbers already realized.
> Thanks,
> Miklos
> ---
> Miklos Szeredi (6):
>       fuse: don't wake up reserved req in fuse_conn_kill()
>       fuse: flush requests on umount
>       fuse: hold inode instead of path after release
>       fuse: reduce max out args
>       fuse: introduce fuse_simple_request() helper
>       fuse: use file_inode() in fuse_file_fallocate()

Hi Miklos,

Commit 7078187a795f ("fuse: introduce fuse_simple_request() helper")
from the above pull request triggers some EIO errors for me in some
tests that rely on fuse.

Looking at the code changes and a bit of debugging info I think
there's a general problem here that fuse_get_req checks and possibly
waits for fc->initialized, and this was always called first.  But this
commit changes the ordering and in many places fc->minor is now
possibly used before fuse_get_req, and we can't be sure that fc has
been initialized.  In my case fuse_lookup_init sets
req->out.args[0].size to the wrong size because fc->minor at that
point is still 0, leading to the EIO error.

Assuming the analysis makes sense, it wasn't obvious what the best fix
should be.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists