From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <56A0133B.9090501@codeaurora.org> Date: Wed, 20 Jan 2016 15:07:39 -0800 From: Nikhilesh Reddy MIME-Version: 1.0 To: Jann Horn CC: Miklos Szeredi , fuse-devel , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk, Richard Weinberger , Theodore Ts'o , jack@suse.cz, Antonio SJ Musumeci , sven.utcke@gmx.de, Nikolaus Rath Subject: Re: [PATCH] fuse: Add support for fuse stacked I/O References: <565394BE.4040506@codeaurora.org> <5696E366.2080605@codeaurora.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: On 01/18/2016 07:07 PM, Jann Horn wrote: > 2016-01-14 0:53 GMT+01:00 Nikhilesh Reddy : >> Add support for filesystem stacked read/write of files >> when enabled through a userspace init option of FUSE_STACKED_IO. >> >> When FUSE_STACKED_IO is enabled all the reads and writes >> to the fuse mount point go directly to the native filesystem >> rather than through the fuse daemon. All requests that aren't >> read/write still go thought the userspace code. > > Maybe I missed it, but how does this guard against kernel stack > overflow and how does it interact with the "sb->s_stack_depth > > FILESYSTEM_MAX_STACK_DEPTH" stacking limit that overlayfs and ecryptfs > use? > > As far as I can tell from a quick glance, someone could just stack > lots of FUSE files on top of each other and cause kernel stack > overflow that way, and that's nasty. > Hi Thanks so much for your comment and for catching this. I have fixed the code to prevent further stacking and will send it out in the updated version of the patch ( now called fuse passthrough ). -- Thanks Nikhilesh Reddy Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.