From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753501AbcAEUnz (ORCPT ); Tue, 5 Jan 2016 15:43:55 -0500 Received: from mx2.suse.de ([195.135.220.15]:59661 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752745AbcAEUnv (ORCPT ); Tue, 5 Jan 2016 15:43:51 -0500 Date: Tue, 5 Jan 2016 12:43:42 -0800 From: Davidlohr Bueso To: Peter Zijlstra Cc: Mel Gorman , Thomas Gleixner , Sebastian Andrzej Siewior , Chris Mason , Darren Hart , linux-kernel@vger.kernel.org, Davidlohr Bueso Subject: Re: [PATCH] futex: Reduce the scope of lock_page, aka lockless futex_get_key() Message-ID: <20160105204342.GA15465@linux-uzut.site> References: <1452025435-15355-1-git-send-email-dave@stgolabs.net> <20160105203317.GQ6344@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20160105203317.GQ6344@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 05 Jan 2016, Peter Zijlstra wrote: >On Tue, Jan 05, 2016 at 12:23:55PM -0800, Davidlohr Bueso wrote: >> + if (unlikely(!mapping)) { >> + int shmem_swizzled; >> + >> + /* >> + * Page lock is required to identify which special case above >> + * applies. If this is really a shmem page then the page lock >> + * will prevent unexpected transitions. >> + */ >> + lock_page(page); >> + shmem_swizzled = PageSwapCache(page); >> unlock_page(page); >> put_page(page); >> + WARN_ON_ONCE(mapping); > >We've not re-loaded mapping, so how could this possibly be? Yep, this wants to be page->mapping. > > >> + /* >> + * Take a reference unless it is about to be freed. Previously >> + * this reference was taken by ihold under the page lock >> + * pinning the inode in place so i_lock was unnecessary. The >> + * only way for this check to fail is if the inode was >> + * truncated in parallel so warn for now if this happens. >> + * >> + * TODO: VFS and/or filesystem people should review this check >> + * and see if there is a safer or more reliable way to do this. >> + */ >> + if (WARN_ON(!atomic_inc_not_zero(&inode->i_count))) { >> + rcu_read_unlock(); >> + put_page(page); >> + goto again; >> + } >> + >> + /* >> + * get_futex_key() must imply MB (B) and we are not going to >> + * call into get_futex_key_refs() at this point. >> + */ >> + smp_mb__after_atomic(); > >I don't get this one, the above is a successful atomic op with return >value, that _must_ imply a full barrier. Ah sure, I was actually following convention of what we have for our plain atomic_inc, but in this case we are returning a value, so yeah, it is not required. Will drop. Thanks, Davidlohr