* RE: [PATCH v2 1/5] netlink: remove NLA_NESTED_COMPAT
From: Johannes Berg @ 2018-09-20 14:56 UTC (permalink / raw)
To: David Laight,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: David Ahern, Johannes Berg
In-Reply-To: <15cc8087b97d4b8693fad397b27f4d10-1XygrNkDbNvwg4NCKwmqgw@public.gmane.org>
>> @@ -172,7 +172,6 @@ enum {
>> NLA_FLAG,
>> NLA_MSECS,
>> NLA_NESTED,
>> - NLA_NESTED_COMPAT,
>> NLA_NUL_STRING,
>> NLA_BINARY,
>> NLA_S8,
>...
>
>Is it safe to remove an item from this emun ?
I believe it is, since it's not part of uapi. At least as long as you recompile all netlink policies afterwards.
johannes
--
Sent from my phone.
^ permalink raw reply
* Re: [EXT] [PATCH net] net: mvneta: fix the Rx desc buffer DMA unmapping
From: Gregory CLEMENT @ 2018-09-20 14:59 UTC (permalink / raw)
To: Antoine Tenart
Cc: Yelena Krivosheev, davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com,
maxime.chevallier@bootlin.com, miquel.raynal@bootlin.com,
Nadav Haklai, Stefan Chulski, Yan Markman, mw@semihalf.com
In-Reply-To: <20180920112010.GB1158@kwain>
Hi Antoine,
On jeu., sept. 20 2018, Antoine Tenart <antoine.tenart@bootlin.com> wrote:
> Hi Yelena,
>
> On Thu, Sep 20, 2018 at 10:14:56AM +0000, Yelena Krivosheev wrote:
>>
>> Please, check and fix all cases of dma_unmap_single() usage.
>> See mvneta_rxq_drop_pkts()
>> ...
>> if (!data || !(rx_desc->buf_phys_addr))
>> continue;
>> dma_unmap_single(pp->dev->dev.parent, rx_desc->buf_phys_addr,
>> MVNETA_RX_BUF_SIZE(pp->pkt_size), DMA_FROM_DEVICE);
>> __free_page(data);
>> ...
>
> I had a look at the one reported by CONFIG_DMA_API_DEBUG, and at DMA
> unmapping calls using PAGE_SIZE. As you pointed out there might be
> others parts, thanks!
Actually Jisheng had submitted a similar patch few weeks ago and as I
pointed at this time, the dma_unmap in mvneta_rxq_drop_pkts can be
called when the allocation is done in with HWBM in this case which use a
dma_map_single.
I though that in this case using dma_map_single is the things to do even
if in the SWBM case it is less optimal.
Gregory
>
> Antoine
>
> --
> Antoine Ténart, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
^ permalink raw reply
* Re: [PATCH bpf-next 2/2] xsk: fix bug when trying to use both copy and zero-copy on one queue id
From: Magnus Karlsson @ 2018-09-20 9:17 UTC (permalink / raw)
To: jakub.kicinski
Cc: ys114321, Karlsson, Magnus, Björn Töpel, ast,
Daniel Borkmann, Network Development
In-Reply-To: <CAJ8uoz27a-+OYxHGnXOT6pY2v0hNxvrmCW8Eb5y5JkWLG9K3hg@mail.gmail.com>
On Wed, Sep 19, 2018 at 9:18 AM Magnus Karlsson
<magnus.karlsson@gmail.com> wrote:
>
> On Wed, Sep 19, 2018 at 3:58 AM Jakub Kicinski
> <jakub.kicinski@netronome.com> wrote:
> >
> > On Tue, 18 Sep 2018 10:22:11 -0700, Y Song wrote:
> > > > +/* The umem is stored both in the _rx struct and the _tx struct as we do
> > > > + * not know if the device has more tx queues than rx, or the opposite.
> > > > + * This might also change during run time.
> > > > + */
> > > > +static void xdp_reg_umem_at_qid(struct net_device *dev, struct xdp_umem *umem,
> > > > + u16 queue_id)
> > > > +{
> > > > + if (queue_id < dev->real_num_rx_queues)
> > > > + dev->_rx[queue_id].umem = umem;
> > > > + if (queue_id < dev->real_num_tx_queues)
> > > > + dev->_tx[queue_id].umem = umem;
> > > > +}
> > > > +
> > > > +static struct xdp_umem *xdp_get_umem_from_qid(struct net_device *dev,
> > > > + u16 queue_id)
> > > > +{
> > > > + if (queue_id < dev->real_num_rx_queues)
> > > > + return dev->_rx[queue_id].umem;
> > > > + if (queue_id < dev->real_num_tx_queues)
> > > > + return dev->_tx[queue_id].umem;
> > > > +
> > > > + return NULL;
> > > > +}
> > > > +
> > > > +static void xdp_clear_umem_at_qid(struct net_device *dev, u16 queue_id)
> > > > +{
> > > > + /* Zero out the entry independent on how many queues are configured
> > > > + * at this point in time, as it might be used in the future.
> > > > + */
> > > > + if (queue_id < dev->num_rx_queues)
> > > > + dev->_rx[queue_id].umem = NULL;
> > > > + if (queue_id < dev->num_tx_queues)
> > > > + dev->_tx[queue_id].umem = NULL;
> > > > +}
> > > > +
> > >
> > > I am sure whether the following scenario can happen or not.
> > > Could you clarify?
> > > 1. suppose initially we have num_rx_queues = num_tx_queues = 10
> > > xdp_reg_umem_at_qid() set umem1 to queue_id = 8
> > > 2. num_tx_queues is changed to 5
> > > 3. xdp_clear_umem_at_qid() is called for queue_id = 8,
> > > and dev->_rx[8].umum = 0.
> > > 4. xdp_reg_umem_at_qid() is called gain to set for queue_id = 8
> > > dev->_rx[8].umem = umem2
> > > 5. num_tx_queues is changed to 10
> > > Now dev->_rx[8].umem != dev->_tx[8].umem, is this possible and is it
> > > a problem?
> >
> > Plus IIRC the check of qid vs real_num_[rt]x_queues in xsk_bind() is
> > not under rtnl_lock so it doesn't count for much. Why not do all the
> > checks against num_[rt]x_queues here, instead of real_..?
>
> You are correct, two separate rtnl_lock regions is broken. Will spin a
> v2 tomorrow when I am back in the office.
>
> Thanks Jakub for catching this. I really appreciate you reviewing my code.
Sorry, forgot to answer your question about why real_num_ instead of
num_. If we used num_ instead, we would get a behavior where we can
open a socket on a queue id, let us say 10, that will not be active if
real_num_ is below 10. So no traffic will flow on this socket until we
issue an ethtool command to state that we have 10 or more queues
configured. While this behavior is sane (and consistent), I believe it
will lead to a more complicated driver implementation, break the
current uapi (since we will return an error if you try to bind to a
queue id that is not active at the moment) and I like my suggestion
below better :-).
What I would like to suggest is that the current model at bind() is
kept, that is it will fail if you try to bind to a non-active queue
id. But we add some code in ethool_set_channels in net/core/ethtool.c
to check if you have an active af_xdp socket on a queue id and try to
make it inactive, we return an error and disallow the change. This
would IMHO be like not allowing a load module to be unloaded if
someone is using it or not allowing unmounting a file system if files
are in use. What do you think? If you think this is the right way to
go, I can implement this in a follow up patch or in this patch set if
that makes more sense, let me know. This suggestion would actually
make it simpler to implement zero-copy support in the driver. Some of
the complications we are having today is due to the fact that ethtool
can come in from the side and change things for us when an AF_XDP
socket is active on a queue id. And implementing zero copy support in
the driver needs to get simpler IMO.
Please let me know what you think.
Thanks: Magnus
> /Magnus
^ permalink raw reply
* [PATCH net] sctp: update dst pmtu with the correct daddr
From: Xin Long @ 2018-09-20 9:27 UTC (permalink / raw)
To: network dev, linux-sctp; +Cc: davem, Marcelo Ricardo Leitner, Neil Horman
When processing pmtu update from an icmp packet, it calls .update_pmtu
with sk instead of skb in sctp_transport_update_pmtu.
However for sctp, the daddr in the transport might be different from
inet_sock->inet_daddr or sk->sk_v6_daddr, which is used to update or
create the route cache. The incorrect daddr will cause a different
route cache created for the path.
So before calling .update_pmtu, inet_sock->inet_daddr/sk->sk_v6_daddr
should be updated with the daddr in the transport, and update it back
after it's done.
The issue has existed since route exceptions introduction.
Fixes: 4895c771c7f0 ("ipv4: Add FIB nexthop exceptions.")
Reported-by: ian.periam@dialogic.com
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/sctp/transport.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/net/sctp/transport.c b/net/sctp/transport.c
index 12cac85..033696e 100644
--- a/net/sctp/transport.c
+++ b/net/sctp/transport.c
@@ -260,6 +260,7 @@ void sctp_transport_pmtu(struct sctp_transport *transport, struct sock *sk)
bool sctp_transport_update_pmtu(struct sctp_transport *t, u32 pmtu)
{
struct dst_entry *dst = sctp_transport_dst_check(t);
+ struct sock *sk = t->asoc->base.sk;
bool change = true;
if (unlikely(pmtu < SCTP_DEFAULT_MINSEGMENT)) {
@@ -271,12 +272,19 @@ bool sctp_transport_update_pmtu(struct sctp_transport *t, u32 pmtu)
pmtu = SCTP_TRUNC4(pmtu);
if (dst) {
- dst->ops->update_pmtu(dst, t->asoc->base.sk, NULL, pmtu);
+ struct sctp_pf *pf = sctp_get_pf_specific(dst->ops->family);
+ union sctp_addr addr;
+
+ pf->af->from_sk(&addr, sk);
+ pf->to_sk_daddr(&t->ipaddr, sk);
+ dst->ops->update_pmtu(dst, sk, NULL, pmtu);
+ pf->to_sk_daddr(&addr, sk);
+
dst = sctp_transport_dst_check(t);
}
if (!dst) {
- t->af_specific->get_dst(t, &t->saddr, &t->fl, t->asoc->base.sk);
+ t->af_specific->get_dst(t, &t->saddr, &t->fl, sk);
dst = t->dst;
}
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] netfilter: nf_tables: add SECMARK support
From: Casey Schaufler @ 2018-09-20 15:23 UTC (permalink / raw)
To: Christian Göttsche
Cc: pablo, kadlec, fw, davem, netfilter-devel, coreteam, netdev,
linux-kernel, Paul Moore, Stephen Smalley, Eric Paris, jmorris,
serge, selinux, linux-security-module
In-Reply-To: <CAJ2a_Ddd19txwUiKkOwpdWUSq9+VWFSR6Cqe4zgXKggWUPi4hw@mail.gmail.com>
On 9/20/2018 12:18 AM, Christian Göttsche wrote:
>> I've only had a cursory look at your patch, but how is it
>> different from what's in xt_SECMARK.c ?
> xt_SEXMARK.c is for xtables, use-able in iptables; this is for nftables (nft)
Thank you. I am enlightened.
^ permalink raw reply
* Re: [PATCH] net: ibm: remove a redundant local variable 'k'
From: Sergei Shtylyov @ 2018-09-20 9:49 UTC (permalink / raw)
To: zhong jiang, davem; +Cc: dougmill, netdev, linux-kernel
In-Reply-To: <1537366995-59168-1-git-send-email-zhongjiang@huawei.com>
Hello!
On 9/19/2018 5:23 PM, zhong jiang wrote:
> The local variable 'k' is never used after being assigned.
> hence it should be redundant adn can be removed.
Can.
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next v5 02/20] zinc: introduce minimal cryptography library
From: Ard Biesheuvel @ 2018-09-20 15:41 UTC (permalink / raw)
To: Jason A. Donenfeld, Arnd Bergmann, Eric Biggers
Cc: Linux Kernel Mailing List, <netdev@vger.kernel.org>,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, David S. Miller,
Greg Kroah-Hartman, Samuel Neves, Andy Lutomirski,
Jean-Philippe Aumasson
In-Reply-To: <20180918161646.19105-3-Jason@zx2c4.com>
(+ Arnd, Eric)
On 18 September 2018 at 09:16, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
...
> diff --git a/lib/zinc/Makefile b/lib/zinc/Makefile
> new file mode 100644
> index 000000000000..83dfd63988c0
> --- /dev/null
> +++ b/lib/zinc/Makefile
> @@ -0,0 +1,4 @@
Apologies for not spotting these before:
> +ccflags-y := -O3
-O3 optimization has been problematic in the past, at least on x86 but
I think on other architectures as well. Please stick with -O2.
> +ccflags-y += -Wframe-larger-than=$(if (CONFIG_KASAN),16384,8192)
There is no way we can support code in the kernel with that kind of
stack space requirements. I will let Arnd comment on what we typically
allow, since he deals with such issues on a regular basis.
> +ccflags-y += -D'pr_fmt(fmt)="zinc: " fmt'
> +ccflags-$(CONFIG_ZINC_DEBUG) += -DDEBUG
> --
> 2.19.0
>
^ permalink raw reply
* Re: [PATCH iproute2 v2 0/3] testsuite: make alltests fixes
From: Luca Boccassi @ 2018-09-20 10:02 UTC (permalink / raw)
To: Petr Vorel, netdev; +Cc: Stephen Hemminger, Phil Sutter
In-Reply-To: <20180919233624.18494-1-petr.vorel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 539 bytes --]
On Thu, 2018-09-20 at 01:36 +0200, Petr Vorel wrote:
> Hi,
>
> here are simply fixes to restore 'make alltests'.
> Currently it does not run.
>
> Kind regards,
> Petr
>
> Petr Vorel (3):
> testsuite: Fix missing generate_nlmsg
> testsuite: Generate generate_nlmsg when needed
> testsuite: Warn about empty $(IPVERS)
>
> testsuite/Makefile | 21 ++++++++++++++-------
> 1 file changed, 14 insertions(+), 7 deletions(-)
Series-tested-by: Luca Boccassi <bluca@debian.org>
--
Kind regards,
Luca Boccassi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array
From: Janusz Krzysztofik @ 2018-09-20 15:48 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Linus Walleij, Jonathan Corbet, Miguel Ojeda Sandonis,
Peter Korsgaard, Peter Rosin, Ulf Hansson, Andrew Lunn,
Florian Fainelli, David S. Miller, Dominik Brodowski,
Greg Kroah-Hartman, Kishon Vijay Abraham I, Lars-Peter Clausen,
Michael Hennerich, Jonathan Cameron, Hartmut Knaack,
Peter Meerwald-Stadler, Jiri Slaby, Willy Tarreau
In-Reply-To: <20180920101151eucas1p221f5a1715b8556bb9d99bf08fe09ce6f~WE-_cEf4l0754207542eucas1p27@eucas1p2.samsung.com>
On Thursday, September 20, 2018 12:11:48 PM CEST Marek Szyprowski wrote:
> Hi All,
>
> On 2018-09-02 14:01, Janusz Krzysztofik wrote:
> > Certain GPIO descriptor arrays returned by gpio_get_array() may contain
> > information on direct mapping of array members to pins of a single GPIO
> > chip in hardware order. In such cases, bitmaps of values can be passed
> > directly from/to the chip's .get/set_multiple() callbacks without
> > wasting time on iterations.
> >
> > Add respective code to gpiod_get/set_array_bitmap_complex() functions.
> > Pins not applicable for fast path are processed as before, skipping
> > over the 'fast' ones.
> >
> > Cc: Jonathan Corbet <corbet@lwn.net>
> > Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
>
> I've just noticed that this patch landed in today's linux-next. Sadly it
> breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
> device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
>
> Booting hangs after detecting MMC cards. Reverting this patch fixes the
> boot. I will try later to add some debugs and investigate it further what
> really happens when booting hangs.
Hi Marek,
Thanks for reporting. Could you please try the following fix?
Thanks,
Janusz
>From d7ecd435bfb4972766b63ac383a43875700c7452 Mon Sep 17 00:00:00 2001
From: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Date: Thu, 20 Sep 2018 17:37:21 +0200
Subject: [PATCH] gpiolib: Fix bitmap index not updated
While skipping fast path bits, bitmap index is not updated with next
found zero bit position. Fix it.
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
---
drivers/gpio/gpiolib.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index a53d17745d21..5bc3447949c9 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2880,7 +2880,7 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
__set_bit(hwgpio, mask);
if (array_info)
- find_next_zero_bit(array_info->get_mask,
+ i = find_next_zero_bit(array_info->get_mask,
array_size, i);
else
i++;
@@ -2905,7 +2905,8 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
trace_gpio_value(desc_to_gpio(desc), 1, value);
if (array_info)
- find_next_zero_bit(array_info->get_mask, i, j);
+ i = find_next_zero_bit(array_info->get_mask, i,
+ j);
else
j++;
}
@@ -3192,7 +3193,7 @@ int gpiod_set_array_value_complex(bool raw, bool can_sleep,
}
if (array_info)
- find_next_zero_bit(array_info->set_mask,
+ i = find_next_zero_bit(array_info->set_mask,
array_size, i);
else
i++;
--
2.16.4
^ permalink raw reply related
* Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array
From: Linus Walleij @ 2018-09-20 15:49 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Janusz Krzysztofik, Jonathan Corbet, Miguel Ojeda Sandonis,
Peter Korsgaard, Peter Rosin, Ulf Hansson, Andrew Lunn,
Florian Fainelli, David S. Miller, Dominik Brodowski, Greg KH,
kishon, Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Hartmut Knaack, Peter Meerwald, Jiri Slaby, Willy Tarreau,
Geert Uytterhoeven
In-Reply-To: <20180920101151eucas1p221f5a1715b8556bb9d99bf08fe09ce6f~WE-_cEf4l0754207542eucas1p27@eucas1p2.samsung.com>
On Thu, Sep 20, 2018 at 3:11 AM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> I've just noticed that this patch landed in today's linux-next. Sadly it
> breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
> device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
Thanks for testing on this platform!
> Booting hangs after detecting MMC cards. Reverting this patch fixes the
> boot. I will try later to add some debugs and investigate it further what
> really happens when booting hangs.
How typical. I hope we can fix it, because this should mean speedups
for your platform.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net-next v5 02/20] zinc: introduce minimal cryptography library
From: Andy Lutomirski @ 2018-09-20 16:01 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Jason A. Donenfeld, Arnd Bergmann, Eric Biggers,
Linux Kernel Mailing List, <netdev@vger.kernel.org>,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, David S. Miller,
Greg Kroah-Hartman, Samuel Neves, Andy Lutomirski,
Jean-Philippe Aumasson
In-Reply-To: <CAKv+Gu-0oTBrg3T8TsNYPOdrmJSSC313-CYASO34kb_nviva6A@mail.gmail.com>
> On Sep 20, 2018, at 8:41 AM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> (+ Arnd, Eric)
>
> On 18 September 2018 at 09:16, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> ...
>
>> diff --git a/lib/zinc/Makefile b/lib/zinc/Makefile
>> new file mode 100644
>> index 000000000000..83dfd63988c0
>> --- /dev/null
>> +++ b/lib/zinc/Makefile
>> @@ -0,0 +1,4 @@
>
> Apologies for not spotting these before:
>
>> +ccflags-y := -O3
>
> -O3 optimization has been problematic in the past, at least on x86 but
> I think on other architectures as well. Please stick with -O2.
>
>> +ccflags-y += -Wframe-larger-than=$(if (CONFIG_KASAN),16384,8192)
>
> There is no way we can support code in the kernel with that kind of
> stack space requirements. I will let Arnd comment on what we typically
> allow, since he deals with such issues on a regular basis.
To make matters worse, KASAN is incompatible with VMAP_STACK right now, and KASAN is not so good at detecting stack overflow.
>
>> +ccflags-y += -D'pr_fmt(fmt)="zinc: " fmt'
>> +ccflags-$(CONFIG_ZINC_DEBUG) += -DDEBUG
>> --
>> 2.19.0
>>
^ permalink raw reply
* Re: [PATCH net-next v5 02/20] zinc: introduce minimal cryptography library
From: Arnd Bergmann @ 2018-09-20 16:02 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Jason A. Donenfeld, Eric Biggers, Linux Kernel Mailing List,
Networking, open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
David Miller, gregkh, sneves, Andy Lutomirski,
jeanphilippe.aumasson
In-Reply-To: <CAKv+Gu-0oTBrg3T8TsNYPOdrmJSSC313-CYASO34kb_nviva6A@mail.gmail.com>
On Thu, Sep 20, 2018 at 8:41 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> (+ Arnd, Eric)
>
> On 18 September 2018 at 09:16, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> ...
>
> > diff --git a/lib/zinc/Makefile b/lib/zinc/Makefile
> > new file mode 100644
> > index 000000000000..83dfd63988c0
> > --- /dev/null
> > +++ b/lib/zinc/Makefile
> > @@ -0,0 +1,4 @@
>
> Apologies for not spotting these before:
>
> > +ccflags-y := -O3
>
> -O3 optimization has been problematic in the past, at least on x86 but
> I think on other architectures as well. Please stick with -O2.
>
> > +ccflags-y += -Wframe-larger-than=$(if (CONFIG_KASAN),16384,8192)
>
> There is no way we can support code in the kernel with that kind of
> stack space requirements. I will let Arnd comment on what we typically
> allow, since he deals with such issues on a regular basis.
Right, if you hit a stack requirement like this, it's usually the compiler
doing something bad, not just using too much stack but also generating
rather slow object code in the process. It's better to fix the bug by
optimizing the code to not spill registers to the stack.
In the long run, I'd like to reduce the stack frame size further, so
best assume that anything over 1024 bytes (on 32-bit) or 1280 bytes
(on 64-bit) is a bug in the code, and stay below that.
For prototyping, you can just mark the broken functions individually
by setting the warning limit for a specific function that is known to
be misoptimized by the compiler (with a comment about which compiler
and architectures are affected), but not override the limit for the
entire file.
Arnd
^ permalink raw reply
* Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array
From: Janusz Krzysztofik @ 2018-09-20 16:21 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Andrew Lunn, Ulf Hansson, linux-doc, linux-iio, Linus Walleij,
Dominik Brodowski, Peter Rosin, netdev, linux-i2c,
Peter Meerwald-Stadler, devel, Florian Fainelli, Jonathan Corbet,
Janusz Krzysztofik, Krzysztof Kozlowski, Kishon Vijay Abraham I,
Tony Lindgren, Lukas Wunner, Geert Uytterhoeven, linux-serial,
Jiri Slaby, Michael Hennerich, Uwe Kleine-König, linux-gpio
In-Reply-To: <9860023.SlBYqtbjDV@z50>
On Thursday, September 20, 2018 5:48:22 PM CEST Janusz Krzysztofik wrote:
> On Thursday, September 20, 2018 12:11:48 PM CEST Marek Szyprowski wrote:
> > Hi All,
> >
> > On 2018-09-02 14:01, Janusz Krzysztofik wrote:
> > > Certain GPIO descriptor arrays returned by gpio_get_array() may contain
> > > information on direct mapping of array members to pins of a single GPIO
> > > chip in hardware order. In such cases, bitmaps of values can be passed
> > > directly from/to the chip's .get/set_multiple() callbacks without
> > > wasting time on iterations.
> > >
> > > Add respective code to gpiod_get/set_array_bitmap_complex() functions.
> > > Pins not applicable for fast path are processed as before, skipping
> > > over the 'fast' ones.
> > >
> > > Cc: Jonathan Corbet <corbet@lwn.net>
> > > Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
> >
> > I've just noticed that this patch landed in today's linux-next. Sadly it
> > breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
> > device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
> >
> > Booting hangs after detecting MMC cards. Reverting this patch fixes the
> > boot. I will try later to add some debugs and investigate it further what
> > really happens when booting hangs.
>
> Hi Marek,
>
> Thanks for reporting. Could you please try the following fix?
Hi again,
I realized the patch was not correct, j, not i, should be updated in second
hunk. Please try the following one.
Thanks,
Janusz
>From a919c504850f6cb40e8e81267a3a37537f7c4fd4 Mon Sep 17 00:00:00 2001
From: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Date: Thu, 20 Sep 2018 17:37:21 +0200
Subject: [PATCH] gpiolib: Fix bitmap index not updated
While skipping fast path bits, bitmap index is not updated with next
found zero bit position. Fix it.
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
---
drivers/gpio/gpiolib.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index a53d17745d21..369bdd358fcc 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2880,7 +2880,7 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
__set_bit(hwgpio, mask);
if (array_info)
- find_next_zero_bit(array_info->get_mask,
+ i = find_next_zero_bit(array_info->get_mask,
array_size, i);
else
i++;
@@ -2905,7 +2905,8 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
trace_gpio_value(desc_to_gpio(desc), 1, value);
if (array_info)
- find_next_zero_bit(array_info->get_mask, i, j);
+ j = find_next_zero_bit(array_info->get_mask, i,
+ j);
else
j++;
}
@@ -3192,7 +3193,7 @@ int gpiod_set_array_value_complex(bool raw, bool can_sleep,
}
if (array_info)
- find_next_zero_bit(array_info->set_mask,
+ i = find_next_zero_bit(array_info->set_mask,
array_size, i);
else
i++;
--
2.16.4
^ permalink raw reply related
* Re: [PATCH] netfilter: conntrack: get rid of double sizeof
From: Pablo Neira Ayuso @ 2018-09-20 16:22 UTC (permalink / raw)
To: zhong jiang; +Cc: davem, kadlec, fw, netfilter-devel, netdev, linux-kernel
In-Reply-To: <1537359671-53720-1-git-send-email-zhongjiang@huawei.com>
On Wed, Sep 19, 2018 at 08:21:11PM +0800, zhong jiang wrote:
> sizeof(sizeof()) is quite strange and does not seem to be what
> is wanted here.
>
> The issue is detected with the help of Coccinelle.
Applied to nf, thanks.
^ permalink raw reply
* Re: [PATCH] netfilter: nft_osf: use enum nft_data_types for nft_validate_register_store
From: Pablo Neira Ayuso @ 2018-09-20 16:24 UTC (permalink / raw)
To: Stefan Agner
Cc: ffmancera, kadlec, fw, davem, netfilter-devel, coreteam, netdev,
linux-kernel
In-Reply-To: <20180918052136.25978-1-stefan@agner.ch>
On Mon, Sep 17, 2018 at 10:21:36PM -0700, Stefan Agner wrote:
> The function nft_validate_register_store requires a struct of type
> struct nft_data_types. NFTA_DATA_VALUE is of type enum
> nft_verdict_attributes. Pass the correct enum type.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 00/22] net: fix return type of ndo_start_xmit function
From: Grygorii Strashko @ 2018-09-20 17:04 UTC (permalink / raw)
To: YueHaibing, davem, dmitry.tarnyagin, wg, mkl, michal.simek,
hsweeten, madalin.bucur, pantelis.antoniou, claudiu.manoil,
leoyang.li, linux, sammy, ralf, nico, steve.glendinning,
f.fainelli, w-kwok2, m-karicheri2, t.sailer, jreuter, kys,
haiyangz, wei.liu2, paul.durrant, arvid.brodin, pshelar
Cc: dev, linux-mips, xen-devel, netdev, linux-usb, linux-kernel,
linux-can, devel, linux-hams, linux-omap, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20180920123306.14772-1-yuehaibing@huawei.com>
On 09/20/2018 07:32 AM, YueHaibing wrote:
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, so make sure the implementation in
> this driver has returns 'netdev_tx_t' value, and change the function
> return type to netdev_tx_t.
>
May be I missed smth, but it's acceptable to report standard error codes from
.xmit() callback as per dev_xmit_complete().
--
regards,
-grygorii
^ permalink raw reply
* [PATCH rdma-next 0/5] IB device rename support
From: Leon Romanovsky @ 2018-09-20 11:21 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, linux-s390, Ursula Braun,
David S. Miller, netdev, Selvin Xavier, Steve Wise, Lijun Ou,
Shiraz Saleem, Ariel Elior, Christian Benvenuti, Adit Ranadive,
Dennis Dalessandro
From: Leon Romanovsky <leonro@mellanox.com>
Hi,
This series introduce long-waiting feature - "IB device rename".
Such feature gives and option to rename user visible IB device name from
vendor specific name (e.g. mlx5_0) to anything else.
The user space component through rdmatool will follow this series.
[leonro@server /]$ lspci |grep -i Ether
00:08.0 Ethernet controller: Red Hat, Inc. Virtio network device
00:09.0 Ethernet controller: Mellanox Technologies MT27700 Family [ConnectX-4]
[leonro@server /]$ sudo rdma dev
1: mlx5_0: node_type ca fw 3.8.9999 node_guid 5254:00c0:fe12:3455 sys_image_guid 5254:00c0:fe12:3455
[leonro@server /]$ sudo rdma dev set mlx5_0 name hfi1_0
[leonro@server /]$ sudo rdma dev
1: hfi1_0: node_type ca fw 3.8.9999 node_guid 5254:00c0:fe12:3455 sys_image_guid 5254:00c0:fe12:3455
First patch introduces getter/setter to access names, i didn't convert
all drivers to stop using name directly, because they don't base their
decision on "name", and use this print only and can print truncated name
if renaming is done at the same time as logging.
Second patch updates SMC to use IB device index instead of name.
Third patch globally converts all drivers to new allocation name
routine.
Forth and fifth patches are actually implement and exports through RDMA
netlink the rename routines.
It uses exported by device_rename() function, despite the comment from
2010, which warns about downsides of this function, the netdev is still
uses, so we will use too.
There is one patch/series which was dropped from this submission -
conversion of SElinux from being IB device name to be IB device index
based. It simply needs more special care and more testing.
This series was tested with mlx5 devices with/without traffic and with
non-modified rdma-core.
Dennis,
I didn't touch hfi1, but I'm not sure if it is needed.
Thanks
Leon Romanovsky (5):
RDMA/core: Provide getter and setter to access IB device name
net/smc: Use IB device index instead of name
RDMA: Convert IB drivers to name allocation routine
RDMA/core: Implement IB device rename function
RDMA/nldev: Allow IB device rename through RDMA netlink
drivers/infiniband/core/core_priv.h | 1 +
drivers/infiniband/core/device.c | 52 +++++++++++++++++++++++---
drivers/infiniband/core/nldev.c | 33 ++++++++++++++++
drivers/infiniband/hw/bnxt_re/main.c | 6 ++-
drivers/infiniband/hw/cxgb3/iwch_provider.c | 5 ++-
drivers/infiniband/hw/cxgb4/provider.c | 5 ++-
drivers/infiniband/hw/hns/hns_roce_main.c | 4 +-
drivers/infiniband/hw/i40iw/i40iw_verbs.c | 7 +++-
drivers/infiniband/hw/mlx4/main.c | 7 +++-
drivers/infiniband/hw/mlx5/main.c | 4 +-
drivers/infiniband/hw/mthca/mthca_provider.c | 5 ++-
drivers/infiniband/hw/nes/nes_verbs.c | 6 ++-
drivers/infiniband/hw/ocrdma/ocrdma_main.c | 7 +++-
drivers/infiniband/hw/qedr/main.c | 4 +-
drivers/infiniband/hw/usnic/usnic_ib_main.c | 5 ++-
drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c | 9 +++--
drivers/infiniband/sw/rxe/rxe_verbs.c | 5 ++-
include/rdma/ib_verbs.h | 8 +++-
include/uapi/rdma/rdma_netlink.h | 3 +-
net/smc/smc_diag.c | 6 +--
net/smc/smc_pnet.c | 27 +++++++------
21 files changed, 171 insertions(+), 38 deletions(-)
^ permalink raw reply
* [PATCH rdma-next 1/5] RDMA/core: Provide getter and setter to access IB device name
From: Leon Romanovsky @ 2018-09-20 11:21 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, linux-s390, Ursula Braun,
David S. Miller, netdev, Selvin Xavier, Steve Wise, Lijun Ou,
Shiraz Saleem, Ariel Elior, Christian Benvenuti, Adit Ranadive,
Dennis Dalessandro
In-Reply-To: <20180920112202.9181-1-leon@kernel.org>
From: Leon Romanovsky <leonro@mellanox.com>
Prepare IB device name field to rename operation by ensuring that all
accesses to it are protected with lock and users don't see part of name.
The protection is done with global device_lock because it is used in
allocation and deallocation phases. At this stage, this lock is not
busy and easily can be moved to be per-device, once it will be needed.
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/infiniband/core/device.c | 24 +++++++++++++++++++++++-
include/rdma/ib_verbs.h | 8 +++++++-
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
index 5a680a88aa87..3270cde6d806 100644
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -170,6 +170,14 @@ static struct ib_device *__ib_device_get_by_name(const char *name)
return NULL;
}
+void ib_device_get_name(struct ib_device *ibdev, char *name)
+{
+ down_read(&lists_rwsem);
+ strlcpy(name, ibdev->name, IB_DEVICE_NAME_MAX);
+ up_read(&lists_rwsem);
+}
+EXPORT_SYMBOL(ib_device_get_name);
+
static int alloc_name(char *name)
{
unsigned long *inuse;
@@ -202,6 +210,21 @@ static int alloc_name(char *name)
return 0;
}
+int ib_device_alloc_name(struct ib_device *ibdev, const char *pattern)
+{
+ int ret = 0;
+
+ mutex_lock(&device_mutex);
+ strlcpy(ibdev->name, pattern, IB_DEVICE_NAME_MAX);
+ if (strchr(ibdev->name, '%'))
+ ret = alloc_name(ibdev->name);
+
+ mutex_unlock(&device_mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL(ib_device_alloc_name);
+
static void ib_device_release(struct device *device)
{
struct ib_device *dev = container_of(device, struct ib_device, dev);
@@ -499,7 +522,6 @@ int ib_register_device(struct ib_device *device,
ret = alloc_name(device->name);
if (ret)
goto out;
- }
if (ib_device_check_mandatory(device)) {
ret = -EINVAL;
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index e764ed1f6025..66660e7b9854 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -2260,6 +2260,11 @@ struct ib_device {
/* Do not access @dma_device directly from ULP nor from HW drivers. */
struct device *dma_device;
+ /*
+ * Do not access @name directly,
+ * use ib_device_get_name()/ib_device_alloc_name()
+ * and don't assume that it can't change after access.
+ */
char name[IB_DEVICE_NAME_MAX];
struct list_head event_handler_list;
@@ -2638,7 +2643,8 @@ struct ib_device *ib_alloc_device(size_t size);
void ib_dealloc_device(struct ib_device *device);
void ib_get_device_fw_str(struct ib_device *device, char *str);
-
+int ib_device_alloc_name(struct ib_device *ibdev, const char *pattern);
+void ib_device_get_name(struct ib_device *ibdev, char *name);
int ib_register_device(struct ib_device *device,
int (*port_callback)(struct ib_device *,
u8, struct kobject *));
^ permalink raw reply related
* [PATCH rdma-next 2/5] net/smc: Use IB device index instead of name
From: Leon Romanovsky @ 2018-09-20 11:21 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, linux-s390, Ursula Braun,
David S. Miller, netdev, Selvin Xavier, Steve Wise, Lijun Ou,
Shiraz Saleem, Ariel Elior, Christian Benvenuti, Adit Ranadive,
Dennis Dalessandro
In-Reply-To: <20180920112202.9181-1-leon@kernel.org>
From: Leon Romanovsky <leonro@mellanox.com>
IB device name is not stable and will be possible to rename in the
following patches, update SMC code to use IB index as a stable
identification.
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
net/smc/smc_diag.c | 6 +++---
net/smc/smc_pnet.c | 27 ++++++++++++++++-----------
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/net/smc/smc_diag.c b/net/smc/smc_diag.c
index dbf64a93d68a..ba8b5a5671ec 100644
--- a/net/smc/smc_diag.c
+++ b/net/smc/smc_diag.c
@@ -156,9 +156,9 @@ static int __smc_diag_dump(struct sock *sk, struct sk_buff *skb,
.lnk[0].link_id = smc->conn.lgr->lnk[0].link_id,
};
- memcpy(linfo.lnk[0].ibname,
- smc->conn.lgr->lnk[0].smcibdev->ibdev->name,
- sizeof(smc->conn.lgr->lnk[0].smcibdev->ibdev->name));
+ ib_device_get_name(smc->conn.lgr->lnk[0].smcibdev->ibdev,
+ linfo.lnk[0].ibname);
+
smc_gid_be16_convert(linfo.lnk[0].gid,
smc->conn.lgr->lnk[0].gid);
smc_gid_be16_convert(linfo.lnk[0].peer_gid,
diff --git a/net/smc/smc_pnet.c b/net/smc/smc_pnet.c
index 01c6ce042a1c..67aec5ce6112 100644
--- a/net/smc/smc_pnet.c
+++ b/net/smc/smc_pnet.c
@@ -70,15 +70,14 @@ struct smc_pnetentry {
u8 ib_port;
};
-/* Check if two RDMA device entries are identical. Use device name and port
+/* Check if two RDMA device entries are identical. Use device index and port
* number for comparison.
*/
-static bool smc_pnet_same_ibname(struct smc_pnetentry *pnetelem, char *ibname,
- u8 ibport)
+static bool smc_pnet_same_ibindex(struct smc_pnetentry *pnetelem, u32 ibindex,
+ u8 ibport)
{
return pnetelem->ib_port == ibport &&
- !strncmp(pnetelem->smcibdev->ibdev->name, ibname,
- sizeof(pnetelem->smcibdev->ibdev->name));
+ pnetelem->smcibdev->ibdev->index == ibindex;
}
/* Find a pnetid in the pnet table.
@@ -179,9 +178,9 @@ static int smc_pnet_enter(struct smc_pnetentry *new_pnetelem)
sizeof(new_pnetelem->pnet_name)) ||
!strncmp(pnetelem->ndev->name, new_pnetelem->ndev->name,
sizeof(new_pnetelem->ndev->name)) ||
- smc_pnet_same_ibname(pnetelem,
- new_pnetelem->smcibdev->ibdev->name,
- new_pnetelem->ib_port)) {
+ smc_pnet_same_ibindex(pnetelem,
+ new_pnetelem->smcibdev->ibdev->index,
+ new_pnetelem->ib_port)) {
dev_put(pnetelem->ndev);
goto found;
}
@@ -227,10 +226,11 @@ static struct smc_ib_device *smc_pnet_find_ib(char *ib_name)
spin_lock(&smc_ib_devices.lock);
list_for_each_entry(ibdev, &smc_ib_devices.list, list) {
- if (!strncmp(ibdev->ibdev->name, ib_name,
- sizeof(ibdev->ibdev->name))) {
+ char name[IB_DEVICE_NAME_MAX] = {};
+
+ ib_device_get_name(ibdev->ibdev, name);
+ if (!strncmp(name, ib_name, IB_DEVICE_NAME_MAX))
goto out;
- }
}
ibdev = NULL;
out:
@@ -267,6 +267,11 @@ static int smc_pnet_fill_entry(struct net *net, struct smc_pnetentry *pnetelem,
goto error;
rc = -EINVAL;
+ /* NOTE !!!: Sadly enough, but this is part of ABI.
+ * From day one, the accesses are performed with device names and not
+ * device indexes for both ETH and IB. It means that this function isn't
+ * reliable after device renaming.
+ */
if (!tb[SMC_PNETID_IBNAME])
goto error;
rc = -ENOENT;
^ permalink raw reply related
* [PATCH rdma-next 4/5] RDMA/core: Implement IB device rename function
From: Leon Romanovsky @ 2018-09-20 11:22 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, linux-s390, Ursula Braun,
David S. Miller, netdev, Selvin Xavier, Steve Wise, Lijun Ou,
Shiraz Saleem, Ariel Elior, Christian Benvenuti, Adit Ranadive,
Dennis Dalessandro
In-Reply-To: <20180920112202.9181-1-leon@kernel.org>
From: Leon Romanovsky <leonro@mellanox.com>
Generic implementation of IB device rename function.
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/infiniband/core/core_priv.h | 1 +
drivers/infiniband/core/device.c | 23 +++++++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/drivers/infiniband/core/core_priv.h b/drivers/infiniband/core/core_priv.h
index d7399d5b1cb6..c5881756b799 100644
--- a/drivers/infiniband/core/core_priv.h
+++ b/drivers/infiniband/core/core_priv.h
@@ -87,6 +87,7 @@ int ib_device_register_sysfs(struct ib_device *device,
int (*port_callback)(struct ib_device *,
u8, struct kobject *));
void ib_device_unregister_sysfs(struct ib_device *device);
+int ib_device_rename(struct ib_device *ibdev, const char *name);
typedef void (*roce_netdev_callback)(struct ib_device *device, u8 port,
struct net_device *idev, void *cookie);
diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
index a9bc2a3f490c..36b79cd6b620 100644
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -178,6 +178,29 @@ void ib_device_get_name(struct ib_device *ibdev, char *name)
}
EXPORT_SYMBOL(ib_device_get_name);
+int ib_device_rename(struct ib_device *ibdev, const char *name)
+{
+ struct ib_device *device;
+ int ret = 0;
+
+ if (!strcmp(name, ibdev->name))
+ return ret;
+
+ mutex_lock(&device_mutex);
+ list_for_each_entry(device, &device_list, core_list) {
+ if (!strcmp(name, device->name)) {
+ ret = -EEXIST;
+ goto out;
+ }
+ }
+
+ strlcpy(ibdev->name, name, IB_DEVICE_NAME_MAX);
+ ret = device_rename(&ibdev->dev, name);
+out:
+ mutex_unlock(&device_mutex);
+ return ret;
+}
+
static int alloc_name(char *name)
{
unsigned long *inuse;
^ permalink raw reply related
* [PATCH rdma-next 5/5] RDMA/nldev: Allow IB device rename through RDMA netlink
From: Leon Romanovsky @ 2018-09-20 11:22 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, linux-s390, Ursula Braun,
David S. Miller, netdev, Selvin Xavier, Steve Wise, Lijun Ou,
Shiraz Saleem, Ariel Elior, Christian Benvenuti, Adit Ranadive,
Dennis Dalessandro
In-Reply-To: <20180920112202.9181-1-leon@kernel.org>
From: Leon Romanovsky <leonro@mellanox.com>
Provide an option to rename IB device name through RDMA netlink and
limit it to users with ADMIN capability only.
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/infiniband/core/nldev.c | 33 +++++++++++++++++++++++++++++++++
include/uapi/rdma/rdma_netlink.h | 3 ++-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/nldev.c b/drivers/infiniband/core/nldev.c
index 0385ab438320..64e1d12e9678 100644
--- a/drivers/infiniband/core/nldev.c
+++ b/drivers/infiniband/core/nldev.c
@@ -645,6 +645,35 @@ static int nldev_get_doit(struct sk_buff *skb, struct nlmsghdr *nlh,
return err;
}
+static int nldev_set_doit(struct sk_buff *skb, struct nlmsghdr *nlh,
+ struct netlink_ext_ack *extack)
+{
+ struct nlattr *tb[RDMA_NLDEV_ATTR_MAX];
+ struct ib_device *device;
+ u32 index;
+ int err;
+
+ err = nlmsg_parse(nlh, 0, tb, RDMA_NLDEV_ATTR_MAX - 1, nldev_policy,
+ extack);
+ if (err || !tb[RDMA_NLDEV_ATTR_DEV_INDEX])
+ return -EINVAL;
+
+ index = nla_get_u32(tb[RDMA_NLDEV_ATTR_DEV_INDEX]);
+ device = ib_device_get_by_index(index);
+ if (!device)
+ return -EINVAL;
+
+ if (tb[RDMA_NLDEV_ATTR_DEV_NAME]) {
+ char name[IB_DEVICE_NAME_MAX] = {};
+
+ nla_strlcpy(name, tb[RDMA_NLDEV_ATTR_DEV_NAME],
+ IB_DEVICE_NAME_MAX);
+ return ib_device_rename(device, name);
+ }
+
+ return 0;
+}
+
static int _nldev_get_dumpit(struct ib_device *device,
struct sk_buff *skb,
struct netlink_callback *cb,
@@ -1077,6 +1106,10 @@ static const struct rdma_nl_cbs nldev_cb_table[RDMA_NLDEV_NUM_OPS] = {
.doit = nldev_get_doit,
.dump = nldev_get_dumpit,
},
+ [RDMA_NLDEV_CMD_SET] = {
+ .doit = nldev_set_doit,
+ .flags = RDMA_NL_ADMIN_PERM,
+ },
[RDMA_NLDEV_CMD_PORT_GET] = {
.doit = nldev_port_get_doit,
.dump = nldev_port_get_dumpit,
diff --git a/include/uapi/rdma/rdma_netlink.h b/include/uapi/rdma/rdma_netlink.h
index edba6351ac13..f9c41bf59efc 100644
--- a/include/uapi/rdma/rdma_netlink.h
+++ b/include/uapi/rdma/rdma_netlink.h
@@ -227,8 +227,9 @@ enum rdma_nldev_command {
RDMA_NLDEV_CMD_UNSPEC,
RDMA_NLDEV_CMD_GET, /* can dump */
+ RDMA_NLDEV_CMD_SET,
- /* 2 - 4 are free to use */
+ /* 3 - 4 are free to use */
RDMA_NLDEV_CMD_PORT_GET = 5, /* can dump */
^ permalink raw reply related
* [PATCH rdma-next 3/5] RDMA: Convert IB drivers to name allocation routine
From: Leon Romanovsky @ 2018-09-20 11:22 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, linux-s390, Ursula Braun,
David S. Miller, netdev, Selvin Xavier, Steve Wise, Lijun Ou,
Shiraz Saleem, Ariel Elior, Christian Benvenuti, Adit Ranadive,
Dennis Dalessandro
In-Reply-To: <20180920112202.9181-1-leon@kernel.org>
From: Leon Romanovsky <leonro@mellanox.com>
Move internal implementation of device name to the IB/core.
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/infiniband/core/device.c | 5 -----
drivers/infiniband/hw/bnxt_re/main.c | 6 +++++-
drivers/infiniband/hw/cxgb3/iwch_provider.c | 5 ++++-
drivers/infiniband/hw/cxgb4/provider.c | 5 ++++-
drivers/infiniband/hw/hns/hns_roce_main.c | 4 +++-
drivers/infiniband/hw/i40iw/i40iw_verbs.c | 7 ++++++-
drivers/infiniband/hw/mlx4/main.c | 7 ++++++-
drivers/infiniband/hw/mlx5/main.c | 4 +++-
drivers/infiniband/hw/mthca/mthca_provider.c | 5 ++++-
drivers/infiniband/hw/nes/nes_verbs.c | 6 +++++-
drivers/infiniband/hw/ocrdma/ocrdma_main.c | 7 ++++++-
drivers/infiniband/hw/qedr/main.c | 4 +++-
drivers/infiniband/hw/usnic/usnic_ib_main.c | 5 ++++-
drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c | 9 ++++++---
drivers/infiniband/sw/rxe/rxe_verbs.c | 5 ++++-
15 files changed, 63 insertions(+), 21 deletions(-)
diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
index 3270cde6d806..a9bc2a3f490c 100644
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -518,11 +518,6 @@ int ib_register_device(struct ib_device *device,
mutex_lock(&device_mutex);
- if (strchr(device->name, '%')) {
- ret = alloc_name(device->name);
- if (ret)
- goto out;
-
if (ib_device_check_mandatory(device)) {
ret = -EINVAL;
goto out;
diff --git a/drivers/infiniband/hw/bnxt_re/main.c b/drivers/infiniband/hw/bnxt_re/main.c
index 20b9f31052bf..5255e5ffd6f4 100644
--- a/drivers/infiniband/hw/bnxt_re/main.c
+++ b/drivers/infiniband/hw/bnxt_re/main.c
@@ -575,11 +575,15 @@ static void bnxt_re_unregister_ib(struct bnxt_re_dev *rdev)
static int bnxt_re_register_ib(struct bnxt_re_dev *rdev)
{
struct ib_device *ibdev = &rdev->ibdev;
+ int ret;
/* ib device init */
ibdev->owner = THIS_MODULE;
ibdev->node_type = RDMA_NODE_IB_CA;
- strlcpy(ibdev->name, "bnxt_re%d", IB_DEVICE_NAME_MAX);
+ ret = ib_device_alloc_name(ibdev, "bnxt_re%d");
+ if (ret)
+ return ret;
+
strlcpy(ibdev->node_desc, BNXT_RE_DESC " HCA",
strlen(BNXT_RE_DESC) + 5);
ibdev->phys_port_cnt = 1;
diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.c b/drivers/infiniband/hw/cxgb3/iwch_provider.c
index 1b9ff21aa1d5..3680d80036eb 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_provider.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.c
@@ -1319,7 +1319,10 @@ int iwch_register_device(struct iwch_dev *dev)
int i;
pr_debug("%s iwch_dev %p\n", __func__, dev);
- strlcpy(dev->ibdev.name, "cxgb3_%d", IB_DEVICE_NAME_MAX);
+ ret = ib_device_alloc_name(&dev->ibdev, "cxgb3_%d");
+ if (ret)
+ return ret;
+
memset(&dev->ibdev.node_guid, 0, sizeof(dev->ibdev.node_guid));
memcpy(&dev->ibdev.node_guid, dev->rdev.t3cdev_p->lldev->dev_addr, 6);
dev->ibdev.owner = THIS_MODULE;
diff --git a/drivers/infiniband/hw/cxgb4/provider.c b/drivers/infiniband/hw/cxgb4/provider.c
index 4eda6872e617..37d40cbdf0dc 100644
--- a/drivers/infiniband/hw/cxgb4/provider.c
+++ b/drivers/infiniband/hw/cxgb4/provider.c
@@ -535,7 +535,10 @@ void c4iw_register_device(struct work_struct *work)
struct c4iw_dev *dev = ctx->dev;
pr_debug("c4iw_dev %p\n", dev);
- strlcpy(dev->ibdev.name, "cxgb4_%d", IB_DEVICE_NAME_MAX);
+ ret = ib_device_alloc_name(&dev->ibdev, "cxgb4_%d");
+ if (ret)
+ return;
+
memset(&dev->ibdev.node_guid, 0, sizeof(dev->ibdev.node_guid));
memcpy(&dev->ibdev.node_guid, dev->rdev.lldi.ports[0]->dev_addr, 6);
dev->ibdev.owner = THIS_MODULE;
diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c b/drivers/infiniband/hw/hns/hns_roce_main.c
index 6edb547baee8..e16f72692c83 100644
--- a/drivers/infiniband/hw/hns/hns_roce_main.c
+++ b/drivers/infiniband/hw/hns/hns_roce_main.c
@@ -449,7 +449,9 @@ static int hns_roce_register_device(struct hns_roce_dev *hr_dev)
spin_lock_init(&iboe->lock);
ib_dev = &hr_dev->ib_dev;
- strlcpy(ib_dev->name, "hns_%d", IB_DEVICE_NAME_MAX);
+ ret = ib_device_alloc_name(ib_dev, "hns_%d");
+ if (ret)
+ return ret;
ib_dev->owner = THIS_MODULE;
ib_dev->node_type = RDMA_NODE_IB_CA;
diff --git a/drivers/infiniband/hw/i40iw/i40iw_verbs.c b/drivers/infiniband/hw/i40iw/i40iw_verbs.c
index e2e6c74a7452..829be11da4e7 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_verbs.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_verbs.c
@@ -2746,13 +2746,18 @@ static struct i40iw_ib_device *i40iw_init_rdma_device(struct i40iw_device *iwdev
struct i40iw_ib_device *iwibdev;
struct net_device *netdev = iwdev->netdev;
struct pci_dev *pcidev = (struct pci_dev *)iwdev->hw.dev_context;
+ int ret;
iwibdev = (struct i40iw_ib_device *)ib_alloc_device(sizeof(*iwibdev));
if (!iwibdev) {
i40iw_pr_err("iwdev == NULL\n");
return NULL;
}
- strlcpy(iwibdev->ibdev.name, "i40iw%d", IB_DEVICE_NAME_MAX);
+
+ ret = ib_device_alloc_name(&iwibdev->ibdev, "i40iw%d");
+ if (ret)
+ return NULL;
+
iwibdev->ibdev.owner = THIS_MODULE;
iwdev->iwibdev = iwibdev;
iwibdev->iwdev = iwdev;
diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c
index bf3cdb88aaf5..8edbc50d298a 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -2540,7 +2540,10 @@ static void *mlx4_ib_add(struct mlx4_dev *dev)
ibdev->dev = dev;
ibdev->bond_next_port = 0;
- strlcpy(ibdev->ib_dev.name, "mlx4_%d", IB_DEVICE_NAME_MAX);
+ err = ib_device_alloc_name(&ibdev->ib_dev, "mlx4_%d");
+ if (err)
+ goto err_name;
+
ibdev->ib_dev.owner = THIS_MODULE;
ibdev->ib_dev.node_type = RDMA_NODE_IB_CA;
ibdev->ib_dev.local_dma_lkey = dev->caps.reserved_lkey;
@@ -2882,6 +2885,8 @@ static void *mlx4_ib_add(struct mlx4_dev *dev)
err_map:
mlx4_ib_free_eqs(dev, ibdev);
+
+err_name:
iounmap(ibdev->uar_map);
err_uar:
diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
index 73782100750d..a4a578ba72ee 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -5698,8 +5698,10 @@ int mlx5_ib_stage_init_init(struct mlx5_ib_dev *dev)
name = "mlx5_%d";
else
name = "mlx5_bond_%d";
+ err = ib_device_alloc_name(&dev->ib_dev, name);
+ if (err)
+ goto err_mp;
- strlcpy(dev->ib_dev.name, name, IB_DEVICE_NAME_MAX);
dev->ib_dev.owner = THIS_MODULE;
dev->ib_dev.node_type = RDMA_NODE_IB_CA;
dev->ib_dev.local_dma_lkey = 0 /* not supported for now */;
diff --git a/drivers/infiniband/hw/mthca/mthca_provider.c b/drivers/infiniband/hw/mthca/mthca_provider.c
index 0d3473b4596e..67ff3ecdf8d5 100644
--- a/drivers/infiniband/hw/mthca/mthca_provider.c
+++ b/drivers/infiniband/hw/mthca/mthca_provider.c
@@ -1198,7 +1198,10 @@ int mthca_register_device(struct mthca_dev *dev)
if (ret)
return ret;
- strlcpy(dev->ib_dev.name, "mthca%d", IB_DEVICE_NAME_MAX);
+ ret = ib_device_alloc_name(&dev->ib_dev, "mthca%d");
+ if (ret)
+ return ret;
+
dev->ib_dev.owner = THIS_MODULE;
dev->ib_dev.uverbs_abi_ver = MTHCA_UVERBS_ABI_VERSION;
diff --git a/drivers/infiniband/hw/nes/nes_verbs.c b/drivers/infiniband/hw/nes/nes_verbs.c
index 6940c7215961..7394d50b02f5 100644
--- a/drivers/infiniband/hw/nes/nes_verbs.c
+++ b/drivers/infiniband/hw/nes/nes_verbs.c
@@ -3635,12 +3635,16 @@ struct nes_ib_device *nes_init_ofa_device(struct net_device *netdev)
struct nes_ib_device *nesibdev;
struct nes_vnic *nesvnic = netdev_priv(netdev);
struct nes_device *nesdev = nesvnic->nesdev;
+ int ret;
nesibdev = (struct nes_ib_device *)ib_alloc_device(sizeof(struct nes_ib_device));
if (nesibdev == NULL) {
return NULL;
}
- strlcpy(nesibdev->ibdev.name, "nes%d", IB_DEVICE_NAME_MAX);
+ ret = ib_device_alloc_name(&nesibdev->ibdev, "nes%d");
+ if (ret)
+ return NULL;
+
nesibdev->ibdev.owner = THIS_MODULE;
nesibdev->ibdev.node_type = RDMA_NODE_RNIC;
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_main.c b/drivers/infiniband/hw/ocrdma/ocrdma_main.c
index 7832ee3e0c84..34f7d8f31ee1 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_main.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_main.c
@@ -116,7 +116,12 @@ static void get_dev_fw_str(struct ib_device *device, char *str)
static int ocrdma_register_device(struct ocrdma_dev *dev)
{
- strlcpy(dev->ibdev.name, "ocrdma%d", IB_DEVICE_NAME_MAX);
+ int ret;
+
+ ret = ib_device_alloc_name(&dev->ibdev, "ocrdma%d");
+ if (ret)
+ return ret;
+
ocrdma_get_guid(dev, (u8 *)&dev->ibdev.node_guid);
BUILD_BUG_ON(sizeof(OCRDMA_NODE_DESC) > IB_DEVICE_NODE_DESC_MAX);
memcpy(dev->ibdev.node_desc, OCRDMA_NODE_DESC,
diff --git a/drivers/infiniband/hw/qedr/main.c b/drivers/infiniband/hw/qedr/main.c
index a0af6d424aed..43e14f6b1c6d 100644
--- a/drivers/infiniband/hw/qedr/main.c
+++ b/drivers/infiniband/hw/qedr/main.c
@@ -170,7 +170,9 @@ static int qedr_register_device(struct qedr_dev *dev)
{
int rc;
- strlcpy(dev->ibdev.name, "qedr%d", IB_DEVICE_NAME_MAX);
+ rc = ib_device_alloc_name(&dev->ibdev, "qedr%d");
+ if (rc)
+ return rc;
dev->ibdev.node_guid = dev->attr.node_guid;
memcpy(dev->ibdev.node_desc, QEDR_NODE_DESC, sizeof(QEDR_NODE_DESC));
diff --git a/drivers/infiniband/hw/usnic/usnic_ib_main.c b/drivers/infiniband/hw/usnic/usnic_ib_main.c
index f0538a460328..15f1509cac8d 100644
--- a/drivers/infiniband/hw/usnic/usnic_ib_main.c
+++ b/drivers/infiniband/hw/usnic/usnic_ib_main.c
@@ -335,6 +335,7 @@ static void *usnic_ib_device_add(struct pci_dev *dev)
union ib_gid gid;
struct in_device *ind;
struct net_device *netdev;
+ int ret;
usnic_dbg("\n");
netdev = pci_get_drvdata(dev);
@@ -364,7 +365,9 @@ static void *usnic_ib_device_add(struct pci_dev *dev)
us_ibdev->ib_dev.num_comp_vectors = USNIC_IB_NUM_COMP_VECTORS;
us_ibdev->ib_dev.dev.parent = &dev->dev;
us_ibdev->ib_dev.uverbs_abi_ver = USNIC_UVERBS_ABI_VERSION;
- strlcpy(us_ibdev->ib_dev.name, "usnic_%d", IB_DEVICE_NAME_MAX);
+ ret = ib_device_alloc_name(&us_ibdev->ib_dev, "usnic_%d");
+ if (ret)
+ goto err_fwd_dealloc;
us_ibdev->ib_dev.uverbs_cmd_mask =
(1ull << IB_USER_VERBS_CMD_GET_CONTEXT) |
diff --git a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
index a5719899f49a..afe84d55bb52 100644
--- a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
+++ b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
@@ -159,10 +159,13 @@ static struct net_device *pvrdma_get_netdev(struct ib_device *ibdev,
static int pvrdma_register_device(struct pvrdma_dev *dev)
{
- int ret = -1;
int i = 0;
+ int ret;
+
+ ret = ib_device_alloc_name(&dev->ib_dev, "vmw_pvrdma%d");
+ if (ret)
+ return ret;
- strlcpy(dev->ib_dev.name, "vmw_pvrdma%d", IB_DEVICE_NAME_MAX);
dev->ib_dev.node_guid = dev->dsr->caps.node_guid;
dev->sys_image_guid = dev->dsr->caps.sys_image_guid;
dev->flags = 0;
@@ -235,7 +238,7 @@ static int pvrdma_register_device(struct pvrdma_dev *dev)
dev->cq_tbl = kcalloc(dev->dsr->caps.max_cq, sizeof(struct pvrdma_cq *),
GFP_KERNEL);
if (!dev->cq_tbl)
- return ret;
+ return -ENOMEM;
spin_lock_init(&dev->cq_tbl_lock);
dev->qp_tbl = kcalloc(dev->dsr->caps.max_qp, sizeof(struct pvrdma_qp *),
diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c b/drivers/infiniband/sw/rxe/rxe_verbs.c
index f5b1e0ad6142..2b017bfeecda 100644
--- a/drivers/infiniband/sw/rxe/rxe_verbs.c
+++ b/drivers/infiniband/sw/rxe/rxe_verbs.c
@@ -1159,7 +1159,10 @@ int rxe_register_device(struct rxe_dev *rxe)
struct ib_device *dev = &rxe->ib_dev;
struct crypto_shash *tfm;
- strlcpy(dev->name, "rxe%d", IB_DEVICE_NAME_MAX);
+ err = ib_device_alloc_name(dev, "rxe%d");
+ if (err)
+ return err;
+
strlcpy(dev->node_desc, "rxe", sizeof(dev->node_desc));
dev->owner = THIS_MODULE;
^ permalink raw reply related
* [RFC PATCH iproute2-next 0/3] rdma: IB device rename
From: Leon Romanovsky @ 2018-09-20 11:22 UTC (permalink / raw)
To: David Ahern; +Cc: Leon Romanovsky, netdev, RDMA mailing list, Stephen Hemminger
From: Leon Romanovsky <leonro@mellanox.com>
Hi,
This is comprehensive part of kernel series posted earlier. The kernel
part is not accepted yet, so first patch will have different commit
message with different commit SHA1. This is why it is marked as RFC.
An example:
[leonro@server /]$ lspci |grep -i Ether
00:08.0 Ethernet controller: Red Hat, Inc. Virtio network device
00:09.0 Ethernet controller: Mellanox Technologies MT27700 Family [ConnectX-4]
[leonro@server /]$ sudo rdma dev
1: mlx5_0: node_type ca fw 3.8.9999 node_guid 5254:00c0:fe12:3455 sys_image_guid 5254:00c0:fe12:3455
[leonro@server /]$ sudo rdma dev set mlx5_0 name hfi1_0
[leonro@server /]$ sudo rdma dev
1: hfi1_0: node_type ca fw 3.8.9999 node_guid 5254:00c0:fe12:3455 sys_image_guid 5254:00c0:fe12:3455
Thanks
Leon Romanovsky (3):
rdma: Update kernel include file to support IB device renaming
rdma: Introduce command execution helper with required device name
rdma: Add an option to rename IB device interface
rdma/dev.c | 35 +++++++++++++++++++++++++++++++++++
rdma/include/uapi/rdma/rdma_netlink.h | 3 ++-
rdma/rdma.h | 1 +
rdma/utils.c | 10 ++++++++++
4 files changed, 48 insertions(+), 1 deletion(-)
^ permalink raw reply
* [RFC PATCH iproute2-next 1/3] rdma: Update kernel include file to support IB device renaming
From: Leon Romanovsky @ 2018-09-20 11:22 UTC (permalink / raw)
To: David Ahern; +Cc: Leon Romanovsky, netdev, RDMA mailing list, Stephen Hemminger
In-Reply-To: <20180920112232.9602-1-leon@kernel.org>
From: Leon Romanovsky <leonro@mellanox.com>
Bring kernel header file changes upto commit 908b44308eda
("RDMA/nldev: Allow IB device rename through RDMA netlink")
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
rdma/include/uapi/rdma/rdma_netlink.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/rdma/include/uapi/rdma/rdma_netlink.h b/rdma/include/uapi/rdma/rdma_netlink.h
index 6513fb89..e2228c09 100644
--- a/rdma/include/uapi/rdma/rdma_netlink.h
+++ b/rdma/include/uapi/rdma/rdma_netlink.h
@@ -227,8 +227,9 @@ enum rdma_nldev_command {
RDMA_NLDEV_CMD_UNSPEC,
RDMA_NLDEV_CMD_GET, /* can dump */
+ RDMA_NLDEV_CMD_SET,
- /* 2 - 4 are free to use */
+ /* 3 - 4 are free to use */
RDMA_NLDEV_CMD_PORT_GET = 5, /* can dump */
^ permalink raw reply related
* [RFC PATCH iproute2-next 2/3] rdma: Introduce command execution helper with required device name
From: Leon Romanovsky @ 2018-09-20 11:22 UTC (permalink / raw)
To: David Ahern; +Cc: Leon Romanovsky, netdev, RDMA mailing list, Stephen Hemminger
In-Reply-To: <20180920112232.9602-1-leon@kernel.org>
From: Leon Romanovsky <leonro@mellanox.com>
In contradiction to various show commands, the set command explicitly
requires to use device name as an argument. Provide new command
execution helper which enforces it.
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
rdma/rdma.h | 1 +
rdma/utils.c | 10 ++++++++++
2 files changed, 11 insertions(+)
diff --git a/rdma/rdma.h b/rdma/rdma.h
index d4b7ba19..dde9e128 100644
--- a/rdma/rdma.h
+++ b/rdma/rdma.h
@@ -90,6 +90,7 @@ int cmd_link(struct rd *rd);
int cmd_res(struct rd *rd);
int rd_exec_cmd(struct rd *rd, const struct rd_cmd *c, const char *str);
int rd_exec_dev(struct rd *rd, int (*cb)(struct rd *rd));
+int rd_exec_require_dev(struct rd *rd, int (*cb)(struct rd *rd));
int rd_exec_link(struct rd *rd, int (*cb)(struct rd *rd), bool strict_port);
void rd_free(struct rd *rd);
int rd_set_arg_to_devname(struct rd *rd);
diff --git a/rdma/utils.c b/rdma/utils.c
index 4840bf22..61f4aeb1 100644
--- a/rdma/utils.c
+++ b/rdma/utils.c
@@ -577,6 +577,16 @@ out:
return ret;
}
+int rd_exec_require_dev(struct rd *rd, int (*cb)(struct rd *rd))
+{
+ if (rd_no_arg(rd)) {
+ pr_err("Please provide device name.\n");
+ return -EINVAL;
+ }
+
+ return rd_exec_dev(rd, cb);
+}
+
int rd_exec_cmd(struct rd *rd, const struct rd_cmd *cmds, const char *str)
{
const struct rd_cmd *c;
^ permalink raw reply related
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