From patchwork Wed Jan 17 19:27:11 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoph Hellwig X-Patchwork-Id: 10170615 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 333BA60386 for ; Wed, 17 Jan 2018 19:41:02 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 24CAB21BED for ; Wed, 17 Jan 2018 19:41:02 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 186E021C9A; Wed, 17 Jan 2018 19:41:02 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9550220564 for ; Wed, 17 Jan 2018 19:41:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752627AbeAQT2G (ORCPT ); Wed, 17 Jan 2018 14:28:06 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:50225 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753117AbeAQT2E (ORCPT ); Wed, 17 Jan 2018 14:28:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=References:In-Reply-To:Message-Id: Date:Subject:Cc:To:From:Sender:Reply-To:MIME-Version:Content-Type: 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=+OscGvwgjFUHOhoyIFP8WWrYqikRxItnc4nituNAmcM=; b=N2XZvoGRWPslbaJGKkNks9zYO ogvmDqmZtkS0nxv30755YKX33D8jNl1+NCvCddB7NMaqNPA64/1UQwHH8eXGM1n7W/+SpHHiImtve TnI73bugnnE81KN24cadi7nbfux8dLyZvfGmE2MX/Hagg62kuT21uC6efCNJfdj/5iHlyklxjDiTx uVTr8phXWT/uQbpnquRL5ENwPiDDRN6vvFroKrxLo5BGEECsrICn5/rFIY4qUxZRlGoaGHICZ//P/ g7VT2aeZ6pCLR4oAXrHu8IiVOYDGJcka8eU7MVIBRM6SbItufcVV5MFzO8C3Z6s3QNG9i5IvPCSX0 TxA6cK+Fw==; Received: from 77.117.185.35.wireless.dyn.drei.com ([77.117.185.35] helo=localhost) by bombadil.infradead.org with esmtpsa (Exim 4.89 #1 (Red Hat Linux)) id 1ebtNS-0002yS-5z; Wed, 17 Jan 2018 19:28:02 +0000 From: Christoph Hellwig To: viro@zeniv.linux.org.uk Cc: Avi Kivity , linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 05/36] aio: simplify cancellation Date: Wed, 17 Jan 2018 20:27:11 +0100 Message-Id: <20180117192742.710-6-hch@lst.de> X-Mailer: git-send-email 2.14.2 In-Reply-To: <20180117192742.710-1-hch@lst.de> References: <20180117192742.710-1-hch@lst.de> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP With the current aio code there is no need for the magic KIOCB_CANCELLED value, as a cancelation just kicks the driver to queue the completion ASAP, with all actual completion handling done in another thread. Given that both the completion path and cancelation take the context lock there is no need for magic cmpxchg loops either. Signed-off-by: Christoph Hellwig Acked-by: Jeff Moyer --- fs/aio.c | 37 +++++++++---------------------------- 1 file changed, 9 insertions(+), 28 deletions(-) diff --git a/fs/aio.c b/fs/aio.c index c32c315f05b5..2d40cf5dd4ec 100644 --- a/fs/aio.c +++ b/fs/aio.c @@ -156,19 +156,6 @@ struct kioctx { unsigned id; }; -/* - * We use ki_cancel == KIOCB_CANCELLED to indicate that a kiocb has been either - * cancelled or completed (this makes a certain amount of sense because - * successful cancellation - io_cancel() - does deliver the completion to - * userspace). - * - * And since most things don't implement kiocb cancellation and we'd really like - * kiocb completion to be lockless when possible, we use ki_cancel to - * synchronize cancellation and completion - we only set it to KIOCB_CANCELLED - * with xchg() or cmpxchg(), see batch_complete_aio() and kiocb_cancel(). - */ -#define KIOCB_CANCELLED ((void *) (~0ULL)) - struct aio_kiocb { union { struct kiocb rw; @@ -565,24 +552,18 @@ void kiocb_set_cancel_fn(struct kiocb *iocb, kiocb_cancel_fn *cancel) } EXPORT_SYMBOL(kiocb_set_cancel_fn); +/* + * Only cancel if there ws a ki_cancel function to start with, and we + * are the one how managed to clear it (to protect against simulatinious + * cancel calls). + */ static int kiocb_cancel(struct aio_kiocb *kiocb) { - kiocb_cancel_fn *old, *cancel; - - /* - * Don't want to set kiocb->ki_cancel = KIOCB_CANCELLED unless it - * actually has a cancel function, hence the cmpxchg() - */ - - cancel = READ_ONCE(kiocb->ki_cancel); - do { - if (!cancel || cancel == KIOCB_CANCELLED) - return -EINVAL; - - old = cancel; - cancel = cmpxchg(&kiocb->ki_cancel, old, KIOCB_CANCELLED); - } while (cancel != old); + kiocb_cancel_fn *cancel = kiocb->ki_cancel; + if (!cancel) + return -EINVAL; + kiocb->ki_cancel = NULL; return cancel(&kiocb->rw); }