* [PATCH 0/4] net: dsa: mv88e6xxx: novice fixes and irq handling
From: Uwe Kleine-König @ 2018-03-19 10:05 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Marc Zyngier, Thomas Gleixner
Cc: kernel, Florian Fainelli, netdev, Gregory CLEMENT
Hello,
this is a set of patches I created while I tried to understand how DSA
works. I don't claim I already got there and so the first 3 fixes are
trivial only.
I tried to make the switch on the espressobin SBC use the interrupt line
and needed the fourth patch to make this work. Given I don't have access
to the documentation of the Marvell switch, the patch is probably not
correct though (and so doesn't have a S-o-b).
When I first added the irq as:
interrupt-parent = <&gpiosb>;
interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
to the switch of the espressobin's dtb, the irq couldn't be used. The
reason is the interaction of several things:
- On the first try to probe the switch, the driver did:
irq = of_irq_get(np, 0);
request_threaded_irq(irq, NULL, func, IRQF_ONESHOT | IRQF_TRIGGER_FALLING, ...);
and then later aborted with -EPROBE_DEFER because another resource
wasn't available yet. This correctly undid the request_threaded_irq
above using free_irq.
- When the probe routine was entered again, the call to of_irq_get(np, 0)
failed becauce the irq code remembered that the irq was requested
using edge triggered logic with:
irq: type mismatch, failed to map hwirq-23 for gpio!
(kernel/irq/irqdomain.c, line 801)
Any of the following changes would make the problem disappear:
- use IRQ_TYPE_EDGE_FALLING in the device tree;
- drop IRQF_TRIGGER_FALLING from the driver's use of
request_threaded_irq() (I think, see below); and
- make the irq code forget the trigger type when the last action is
removed
I think both the second and the third should be done.
For the third, after a quick look into kernel/irq I didn't find a
suitable place where to do that and so it would be great to get some
feedback from Marc or Thomas here.
Regarding the first one: Is the irq of the switch really edge sensitive?
I didn't see the line reset to 1 after an irq was triggered. (And again,
I don't have access on the documentation of the switch.) When I tested
the second change however the driver still failed because the
gpio controller doesn't support level sensitive irqs. :-|
Looking forward to your comments
Uwe Kleine-Köníg
Uwe Kleine-König (4):
net: dsa: mv88e6xxx: Fix name of switch 88E6141
net: dsa: mv88e6xxx: Fix typo in a comment
net: dsa: mv88e6xxx: Fix interrupt name for g2 irq
net: dsa: mv88e6xxx: Guess number of g1 irqs
drivers/net/dsa/mv88e6xxx/chip.c | 6 ++++--
drivers/net/dsa/mv88e6xxx/global2.c | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
--
2.16.2
^ permalink raw reply
* [PATCH 3/4] net: dsa: mv88e6xxx: fix interrupt name for g2 irq
From: Uwe Kleine-König @ 2018-03-19 10:05 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot
Cc: kernel, Florian Fainelli, netdev, Gregory CLEMENT
In-Reply-To: <20180319100523.24498-1-u.kleine-koenig@pengutronix.de>
This changes the respective line in /proc/interrupts from
49: x x mv88e6xxx-g1 7 Edge mv88e6xxx-g1
to
49: x x mv88e6xxx-g1 7 Edge mv88e6xxx-g2
which makes more sense.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/net/dsa/mv88e6xxx/global2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/global2.c b/drivers/net/dsa/mv88e6xxx/global2.c
index 5f370f1fc7c4..e047f1d355a8 100644
--- a/drivers/net/dsa/mv88e6xxx/global2.c
+++ b/drivers/net/dsa/mv88e6xxx/global2.c
@@ -1090,7 +1090,7 @@ int mv88e6xxx_g2_irq_setup(struct mv88e6xxx_chip *chip)
err = request_threaded_irq(chip->device_irq, NULL,
mv88e6xxx_g2_irq_thread_fn,
- IRQF_ONESHOT, "mv88e6xxx-g1", chip);
+ IRQF_ONESHOT, "mv88e6xxx-g2", chip);
if (err)
goto out;
--
2.16.2
^ permalink raw reply related
* [PATCH 2/4] net: dsa: mv88e6xxx: fix typo in a comment
From: Uwe Kleine-König @ 2018-03-19 10:05 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot
Cc: kernel, Florian Fainelli, netdev, Gregory CLEMENT
In-Reply-To: <20180319100523.24498-1-u.kleine-koenig@pengutronix.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index e2d3df9908e0..38fe875b9631 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4133,7 +4133,7 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
}
/* Has to be performed before the MDIO bus is created, because
- * the PHYs will link there interrupts to these interrupt
+ * the PHYs will link their interrupts to these interrupt
* controllers
*/
mutex_lock(&chip->reg_lock);
--
2.16.2
^ permalink raw reply related
* [PATCH 4/4] net: dsa: mv88e6xxx: guess number of g1 irqs
From: Uwe Kleine-König @ 2018-03-19 10:05 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot
Cc: kernel, Florian Fainelli, netdev, Gregory CLEMENT
In-Reply-To: <20180319100523.24498-1-u.kleine-koenig@pengutronix.de>
I don't have access to the documentation of the marvell switches, but
with this change the switch driver successfully binds on the
espressobin after its device tree makes use of the switch's irq line.
---
drivers/net/dsa/mv88e6xxx/chip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 38fe875b9631..b3696540e002 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3420,6 +3420,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.global2_addr = 0x1c,
.age_time_coeff = 3750,
.atu_move_port_mask = 0x1f,
+ .g1_irqs = 9,
.g2_irqs = 10,
.pvt = true,
.multi_chip = true,
@@ -3728,6 +3729,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.global2_addr = 0x1c,
.age_time_coeff = 3750,
.atu_move_port_mask = 0x1f,
+ .g1_irqs = 9,
.g2_irqs = 10,
.pvt = true,
.multi_chip = true,
--
2.16.2
^ permalink raw reply related
* [PATCH 1/4] net: dsa: mv88e6xxx: Fix name of switch 88E6141
From: Uwe Kleine-König @ 2018-03-19 10:05 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot
Cc: kernel, Florian Fainelli, netdev, Gregory CLEMENT
In-Reply-To: <20180319100523.24498-1-u.kleine-koenig@pengutronix.de>
The switch name is emitted in the kernel log, so having the right name
there is nice.
Fixes: 1558727a1c1b ("net: dsa: mv88e6xxx: Add support for ethernet switch 88E6141")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 41f872d4ba3c..e2d3df9908e0 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3410,7 +3410,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
[MV88E6141] = {
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6141,
.family = MV88E6XXX_FAMILY_6341,
- .name = "Marvell 88E6341",
+ .name = "Marvell 88E6141",
.num_databases = 4096,
.num_ports = 6,
.num_gpio = 11,
--
2.16.2
^ permalink raw reply related
* Re: [PATCH net] devlink: Remove redundant free on error path
From: Jiri Pirko @ 2018-03-19 10:03 UTC (permalink / raw)
To: Arkadi Sharshevsky; +Cc: netdev, davem, mlxsw
In-Reply-To: <1521387442-31494-1-git-send-email-arkadis@mellanox.com>
Sun, Mar 18, 2018 at 04:37:22PM CET, arkadis@mellanox.com wrote:
>The current code performs unneeded free. Remove the redundant skb freeing
>during the error path.
>
>Fixes: 1555d204e743 ("devlink: Support for pipeline debug (dpipe)")
>Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 0/5] Add support for RDMA enhancements in cxgb4
From: Raju Rangoju @ 2018-03-19 9:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, nirranjan, indranil, venkatesh, swise, bharat
In-Reply-To: <20180317.201915.621317397995255421.davem@davemloft.net>
On Saturday, March 03/17/18, 2018 at 20:19:15 -0400, David Miller wrote:
> From: Raju Rangoju <rajur@chelsio.com>
> Date: Sat, 17 Mar 2018 12:52:24 +0530
>
> > Allocates the HW-resources and provide the necessary routines for the
> > upper layer driver (rdma/iw_cxgb4) to enable the RDMA SRQ support for Chelsio adapters.
> >
> > Advertise support for write with immediate work request
> > Advertise support for write with completion
>
> Patch #2 doesn't apply cleanly to net-next, please respin.
>
> Thank you.
Sure, I'll respin it.
Thanks Dave.
^ permalink raw reply
* Re: [bpf-next V2 PATCH 10/15] xdp: rhashtable with allocator ID to pointer mapping
From: Jesper Dangaard Brouer @ 2018-03-19 9:48 UTC (permalink / raw)
To: Jason Wang
Cc: netdev, BjörnTöpel, magnus.karlsson, eugenia,
John Fastabend, Eran Ben Elisha, Saeed Mahameed, galp,
Daniel Borkmann, Alexei Starovoitov, Tariq Toukan, brouer
In-Reply-To: <36f68a76-4c73-e0d1-b97b-645393e006ee@redhat.com>
On Fri, 16 Mar 2018 16:45:30 +0800
Jason Wang <jasowang@redhat.com> wrote:
> On 2018年03月10日 00:07, Jesper Dangaard Brouer wrote:
> > On Fri, 9 Mar 2018 21:07:36 +0800
> > Jason Wang <jasowang@redhat.com> wrote:
> >
> >>>>> Use the IDA infrastructure for getting a cyclic increasing ID number,
> >>>>> that is used for keeping track of each registered allocator per
> >>>>> RX-queue xdp_rxq_info.
> >>>>>
> >>>>> Signed-off-by: Jesper Dangaard Brouer<brouer@redhat.com>
> >>>> A stupid question is, can we manage to unify this ID with NAPI id?
> >>> Sorry I don't understand the question?
> >>
> >> I mean can we associate page poll pointer to napi_struct, record NAPI id
> >> in xdp_mem_info and do lookup through NAPI id?
> >
> > No. The driver can unreg/reg a new XDP memory model,
>
> Is there an actual use case for this?
I believe this is the common use case. When attaching an XDP/bpf prog,
then the driver usually want to change the RX-ring memory model
(different performance trade off). When detaching XDP, then driver
want to change back to old memory model. During this process, I
believe, the NAPI-ID remains the same (right?).
> > without reloading
> > the NAPI and generate a new NAPI id.
> >
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next 04/10] phy: add 2.5G SGMII mode to the phy_mode enum
From: Kishon Vijay Abraham I @ 2018-03-19 9:46 UTC (permalink / raw)
To: Antoine Tenart, davem, linux, gregory.clement, andrew, jason,
sebastian.hesselbarth
Cc: ymarkman, netdev, linux-kernel, maxime.chevallier, nadavh,
thomas.petazzoni, miquel.raynal, stefanc, mw, linux-arm-kernel
In-Reply-To: <20180316103351.16616-5-antoine.tenart@bootlin.com>
On Friday 16 March 2018 04:03 PM, Antoine Tenart wrote:
> This patch adds one more generic PHY mode to the phy_mode enum, to allow
> configuring generic PHYs to the 2.5G SGMII mode by using the set_mode
> callback.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> include/linux/phy/phy.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 4f8423a948d5..5a80e9de3686 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -28,6 +28,7 @@ enum phy_mode {
> PHY_MODE_USB_DEVICE,
> PHY_MODE_USB_OTG,
> PHY_MODE_SGMII,
> + PHY_MODE_2500SGMII,
> PHY_MODE_10GKR,
> PHY_MODE_UFS_HS_A,
> PHY_MODE_UFS_HS_B,
>
^ permalink raw reply
* Re: [PATCH v11 crypto 00/12] Chelsio Inline TLS
From: Atul Gupta @ 2018-03-19 9:44 UTC (permalink / raw)
To: Herbert Xu, David Miller
Cc: davejwatson, sd, sbrivio, linux-crypto, netdev, ganeshgr
In-Reply-To: <20180319092258.GA12302@gondor.apana.org.au>
On 3/19/2018 2:52 PM, Herbert Xu wrote:
> On Sun, Mar 18, 2018 at 10:36:02AM -0400, David Miller wrote:
>> Herbert, is it OK for this entire series to go via net-next?
> Sure, although there could be conflicts since the chelsio driver
> seems to be changing quite fast.
I applied chcr patches [applied recently in crypto tree] on net-next tree over my changes and it worked fine.
There is no conflict and can safely submit changes in net-next.
Thanks
Atul
>
> Cheers,
^ permalink raw reply
* RE: [PATCH v5 0/2] Remove false-positive VLAs when using max()
From: David Laight @ 2018-03-19 9:43 UTC (permalink / raw)
To: 'Linus Torvalds', Rasmus Villemoes
Cc: Kees Cook, Al Viro, Florian Weimer, Andrew Morton, Josh Poimboeuf,
Randy Dunlap, Miguel Ojeda, Ingo Molnar, Ian Abbott, linux-input,
linux-btrfs, Network Development, Linux Kernel Mailing List,
Kernel Hardening
In-Reply-To: <CA+55aFw0WC+S3TTE6x_vkLbRV6YLeR4-1S9LsBXhE+E2KZqBuA@mail.gmail.com>
From: linus971@gmail.com [mailto:linus971@gmail.com] On Behalf Of Linus Torvalds
> Sent: 18 March 2018 23:36
...
>
> Yeah, and since we're in the situation that *new* gcc versions work
> for us anyway, and we only have issues with older gcc's (that sadly
> people still use), even if there was a new cool feature we couldn't
> use it.
Is it necessary to have the full checks for old versions of gcc?
Even -Wvla could be predicated on very recent gcc - since we aren't
worried about whether gcc decides to generate a vla, but whether
the source requests one.
David
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac
From: Arend van Spriel @ 2018-03-19 9:31 UTC (permalink / raw)
To: Alexey Roslyakov, andrew, kvalo, robh+dt, mark.rutland,
franky.lin, hante.meuleman, chi-hsien.lin, wright.feng, netdev
Cc: linux-wireless, devicetree, linux-kernel, brcm80211-dev-list.pdl,
brcm80211-dev-list
In-Reply-To: <20180319014032.9394-3-alexey.roslyakov@gmail.com>
On 3/19/2018 2:40 AM, Alexey Roslyakov wrote:
> In case if the host has higher align requirements for SG items, allow
> setting device-specific aligns for scatterlist items.
>
> Signed-off-by: Alexey Roslyakov <alexey.roslyakov@gmail.com>
> ---
> Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> index 86602f264dce..187b8c1b52a7 100644
> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> @@ -17,6 +17,11 @@ Optional properties:
> When not specified the device will use in-band SDIO interrupts.
> - interrupt-names : name of the out-of-band interrupt, which must be set
> to "host-wake".
> + - brcm,broken-sg-support : boolean flag to indicate that the SDIO host
> + controller has higher align requirement than 32 bytes for each
> + scatterlist item.
> + - brcm,sd-head-align : alignment requirement for start of data buffer.
> + - brcm,sd-sgentry-align : length alignment requirement for each sg entry.
Hi Alexey,
Thanks for the patch. However, the problem with these is that they are
characterizing the host controller and not the wireless device. So from
device tree perspective , which is to describe the hardware, these
properties should be SDIO host controller properties. Also I am not sure
if the broken-sg-support is still needed. We added that for omap_hsmmc,
but that has since changed to scatter-gather emulation so it might not
be needed anymore.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH v11 crypto 00/12] Chelsio Inline TLS
From: Herbert Xu @ 2018-03-19 9:22 UTC (permalink / raw)
To: David Miller
Cc: atul.gupta, davejwatson, sd, sbrivio, linux-crypto, netdev,
ganeshgr
In-Reply-To: <20180318.103602.252024301365216579.davem@davemloft.net>
On Sun, Mar 18, 2018 at 10:36:02AM -0400, David Miller wrote:
>
> Herbert, is it OK for this entire series to go via net-next?
Sure, although there could be conflicts since the chelsio driver
seems to be changing quite fast.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: linux-next on x60: network manager often complains "network is disabled" after resume
From: Pavel Machek @ 2018-03-19 9:21 UTC (permalink / raw)
To: Woody Suwalski
Cc: Rafael J. Wysocki, kernel list, Linux-pm mailing list,
Netdev list
In-Reply-To: <70721f83-344a-0f23-223b-9c81f6e9e32a@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 591 bytes --]
On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
> Pavel Machek wrote:
> >Hi!
> >
> >With recent linux-next, after resume networkmanager often claims that
> >"network is disabled". Sometimes suspend/resume clears that.
> >
> >Any ideas? Does it work for you?
> > Pavel
> Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
Thanks for testing... but yes, 4.16 should be ok. If not fixed,
problem will appear in 4.17-rc1.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: linux-next on x60: network manager often complains "network is disabled" after resume
From: Woody Suwalski @ 2018-03-19 9:17 UTC (permalink / raw)
To: Pavel Machek, Rafael J. Wysocki, kernel list,
Linux-pm mailing list
Cc: Netdev list
In-Reply-To: <20180318104023.GA10392@amd>
Pavel Machek wrote:
> Hi!
>
> With recent linux-next, after resume networkmanager often claims that
> "network is disabled". Sometimes suspend/resume clears that.
>
> Any ideas? Does it work for you?
> Pavel
Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
Woody
^ permalink raw reply
* [PATCH net-next v2 5/5] net: Replace ip_ra_lock with per-net mutex
From: Kirill Tkhai @ 2018-03-19 9:15 UTC (permalink / raw)
To: davem, yoshfuji, edumazet, yanhaishuang, nikolay, yotamg, soheil,
avagin, nicolas.dichtel, ebiederm, fw, roman.kapl, netdev,
xiyou.wangcong, dvyukov, andreyknvl, lkp, ktkhai
In-Reply-To: <152145065475.7718.16297762717744383072.stgit@localhost.localdomain>
Since ra_chain is per-net, we may use per-net mutexes
to protect them in ip_ra_control(). This improves
scalability.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
include/net/netns/ipv4.h | 1 +
net/core/net_namespace.c | 1 +
net/ipv4/ip_sockglue.c | 15 ++++++---------
3 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index 97d7ee6667c7..8491bc9c86b1 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -50,6 +50,7 @@ struct netns_ipv4 {
struct ipv4_devconf *devconf_all;
struct ipv4_devconf *devconf_dflt;
struct ip_ra_chain __rcu *ra_chain;
+ struct mutex ra_mutex;
#ifdef CONFIG_IP_MULTIPLE_TABLES
struct fib_rules_ops *rules_ops;
bool fib_has_custom_rules;
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index c340d5cfbdec..95ba2c53bd9a 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -301,6 +301,7 @@ static __net_init int setup_net(struct net *net, struct user_namespace *user_ns)
net->user_ns = user_ns;
idr_init(&net->netns_ids);
spin_lock_init(&net->nsid_lock);
+ mutex_init(&net->ipv4.ra_mutex);
list_for_each_entry(ops, &pernet_list, list) {
error = ops_init(ops, net);
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index f36d35fe924b..5ad2d8ed3a3f 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -322,9 +322,6 @@ int ip_cmsg_send(struct sock *sk, struct msghdr *msg, struct ipcm_cookie *ipc,
return 0;
}
-static DEFINE_SPINLOCK(ip_ra_lock);
-
-
static void ip_ra_destroy_rcu(struct rcu_head *head)
{
struct ip_ra_chain *ra = container_of(head, struct ip_ra_chain, rcu);
@@ -345,21 +342,21 @@ int ip_ra_control(struct sock *sk, unsigned char on,
new_ra = on ? kmalloc(sizeof(*new_ra), GFP_KERNEL) : NULL;
- spin_lock_bh(&ip_ra_lock);
+ mutex_lock(&net->ipv4.ra_mutex);
for (rap = &net->ipv4.ra_chain;
(ra = rcu_dereference_protected(*rap,
- lockdep_is_held(&ip_ra_lock))) != NULL;
+ lockdep_is_held(&net->ipv4.ra_mutex))) != NULL;
rap = &ra->next) {
if (ra->sk == sk) {
if (on) {
- spin_unlock_bh(&ip_ra_lock);
+ mutex_unlock(&net->ipv4.ra_mutex);
kfree(new_ra);
return -EADDRINUSE;
}
/* dont let ip_call_ra_chain() use sk again */
ra->sk = NULL;
RCU_INIT_POINTER(*rap, ra->next);
- spin_unlock_bh(&ip_ra_lock);
+ mutex_unlock(&net->ipv4.ra_mutex);
if (ra->destructor)
ra->destructor(sk);
@@ -374,7 +371,7 @@ int ip_ra_control(struct sock *sk, unsigned char on,
}
}
if (!new_ra) {
- spin_unlock_bh(&ip_ra_lock);
+ mutex_unlock(&net->ipv4.ra_mutex);
return -ENOBUFS;
}
new_ra->sk = sk;
@@ -383,7 +380,7 @@ int ip_ra_control(struct sock *sk, unsigned char on,
RCU_INIT_POINTER(new_ra->next, ra);
rcu_assign_pointer(*rap, new_ra);
sock_hold(sk);
- spin_unlock_bh(&ip_ra_lock);
+ mutex_unlock(&net->ipv4.ra_mutex);
return 0;
}
^ permalink raw reply related
* [PATCH net-next v2 4/5] net: Make ip_ra_chain per struct net
From: Kirill Tkhai @ 2018-03-19 9:15 UTC (permalink / raw)
To: davem, yoshfuji, edumazet, yanhaishuang, nikolay, yotamg, soheil,
avagin, nicolas.dichtel, ebiederm, fw, roman.kapl, netdev,
xiyou.wangcong, dvyukov, andreyknvl, lkp, ktkhai
In-Reply-To: <152145065475.7718.16297762717744383072.stgit@localhost.localdomain>
This is optimization, which makes ip_call_ra_chain()
iterate less sockets to find the sockets it's looking for.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
include/net/ip.h | 13 +++++++++++--
include/net/netns/ipv4.h | 1 +
net/ipv4/ip_input.c | 5 ++---
net/ipv4/ip_sockglue.c | 15 ++-------------
4 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index fe63ba95d12b..d53b5a9eae34 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -91,6 +91,17 @@ static inline int inet_sdif(struct sk_buff *skb)
return 0;
}
+/* Special input handler for packets caught by router alert option.
+ They are selected only by protocol field, and then processed likely
+ local ones; but only if someone wants them! Otherwise, router
+ not running rsvpd will kill RSVP.
+
+ It is user level problem, what it will make with them.
+ I have no idea, how it will masquearde or NAT them (it is joke, joke :-)),
+ but receiver should be enough clever f.e. to forward mtrace requests,
+ sent to multicast group to reach destination designated router.
+ */
+
struct ip_ra_chain {
struct ip_ra_chain __rcu *next;
struct sock *sk;
@@ -101,8 +112,6 @@ struct ip_ra_chain {
struct rcu_head rcu;
};
-extern struct ip_ra_chain __rcu *ip_ra_chain;
-
/* IP flags. */
#define IP_CE 0x8000 /* Flag: "Congestion" */
#define IP_DF 0x4000 /* Flag: "Don't Fragment" */
diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index 382bfd7583cf..97d7ee6667c7 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -49,6 +49,7 @@ struct netns_ipv4 {
#endif
struct ipv4_devconf *devconf_all;
struct ipv4_devconf *devconf_dflt;
+ struct ip_ra_chain __rcu *ra_chain;
#ifdef CONFIG_IP_MULTIPLE_TABLES
struct fib_rules_ops *rules_ops;
bool fib_has_custom_rules;
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 57fc13c6ab2b..7582713dd18f 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -159,7 +159,7 @@ bool ip_call_ra_chain(struct sk_buff *skb)
struct net_device *dev = skb->dev;
struct net *net = dev_net(dev);
- for (ra = rcu_dereference(ip_ra_chain); ra; ra = rcu_dereference(ra->next)) {
+ for (ra = rcu_dereference(net->ipv4.ra_chain); ra; ra = rcu_dereference(ra->next)) {
struct sock *sk = ra->sk;
/* If socket is bound to an interface, only report
@@ -167,8 +167,7 @@ bool ip_call_ra_chain(struct sk_buff *skb)
*/
if (sk && inet_sk(sk)->inet_num == protocol &&
(!sk->sk_bound_dev_if ||
- sk->sk_bound_dev_if == dev->ifindex) &&
- net_eq(sock_net(sk), net)) {
+ sk->sk_bound_dev_if == dev->ifindex)) {
if (ip_is_fragment(ip_hdr(skb))) {
if (ip_defrag(net, skb, IP_DEFRAG_CALL_RA_CHAIN))
return true;
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index bf5f44b27b7e..f36d35fe924b 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -322,18 +322,6 @@ int ip_cmsg_send(struct sock *sk, struct msghdr *msg, struct ipcm_cookie *ipc,
return 0;
}
-
-/* Special input handler for packets caught by router alert option.
- They are selected only by protocol field, and then processed likely
- local ones; but only if someone wants them! Otherwise, router
- not running rsvpd will kill RSVP.
-
- It is user level problem, what it will make with them.
- I have no idea, how it will masquearde or NAT them (it is joke, joke :-)),
- but receiver should be enough clever f.e. to forward mtrace requests,
- sent to multicast group to reach destination designated router.
- */
-struct ip_ra_chain __rcu *ip_ra_chain;
static DEFINE_SPINLOCK(ip_ra_lock);
@@ -350,6 +338,7 @@ int ip_ra_control(struct sock *sk, unsigned char on,
{
struct ip_ra_chain *ra, *new_ra;
struct ip_ra_chain __rcu **rap;
+ struct net *net = sock_net(sk);
if (sk->sk_type != SOCK_RAW || inet_sk(sk)->inet_num == IPPROTO_RAW)
return -EINVAL;
@@ -357,7 +346,7 @@ int ip_ra_control(struct sock *sk, unsigned char on,
new_ra = on ? kmalloc(sizeof(*new_ra), GFP_KERNEL) : NULL;
spin_lock_bh(&ip_ra_lock);
- for (rap = &ip_ra_chain;
+ for (rap = &net->ipv4.ra_chain;
(ra = rcu_dereference_protected(*rap,
lockdep_is_held(&ip_ra_lock))) != NULL;
rap = &ra->next) {
^ permalink raw reply related
* [PATCH net-next v2 3/5] net: Move IP_ROUTER_ALERT out of lock_sock(sk)
From: Kirill Tkhai @ 2018-03-19 9:15 UTC (permalink / raw)
To: davem, yoshfuji, edumazet, yanhaishuang, nikolay, yotamg, soheil,
avagin, nicolas.dichtel, ebiederm, fw, roman.kapl, netdev,
xiyou.wangcong, dvyukov, andreyknvl, lkp, ktkhai
In-Reply-To: <152145065475.7718.16297762717744383072.stgit@localhost.localdomain>
ip_ra_control() does not need sk_lock. Who are the another
users of ip_ra_chain? ip_mroute_setsockopt() doesn't take
sk_lock, while parallel IP_ROUTER_ALERT syscalls are
synchronized by ip_ra_lock. So, we may move this command
out of sk_lock.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
net/ipv4/ip_sockglue.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index b7bac7351409..bf5f44b27b7e 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -646,6 +646,8 @@ static int do_ip_setsockopt(struct sock *sk, int level,
/* If optlen==0, it is equivalent to val == 0 */
+ if (optname == IP_ROUTER_ALERT)
+ return ip_ra_control(sk, val ? 1 : 0, NULL);
if (ip_mroute_opt(optname))
return ip_mroute_setsockopt(sk, optname, optval, optlen);
@@ -1156,9 +1158,6 @@ static int do_ip_setsockopt(struct sock *sk, int level,
goto e_inval;
inet->mc_all = val;
break;
- case IP_ROUTER_ALERT:
- err = ip_ra_control(sk, val ? 1 : 0, NULL);
- break;
case IP_FREEBIND:
if (optlen < 1)
^ permalink raw reply related
* [PATCH net-next v2 2/5] net: Revert "ipv4: fix a deadlock in ip_ra_control"
From: Kirill Tkhai @ 2018-03-19 9:14 UTC (permalink / raw)
To: davem, yoshfuji, edumazet, yanhaishuang, nikolay, yotamg, soheil,
avagin, nicolas.dichtel, ebiederm, fw, roman.kapl, netdev,
xiyou.wangcong, dvyukov, andreyknvl, lkp, ktkhai
In-Reply-To: <152145065475.7718.16297762717744383072.stgit@localhost.localdomain>
This reverts commit 1215e51edad1.
Since raw_close() is used on every RAW socket destruction,
the changes made by 1215e51edad1 scale sadly. This clearly
seen on endless unshare(CLONE_NEWNET) test, and cleanup_net()
kwork spends a lot of time waiting for rtnl_lock() introduced
by this commit.
Next patches in series will rework this in another way,
so now we revert 1215e51edad1. Also, it doesn't seen
mrtsock_destruct() takes sk_lock, and the comment to the commit
does not show the actual stack dump. So, there is a question
did we really need in it.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
net/ipv4/ip_sockglue.c | 1 -
net/ipv4/ipmr.c | 11 +++++++++--
net/ipv4/raw.c | 2 --
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index be7c3b71914d..b7bac7351409 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -594,7 +594,6 @@ static bool setsockopt_needs_rtnl(int optname)
case MCAST_LEAVE_GROUP:
case MCAST_LEAVE_SOURCE_GROUP:
case MCAST_UNBLOCK_SOURCE:
- case IP_ROUTER_ALERT:
return true;
}
return false;
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index d752a70855d8..f6be5db16da2 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1399,7 +1399,7 @@ static void mrtsock_destruct(struct sock *sk)
struct net *net = sock_net(sk);
struct mr_table *mrt;
- ASSERT_RTNL();
+ rtnl_lock();
ipmr_for_each_table(mrt, net) {
if (sk == rtnl_dereference(mrt->mroute_sk)) {
IPV4_DEVCONF_ALL(net, MC_FORWARDING)--;
@@ -1411,6 +1411,7 @@ static void mrtsock_destruct(struct sock *sk)
mroute_clean_tables(mrt, false);
}
}
+ rtnl_unlock();
}
/* Socket options and virtual interface manipulation. The whole
@@ -1475,8 +1476,13 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval,
if (sk != rcu_access_pointer(mrt->mroute_sk)) {
ret = -EACCES;
} else {
+ /* We need to unlock here because mrtsock_destruct takes
+ * care of rtnl itself and we can't change that due to
+ * the IP_ROUTER_ALERT setsockopt which runs without it.
+ */
+ rtnl_unlock();
ret = ip_ra_control(sk, 0, NULL);
- goto out_unlock;
+ goto out;
}
break;
case MRT_ADD_VIF:
@@ -1588,6 +1594,7 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval,
}
out_unlock:
rtnl_unlock();
+out:
return ret;
}
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 54648d20bf0f..720bef7da2f6 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -711,9 +711,7 @@ static void raw_close(struct sock *sk, long timeout)
/*
* Raw sockets may have direct kernel references. Kill them.
*/
- rtnl_lock();
ip_ra_control(sk, 0, NULL);
- rtnl_unlock();
sk_common_release(sk);
}
^ permalink raw reply related
* [PATCH net-next v2 1/5] net: Revert "ipv4: get rid of ip_ra_lock"
From: Kirill Tkhai @ 2018-03-19 9:14 UTC (permalink / raw)
To: davem, yoshfuji, edumazet, yanhaishuang, nikolay, yotamg, soheil,
avagin, nicolas.dichtel, ebiederm, fw, roman.kapl, netdev,
xiyou.wangcong, dvyukov, andreyknvl, lkp, ktkhai
In-Reply-To: <152145065475.7718.16297762717744383072.stgit@localhost.localdomain>
This reverts commit ba3f571d5dde. The commit was made
after 1215e51edad1 "ipv4: fix a deadlock in ip_ra_control",
and killed ip_ra_lock, which became useless after rtnl_lock()
made used to destroy every raw ipv4 socket. This scales
very bad, and next patch in series reverts 1215e51edad1.
ip_ra_lock will be used again.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
net/ipv4/ip_sockglue.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 74c962b9b09c..be7c3b71914d 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -334,6 +334,7 @@ int ip_cmsg_send(struct sock *sk, struct msghdr *msg, struct ipcm_cookie *ipc,
sent to multicast group to reach destination designated router.
*/
struct ip_ra_chain __rcu *ip_ra_chain;
+static DEFINE_SPINLOCK(ip_ra_lock);
static void ip_ra_destroy_rcu(struct rcu_head *head)
@@ -355,17 +356,21 @@ int ip_ra_control(struct sock *sk, unsigned char on,
new_ra = on ? kmalloc(sizeof(*new_ra), GFP_KERNEL) : NULL;
+ spin_lock_bh(&ip_ra_lock);
for (rap = &ip_ra_chain;
- (ra = rtnl_dereference(*rap)) != NULL;
+ (ra = rcu_dereference_protected(*rap,
+ lockdep_is_held(&ip_ra_lock))) != NULL;
rap = &ra->next) {
if (ra->sk == sk) {
if (on) {
+ spin_unlock_bh(&ip_ra_lock);
kfree(new_ra);
return -EADDRINUSE;
}
/* dont let ip_call_ra_chain() use sk again */
ra->sk = NULL;
RCU_INIT_POINTER(*rap, ra->next);
+ spin_unlock_bh(&ip_ra_lock);
if (ra->destructor)
ra->destructor(sk);
@@ -379,14 +384,17 @@ int ip_ra_control(struct sock *sk, unsigned char on,
return 0;
}
}
- if (!new_ra)
+ if (!new_ra) {
+ spin_unlock_bh(&ip_ra_lock);
return -ENOBUFS;
+ }
new_ra->sk = sk;
new_ra->destructor = destructor;
RCU_INIT_POINTER(new_ra->next, ra);
rcu_assign_pointer(*rap, new_ra);
sock_hold(sk);
+ spin_unlock_bh(&ip_ra_lock);
return 0;
}
^ permalink raw reply related
* [PATCH net-next v2 0/5] Rework ip_ra_chain protection
From: Kirill Tkhai @ 2018-03-19 9:14 UTC (permalink / raw)
To: davem, yoshfuji, edumazet, yanhaishuang, nikolay, yotamg, soheil,
avagin, nicolas.dichtel, ebiederm, fw, roman.kapl, netdev,
xiyou.wangcong, dvyukov, andreyknvl, lkp, ktkhai
Commit 1215e51edad1 "ipv4: fix a deadlock in ip_ra_control"
made rtnl_lock() be used in raw_close(). This function is called
on every RAW socket destruction, so that rtnl_mutex is taken
every time. This scales very sadly. I observe cleanup_net()
spending a lot of time in rtnl_lock() and raw_close() is one
of the biggest rtnl user (since we have percpu net->ipv4.icmp_sk).
Another problem is that commit does not explain actual call path
mrtsock_destruct() takes sk lock and the way to deadlock.
But there is no sk lock taking is visible in mrtsock_destruct().
So, it is a question does we need it at all.
This patchset reworks the locking: reverts the problem commit
and its descendant, and introduces rtnl-independent locking.
This may have a continuation, and someone may work on killing
rtnl_lock() in mrtsock_destruct() in the future.
Thanks,
Kirill
---
v2: Fix sparse warning (4/5), as reported by kbuild test robot.
Kirill Tkhai (5):
net: Revert "ipv4: get rid of ip_ra_lock"
net: Revert "ipv4: fix a deadlock in ip_ra_control"
net: Move IP_ROUTER_ALERT out of lock_sock(sk)
net: Make ip_ra_chain per struct net
net: Replace ip_ra_lock with per-net mutex
include/net/ip.h | 13 +++++++++++--
include/net/netns/ipv4.h | 2 ++
net/core/net_namespace.c | 1 +
net/ipv4/ip_input.c | 5 ++---
net/ipv4/ip_sockglue.c | 34 +++++++++++++---------------------
net/ipv4/ipmr.c | 11 +++++++++--
net/ipv4/raw.c | 2 --
7 files changed, 38 insertions(+), 30 deletions(-)
--
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
^ permalink raw reply
* Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
From: Antoine Tenart @ 2018-03-19 8:52 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Antoine Tenart, davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180316155307.GQ9418@n2100.armlinux.org.uk>
Hi Russell,
On Fri, Mar 16, 2018 at 03:53:07PM +0000, Russell King - ARM Linux wrote:
> On Fri, Mar 16, 2018 at 11:33:43AM +0100, Antoine Tenart wrote:
> > The PHY mode 10GKR can use in-band negotiation. This patches allows this
> > mode to be used with MLO_AN_INBAND in phylink.
> >
> > Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
> > ---
> > drivers/net/phy/phylink.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> > index 51a011a349fe..7224b005f0dd 100644
> > --- a/drivers/net/phy/phylink.c
> > +++ b/drivers/net/phy/phylink.c
> > @@ -768,7 +768,8 @@ int phylink_of_phy_connect(struct phylink *pl, struct device_node *dn,
> > /* Fixed links and 802.3z are handled without needing a PHY */
> > if (pl->link_an_mode == MLO_AN_FIXED ||
> > (pl->link_an_mode == MLO_AN_INBAND &&
> > - phy_interface_mode_is_8023z(pl->link_interface)))
> > + (phy_interface_mode_is_8023z(pl->link_interface) ||
> > + pl->link_interface == PHY_INTERFACE_MODE_10GKR)))
>
> There is no inband negotiation like there is with 802.3z or SGMII,
> so this makes no sense.
Oh, that's what I feared. I read some docs but probably will need more
:)
Anyway, the reason to use in-band negotiation was also to avoid using
fixed-link. It would work but always report the link is up, which for
the user isn't a great experience as we have a way to detect this.
What would you suggest to achieve this in a reasonable way?
Thanks,
Antoine
--
Antoine Ténart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next 03/10] net: mvpp2: phylink support
From: Antoine Tenart @ 2018-03-19 8:45 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Antoine Tenart, davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180316160322.GR9418@n2100.armlinux.org.uk>
Hi Russell,
On Fri, Mar 16, 2018 at 04:03:22PM +0000, Russell King - ARM Linux wrote:
> On Fri, Mar 16, 2018 at 11:33:44AM +0100, Antoine Tenart wrote:
> > +static void mvpp2_phylink_validate(struct net_device *dev,
> > + unsigned long *supported,
> > + struct phylink_link_state *state)
> > +{
> > + __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
> > +
> > + phylink_set(mask, Autoneg);
> > + phylink_set_port_modes(mask);
> > + phylink_set(mask, Pause);
> > + phylink_set(mask, Asym_Pause);
> > +
> > + phylink_set(mask, 10baseT_Half);
> > + phylink_set(mask, 10baseT_Full);
> > + phylink_set(mask, 100baseT_Half);
> > + phylink_set(mask, 100baseT_Full);
> > + phylink_set(mask, 1000baseT_Full);
> > + phylink_set(mask, 1000baseX_Full);
>
> AFAICS, the driver (before these patches) does not support 1000baseX
> as it always clears the MVPP2_GMAC_PORT_TYPE_MASK bit, so adding this
> mode should be part of the patch adding 1000baseX support.
Right, I'll remove 1000baseX_Full from this patch and only add it in the
1000BaseX support patch.
Thanks!
Antoine
--
Antoine Ténart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next 05/10] phy: cp110-comphy: 2.5G SGMII mode
From: Antoine Tenart @ 2018-03-19 8:44 UTC (permalink / raw)
To: Baruch Siach
Cc: Antoine Tenart, davem, kishon, linux, gregory.clement, andrew,
jason, sebastian.hesselbarth, ymarkman, netdev, linux-kernel,
maxime.chevallier, nadavh, thomas.petazzoni, miquel.raynal,
stefanc, mw, linux-arm-kernel
In-Reply-To: <20180318044247.kp3i2ymvrj5fdoj3@sapphire.tkos.co.il>
Hi Baruch,
On Sun, Mar 18, 2018 at 06:42:48AM +0200, Baruch Siach wrote:
> On Fri, Mar 16, 2018 at 11:33:46AM +0100, Antoine Tenart wrote:
> > This patch allow the CP100 comphy to configure some lanes in the
>
> Should be 'CP110'.
That's right, I'll update.
Thanks!
Antoine
--
Antoine Ténart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: aio poll, io_pgetevents and a new in-kernel poll API V5
From: Christoph Hellwig @ 2018-03-19 8:35 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180305212743.16664-1-hch@lst.de>
Hi everyone,
this posting has been out for 2 weeks now, without any replies except
for Jeff reminding of the missing reviews he already gave me in the
previous version.
Canwe make some progress on this? Especially as all the aio bits
have gotten reviews from Jeff.
On Mon, Mar 05, 2018 at 01:27:07PM -0800, Christoph Hellwig wrote:
> Hi all,
>
> this series adds support for the IOCB_CMD_POLL operation to poll for the
> readyness of file descriptors using the aio subsystem. The API is based
> on patches that existed in RHAS2.1 and RHEL3, which means it already is
> supported by libaio. To implement the poll support efficiently new
> methods to poll are introduced in struct file_operations: get_poll_head
> and poll_mask. The first one returns a wait_queue_head to wait on
> (lifetime is bound by the file), and the second does a non-blocking
> check for the POLL* events. This allows aio poll to work without
> any additional context switches, unlike epoll.
>
> To make the interface fully useful a new io_pgetevents system call is
> added, which atomically saves and restores the signal mask over the
> io_pgetevents system call. It it the logical equivalent to pselect and
> ppoll for io_pgetevents.
>
> The corresponding libaio changes for io_pgetevents support and
> documentation, as well as a test case will be posted in a separate
> series.
>
> The changes were sponsored by Scylladb, and improve performance
> of the seastar framework up to 10%, while also removing the need
> for a privileged SCHED_FIFO epoll listener thread.
>
> git://git.infradead.org/users/hch/vfs.git aio-poll.5
>
> Gitweb:
>
> http://git.infradead.org/users/hch/vfs.git/shortlog/refs/heads/aio-poll.5
>
> Libaio changes:
>
> https://pagure.io/libaio.git io-poll
>
> Seastar changes (not updated for the new io_pgetevens ABI yet):
>
> https://github.com/avikivity/seastar/commits/aio
>
> Changes since V4:
> - rebased ontop of Linux 4.16-rc4
>
> Changes since V3:
> - remove the pre-sleep ->poll_mask call in vfs_poll,
> allow ->get_poll_head to return POLL* values.
>
> Changes since V2:
> - removed a double initialization
> - new vfs_get_poll_head helper
> - document that ->get_poll_head can return NULL
> - call ->poll_mask before sleeping
> - various ACKs
> - add conversion of random to ->poll_mask
> - add conversion of af_alg to ->poll_mask
> - lacking ->poll_mask support now returns -EINVAL for IOCB_CMD_POLL
> - reshuffled the series so that prep patches and everything not
> requiring the new in-kernel poll API is in the beginning
>
> Changes since V1:
> - handle the NULL ->poll case in vfs_poll
> - dropped the file argument to the ->poll_mask socket operation
> - replace the ->pre_poll socket operation with ->get_poll_head as
> in the file operations
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-aio' in
> the body to majordomo@kvack.org. For more info on Linux AIO,
> see: http://www.kvack.org/aio/
> Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
---end quoted text---
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox