On 09/16/2014 12:19 PM, Miklos Szeredi wrote:
On Thu, Sep 11, 2014 at 6:14 PM, Maxim Patlasov wrote:
I really need your help to proceed with this patch. Could you please explain
what those places are where we should allow interruption.
BTW, as for "just an optimization", I've recently noticed
On Thu, Sep 11, 2014 at 6:14 PM, Maxim Patlasov wrote:
> I really need your help to proceed with this patch. Could you please explain
> what those places are where we should allow interruption.
>
> BTW, as for "just an optimization", I've recently noticed that __fput()
> calls locks_remove_file()
On 08/22/2014 06:08 PM, Miklos Szeredi wrote:
On Thu, Aug 21, 2014 at 6:09 PM, Maxim Patlasov wrote:
If fuse_file_put() is called with sync==true, the user may be blocked for
a while, until userspace ACKs our FUSE_RELEASE request. This blocking must be
uninterruptible. Otherwise request could b
On 08/22/2014 06:08 PM, Miklos Szeredi wrote:
On Thu, Aug 21, 2014 at 6:09 PM, Maxim Patlasov wrote:
If fuse_file_put() is called with sync==true, the user may be blocked for
a while, until userspace ACKs our FUSE_RELEASE request. This blocking must be
uninterruptible. Otherwise request could b
On Thu, Aug 21, 2014 at 6:09 PM, Maxim Patlasov wrote:
> If fuse_file_put() is called with sync==true, the user may be blocked for
> a while, until userspace ACKs our FUSE_RELEASE request. This blocking must be
> uninterruptible. Otherwise request could be interrupted, but file association
> in us
If fuse_file_put() is called with sync==true, the user may be blocked for
a while, until userspace ACKs our FUSE_RELEASE request. This blocking must be
uninterruptible. Otherwise request could be interrupted, but file association
in user space remains.
Signed-off-by: Maxim Patlasov
---
fs/fuse/f
6 matches
Mail list logo
