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] [day] [month] [year] [list]
Date:	Mon, 17 Mar 2008 08:22:17 -0800
From:	Badari Pulavarty <pbadari@...il.com>
To:	Jan Kara <jack@...e.cz>
Cc:	ext4 <linux-ext4@...r.kernel.org>
Subject: Re: Reversing order of transaction start and page_lock for ext3/4

On Thu, 2008-03-13 at 19:05 +0100, Jan Kara wrote:
>   Hi,
> 
>   As Mark Fasheh pointed out, we cannot take page_lock inside a transaction
> commit because that could possibly deadlock with other thread holding the
> page_lock and waiting for commit to finish in journal_start. This is
> kind-of blocker for my new approach of handling of ordered mode in JBD.
> 
> So first, I'd like to ask what other people think about reversing locking
> order of page_lock and transaction start in ext3/4? I personally find it a
> good thing anyway (I've stumbled on problems with the current locking order
> several times, but so far I could always workaround them), logically it
> simply "makes sence" as transaction handle is naturally more long-lived
> than a lock on one page.
> 
> For the case that we agree we want to reverse the order, I've looked into
> how hard would it be. Ordinary write path is trivial. If we provide
> page_mkwrite function (which should be quite simple), we don't have to be
> afraid of instantiating holes in writepage so that makes things in
> writepage simpler (although we'd pay the some performance for writing page
> of zeros into the hole and later writing real data in writepage - currently
> we do only the second write together with block allocation). With
> page_mkwrite, we don't have to start transaction at all in writepage in
> writeback and ordered modes.

3 years ago, I tried to support writepages() for ext3 and ran into this.
At that time, page_mkwrite() was still under works and couldn't use it.
I think with page_mkwrite() we can do this, except that its a slight
behaviour change in the sense that the app could get allocation errors
(ENOSPC) while writing to mmap(). But I think its a good thing.

For ext4 delayed allocation, we might see small performance issue - but
I think it would be a special case.

Thanks,
Badari

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ