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:	Fri, 1 Jun 2007 03:34:02 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	Mark Fasheh <mark.fasheh@...cle.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.22-rc3-mm1 - page_mkwrite() breakage

On Thu, May 31, 2007 at 06:24:40PM -0700, Mark Fasheh wrote:
> On Fri, Jun 01, 2007 at 03:01:29AM +0200, Nick Piggin wrote:
> > Ah, I didn't realise you were using that yet. I expect ocfs2 is using
> > VM_CAN_INVALIDATE there anyway.
> > 
> > Hmm, this becomes easier to deal with after page_mkwrite is merged with
> > ->fault. But for now, can we just lock the page at the do_wp_page site
> > as well, and change the API? All users I have seen want the page locked
> > there anyway...
> 
> Unfortunately that doesn't work for ocfs2 for exactly the same reasons page
> lock doesn't work during a write either - there's a cluster lock inversion
> and we might have to zero adjacent pages for an allocating write.

I guess you could just fail the page_mkwrite and have it try again? ..
that would require changing it not to always go SIGBUS though.


> What's involved in merging it with ->fault?

Just I have't sent the patch (because at the time there were no
page_mkwrite users to look at).

It is nicer too, because the nopage path only has  to call into
the filesystem once, to return the page (the filesystem can check
whether it is for write, and do the page_mkwrite thing at that
time). do_wp_page obviously still involves the extra call, and
that will be with a flag telling the fs that it isn't a "nopage"
fault, but a write fault on an existing page.

 
> Here's a nasty idea... Would it be valid for ->page_mkwrite to unlock the
> page, so long as it's returned in a locked state? Though, do we even need
> the page lock that early? It seemed to me that you were adding it for
> consistency reasons (I could be wrong though).

You could do that, but you'd have to probably check that it is
within i_size after you relock it, I think... yeah, that might
be the best thing for ocfs to do for now.
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ