Message ID | 20240125225704.12781-4-jdamato@fastly.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-39395-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:e09d:b0:103:945f:af90 with SMTP id gm29csp314226dyb; Thu, 25 Jan 2024 15:01:16 -0800 (PST) X-Google-Smtp-Source: AGHT+IGIs3qNP5HVW7UTbGrF9OPFucMDV+tRbjGJXF3wDZ0BSAW8RJMw+dpwqC8S1W9FLVB9NhSj X-Received: by 2002:a17:902:d48b:b0:1d4:25d5:5a75 with SMTP id c11-20020a170902d48b00b001d425d55a75mr516776plg.74.1706223676295; Thu, 25 Jan 2024 15:01:16 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706223676; cv=pass; d=google.com; s=arc-20160816; b=buSgSvouefEU9SAg7gq7Q3zXWaMBN8FQr7bELx8EwF0PFOmvWDMnXb6KOUbSmsSXWH nhaCNxfSiPxUAQSdRKNx/uEv3Cx//xqWLKf2qpFylvA+JZpzBchQY6W+JSpotSZ84B+0 IijK8SrmII31+l7H2OAeTS2KxIRjJxlsLKKZl5smtBiOWFgWZtYlxvRb1gRUEP9zb3Tu qpYWUDOB23xPFQkZ9yPP4cJ2znqh+c4YIvv27YLzG3GF9Ic/WJQszqU2TYuGmOCDcHFJ KiE7GNcJQXMYWoZVLM8NBqBCCiIqgsFbvzyHZyQzJGqRL4psL82uINBEKW7uNl0xWiLu IR/g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=lGA3mbdBd/zeAlBJTaRnqUyMp6Mg1t+BBnoYkgoxqFQ=; fh=13ML0Ts+TAZCBK5Xu4Tytdb43Hj7j+tlNOBTtrs4qSk=; b=gT0alkIp3k0kvPLaQa49mkzd7tO2PFbXmNQL8Li8rX719iwd3C5ZGQHeiQzdzS89bU 6UcZ6A2yvM7YIuXQKTR1L/u66U5ZzolddVbz08txFwl1KNl4t5knWxahY2pO6FYeVUXm +kUQAupZWAhGwxg6ntS/jdUCrolGSFDWjuYpu7VCFwO1ujXcuj5tej+6zOlItAEGrQZA WPOB+Yrl17eW+HkhxG2lRcIoUul9h8Xr+EB4w8L/49NAHSUr0cx/u0lSax6aDhtwlbKc hFjHEr6PJTl8B2EWqVt3WFQclPlY5AsXp+JP3OnIrLvr8RKiDGDWatDezGgszpp2ZLOr IjdQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@fastly.com header.s=google header.b=fksUhXYA; arc=pass (i=1 spf=pass spfdomain=fastly.com dkim=pass dkdomain=fastly.com dmarc=pass fromdomain=fastly.com); spf=pass (google.com: domain of linux-kernel+bounces-39395-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-39395-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=fastly.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id ix6-20020a170902f80600b001d787d9d62esi13191plb.210.2024.01.25.15.01.16 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jan 2024 15:01:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-39395-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@fastly.com header.s=google header.b=fksUhXYA; arc=pass (i=1 spf=pass spfdomain=fastly.com dkim=pass dkdomain=fastly.com dmarc=pass fromdomain=fastly.com); spf=pass (google.com: domain of linux-kernel+bounces-39395-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-39395-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=fastly.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id A6CC728F738 for <ouuuleilei@gmail.com>; Thu, 25 Jan 2024 23:01:09 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CD2041A726; Thu, 25 Jan 2024 22:57:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=fastly.com header.i=@fastly.com header.b="fksUhXYA" Received: from mail-oo1-f50.google.com (mail-oo1-f50.google.com [209.85.161.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D97241947F for <linux-kernel@vger.kernel.org>; Thu, 25 Jan 2024 22:57:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.50 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706223476; cv=none; b=DVztmlm0tu8XouYaCp/B4+H889OO1fylKwZ3w82UkVOCVeDBNWt9YKwex+7xNINxi4jFFuCkmB4M9kvZzPqwYoYMvZVdqxXW5ffWdgpMi0HQLAIcpsD6ZjFjoaBnt80eqLBmiZ3oCbiKhmgBqbR5OUaIiyimypVldW4yZSBFk6k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706223476; c=relaxed/simple; bh=BCSqrZ9DLkXBlfucIFiKDapTJzswZizsRiSDn8OrvBQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=AIkWXlN1pbVP9eVReuzVPEithW27sz/eUdnSRyEI+2efYvb5zzSAsf//0+8tlvxVKdy7eC+wBURiRdcE7Spj/T4+ZZOcyfn2n3v6X6KXcHhURp9o83rOUse1kA5r5Qdj9ZSDHuZvWhcsUd1Yd7WQ5rHXtXe9WUeYD0MkCOZGLLI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=fastly.com; spf=pass smtp.mailfrom=fastly.com; dkim=pass (1024-bit key) header.d=fastly.com header.i=@fastly.com header.b=fksUhXYA; arc=none smtp.client-ip=209.85.161.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=fastly.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fastly.com Received: by mail-oo1-f50.google.com with SMTP id 006d021491bc7-599ef8b1c35so27555eaf.0 for <linux-kernel@vger.kernel.org>; Thu, 25 Jan 2024 14:57:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; t=1706223473; x=1706828273; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=lGA3mbdBd/zeAlBJTaRnqUyMp6Mg1t+BBnoYkgoxqFQ=; b=fksUhXYAa2oMRpsDfRj3YHst/iyi9aJLZRzTEHZ++MaS/NLAOoBSKbwG2gZ6UKH4RL mD63+XN/vjWEf2f10Qm4OtbHDZgVd3nMJsoOEvzv/PdPpfsdTEH8fEe/myeHQ9go0cmV DPM9PbYHXWGRyJd89tPDG9zTkoViWNpLnM6DI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706223473; x=1706828273; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lGA3mbdBd/zeAlBJTaRnqUyMp6Mg1t+BBnoYkgoxqFQ=; b=sZ4tlV43uocpcwnpwkkXFmkxGMPUXc0D1ecQh50UfYuGYH0XVsRYsE1pmP2kInjG1U 2kTDCFaichmt19PPIbl1C/29iTiH1Z17WOk5eh0wX3ZiS5lz9yjodUWmzW8umqjshVnG d3wCpJR7du7/PxTMb9ML75Lo7rdag5s68wDuINOViMTEkLmoA2yCvByf+ApEqF6BlO+s iXzMKhKKb39YKdhOcoDpZdYkK+XHikv5r6RMsSu4D/JJT9Di3GPXuxXDQ+haMh0YTcRR RkCQ/4jqcwL/kJlfArCQ+emhuveMt+qCdE7vIuCixnSOVMu/t5m9nsgN6r1Axw8xX5PD tGlg== X-Gm-Message-State: AOJu0Yyk4Z0n9kpM2XiWqOfaKwq/TCXZm53ypD4PDyAAmaHvgluSQaWL J2WFrPSqzTUxtohZhaRrWThScamTt38ZyjplKQcURVUzLX6/e3sryWqmE2DHZfbZNIYU6b0J3Ad mLGKq9JtS6nWVsHQMTU9AfY3Tg1DOLzgOaBuWa7pmCR9Snn3z/8BWdBPNXCB1TX5S7HM5ekBjKN SmhIGQ/AUnQAqxyiAsOvw1XRwAZMZ0E7X93Y1argBM8kwatg== X-Received: by 2002:a05:6358:9497:b0:176:916b:462b with SMTP id i23-20020a056358949700b00176916b462bmr515749rwb.4.1706223473551; Thu, 25 Jan 2024 14:57:53 -0800 (PST) Received: from localhost.localdomain ([2620:11a:c018:0:ea8:be91:8d1:f59b]) by smtp.gmail.com with ESMTPSA id z24-20020a631918000000b005d68962e1a7sm19948pgl.24.2024.01.25.14.57.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jan 2024 14:57:53 -0800 (PST) From: Joe Damato <jdamato@fastly.com> To: linux-kernel@vger.kernel.org, netdev@vger.kernel.org Cc: chuck.lever@oracle.com, jlayton@kernel.org, linux-api@vger.kernel.org, brauner@kernel.org, edumazet@google.com, davem@davemloft.net, alexander.duyck@gmail.com, sridhar.samudrala@intel.com, kuba@kernel.org, willemdebruijn.kernel@gmail.com, weiwan@google.com, Joe Damato <jdamato@fastly.com>, Jonathan Corbet <corbet@lwn.net>, Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>, Michael Ellerman <mpe@ellerman.id.au>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Nathan Lynch <nathanl@linux.ibm.com>, Steve French <stfrench@microsoft.com>, Thomas Zimmermann <tzimmermann@suse.de>, Jiri Slaby <jirislaby@kernel.org>, Julien Panis <jpanis@baylibre.com>, Arnd Bergmann <arnd@arndb.de>, Andrew Waterman <waterman@eecs.berkeley.edu>, Thomas Huth <thuth@redhat.com>, Palmer Dabbelt <palmer@dabbelt.com>, linux-doc@vger.kernel.org (open list:DOCUMENTATION), linux-fsdevel@vger.kernel.org (open list:FILESYSTEMS (VFS and infrastructure)) Subject: [PATCH net-next v3 3/3] eventpoll: Add epoll ioctl for epoll_params Date: Thu, 25 Jan 2024 22:56:59 +0000 Message-Id: <20240125225704.12781-4-jdamato@fastly.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20240125225704.12781-1-jdamato@fastly.com> References: <20240125225704.12781-1-jdamato@fastly.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789105197533069733 X-GMAIL-MSGID: 1789105197533069733 |
Series |
Per epoll context busy poll support
|
|
Commit Message
Joe Damato
Jan. 25, 2024, 10:56 p.m. UTC
Add an ioctl for getting and setting epoll_params. User programs can use
this ioctl to get and set the busy poll usec time or packet budget
params for a specific epoll context.
Signed-off-by: Joe Damato <jdamato@fastly.com>
---
.../userspace-api/ioctl/ioctl-number.rst | 1 +
fs/eventpoll.c | 64 +++++++++++++++++++
include/uapi/linux/eventpoll.h | 12 ++++
3 files changed, 77 insertions(+)
Comments
On Thu, Jan 25, 2024 at 10:56:59PM +0000, Joe Damato wrote: > --- a/fs/eventpoll.c > +++ b/fs/eventpoll.c > @@ -6,6 +6,8 @@ > * Davide Libenzi <davidel@xmailserver.org> > */ > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > + Why this addition? You do not add any pr_*() calls in this patch at all that I can see. thanks, greg k-h
On Thu, Jan 25, 2024 at 10:56:59PM +0000, Joe Damato wrote: > +struct epoll_params { > + u64 busy_poll_usecs; > + u16 busy_poll_budget; > + > + /* for future fields */ > + u8 data[118]; > +} EPOLL_PACKED; variables that cross the user/kernel boundry need to be __u64, __u16, and __u8 here. And why 118? thanks, greg k-h
On Thu, Jan 25, 2024 at 10:56:59PM +0000, Joe Damato wrote: > Add an ioctl for getting and setting epoll_params. User programs can use > this ioctl to get and set the busy poll usec time or packet budget > params for a specific epoll context. > > Signed-off-by: Joe Damato <jdamato@fastly.com> > --- > .../userspace-api/ioctl/ioctl-number.rst | 1 + > fs/eventpoll.c | 64 +++++++++++++++++++ > include/uapi/linux/eventpoll.h | 12 ++++ > 3 files changed, 77 insertions(+) > > diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst > index 457e16f06e04..b33918232f78 100644 > --- a/Documentation/userspace-api/ioctl/ioctl-number.rst > +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst > @@ -309,6 +309,7 @@ Code Seq# Include File Comments > 0x89 0B-DF linux/sockios.h > 0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range > 0x89 F0-FF linux/sockios.h SIOCDEVPRIVATE range > +0x8A 00-1F linux/eventpoll.h > 0x8B all linux/wireless.h > 0x8C 00-3F WiNRADiO driver > <http://www.winradio.com.au/> > diff --git a/fs/eventpoll.c b/fs/eventpoll.c > index 40bd97477b91..73ae886efb8a 100644 > --- a/fs/eventpoll.c > +++ b/fs/eventpoll.c > @@ -6,6 +6,8 @@ > * Davide Libenzi <davidel@xmailserver.org> > */ > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > + > #include <linux/init.h> > #include <linux/kernel.h> > #include <linux/sched/signal.h> > @@ -37,6 +39,7 @@ > #include <linux/seq_file.h> > #include <linux/compat.h> > #include <linux/rculist.h> > +#include <linux/capability.h> > #include <net/busy_poll.h> > > /* > @@ -495,6 +498,39 @@ static inline void ep_set_busy_poll_napi_id(struct epitem *epi) > ep->napi_id = napi_id; > } > > +static long ep_eventpoll_bp_ioctl(struct file *file, unsigned int cmd, > + unsigned long arg) > +{ > + struct eventpoll *ep; > + struct epoll_params epoll_params; > + void __user *uarg = (void __user *) arg; > + > + ep = file->private_data; > + > + switch (cmd) { > + case EPIOCSPARAMS: > + if (copy_from_user(&epoll_params, uarg, sizeof(epoll_params))) > + return -EFAULT; > + > + if (epoll_params.busy_poll_budget > NAPI_POLL_WEIGHT && > + !capable(CAP_NET_ADMIN)) > + return -EPERM; > + > + ep->busy_poll_usecs = epoll_params.busy_poll_usecs; > + ep->busy_poll_budget = epoll_params.busy_poll_budget; > + return 0; > + case EPIOCGPARAMS: > + memset(&epoll_params, 0, sizeof(epoll_params)); > + epoll_params.busy_poll_usecs = ep->busy_poll_usecs; > + epoll_params.busy_poll_budget = ep->busy_poll_budget; > + if (copy_to_user(uarg, &epoll_params, sizeof(epoll_params))) > + return -EFAULT; > + return 0; > + default: > + return -ENOIOCTLCMD; > + } > +} > + > #else > > static inline bool ep_busy_loop(struct eventpoll *ep, int nonblock) > @@ -510,6 +546,12 @@ static inline bool ep_busy_loop_on(struct eventpoll *ep) > { > return false; > } > + > +static long ep_eventpoll_bp_ioctl(struct file *file, unsigned int cmd, > + unsigned long arg) > +{ > + return -EOPNOTSUPP; > +} > #endif /* CONFIG_NET_RX_BUSY_POLL */ > > /* > @@ -869,6 +911,26 @@ static void ep_clear_and_put(struct eventpoll *ep) > ep_free(ep); > } > > +static long ep_eventpoll_ioctl(struct file *file, unsigned int cmd, unsigned long arg) > +{ > + int ret; > + > + if (!is_file_epoll(file)) > + return -EINVAL; > + > + switch (cmd) { > + case EPIOCSPARAMS: > + case EPIOCGPARAMS: > + ret = ep_eventpoll_bp_ioctl(file, cmd, arg); > + break; > + default: > + ret = -EINVAL; > + break; > + } > + > + return ret; > +} > + > static int ep_eventpoll_release(struct inode *inode, struct file *file) > { > struct eventpoll *ep = file->private_data; > @@ -975,6 +1037,8 @@ static const struct file_operations eventpoll_fops = { > .release = ep_eventpoll_release, > .poll = ep_eventpoll_poll, > .llseek = noop_llseek, > + .unlocked_ioctl = ep_eventpoll_ioctl, > + .compat_ioctl = compat_ptr_ioctl, > }; > > /* > diff --git a/include/uapi/linux/eventpoll.h b/include/uapi/linux/eventpoll.h > index cfbcc4cc49ac..8eb0fdbce995 100644 > --- a/include/uapi/linux/eventpoll.h > +++ b/include/uapi/linux/eventpoll.h > @@ -85,4 +85,16 @@ struct epoll_event { > __u64 data; > } EPOLL_PACKED; > > +struct epoll_params { > + u64 busy_poll_usecs; > + u16 busy_poll_budget; > + > + /* for future fields */ > + u8 data[118]; You forgot to validate that "data" is set to 0, which means that this would be useless. Why have this at all? thanks, greg k-h
On Thu, Jan 25, 2024 at 03:20:37PM -0800, Greg Kroah-Hartman wrote: > On Thu, Jan 25, 2024 at 10:56:59PM +0000, Joe Damato wrote: > > --- a/fs/eventpoll.c > > +++ b/fs/eventpoll.c > > @@ -6,6 +6,8 @@ > > * Davide Libenzi <davidel@xmailserver.org> > > */ > > > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > + > > Why this addition? You do not add any pr_*() calls in this patch at all > that I can see. Thanks, I've removed this for the next version. It was a remnant from a previous version.
On Thu, Jan 25, 2024 at 03:22:34PM -0800, Greg Kroah-Hartman wrote: > On Thu, Jan 25, 2024 at 10:56:59PM +0000, Joe Damato wrote: > > Add an ioctl for getting and setting epoll_params. User programs can use > > this ioctl to get and set the busy poll usec time or packet budget > > params for a specific epoll context. > > > > Signed-off-by: Joe Damato <jdamato@fastly.com> > > --- > > .../userspace-api/ioctl/ioctl-number.rst | 1 + > > fs/eventpoll.c | 64 +++++++++++++++++++ > > include/uapi/linux/eventpoll.h | 12 ++++ > > 3 files changed, 77 insertions(+) > > > > diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst > > index 457e16f06e04..b33918232f78 100644 > > --- a/Documentation/userspace-api/ioctl/ioctl-number.rst > > +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst > > @@ -309,6 +309,7 @@ Code Seq# Include File Comments > > 0x89 0B-DF linux/sockios.h > > 0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range > > 0x89 F0-FF linux/sockios.h SIOCDEVPRIVATE range > > +0x8A 00-1F linux/eventpoll.h > > 0x8B all linux/wireless.h > > 0x8C 00-3F WiNRADiO driver > > <http://www.winradio.com.au/> > > diff --git a/fs/eventpoll.c b/fs/eventpoll.c > > index 40bd97477b91..73ae886efb8a 100644 > > --- a/fs/eventpoll.c > > +++ b/fs/eventpoll.c > > @@ -6,6 +6,8 @@ > > * Davide Libenzi <davidel@xmailserver.org> > > */ > > > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > + > > #include <linux/init.h> > > #include <linux/kernel.h> > > #include <linux/sched/signal.h> > > @@ -37,6 +39,7 @@ > > #include <linux/seq_file.h> > > #include <linux/compat.h> > > #include <linux/rculist.h> > > +#include <linux/capability.h> > > #include <net/busy_poll.h> > > > > /* > > @@ -495,6 +498,39 @@ static inline void ep_set_busy_poll_napi_id(struct epitem *epi) > > ep->napi_id = napi_id; > > } > > > > +static long ep_eventpoll_bp_ioctl(struct file *file, unsigned int cmd, > > + unsigned long arg) > > +{ > > + struct eventpoll *ep; > > + struct epoll_params epoll_params; > > + void __user *uarg = (void __user *) arg; > > + > > + ep = file->private_data; > > + > > + switch (cmd) { > > + case EPIOCSPARAMS: > > + if (copy_from_user(&epoll_params, uarg, sizeof(epoll_params))) > > + return -EFAULT; > > + > > + if (epoll_params.busy_poll_budget > NAPI_POLL_WEIGHT && > > + !capable(CAP_NET_ADMIN)) > > + return -EPERM; > > + > > + ep->busy_poll_usecs = epoll_params.busy_poll_usecs; > > + ep->busy_poll_budget = epoll_params.busy_poll_budget; > > + return 0; > > + case EPIOCGPARAMS: > > + memset(&epoll_params, 0, sizeof(epoll_params)); > > + epoll_params.busy_poll_usecs = ep->busy_poll_usecs; > > + epoll_params.busy_poll_budget = ep->busy_poll_budget; > > + if (copy_to_user(uarg, &epoll_params, sizeof(epoll_params))) > > + return -EFAULT; > > + return 0; > > + default: > > + return -ENOIOCTLCMD; > > + } > > +} > > + > > #else > > > > static inline bool ep_busy_loop(struct eventpoll *ep, int nonblock) > > @@ -510,6 +546,12 @@ static inline bool ep_busy_loop_on(struct eventpoll *ep) > > { > > return false; > > } > > + > > +static long ep_eventpoll_bp_ioctl(struct file *file, unsigned int cmd, > > + unsigned long arg) > > +{ > > + return -EOPNOTSUPP; > > +} > > #endif /* CONFIG_NET_RX_BUSY_POLL */ > > > > /* > > @@ -869,6 +911,26 @@ static void ep_clear_and_put(struct eventpoll *ep) > > ep_free(ep); > > } > > > > +static long ep_eventpoll_ioctl(struct file *file, unsigned int cmd, unsigned long arg) > > +{ > > + int ret; > > + > > + if (!is_file_epoll(file)) > > + return -EINVAL; > > + > > + switch (cmd) { > > + case EPIOCSPARAMS: > > + case EPIOCGPARAMS: > > + ret = ep_eventpoll_bp_ioctl(file, cmd, arg); > > + break; > > + default: > > + ret = -EINVAL; > > + break; > > + } > > + > > + return ret; > > +} > > + > > static int ep_eventpoll_release(struct inode *inode, struct file *file) > > { > > struct eventpoll *ep = file->private_data; > > @@ -975,6 +1037,8 @@ static const struct file_operations eventpoll_fops = { > > .release = ep_eventpoll_release, > > .poll = ep_eventpoll_poll, > > .llseek = noop_llseek, > > + .unlocked_ioctl = ep_eventpoll_ioctl, > > + .compat_ioctl = compat_ptr_ioctl, > > }; > > > > /* > > diff --git a/include/uapi/linux/eventpoll.h b/include/uapi/linux/eventpoll.h > > index cfbcc4cc49ac..8eb0fdbce995 100644 > > --- a/include/uapi/linux/eventpoll.h > > +++ b/include/uapi/linux/eventpoll.h > > @@ -85,4 +85,16 @@ struct epoll_event { > > __u64 data; > > } EPOLL_PACKED; > > > > +struct epoll_params { > > + u64 busy_poll_usecs; > > + u16 busy_poll_budget; > > + > > + /* for future fields */ > > + u8 data[118]; > > You forgot to validate that "data" is set to 0, which means that this > would be useless. Why have this at all? I included this because I (probably incorrectly) thought that there should be some extra space in the struct for future additions if needed. I am not sure if that is a recommended practice for this sort of thing or not, but if it is I can add some validation. Thanks for your time and effort in reviewing my code.
On Thu, Jan 25, 2024 at 03:21:46PM -0800, Greg Kroah-Hartman wrote: > On Thu, Jan 25, 2024 at 10:56:59PM +0000, Joe Damato wrote: > > +struct epoll_params { > > + u64 busy_poll_usecs; > > + u16 busy_poll_budget; > > + > > + /* for future fields */ > > + u8 data[118]; > > +} EPOLL_PACKED; > > variables that cross the user/kernel boundry need to be __u64, __u16, > and __u8 here. I'll make that change for the next version, thank you. > And why 118? I chose this arbitrarily. I figured that a 128 byte struct would support 16 u64s in the event that other fields needed to be added in the future. 118 is what was left after the existing fields. There's almost certainly a better way to do this - or perhaps it is unnecessary as per your other message. I am not sure if leaving extra space in the struct is a recommended practice for ioctls or not - I thought I noticed some code that did and some that didn't in the kernel so I err'd on the side of leaving the space and probably did it in the worst way possible. Thanks, Joe
On Thu, Jan 25, 2024 at 04:11:28PM -0800, Joe Damato wrote: > On Thu, Jan 25, 2024 at 03:21:46PM -0800, Greg Kroah-Hartman wrote: > > On Thu, Jan 25, 2024 at 10:56:59PM +0000, Joe Damato wrote: > > > +struct epoll_params { > > > + u64 busy_poll_usecs; > > > + u16 busy_poll_budget; > > > + > > > + /* for future fields */ > > > + u8 data[118]; > > > +} EPOLL_PACKED; > > > > variables that cross the user/kernel boundry need to be __u64, __u16, > > and __u8 here. > > I'll make that change for the next version, thank you. > > > And why 118? > > I chose this arbitrarily. I figured that a 128 byte struct would support 16 > u64s in the event that other fields needed to be added in the future. 118 > is what was left after the existing fields. There's almost certainly a > better way to do this - or perhaps it is unnecessary as per your other > message. > > I am not sure if leaving extra space in the struct is a recommended > practice for ioctls or not - I thought I noticed some code that did and > some that didn't in the kernel so I err'd on the side of leaving the space > and probably did it in the worst way possible. It's not really a good idea unless you know exactly what you are going to do with it. Why not just have a new ioctl if you need new information in the future? That's simpler, right? thanks, greg k-h
On Thu, Jan 25, 2024 at 04:23:58PM -0800, Greg Kroah-Hartman wrote: > On Thu, Jan 25, 2024 at 04:11:28PM -0800, Joe Damato wrote: > > On Thu, Jan 25, 2024 at 03:21:46PM -0800, Greg Kroah-Hartman wrote: > > > On Thu, Jan 25, 2024 at 10:56:59PM +0000, Joe Damato wrote: > > > > +struct epoll_params { > > > > + u64 busy_poll_usecs; > > > > + u16 busy_poll_budget; > > > > + > > > > + /* for future fields */ > > > > + u8 data[118]; > > > > +} EPOLL_PACKED; > > > > > > variables that cross the user/kernel boundry need to be __u64, __u16, > > > and __u8 here. > > > > I'll make that change for the next version, thank you. > > > > > And why 118? > > > > I chose this arbitrarily. I figured that a 128 byte struct would support 16 > > u64s in the event that other fields needed to be added in the future. 118 > > is what was left after the existing fields. There's almost certainly a > > better way to do this - or perhaps it is unnecessary as per your other > > message. > > > > I am not sure if leaving extra space in the struct is a recommended > > practice for ioctls or not - I thought I noticed some code that did and > > some that didn't in the kernel so I err'd on the side of leaving the space > > and probably did it in the worst way possible. > > It's not really a good idea unless you know exactly what you are going > to do with it. Why not just have a new ioctl if you need new > information in the future? That's simpler, right? Sure, that makes sense to me. I'll remove it in the v4 alongside the other changes you've requested. Thanks for your time and patience reviewing my code. I greatly appreciate your helpful comments and feedback. Thanks, Joe
On Fri, Jan 26, 2024, at 03:36, Joe Damato wrote: > On Thu, Jan 25, 2024 at 04:23:58PM -0800, Greg Kroah-Hartman wrote: >> On Thu, Jan 25, 2024 at 04:11:28PM -0800, Joe Damato wrote: >> > On Thu, Jan 25, 2024 at 03:21:46PM -0800, Greg Kroah-Hartman wrote: >> > > On Thu, Jan 25, 2024 at 10:56:59PM +0000, Joe Damato wrote: >> > > > +struct epoll_params { >> > > > + u64 busy_poll_usecs; >> > > > + u16 busy_poll_budget; >> > > > + >> > > > + /* for future fields */ >> > > > + u8 data[118]; >> > > > +} EPOLL_PACKED; >> > > > > Sure, that makes sense to me. I'll remove it in the v4 alongside the other > changes you've requested. > > Thanks for your time and patience reviewing my code. I greatly appreciate > your helpful comments and feedback. Note that you should still pad the structure to its normal alignment. On non-x86 targets this would currently mean a multiple of 64 bits. I would suggest dropping the EPOLL_PACKED here entirely and just using a fully aligned structure on all architectures, like struct epoll_params { __aligned_u64 busy_poll_usecs; __u16 busy_poll_budget; __u8 __pad[6]; }; The explicit padding can help avoid leaking stack data when a structure is copied back from kernel to userspace, so I would just always use it in ioctl data structures. Arnd
On Thu, Jan 25, 2024 at 06:36:30PM -0800, Joe Damato wrote: > On Thu, Jan 25, 2024 at 04:23:58PM -0800, Greg Kroah-Hartman wrote: > > On Thu, Jan 25, 2024 at 04:11:28PM -0800, Joe Damato wrote: > > > On Thu, Jan 25, 2024 at 03:21:46PM -0800, Greg Kroah-Hartman wrote: > > > > On Thu, Jan 25, 2024 at 10:56:59PM +0000, Joe Damato wrote: > > > > > +struct epoll_params { > > > > > + u64 busy_poll_usecs; > > > > > + u16 busy_poll_budget; > > > > > + > > > > > + /* for future fields */ > > > > > + u8 data[118]; > > > > > +} EPOLL_PACKED; > > > > > > > > variables that cross the user/kernel boundry need to be __u64, __u16, > > > > and __u8 here. > > > > > > I'll make that change for the next version, thank you. > > > > > > > And why 118? > > > > > > I chose this arbitrarily. I figured that a 128 byte struct would support 16 > > > u64s in the event that other fields needed to be added in the future. 118 > > > is what was left after the existing fields. There's almost certainly a > > > better way to do this - or perhaps it is unnecessary as per your other > > > message. > > > > > > I am not sure if leaving extra space in the struct is a recommended > > > practice for ioctls or not - I thought I noticed some code that did and > > > some that didn't in the kernel so I err'd on the side of leaving the space > > > and probably did it in the worst way possible. > > > > It's not really a good idea unless you know exactly what you are going > > to do with it. Why not just have a new ioctl if you need new > > information in the future? That's simpler, right? > > Sure, that makes sense to me. I'll remove it in the v4 alongside the other > changes you've requested. Fwiw, we do support extensible ioctls since they encode the size. Take a look at kernel/seccomp.c. It's a clean extensible interface built on top of the copy_struct_from_user() pattern we added for system calls (openat(), clone3() etc.): static long seccomp_notify_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { struct seccomp_filter *filter = file->private_data; void __user *buf = (void __user *)arg; /* Fixed-size ioctls */ switch (cmd) { case SECCOMP_IOCTL_NOTIF_RECV: return seccomp_notify_recv(filter, buf); case SECCOMP_IOCTL_NOTIF_SEND: return seccomp_notify_send(filter, buf); case SECCOMP_IOCTL_NOTIF_ID_VALID_WRONG_DIR: case SECCOMP_IOCTL_NOTIF_ID_VALID: return seccomp_notify_id_valid(filter, buf); case SECCOMP_IOCTL_NOTIF_SET_FLAGS: return seccomp_notify_set_flags(filter, arg); } /* Extensible Argument ioctls */ #define EA_IOCTL(cmd) ((cmd) & ~(IOC_INOUT | IOCSIZE_MASK)) switch (EA_IOCTL(cmd)) { case EA_IOCTL(SECCOMP_IOCTL_NOTIF_ADDFD): return seccomp_notify_addfd(filter, buf, _IOC_SIZE(cmd)); default: return -EINVAL; } } static long seccomp_notify_addfd(struct seccomp_filter *filter, struct seccomp_notif_addfd __user *uaddfd, unsigned int size) { struct seccomp_notif_addfd addfd; struct seccomp_knotif *knotif; struct seccomp_kaddfd kaddfd; int ret; BUILD_BUG_ON(sizeof(addfd) < SECCOMP_NOTIFY_ADDFD_SIZE_VER0); BUILD_BUG_ON(sizeof(addfd) != SECCOMP_NOTIFY_ADDFD_SIZE_LATEST); if (size < SECCOMP_NOTIFY_ADDFD_SIZE_VER0 || size >= PAGE_SIZE) return -EINVAL; ret = copy_struct_from_user(&addfd, sizeof(addfd), uaddfd, size); if (ret) return ret;
On Fri, Jan 26, 2024 at 11:07:36AM +0100, Christian Brauner wrote: > On Thu, Jan 25, 2024 at 06:36:30PM -0800, Joe Damato wrote: > > On Thu, Jan 25, 2024 at 04:23:58PM -0800, Greg Kroah-Hartman wrote: > > > On Thu, Jan 25, 2024 at 04:11:28PM -0800, Joe Damato wrote: > > > > On Thu, Jan 25, 2024 at 03:21:46PM -0800, Greg Kroah-Hartman wrote: > > > > > On Thu, Jan 25, 2024 at 10:56:59PM +0000, Joe Damato wrote: > > > > > > +struct epoll_params { > > > > > > + u64 busy_poll_usecs; > > > > > > + u16 busy_poll_budget; > > > > > > + > > > > > > + /* for future fields */ > > > > > > + u8 data[118]; > > > > > > +} EPOLL_PACKED; > > > > > > > > > > variables that cross the user/kernel boundry need to be __u64, __u16, > > > > > and __u8 here. > > > > > > > > I'll make that change for the next version, thank you. > > > > > > > > > And why 118? > > > > > > > > I chose this arbitrarily. I figured that a 128 byte struct would support 16 > > > > u64s in the event that other fields needed to be added in the future. 118 > > > > is what was left after the existing fields. There's almost certainly a > > > > better way to do this - or perhaps it is unnecessary as per your other > > > > message. > > > > > > > > I am not sure if leaving extra space in the struct is a recommended > > > > practice for ioctls or not - I thought I noticed some code that did and > > > > some that didn't in the kernel so I err'd on the side of leaving the space > > > > and probably did it in the worst way possible. > > > > > > It's not really a good idea unless you know exactly what you are going > > > to do with it. Why not just have a new ioctl if you need new > > > information in the future? That's simpler, right? > > > > Sure, that makes sense to me. I'll remove it in the v4 alongside the other > > changes you've requested. > > Fwiw, we do support extensible ioctls since they encode the size. Take a > look at kernel/seccomp.c. It's a clean extensible interface built on top > of the copy_struct_from_user() pattern we added for system calls > (openat(), clone3() etc.): > > static long seccomp_notify_ioctl(struct file *file, unsigned int cmd, > unsigned long arg) > { > struct seccomp_filter *filter = file->private_data; > void __user *buf = (void __user *)arg; > > /* Fixed-size ioctls */ > switch (cmd) { > case SECCOMP_IOCTL_NOTIF_RECV: > return seccomp_notify_recv(filter, buf); > case SECCOMP_IOCTL_NOTIF_SEND: > return seccomp_notify_send(filter, buf); > case SECCOMP_IOCTL_NOTIF_ID_VALID_WRONG_DIR: > case SECCOMP_IOCTL_NOTIF_ID_VALID: > return seccomp_notify_id_valid(filter, buf); > case SECCOMP_IOCTL_NOTIF_SET_FLAGS: > return seccomp_notify_set_flags(filter, arg); > } > > /* Extensible Argument ioctls */ > #define EA_IOCTL(cmd) ((cmd) & ~(IOC_INOUT | IOCSIZE_MASK)) > switch (EA_IOCTL(cmd)) { > case EA_IOCTL(SECCOMP_IOCTL_NOTIF_ADDFD): > return seccomp_notify_addfd(filter, buf, _IOC_SIZE(cmd)); > default: > return -EINVAL; > } > } > > static long seccomp_notify_addfd(struct seccomp_filter *filter, > struct seccomp_notif_addfd __user *uaddfd, > unsigned int size) > { > struct seccomp_notif_addfd addfd; > struct seccomp_knotif *knotif; > struct seccomp_kaddfd kaddfd; > int ret; > > BUILD_BUG_ON(sizeof(addfd) < SECCOMP_NOTIFY_ADDFD_SIZE_VER0); > BUILD_BUG_ON(sizeof(addfd) != SECCOMP_NOTIFY_ADDFD_SIZE_LATEST); > > if (size < SECCOMP_NOTIFY_ADDFD_SIZE_VER0 || size >= PAGE_SIZE) > return -EINVAL; > > ret = copy_struct_from_user(&addfd, sizeof(addfd), uaddfd, size); > if (ret) > return ret; Thanks; that's a really helpful note and example. I'm inclined to believe that new fields probably won't be needed for a while, but if they are: an extensible ioctl could be added in the future to deal with that problem at that point. Thanks, Joe
From: Arnd Bergmann > Sent: 26 January 2024 06:16 > > On Fri, Jan 26, 2024, at 03:36, Joe Damato wrote: > > On Thu, Jan 25, 2024 at 04:23:58PM -0800, Greg Kroah-Hartman wrote: > >> On Thu, Jan 25, 2024 at 04:11:28PM -0800, Joe Damato wrote: > >> > On Thu, Jan 25, 2024 at 03:21:46PM -0800, Greg Kroah-Hartman wrote: > >> > > On Thu, Jan 25, 2024 at 10:56:59PM +0000, Joe Damato wrote: > >> > > > +struct epoll_params { > >> > > > + u64 busy_poll_usecs; > >> > > > + u16 busy_poll_budget; > >> > > > + > >> > > > + /* for future fields */ > >> > > > + u8 data[118]; > >> > > > +} EPOLL_PACKED; > >> > > > > > > Sure, that makes sense to me. I'll remove it in the v4 alongside the other > > changes you've requested. > > > > Thanks for your time and patience reviewing my code. I greatly appreciate > > your helpful comments and feedback. > > Note that you should still pad the structure to its normal > alignment. On non-x86 targets this would currently mean a > multiple of 64 bits. > > I would suggest dropping the EPOLL_PACKED here entirely and > just using a fully aligned structure on all architectures, like > > struct epoll_params { > __aligned_u64 busy_poll_usecs; > __u16 busy_poll_budget; > __u8 __pad[6]; > }; > > The explicit padding can help avoid leaking stack data when > a structure is copied back from kernel to userspace, so I would > just always use it in ioctl data structures. Or just use 32bit types for both fields. Both values need erroring before they get that large. 32bit of usec is about 20 seconds. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Hi Joe, kernel test robot noticed the following build errors: [auto build test ERROR on net-next/main] url: https://github.com/intel-lab-lkp/linux/commits/Joe-Damato/eventpoll-support-busy-poll-per-epoll-instance/20240126-070250 base: net-next/main patch link: https://lore.kernel.org/r/20240125225704.12781-4-jdamato%40fastly.com patch subject: [PATCH net-next v3 3/3] eventpoll: Add epoll ioctl for epoll_params config: i386-buildonly-randconfig-002-20240127 (https://download.01.org/0day-ci/archive/20240128/202401281917.WeFbZE56-lkp@intel.com/config) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240128/202401281917.WeFbZE56-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202401281917.WeFbZE56-lkp@intel.com/ All errors (new ones prefixed by >>): In file included from <command-line>: >> ./usr/include/linux/eventpoll.h:89:9: error: unknown type name 'u64' 89 | u64 busy_poll_usecs; | ^~~ >> ./usr/include/linux/eventpoll.h:90:9: error: unknown type name 'u16' 90 | u16 busy_poll_budget; | ^~~ >> ./usr/include/linux/eventpoll.h:93:9: error: unknown type name 'u8' 93 | u8 data[118]; | ^~
diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 457e16f06e04..b33918232f78 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -309,6 +309,7 @@ Code Seq# Include File Comments 0x89 0B-DF linux/sockios.h 0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range 0x89 F0-FF linux/sockios.h SIOCDEVPRIVATE range +0x8A 00-1F linux/eventpoll.h 0x8B all linux/wireless.h 0x8C 00-3F WiNRADiO driver <http://www.winradio.com.au/> diff --git a/fs/eventpoll.c b/fs/eventpoll.c index 40bd97477b91..73ae886efb8a 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -6,6 +6,8 @@ * Davide Libenzi <davidel@xmailserver.org> */ +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + #include <linux/init.h> #include <linux/kernel.h> #include <linux/sched/signal.h> @@ -37,6 +39,7 @@ #include <linux/seq_file.h> #include <linux/compat.h> #include <linux/rculist.h> +#include <linux/capability.h> #include <net/busy_poll.h> /* @@ -495,6 +498,39 @@ static inline void ep_set_busy_poll_napi_id(struct epitem *epi) ep->napi_id = napi_id; } +static long ep_eventpoll_bp_ioctl(struct file *file, unsigned int cmd, + unsigned long arg) +{ + struct eventpoll *ep; + struct epoll_params epoll_params; + void __user *uarg = (void __user *) arg; + + ep = file->private_data; + + switch (cmd) { + case EPIOCSPARAMS: + if (copy_from_user(&epoll_params, uarg, sizeof(epoll_params))) + return -EFAULT; + + if (epoll_params.busy_poll_budget > NAPI_POLL_WEIGHT && + !capable(CAP_NET_ADMIN)) + return -EPERM; + + ep->busy_poll_usecs = epoll_params.busy_poll_usecs; + ep->busy_poll_budget = epoll_params.busy_poll_budget; + return 0; + case EPIOCGPARAMS: + memset(&epoll_params, 0, sizeof(epoll_params)); + epoll_params.busy_poll_usecs = ep->busy_poll_usecs; + epoll_params.busy_poll_budget = ep->busy_poll_budget; + if (copy_to_user(uarg, &epoll_params, sizeof(epoll_params))) + return -EFAULT; + return 0; + default: + return -ENOIOCTLCMD; + } +} + #else static inline bool ep_busy_loop(struct eventpoll *ep, int nonblock) @@ -510,6 +546,12 @@ static inline bool ep_busy_loop_on(struct eventpoll *ep) { return false; } + +static long ep_eventpoll_bp_ioctl(struct file *file, unsigned int cmd, + unsigned long arg) +{ + return -EOPNOTSUPP; +} #endif /* CONFIG_NET_RX_BUSY_POLL */ /* @@ -869,6 +911,26 @@ static void ep_clear_and_put(struct eventpoll *ep) ep_free(ep); } +static long ep_eventpoll_ioctl(struct file *file, unsigned int cmd, unsigned long arg) +{ + int ret; + + if (!is_file_epoll(file)) + return -EINVAL; + + switch (cmd) { + case EPIOCSPARAMS: + case EPIOCGPARAMS: + ret = ep_eventpoll_bp_ioctl(file, cmd, arg); + break; + default: + ret = -EINVAL; + break; + } + + return ret; +} + static int ep_eventpoll_release(struct inode *inode, struct file *file) { struct eventpoll *ep = file->private_data; @@ -975,6 +1037,8 @@ static const struct file_operations eventpoll_fops = { .release = ep_eventpoll_release, .poll = ep_eventpoll_poll, .llseek = noop_llseek, + .unlocked_ioctl = ep_eventpoll_ioctl, + .compat_ioctl = compat_ptr_ioctl, }; /* diff --git a/include/uapi/linux/eventpoll.h b/include/uapi/linux/eventpoll.h index cfbcc4cc49ac..8eb0fdbce995 100644 --- a/include/uapi/linux/eventpoll.h +++ b/include/uapi/linux/eventpoll.h @@ -85,4 +85,16 @@ struct epoll_event { __u64 data; } EPOLL_PACKED; +struct epoll_params { + u64 busy_poll_usecs; + u16 busy_poll_budget; + + /* for future fields */ + u8 data[118]; +} EPOLL_PACKED; + +#define EPOLL_IOC_TYPE 0x8A +#define EPIOCSPARAMS _IOW(EPOLL_IOC_TYPE, 0x01, struct epoll_params) +#define EPIOCGPARAMS _IOR(EPOLL_IOC_TYPE, 0x02, struct epoll_params) + #endif /* _UAPI_LINUX_EVENTPOLL_H */