Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3326848ybc; Thu, 14 Nov 2019 07:28:14 -0800 (PST) X-Google-Smtp-Source: APXvYqyVvRSbrCWqQBWhHeO14b8oQ3Ghyiy0XL2ohgZWy0x4dtdhZsG7zm3qQWZd/TwTFEujI6d+ X-Received: by 2002:a17:906:70d6:: with SMTP id g22mr8830770ejk.221.1573745294478; Thu, 14 Nov 2019 07:28:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573745294; cv=none; d=google.com; s=arc-20160816; b=QU1Sqy0LL+o3fnCawEWvTR4eveTDGgZ3emfUaVShox5YCS2ftkEAmOLPnW7gumXLrB /H2u9UX6LQL/yKyx68QGskssx1+jo6c47aWH2KPNJEWZWtJsKc5XcTcOovxVpirIaMCQ TFfQTVkChgyQHBymnQooOHUl1+g+CZky7oZAReGtny8PN4P8oA/IVFOAUuwQ29GaqJVc 6eDadtNDzRxdXTGvAB+QvlOeO7BYRlOXskFGrp8DiaHK324yzS2Rib5lgGEs0o+MDQry OOgV+nkUyE9s5Y3Qy1IWlMkP/aPuX4wTDLdLR39h9NyM3gGvQwarOWCGoGZpTHg9xdSy /FSw== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject:dkim-signature; bh=Pb54/52KiePo49EfwninY5VWqB/XGPD0qnr9bLS7S8k=; b=kJJUYQ29J2CsYhtnYxtLMJdm7PZQmjBWQlLsZarr5kCR6Z5pyHgx+4epRd+Q7CvSeX rpy0G+O2FtwiHQmG69M7wjR9fyZZ6sfobuZlTXsMMpvPyASmAU3IAvd5HN3r4v2tPiGa OQfQ6/CROVwMfovIGGVUN/zG7h7mDfoqX4dfok/lDuUn5dC9nkjdK5MTbObUVDnMwWTH BSxEy+WwRZkSXdlJiSbDgRLL8o57XoheYQeIqTCvHV977Q+9m31qgz6SCmwbaw+BnvOK w7yt97btDh41if0tRSezEP3gBnxdi2xRG2hCM4EbdlDF51FnteNARxHvAnWiUZSJ4l72 86JA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=rDovllyb; 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 f12si3548881eje.253.2019.11.14.07.27.49; Thu, 14 Nov 2019 07:28:14 -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-dk.20150623.gappssmtp.com header.s=20150623 header.b=rDovllyb; 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 S1726996AbfKNP1G (ORCPT + 99 others); Thu, 14 Nov 2019 10:27:06 -0500 Received: from mail-io1-f66.google.com ([209.85.166.66]:45119 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726482AbfKNP1G (ORCPT ); Thu, 14 Nov 2019 10:27:06 -0500 Received: by mail-io1-f66.google.com with SMTP id v17so7183233iol.12 for ; Thu, 14 Nov 2019 07:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Pb54/52KiePo49EfwninY5VWqB/XGPD0qnr9bLS7S8k=; b=rDovllybZqP1ZDWSHLZO6REyTT9oYLVsCxmcdg0WVk1ON7+4YYdxZU+I7l/0XAUoJF tmcEP6qLPv2dEzCfH04xvQpTf5Sbw85Kpn3OnVNT5YgESlrv20DxTucx6+EeAT8w3r9z lNMBxbUVDl4tQZx6P/rmmzppXh/cBEWrh/zOuc68bss/MPoI1B9xRWUiLM6wJUiXe9uo TpjdAI0/OSvNka5ShdqM5Wkzc6gRP60UGMC3IfA6llkqWpnRZRZKukjE/ohBrdK6qTrI e4gfzoFBUvL3r2A7PyfoAjpCphwcunR48nIaKrIJIKE+ml7Bnf1orU/t4tvyjQNVNbK1 sjPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Pb54/52KiePo49EfwninY5VWqB/XGPD0qnr9bLS7S8k=; b=Kd4rSs/I36i+aaezv2SUbJBk+nwqsrq10WVM/reEDNoWLQHHMZs+T/7Evz6rBWWQk7 M0hSRKv5Vc71AaZ5GGVxKMAI06OBqCPVKksnFjxGVqn+YHfYxNLqTOOW3JGLa8Kxovn2 ZX4OPMWPDGpl2o4fgdkLNlkX2j9KAWPZ4Z1jd+5Azw83ZCI9l9bOZR3eHFsMe9wtl7BR 9jcdCYCKGXt3u4wHQaYlf3LLb/gtZXFTP+t5L2PrqBKnLE4+VQWr+KXm8fsba8mUCa0t hon9KAGzUqxt/4D30MFKiOlLhDM13GQCHX+DeqsTxt7k4WGvqh2YBKXt0nzp4y+4+KlC admg== X-Gm-Message-State: APjAAAXJ2T21OSgynkp+o4U2P81Q5oCM4LvSrndS0cvhEBG0mmp88j4n vNRjZ3sv49Ls2tIi0fRV2OST5Q== X-Received: by 2002:a02:a086:: with SMTP id g6mr8065764jah.56.1573745223480; Thu, 14 Nov 2019 07:27:03 -0800 (PST) Received: from [192.168.1.159] ([65.144.74.34]) by smtp.gmail.com with ESMTPSA id l63sm505052ioa.19.2019.11.14.07.27.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Nov 2019 07:27:02 -0800 (PST) Subject: Re: [PATCH RFC] io_uring: make signalfd work with io_uring (and aio) POLL From: Jens Axboe To: Rasmus Villemoes , Jann Horn Cc: io-uring@vger.kernel.org, "linux-kernel@vger.kernel.org" , Alexander Viro , Andrew Morton , linux-fsdevel , Christoph Hellwig References: <58059c9c-adf9-1683-99f5-7e45280aea87@kernel.dk> <58246851-fa45-a72d-2c42-7e56461ec04e@kernel.dk> <0f74341f-76fa-93ee-c03e-554d02707053@rasmusvillemoes.dk> <6243eb59-3340-deb5-d4b8-08501be01f34@kernel.dk> Message-ID: <85e8e954-d09c-f0b4-0944-598208098c8c@kernel.dk> Date: Thu, 14 Nov 2019 08:27:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <6243eb59-3340-deb5-d4b8-08501be01f34@kernel.dk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/14/19 8:20 AM, Jens Axboe wrote: > On 11/14/19 8:19 AM, Rasmus Villemoes wrote: >> On 14/11/2019 16.09, Jens Axboe wrote: >>> On 11/14/19 7:12 AM, Rasmus Villemoes wrote: >> >>>> So, I can't really think of anybody that might be relying on inheriting >>>> a signalfd instead of just setting it up in the child, but changing the >>>> semantics of it now seems rather dangerous. Also, I _can_ imagine >>>> threads in a process sharing a signalfd (initial thread sets it up and >>>> blocks the signals, all threads subsequently use that same fd), and for >>>> that case it would be wrong for one thread to dequeue signals directed >>>> at the initial thread. Plus the lifetime problems. >>> >>> What if we just made it specific SFD_CLOEXEC? >> >> O_CLOEXEC can be set and removed afterwards. Sure, we're far into >> "nobody does that" land, but having signalfd() have wildly different >> semantics based on whether it was initially created with O_CLOEXEC seems >> rather dubious. >> >> I don't want to break >>> existing applications, even if the use case is nonsensical, but it is >>> important to allow signalfd to be properly used with use cases that are >>> already in the kernel (aio with IOCB_CMD_POLL, io_uring with >>> IORING_OP_POLL_ADD). Alternatively, if need be, we could add a specific >>> SFD_ flag for this. >> >> Yeah, if you want another signalfd flavour, adding it via a new SFD_ >> flag seems the way to go. Though I can't imagine the resulting code >> would be very pretty. > > Well, it's currently _broken_ for the listed in-kernel use cases, so > I think making it work is the first priority here. How about something like this, then? Not tested. diff --git a/fs/signalfd.c b/fs/signalfd.c index 44b6845b071c..d8b183ec1d4e 100644 --- a/fs/signalfd.c +++ b/fs/signalfd.c @@ -50,6 +50,8 @@ void signalfd_cleanup(struct sighand_struct *sighand) struct signalfd_ctx { sigset_t sigmask; + struct task_struct *task; + u32 task_exec_id; }; static int signalfd_release(struct inode *inode, struct file *file) @@ -61,16 +63,22 @@ static int signalfd_release(struct inode *inode, struct file *file) static __poll_t signalfd_poll(struct file *file, poll_table *wait) { struct signalfd_ctx *ctx = file->private_data; + struct task_struct *tsk = ctx->task ?: current; __poll_t events = 0; - poll_wait(file, ¤t->sighand->signalfd_wqh, wait); + if (ctx->task && ctx->task->self_exec_id == ctx->task_exec_id) + tsk = ctx->task; + else + tsk = current; - spin_lock_irq(¤t->sighand->siglock); - if (next_signal(¤t->pending, &ctx->sigmask) || - next_signal(¤t->signal->shared_pending, + poll_wait(file, &tsk->sighand->signalfd_wqh, wait); + + spin_lock_irq(&tsk->sighand->siglock); + if (next_signal(&tsk->pending, &ctx->sigmask) || + next_signal(&tsk->signal->shared_pending, &ctx->sigmask)) events |= EPOLLIN; - spin_unlock_irq(¤t->sighand->siglock); + spin_unlock_irq(&tsk->sighand->siglock); return events; } @@ -267,19 +275,26 @@ static int do_signalfd4(int ufd, sigset_t *mask, int flags) /* Check the SFD_* constants for consistency. */ BUILD_BUG_ON(SFD_CLOEXEC != O_CLOEXEC); BUILD_BUG_ON(SFD_NONBLOCK != O_NONBLOCK); + BUILD_BUG_ON(SFD_TASK & (SFD_CLOEXEC | SFD_NONBLOCK)); - if (flags & ~(SFD_CLOEXEC | SFD_NONBLOCK)) + if (flags & ~(SFD_CLOEXEC | SFD_NONBLOCK | SFD_TASK)) + return -EINVAL; + if ((flags & (SFD_CLOEXEC | SFD_TASK)) == SFD_TASK) return -EINVAL; sigdelsetmask(mask, sigmask(SIGKILL) | sigmask(SIGSTOP)); signotset(mask); if (ufd == -1) { - ctx = kmalloc(sizeof(*ctx), GFP_KERNEL); + ctx = kzalloc(sizeof(*ctx), GFP_KERNEL); if (!ctx) return -ENOMEM; ctx->sigmask = *mask; + if (flags & SFD_TASK) { + ctx->task = current; + ctx->task_exec_id = current->self_exec_id; + } /* * When we call this, the initialization must be complete, since diff --git a/include/uapi/linux/signalfd.h b/include/uapi/linux/signalfd.h index 83429a05b698..064c5dc3eb99 100644 --- a/include/uapi/linux/signalfd.h +++ b/include/uapi/linux/signalfd.h @@ -16,6 +16,7 @@ /* Flags for signalfd4. */ #define SFD_CLOEXEC O_CLOEXEC #define SFD_NONBLOCK O_NONBLOCK +#define SFD_TASK 00000001 struct signalfd_siginfo { __u32 ssi_signo; -- Jens Axboe