Re: [PATCH v3 3/4] mm: don't expose non-hugetlb page to fast gup prematurely

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue 01-10-19 10:36:04, Peter Zijlstra wrote:
> On Tue, Oct 01, 2019 at 09:10:08AM +0200, Jan Kara wrote:
> > On Mon 30-09-19 10:57:08, John Hubbard wrote:
> 
> > > Well, a couple of questions:
> > > 
> > > 1. Is there *really* a memory barrier in try_get_compound_head()? Because
> > > I only see a READ_ONCE compile barrier, which would mean that run time
> > > reordering is still possible.
> > 
> > try_get_compound_head() has page_cache_add_speculative() which is
> > atomic_add_unless() which is guaranteed to provide ordering.
> 
> atomic_add_unless() only provides ordering on SUCCESS, now looking at
> the code in question that seems sufficient, so all should be well. Just
> wanted to let you know that if atomic_add_unless() FAILs there is no
> implied ordering what so ever.

Yeah, right, thanks for correction!

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux