From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764310AbcINPp6 (ORCPT ); Wed, 14 Sep 2016 11:45:58 -0400 Received: from mx2.suse.de ([195.135.220.15]:48329 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761966AbcINPpx (ORCPT ); Wed, 14 Sep 2016 11:45:53 -0400 Date: Wed, 14 Sep 2016 08:45:48 -0700 From: Davidlohr Bueso To: Manfred Spraul Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Davidlohr Bueso Subject: Re: [PATCH 2/5] ipc/sem: rework task wakeups Message-ID: <20160914154548.GB28073@linux-80c1.suse> References: <1473681216-20025-1-git-send-email-dave@stgolabs.net> <1473681216-20025-3-git-send-email-dave@stgolabs.net> <6b406bcf-75e6-6f59-1de8-fe1c2c2f1315@colorfullife.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <6b406bcf-75e6-6f59-1de8-fe1c2c2f1315@colorfullife.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Sep 2016, Manfred Spraul wrote: >>+ if ((error = queue.status) != -EINTR && !signal_pending(current)) { >>+ /* >>+ * User space could assume that semop() is a memory barrier: >>+ * Without the mb(), the cpu could speculatively read in user >>+ * space stale data that was overwritten by the previous owner >>+ * of the semaphore. >> */ >> smp_mb(); >>- >> goto out_free; >> } >> rcu_read_lock(); >> sma = sem_obtain_lock(ns, semid, sops, nsops, &locknum); >What is the purpose of the !signal_pending()? >Even if there is a signal: If someone has set queue.status, then our >semaphore operations completed and we must return that result code. It was a way of detecting being awoken by an unrelated event while the task is marked for wakeup and wake_up_process is still not called and force the slowpath. The same window that get_queue_result deals with by busy waiting when IN_WAKEUP. >Obviously: At syscall return, the syscall return code will notice the >pending signal and immediately the signal handler is called, but I >don't see that this prevents us from using the fast path. Right, and we cannot race with sys_exit. Will drop the signal check. >And, at least my opinion: I would avoid placing the error= into the if(). Sure, agreed. Thanks, Davidlohr