Re: [PATCH] mm: don't expose page to fast gup before it's ready

2019-05-14 Thread Yu Zhao
On Tue, May 14, 2019 at 02:25:27PM -0700, Andrew Morton wrote: > On Tue, 9 Jan 2018 02:10:50 -0800 Yu Zhao wrote: > > > > Also what prevents reordering here? There do not seem to be any barriers > > > to prevent __SetPageSwapBacked leak after set_pte_at with your patch. > > > > I assumed

Re: [PATCH] mm: don't expose page to fast gup before it's ready

2019-05-14 Thread Andrew Morton
On Tue, 9 Jan 2018 02:10:50 -0800 Yu Zhao wrote: > > Also what prevents reordering here? There do not seem to be any barriers > > to prevent __SetPageSwapBacked leak after set_pte_at with your patch. > > I assumed mem_cgroup_commit_charge() acted as full barrier. Since you > explicitly asked

Re: [PATCH] mm: don't expose page to fast gup before it's ready

2018-01-31 Thread Andrew Morton
On Tue, 9 Jan 2018 02:10:50 -0800 Yu Zhao wrote: > On Tue, Jan 09, 2018 at 09:46:22AM +0100, Michal Hocko wrote: > > On Mon 08-01-18 14:56:32, Yu Zhao wrote: > > > We don't want to expose page before it's properly setup. During > > > page setup, we may call

Re: [PATCH] mm: don't expose page to fast gup before it's ready

2018-01-31 Thread Andrew Morton
On Tue, 9 Jan 2018 02:10:50 -0800 Yu Zhao wrote: > On Tue, Jan 09, 2018 at 09:46:22AM +0100, Michal Hocko wrote: > > On Mon 08-01-18 14:56:32, Yu Zhao wrote: > > > We don't want to expose page before it's properly setup. During > > > page setup, we may call page_add_new_anon_rmap() which uses

Re: [PATCH] mm: don't expose page to fast gup before it's ready

2018-01-09 Thread Yu Zhao
On Tue, Jan 09, 2018 at 09:46:22AM +0100, Michal Hocko wrote: > On Mon 08-01-18 14:56:32, Yu Zhao wrote: > > We don't want to expose page before it's properly setup. During > > page setup, we may call page_add_new_anon_rmap() which uses non- > > atomic bit op. If page is exposed before it's done,

Re: [PATCH] mm: don't expose page to fast gup before it's ready

2018-01-09 Thread Yu Zhao
On Tue, Jan 09, 2018 at 09:46:22AM +0100, Michal Hocko wrote: > On Mon 08-01-18 14:56:32, Yu Zhao wrote: > > We don't want to expose page before it's properly setup. During > > page setup, we may call page_add_new_anon_rmap() which uses non- > > atomic bit op. If page is exposed before it's done,

Re: [PATCH] mm: don't expose page to fast gup before it's ready

2018-01-09 Thread Michal Hocko
On Mon 08-01-18 14:56:32, Yu Zhao wrote: > We don't want to expose page before it's properly setup. During > page setup, we may call page_add_new_anon_rmap() which uses non- > atomic bit op. If page is exposed before it's done, we could > overwrite page flags that are set by get_user_pages_fast()

Re: [PATCH] mm: don't expose page to fast gup before it's ready

2018-01-09 Thread Michal Hocko
On Mon 08-01-18 14:56:32, Yu Zhao wrote: > We don't want to expose page before it's properly setup. During > page setup, we may call page_add_new_anon_rmap() which uses non- > atomic bit op. If page is exposed before it's done, we could > overwrite page flags that are set by get_user_pages_fast()

[PATCH] mm: don't expose page to fast gup before it's ready

2018-01-08 Thread Yu Zhao
We don't want to expose page before it's properly setup. During page setup, we may call page_add_new_anon_rmap() which uses non- atomic bit op. If page is exposed before it's done, we could overwrite page flags that are set by get_user_pages_fast() or it's callers. Here is a non-fatal scenario

[PATCH] mm: don't expose page to fast gup before it's ready

2018-01-08 Thread Yu Zhao
We don't want to expose page before it's properly setup. During page setup, we may call page_add_new_anon_rmap() which uses non- atomic bit op. If page is exposed before it's done, we could overwrite page flags that are set by get_user_pages_fast() or it's callers. Here is a non-fatal scenario