linux-kernel - Re: [PATCH 2/2] fuse: wait for writeback in fuse_file

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Aug 2013 18:37:44 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Maxim Patlasov <mpatlasov@...allels.com>
Cc:	fuse-devel@...ts.sourceforge.net, bfoster@...hat.com,
	xemul@...allels.com, linux-kernel@...r.kernel.org, devel@...nvz.org
Subject: Re: [PATCH 2/2] fuse: wait for writeback in fuse_file_fallocate() -v2

On Thu, Aug 29, 2013 at 08:27:30PM +0400, Maxim Patlasov wrote:

> >So having a barrier like FUSE_NOWRITE is good but then we need to take care
> >of throwing away the truncated part of the queue.  But that should be doable
> >by passing the truncated range explicitly to fuse_release_nowrite().
> 
> Yes, I considered this approach, but splitting a fuse request into
> two in fuse_send_writepage() made me sick. What if allocation fails?

Heh, yeah.

I can think of a hundred ways this could be solved without needing an
allocation.  Probably none of them worth the hassle.

Or if the hole fits inside the write we could just zero out the affected pages.
Which is cheating a bit, but no one will notice ;)

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/