Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp3690926ybv; Mon, 10 Feb 2020 04:47:16 -0800 (PST) X-Google-Smtp-Source: APXvYqzwW6NkdvtqiFf9Q7+6X6rv6mwxjmVSFPTmQp4j/QGqxXFk0FSKwCo1dc9SADspmHuv4Oxa X-Received: by 2002:aca:c7ca:: with SMTP id x193mr724617oif.70.1581338836285; Mon, 10 Feb 2020 04:47:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581338836; cv=none; d=google.com; s=arc-20160816; b=TQX9HaH2zWYVwzlHYZsMPZTE0Fv3/keZj/XZg46oYNQaqOQiKce/hXL2DqB630XzZw iuQg5SUmFo7j7BWbLp7N7x8HclXOOi3T1n6eHovw58zrH6AqaaYqE+z2Q3wwrxnOAMDo /jf6+yh8TitElZk/qH1SiF4Xx2EmUe94urKA7JI10FgU5DH3jC5lJFXScnd4XxQ3R5DS ntMkeGnyPYbYf6IKVQcIHG8tdsjei/C6teQObdCJ6WOsWhuLRgc8DIqKd6UEJ2Rv+Twq SvjtqUzpI5pmslIdiVhf6hs49aUEWAXhtCMhRc5mQyi9CXbeFezioXljMdQGLBaC35J5 e37g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=CYQL/FYdDJACfioZEpzmyXcOK5EZ8uJV0jjs8bdRP8o=; b=gtGLzvjG/ryb+0U2Ag6i06PI6AFXbnz7M2ynr2d9lqMErUbispiWV2edXpUDYgXrLn bgihR3lrPqOCy8Yw9bhlojwxAo7jz1HIdKVtWCQjwNMBbRwPKt3jM1E53HobI/StODUM upyTQBsJOyXGet6I4fZ2ZbnHBf4Ttjqf3MJ6xG1xzf8tW5tY36EYWDsjU2OA0iP/fAX6 AfheMfDEsFmBC2jLIq2461ba5sjxIPJeWK9KE7NBW71Vrc/Q5Ks8GkUINhnwFGwGpoAR pAj6D49GlZ49+3IMQdfEXtjF8gbkoxVNNOv56aj48ha20Xm3u+TGkL2saVFZjCXbgNZH NnGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=uOqjpd2D; 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 v21si114731oie.178.2020.02.10.04.47.04; Mon, 10 Feb 2020 04:47:16 -0800 (PST) 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=pass header.i=@kernel.org header.s=default header.b=uOqjpd2D; 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 S1728165AbgBJMpk (ORCPT + 99 others); Mon, 10 Feb 2020 07:45:40 -0500 Received: from mail.kernel.org ([198.145.29.99]:42580 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729885AbgBJMlG (ORCPT ); Mon, 10 Feb 2020 07:41:06 -0500 Received: from localhost (unknown [209.37.97.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BAF0320661; Mon, 10 Feb 2020 12:41:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581338465; bh=u5iY+zUkAwoQvPV4FOjhEXet1A340J2ouQeqEjKVdEQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uOqjpd2DnEWWwEInlM5wXRhqSHyRkB4uEZHZG9itztrMXL9uiumDDdrALGpolCCbp gfZwt71NEHOL9lhM41MepjwsXKjzn1bOF1HvjeBVtNBj9ZZnviFuF8tywreIqXEQ3p klz5XU4UL0rqpry5GMbHS9EYnz4XHS/vi//zmVq4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jeff Moyer , Jens Axboe Subject: [PATCH 5.5 226/367] aio: prevent potential eventfd recursion on poll Date: Mon, 10 Feb 2020 04:32:19 -0800 Message-Id: <20200210122445.299858467@linuxfoundation.org> X-Mailer: git-send-email 2.25.0 In-Reply-To: <20200210122423.695146547@linuxfoundation.org> References: <20200210122423.695146547@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jens Axboe commit 01d7a356872eec22ef34a33a5f9cfa917d145468 upstream. If we have nested or circular eventfd wakeups, then we can deadlock if we run them inline from our poll waitqueue wakeup handler. It's also possible to have very long chains of notifications, to the extent where we could risk blowing the stack. Check the eventfd recursion count before calling eventfd_signal(). If it's non-zero, then punt the signaling to async context. This is always safe, as it takes us out-of-line in terms of stack and locking context. Cc: stable@vger.kernel.org # 4.19+ Reviewed-by: Jeff Moyer Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman --- fs/aio.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) --- a/fs/aio.c +++ b/fs/aio.c @@ -1610,6 +1610,14 @@ static int aio_fsync(struct fsync_iocb * return 0; } +static void aio_poll_put_work(struct work_struct *work) +{ + struct poll_iocb *req = container_of(work, struct poll_iocb, work); + struct aio_kiocb *iocb = container_of(req, struct aio_kiocb, poll); + + iocb_put(iocb); +} + static void aio_poll_complete_work(struct work_struct *work) { struct poll_iocb *req = container_of(work, struct poll_iocb, work); @@ -1674,6 +1682,8 @@ static int aio_poll_wake(struct wait_que list_del_init(&req->wait.entry); if (mask && spin_trylock_irqsave(&iocb->ki_ctx->ctx_lock, flags)) { + struct kioctx *ctx = iocb->ki_ctx; + /* * Try to complete the iocb inline if we can. Use * irqsave/irqrestore because not all filesystems (e.g. fuse) @@ -1683,8 +1693,14 @@ static int aio_poll_wake(struct wait_que list_del(&iocb->ki_list); iocb->ki_res.res = mangle_poll(mask); req->done = true; - spin_unlock_irqrestore(&iocb->ki_ctx->ctx_lock, flags); - iocb_put(iocb); + if (iocb->ki_eventfd && eventfd_signal_count()) { + iocb = NULL; + INIT_WORK(&req->work, aio_poll_put_work); + schedule_work(&req->work); + } + spin_unlock_irqrestore(&ctx->ctx_lock, flags); + if (iocb) + iocb_put(iocb); } else { schedule_work(&req->work); }