linux-kernel - Re: open(2) says O_DIRECT works on 512 byte boundries?

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]

Message-Id: <20090203124230.c738302a.kamezawa.hiroyu@jp.fujitsu.com>
Date:	Tue, 3 Feb 2009 12:42:30 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc:	Andrea Arcangeli <aarcange@...hat.com>, Greg KH <greg@...ah.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	mtk.manpages@...il.com, linux-man@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: open(2) says O_DIRECT works on 512 byte boundries?

On Tue, 3 Feb 2009 11:55:40 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> wrote:

> On Tue, 3 Feb 2009 03:31:47 +0100
> Andrea Arcangeli <aarcange@...hat.com> wrote:
> 
> > On Tue, Feb 03, 2009 at 10:29:20AM +0900, KAMEZAWA Hiroyuki wrote:
> > > On Mon, 2 Feb 2009 23:08:56 +0100
> > > Andrea Arcangeli <aarcange@...hat.com> wrote:
> > > 
> > > > Hi Greg!
> > > > 
> > > > > Thanks for the pointers, I'll go read the thread and follow up there.
> > > > 
> > > > If you also run into this final fix is attached below. Porting to
> > > > mainline is a bit hard because of gup-fast... Perhaps we can use mmu
> > > > notifiers to fix gup-fast... need to think more about it then I'll
> > > > post something.
> > > > 
> > > > Please help testing the below on pre-gup-fast kernels, thanks!
> > > > 
> > > I commented in FJ-Redhat Path but not forwared from unknown reason ;)
> > > I comment again.
> > > 
> > > 1. Why TestSetLockPage() is necessary ?
> > >    It seems not necesary.
> > 
> > To avoid the VM to remove or add the page from/to swapcache and change
> > page_count/mapcount from under us. This most certainly wasn't the
> > reason of the slowdown (the slowdown were the false positives
> > generated by pagevec pinning) and removing it was more intrusive than
> > I wanted.
> 
> My point is.
>   - If TestSetLockPage() failes, force_cow=1.
>   - If count/mapcount check fails, force_cow=1.
> 
> So, lock_page() here seems meaningless. If you consider lock_page() is important,
> just use lock_page() seems better.
> 
I changed my thinking. I understood *lock* is necessary here.
But I'm not sure this is enough.



> > > 3. Why "follow_page() successfully finds a page" case only ?
> > >  not necessary to insert SetPageGUP() in following path ?
> > > 
> > >  - handle_mm_fault()
> > >            => do_anonymos/swap/wp_page()
> > >            or some.
> > 
> > No need to change that either, all we need to know are the pages whose
> > count vs mapcount has a discrepancy that could have been caused by
> > get_user_pages. So only follow_page has to set it. More precisely
> > FOLL_GET|FOLL_WRITE is the only path we care about there.
> > 
> 
> Assume 3 threads in a process.
please ignore this, I'm shame ;(

-Kame

--
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/