Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp375638ybi; Fri, 31 May 2019 02:58:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqxdx8PtkN0SQn6eO1bvi3h4dmk7SWKsZgB9YS7ZAwgLiUPpGBAzBnxrKboVdV/sn/wk0c1Z X-Received: by 2002:a63:de4b:: with SMTP id y11mr7176602pgi.301.1559296733684; Fri, 31 May 2019 02:58:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559296733; cv=none; d=google.com; s=arc-20160816; b=Ykhbm5cYEgxGZDvtEBw5d6l2MZ9tJshcWy/8JUIG22T5PgHLCFQUhf8EG4uSadSg33 EQmOFkV424InfpTkwcJZrzRpu5J1O7rKy2pAmXfPq4yd3r2icVPUiXijpXYn6E6idzd2 fG0Y4swiXmHal9u7/ohSjC0WCA/hAar6VDLZPk36E+3TPyzvqVaRXpqbfXjE4O+rbAlU wV4K1y3gZDr3l49bm/6w/CV4i5urCBk844uwB//MMA4St0dBTfuUSyuYle6WmNTdhsfu +DyB8/3vy0DmPe0gzrYieVHFwmGxBk8RJ6rFBkQpTIgd5SeBhyEIIdcf3H5LwqVgounm 2Ewg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=newM6axnRsLPzVidNzZIs9UXkF30YKMRSAFuj0fIORw=; b=Mx4n/FjTevXO6ywPtcPmIg2JatV4H9h8BsyudTxYEXCn8TKRdMN8WeXR4c3AJP5IPY pdoM6rBjKsNeATWmT2lgK/4luMJM4Nx9EfTcJuttzrTaqQ9qN5OcWnDOrOuBoXie0DVl K/z6ddppy8GfT5Lc9DlBvMks1/7UFM3jqraj0abjZqcbgDU6dunf7Xgfmh677FXDAwnP f1aVbA7RUeesusLWUGsImr09jjMQk7eKQISKgVSkc2a0UqM9cYSw3qsZRdujMdad08Dp HbUjZaA6XU9mRA00eoLbr/dMsb+VNCNsay4cVvOnMVOGd0rOOVV6EysG8M5XFNhyAQKC sJ1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=LGsWfVxn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m11si5447443pjq.80.2019.05.31.02.58.37; Fri, 31 May 2019 02:58:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=LGsWfVxn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727184AbfEaJ4N (ORCPT + 99 others); Fri, 31 May 2019 05:56:13 -0400 Received: from merlin.infradead.org ([205.233.59.134]:59418 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726002AbfEaJ4N (ORCPT ); Fri, 31 May 2019 05:56:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=newM6axnRsLPzVidNzZIs9UXkF30YKMRSAFuj0fIORw=; b=LGsWfVxndsoPcaqAe86E0fcjm ACd9wShqg+zN82Gj4OjPnSa1T9+a1I0dGBEIxVp1ACCo+eRXDyZu1wc5PyZoHull9NBCNoMMhSzqE Ltp/mVblBHO9eA6MF+5WeRoGTf0JGdxOF9/N3hwK8006xqQWZCiVd6h8jU9j6iTP/fNQ9uCMGQwJG R/G7lYCFuHLfWAJj9q7bgmhoVvG7Gcd6mWO2n2toyEqVMTtBr5oqsuQAl8h/o+RKf545ZXH6YiUuX YY+ZZ4ADIcugpA3QCuJcKPsQx8OiV9WSKM/hFeDkdV8DgISAzi86B1Y/ytfaEyoqDE5nFiKicdH4x KpAt9uuXQ==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1hWeGf-0003jo-5Y; Fri, 31 May 2019 09:56:09 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id EAE96201D5AB1; Fri, 31 May 2019 11:56:07 +0200 (CEST) Date: Fri, 31 May 2019 11:56:07 +0200 From: Peter Zijlstra To: Roman Penyaev Cc: azat@libevent.org, akpm@linux-foundation.org, viro@zeniv.linux.org.uk, torvalds@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 06/13] epoll: introduce helpers for adding/removing events to uring Message-ID: <20190531095607.GC17637@hirez.programming.kicks-ass.net> References: <20190516085810.31077-1-rpenyaev@suse.de> <20190516085810.31077-7-rpenyaev@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190516085810.31077-7-rpenyaev@suse.de> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 16, 2019 at 10:58:03AM +0200, Roman Penyaev wrote: > +static inline bool ep_add_event_to_uring(struct epitem *epi, __poll_t pollflags) > +{ > + struct eventpoll *ep = epi->ep; > + struct epoll_uitem *uitem; > + bool added = false; > + > + if (WARN_ON(!pollflags)) > + return false; > + > + uitem = &ep->user_header->items[epi->bit]; > + /* > + * Can be represented as: > + * > + * was_ready = uitem->ready_events; > + * uitem->ready_events &= ~EPOLLREMOVED; > + * uitem->ready_events |= pollflags; > + * if (!was_ready) { > + * // create index entry > + * } > + * > + * See the big comment inside ep_remove_user_item(), why it is > + * important to mask EPOLLREMOVED. > + */ > + if (!atomic_or_with_mask(&uitem->ready_events, > + pollflags, EPOLLREMOVED)) { > + unsigned int i, *item_idx, index_mask; > + > + /* > + * Item was not ready before, thus we have to insert > + * new index to the ring. > + */ > + > + index_mask = ep_max_index_nr(ep) - 1; > + i = __atomic_fetch_add(&ep->user_header->tail, 1, > + __ATOMIC_ACQUIRE); afaict __atomic_fetch_add() does not exist. > + item_idx = &ep->user_index[i & index_mask]; > + > + /* Signal with a bit, which is > 0 */ > + *item_idx = epi->bit + 1; Did you just increment the user visible tail pointer before you filled the data? That is, can the concurrent userspace observe the increment before you put credible data in its place? > + > + /* > + * Want index update be flushed from CPU write buffer and > + * immediately visible on userspace side to avoid long busy > + * loops. > + */ > + smp_wmb(); That's still complete nonsense. > + > + added = true; > + } > + > + return added; > +}