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, 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.




[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