All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maxim V. Patlasov" <mpatlasov@parallels.com>
To: Brian Foster <bfoster@redhat.com>
Cc: <miklos@szeredi.hu>, <dev@parallels.com>, <xemul@parallels.com>,
	<fuse-devel@lists.sourceforge.net>,
	<linux-kernel@vger.kernel.org>, <devel@openvz.org>
Subject: Re: [PATCH 5/6] fuse: truncate file if async dio failed
Date: Tue, 18 Dec 2012 12:12:00 +0400	[thread overview]
Message-ID: <50D02550.3090903@parallels.com> (raw)
In-Reply-To: <50CF6CB6.5030703@redhat.com>

12/17/2012 11:04 PM, Brian Foster пишет:
> On 12/17/2012 09:13 AM, Maxim V. Patlasov wrote:
>> Hi,
>>
>> 12/15/2012 12:16 AM, Brian Foster пишет:
>>> On 12/14/2012 10:21 AM, Maxim V. Patlasov wrote:
> ...
>>>> +
>>> fuse_do_truncate() looks fairly close to fuse_do_setattr(). Is there any
>>> reason we couldn't make fuse_do_setattr() non-static, change the dentry
>>> parameter to an inode and use that?
>> fuse_do_setattr() performs extra checks that fuse_do_truncate() needn't.
>> Some of them are harmless, some not: fuse_allow_task() may return 0 if
>> task credentials changed. E.g. super-user successfully opened a file,
>> then setuid(other_user_uid), then write(2) to the file. write(2) doesn't
>> check uid, but fuse_do_truncate() - via fuse_allow_task() - does.
>>
> Conversely, what about the extra error handling bits in
> fuse_do_setattr() that do not appear in fuse_do_truncate() (i.e., the
> inode mode check, the change attributes call, updating the inode size,
> etc.)? It seems like we would want some of that code here.

Yes, they won't harm.

>
> fuse_setattr() is the only caller of fuse_do_setattr(), so why not embed
> some of the initial checks (such as fuse_allow_task()) there? I suppose
> we could pull out some of the error handling checks there as well if
> they are considered harmful to this post-write error truncate situation.

Makes sense. I like it especially because it allows to avoid code 
duplication (handling FUSE_SETATTR fuse-request).

> FWIW, I just tested a quick change that pulls up the fuse_allow_task()
> check (via instrumenting a write error) and it seems to work as
> expected. I can forward a patch if interested...

I did exactly the same before sending previous email :) In my tests it 
works as expected too (modulo fuse_allow_task() that we can move up). 
I'll re-send corrected patch soon.

Thanks,
Maxim

  reply	other threads:[~2012-12-18  8:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-14 15:20 [PATCH v2 0/6] fuse: process direct IO asynchronously Maxim V. Patlasov
2012-12-14 15:20 ` [PATCH 1/6] fuse: move fuse_release_user_pages() up Maxim V. Patlasov
2012-12-14 15:20 ` [PATCH 2/6] fuse: add support of async IO Maxim V. Patlasov
2013-04-22 16:34   ` Miklos Szeredi
2013-04-23 12:21     ` Maxim V. Patlasov
2012-12-14 15:20 ` [PATCH 3/6] fuse: make fuse_direct_io() aware about AIO Maxim V. Patlasov
2012-12-14 15:21 ` [PATCH 4/6] fuse: enable asynchronous processing direct IO Maxim V. Patlasov
2012-12-14 15:21 ` [PATCH 5/6] fuse: truncate file if async dio failed Maxim V. Patlasov
2012-12-14 20:16   ` Brian Foster
2012-12-17 14:13     ` Maxim V. Patlasov
2012-12-17 19:04       ` Brian Foster
2012-12-18  8:12         ` Maxim V. Patlasov [this message]
2013-04-17 20:42           ` Miklos Szeredi
2012-12-18 10:05   ` [PATCH] fuse: truncate file if async dio failed - v2 Maxim V. Patlasov
2012-12-14 15:21 ` [PATCH 6/6] fuse: optimize short direct reads Maxim V. Patlasov
2012-12-18 14:14 ` [PATCH v2 0/6] fuse: process direct IO asynchronously Brian Foster
2013-04-11 11:22 ` [fuse-devel] " Maxim V. Patlasov
2013-04-11 16:07   ` Miklos Szeredi
2013-04-11 16:43     ` Maxim V. Patlasov
  -- strict thread matches above, loose matches on Subject: below --
2012-12-10  7:41 [PATCH " Maxim V. Patlasov
2012-12-10  7:42 ` [PATCH 5/6] fuse: truncate file if async dio failed Maxim V. Patlasov

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=50D02550.3090903@parallels.com \
    --to=mpatlasov@parallels.com \
    --cc=bfoster@redhat.com \
    --cc=dev@parallels.com \
    --cc=devel@openvz.org \
    --cc=fuse-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=xemul@parallels.com \
    /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.