All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikhilesh Reddy <reddyn-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Linus Torvalds
	<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Cc: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>,
	Nikolaus Rath <nikolaus-BTH8mxji4b0@public.gmane.org>,
	fuse-devel
	<fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
	Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	Greg KH
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	linux-fsdevel
	<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>,
	Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org>,
	sven.utcke-Mmb7MZpHnFY@public.gmane.org,
	Miklos Szeredi <miklos-sUDqSbJrdHQHWmgEVkV9KA@public.gmane.org>,
	Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Antonio SJ Musumeci
	<trapexit-wGTF+nt6ur047o9RxwvyTQ@public.gmane.org>
Subject: Re: [PATCH] fuse: Add support for fuse stacked I/O
Date: Wed, 20 Jan 2016 15:24:12 -0800	[thread overview]
Message-ID: <56A0171C.6050108@codeaurora.org> (raw)
In-Reply-To: <569DA62B.7070701-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

On 01/18/2016 06:57 PM, Nikhilesh Reddy wrote:
> On 01/15/2016 01:53 PM, Linus Torvalds wrote:
>> On Fri, Jan 15, 2016 at 1:46 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
>> wrote:
>>
>>> If mmap sets vm_file to the underlying thing, wouldn't CRIU and
>>> anything else that uses map_files get confused?  Or did you have
>>> something else in mind?
>>
>> Why would they care?
>>
>> Also, I don't think you actually need to change vm_file - we have this
>> whole notion of "inode->i_data" vs "inode->i_mapping".
>>
>> So I think you could set the "i_mapping" of the fuse inode to be the
>> i_mapping of the passed-through-to inode, and it should just work.
>>
>> And no, I didn't look into this very deeply, and maybe there is some
>> annoying detail that would make that not work well. But that's part of
>> the whole point of the i_mapping indirection: so that you can share
>> the page cache when you have two separate anchor points. I think coda
>> uses it for the local caching, and block devices use it to not have
>> mapping aliases between different inodex that all are the same block
>> device.
>>
>>                   Linus
>>
>
> Hi
>
> Thanks for your support.
>
> I am looking  into adding the mmap by change the i_mmaping but seems to
> be getting stuck for some stress tests.
>
> Once i get that debugged and working i will definitely send out a new
> patch with that functionality.
>
> ( Sending it as a second patch will help make it easier to go through
> the legal redtape and procedures i am forced to follow).
>
> For now i am going to update the current patch and call it "passthrough"
> as you suggested and also update the commit message giving  a clearer
> explanation of the motivation.
>
> Once i get it tested I can send it out for consideration and review
>
> Please do let me know if you have any questions or concerns on this and
> i will try my best to address them all.
>
>
I have just sent out the latest version of the patch in the email with 
the subject
[PATCH v3] fuse: Add support for passthrough read/write

Please do let me know if you have any questions or concerns on this and
i will try my best to address them all.

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

WARNING: multiple messages have this Message-ID (diff)
From: Nikhilesh Reddy <reddyn@codeaurora.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Nikolaus Rath <nikolaus@rath.org>,
	fuse-devel <fuse-devel@lists.sourceforge.net>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Greg KH <gregkh@linuxfoundation.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>, Jan Kara <jack@suse.cz>,
	Theodore Ts'o <tytso@mit.edu>,
	sven.utcke@gmx.de, Miklos Szeredi <miklos@szeredi.hu>,
	Richard Weinberger <richard@nod.at>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Antonio SJ Musumeci <trapexit@spawn.link>
Subject: Re: [PATCH] fuse: Add support for fuse stacked I/O
Date: Wed, 20 Jan 2016 15:24:12 -0800	[thread overview]
Message-ID: <56A0171C.6050108@codeaurora.org> (raw)
In-Reply-To: <569DA62B.7070701@codeaurora.org>

On 01/18/2016 06:57 PM, Nikhilesh Reddy wrote:
> On 01/15/2016 01:53 PM, Linus Torvalds wrote:
>> On Fri, Jan 15, 2016 at 1:46 PM, Andy Lutomirski <luto@amacapital.net>
>> wrote:
>>
>>> If mmap sets vm_file to the underlying thing, wouldn't CRIU and
>>> anything else that uses map_files get confused?  Or did you have
>>> something else in mind?
>>
>> Why would they care?
>>
>> Also, I don't think you actually need to change vm_file - we have this
>> whole notion of "inode->i_data" vs "inode->i_mapping".
>>
>> So I think you could set the "i_mapping" of the fuse inode to be the
>> i_mapping of the passed-through-to inode, and it should just work.
>>
>> And no, I didn't look into this very deeply, and maybe there is some
>> annoying detail that would make that not work well. But that's part of
>> the whole point of the i_mapping indirection: so that you can share
>> the page cache when you have two separate anchor points. I think coda
>> uses it for the local caching, and block devices use it to not have
>> mapping aliases between different inodex that all are the same block
>> device.
>>
>>                   Linus
>>
>
> Hi
>
> Thanks for your support.
>
> I am looking  into adding the mmap by change the i_mmaping but seems to
> be getting stuck for some stress tests.
>
> Once i get that debugged and working i will definitely send out a new
> patch with that functionality.
>
> ( Sending it as a second patch will help make it easier to go through
> the legal redtape and procedures i am forced to follow).
>
> For now i am going to update the current patch and call it "passthrough"
> as you suggested and also update the commit message giving  a clearer
> explanation of the motivation.
>
> Once i get it tested I can send it out for consideration and review
>
> Please do let me know if you have any questions or concerns on this and
> i will try my best to address them all.
>
>
I have just sent out the latest version of the patch in the email with 
the subject
[PATCH v3] fuse: Add support for passthrough read/write

Please do let me know if you have any questions or concerns on this and
i will try my best to address them all.

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

  parent reply	other threads:[~2016-01-20 23:24 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <565394BE.4040506@codeaurora.org>
     [not found] ` <565394BE.4040506-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-01-13 23:53   ` [PATCH] fuse: Add support for fuse stacked I/O Nikhilesh Reddy
2016-01-13 23:53     ` Nikhilesh Reddy
2016-01-14  4:57     ` Greg KH
2016-01-14 18:57       ` Nikhilesh Reddy
     [not found]         ` <5697EF97.9020800-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-01-14 19:19           ` Linus Torvalds
2016-01-14 19:19             ` Linus Torvalds
     [not found]             ` <CA+55aFwxaU0Y_UxyKFv6WaYsPWDDzZG-rhVtMuLSPcJ0WLLw2A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-15 16:31               ` Andy Lutomirski
2016-01-15 16:31                 ` Andy Lutomirski
     [not found]                 ` <CALCETrWNQ9ytw1bCOOjFJRstauYc6DocQAmZCF61CErAJ5BF2g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-15 17:37                   ` Antonio SJ Musumeci
     [not found]                     ` <CAB3-ZyT+xcU-0BnNvq-+GsDe6W8=MCWwxguS-+KQ39gajmM5pw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-15 17:51                       ` Nikolaus Rath
2016-01-15 17:51                         ` Nikolaus Rath
2016-01-15 19:29                         ` Nikhilesh Reddy
     [not found]                           ` <56994884.9060002-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-01-15 21:38                             ` Nikolaus Rath
2016-01-15 21:38                               ` Nikolaus Rath
2016-01-15 21:43                           ` Linus Torvalds
2016-01-15 21:46                             ` Andy Lutomirski
     [not found]                               ` <CALCETrUA2veiBYYbN1hCSkHxBFyDpe3b=PXg=j53_ZuQBt1FUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-15 21:53                                 ` Linus Torvalds
2016-01-15 21:53                                   ` Linus Torvalds
2016-01-19  2:57                                   ` Nikhilesh Reddy
     [not found]                                     ` <569DA62B.7070701-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-01-20 23:24                                       ` Nikhilesh Reddy [this message]
2016-01-20 23:24                                         ` Nikhilesh Reddy
2016-01-15 21:56                           ` [fuse-devel] " Hans Beckerus
     [not found]     ` <5696E366.2080605-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-01-14  8:25       ` Christoph Hellwig
2016-01-14  8:25         ` Christoph Hellwig
2016-01-14 15:52         ` Nikolaus Rath
     [not found]           ` <87mvs8qhun.fsf-Zv899e0YUSYPWKMTL/zdXNi2O/JbrIOy@public.gmane.org>
2016-01-15  9:29             ` Christoph Hellwig
2016-01-15  9:29               ` Christoph Hellwig
2016-01-19  3:07       ` Jann Horn
2016-01-19  3:07         ` Jann Horn
     [not found]         ` <CAK9i0=ojVmbuDiFXY_sHA12vTWgz9aKwEQuZmmYtUka3zqr=hg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-20 23:07           ` Nikhilesh Reddy
2016-01-20 23:07             ` Nikhilesh Reddy

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=56A0171C.6050108@codeaurora.org \
    --to=reddyn-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
    --cc=fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
    --cc=jack-AlSwsSmVLrQ@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org \
    --cc=miklos-sUDqSbJrdHQHWmgEVkV9KA@public.gmane.org \
    --cc=nikolaus-BTH8mxji4b0@public.gmane.org \
    --cc=richard-/L3Ra7n9ekc@public.gmane.org \
    --cc=sven.utcke-Mmb7MZpHnFY@public.gmane.org \
    --cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=trapexit-wGTF+nt6ur047o9RxwvyTQ@public.gmane.org \
    --cc=tytso-3s7WtUTddSA@public.gmane.org \
    --cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.