* [PATCH] net: toshiba: remove a redundant local variable 'index_specified'
From: zhong jiang @ 2018-09-20 1:56 UTC (permalink / raw)
To: davem; +Cc: benh, paulus, mpe, netdev, linux-kernel
The local variable 'index_specified' is never used after being assigned.
hence it should be redundant adn can be removed.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/ethernet/toshiba/ps3_gelic_wireless.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
index 302079e..00ab417 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
@@ -1094,7 +1094,7 @@ static int gelic_wl_get_encode(struct net_device *netdev,
struct gelic_wl_info *wl = port_wl(netdev_priv(netdev));
struct iw_point *enc = &data->encoding;
unsigned long irqflag;
- unsigned int key_index, index_specified;
+ unsigned int key_index;
int ret = 0;
pr_debug("%s: <-\n", __func__);
@@ -1105,13 +1105,10 @@ static int gelic_wl_get_encode(struct net_device *netdev,
return -EINVAL;
spin_lock_irqsave(&wl->lock, irqflag);
- if (key_index) {
- index_specified = 1;
+ if (key_index)
key_index--;
- } else {
- index_specified = 0;
+ else
key_index = wl->current_key;
- }
if (wl->group_cipher_method == GELIC_WL_CIPHER_WEP) {
switch (wl->auth_method) {
--
1.7.12.4
^ permalink raw reply related
* [PATCH net-next] e1000: remove set but not used variable 'txb2b'
From: YueHaibing @ 2018-09-20 2:04 UTC (permalink / raw)
To: Jeff Kirsher, David S. Miller
Cc: YueHaibing, intel-wired-lan, netdev, kernel-janitors,
linux-kernel
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/intel/e1000/e1000_main.c: In function 'e1000_watchdog':
drivers/net/ethernet/intel/e1000/e1000_main.c:2436:9: warning:
variable 'txb2b' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/intel/e1000/e1000_main.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 7e0f1f9..43b6d3c 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -2433,7 +2433,6 @@ static void e1000_watchdog(struct work_struct *work)
if (link) {
if (!netif_carrier_ok(netdev)) {
u32 ctrl;
- bool txb2b = true;
/* update snapshot of PHY registers on LSC */
e1000_get_speed_and_duplex(hw,
&adapter->link_speed,
@@ -2455,11 +2454,9 @@ static void e1000_watchdog(struct work_struct *work)
adapter->tx_timeout_factor = 1;
switch (adapter->link_speed) {
case SPEED_10:
- txb2b = false;
adapter->tx_timeout_factor = 16;
break;
case SPEED_100:
- txb2b = false;
/* maybe add some timeout factor ? */
break;
}
^ permalink raw reply related
* Re: Bridge connectivity interruptions while devices join or leave the bridge
From: Johannes Wienke @ 2018-09-19 20:57 UTC (permalink / raw)
To: Stephen Hemminger, Ido Schimmel; +Cc: netdev
In-Reply-To: <20180919100358.0ea95c20@xeon-e3>
On 19.09.18 19:03, Stephen Hemminger wrote:
> On Wed, 19 Sep 2018 19:45:08 +0300
> Ido Schimmel <idosch@idosch.org> wrote:
>
>> On Wed, Sep 19, 2018 at 01:00:15PM +0200, Johannes Wienke wrote:
>>> This behavior of inheriting the mac address is really unexpected to us.
>>> Is it documented somewhere?
>>
>> Not that I'm aware, but it's a well established behavior.
>
> Not documented, has always been that way. It seems to be part of 802 standard maybe?
> Anyway, if you set a MAC address of the bridge device it makes it sticky;
> i.e it won't change if ports of bridge change.
Yes sure. It was just unexpected to meet this and we ha no clue that
this could be a reasonable default. I just wonder what the motivation
for hat is and of course some more obvious documentation would have
helped a lot in debugging/avoid this.
Cheers,
Johannes
--
Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University
Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307)
Phone: +49 521 106-67277
^ permalink raw reply
* Re: [PATCH mlx5-next 03/25] net/mlx5: Set uid as part of RQ commands
From: Jason Gunthorpe @ 2018-09-19 21:10 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Leon Romanovsky, Doug Ledford, Leon Romanovsky, RDMA mailing list,
Yishai Hadas, Saeed Mahameed, Linux Netdev List
In-Reply-To: <CALzJLG-YOtkm0HBWBrgPOSYy1bcxvW+D2YorjVHCLMQZRpZUbA@mail.gmail.com>
On Wed, Sep 19, 2018 at 11:40:45AM -0700, Saeed Mahameed wrote:
> On Wed, Sep 19, 2018 at 10:28 AM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >
> > On Mon, Sep 17, 2018 at 02:03:56PM +0300, Leon Romanovsky wrote:
> > > From: Yishai Hadas <yishaih@mellanox.com>
> > >
> > > Set uid as part of RQ commands so that the firmware can manage the
> > > RQ object in a secured way.
> > >
> > > That will enable using an RQ that was created by verbs application
> > > to be used by the DEVX flow in case the uid is equal.
> > >
> > > Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
> > > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > > drivers/net/ethernet/mellanox/mlx5/core/qp.c | 16 ++++++++++++++--
> > > include/linux/mlx5/mlx5_ifc.h | 6 +++---
> > > 2 files changed, 17 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/qp.c b/drivers/net/ethernet/mellanox/mlx5/core/qp.c
> > > index 04f72a1cdbcc..0ca68ef54d93 100644
> > > +++ b/drivers/net/ethernet/mellanox/mlx5/core/qp.c
> > > @@ -540,6 +540,17 @@ int mlx5_core_xrcd_dealloc(struct mlx5_core_dev *dev, u32 xrcdn)
> > > }
> > > EXPORT_SYMBOL_GPL(mlx5_core_xrcd_dealloc);
> > >
> > > +static void destroy_rq_tracked(struct mlx5_core_dev *dev, u32 rqn, u16 uid)
> > > +{
> > > + u32 in[MLX5_ST_SZ_DW(destroy_rq_in)] = {0};
> > > + u32 out[MLX5_ST_SZ_DW(destroy_rq_out)] = {0};
> >
> > = {} is the preferred version of this, right?
> >
> > {0} explicitly initializes the first element to zero and only works if
> > the first element happens to be something integral..
> >
>
> Both are perfectly ok in our scenarios.
> I remember one of the syntaxes yielded a statistic checker warning, i
> don't remember which syntax and what static checker :) ..
{0} will throw a 'missing-field-initializers' compiler warning,
however it recognizes '= {}' as an idom meaning 'zero everything' and
does not throw a warning.
Jason
^ permalink raw reply
* Re: [RFC 4/5] netlink: prepare validate extack setting for recursion
From: Marcelo Ricardo Leitner @ 2018-09-19 21:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev
In-Reply-To: <1537384771.10305.68.camel@sipsolutions.net>
On Wed, Sep 19, 2018 at 09:19:31PM +0200, Johannes Berg wrote:
> On Wed, 2018-09-19 at 15:46 -0300, Marcelo Ricardo Leitner wrote:
>
> > > NL_SET_ERR_MSG(extack, "warning: deprecated command");
> > > err = nla_parse(..., extack);
> > > if (err)
> > > return err;
> > > /* do something */
> > > return 0;
> > >
> > > Here you could consider the message there a warning that's transported
> > > out even if we return 0, but if we return with a failure from
> > > nla_parse() (or nla_validate instead if you wish), then that failure
> > > message "wins".
> >
> > Agree. This is the core issue here, IMHO. Once out of the context that
> > set the message, we have no way of knowing if we can nor should
> > overwrite the message that is already in there.
>
> True.
>
> I'm not really sure I'd go as far as calling it an issue though.
Ok, s/issue/matter in question/.
...
> > > I suppose we could - technically - make that generic, in that we could
> > > have both
> > >
> > > NLA_SET_WARN_MSG(extack, "...");
> > > NLA_SET_ERR_MSG(extack, "...");
> >
> > I like this.
>
> I'm not really sure what for though :-)
Hehe :-)
>
> FWIW, if you do think that there's a need for distinguishing this, then
> I'd argue that perhaps the right way to address this would be to extend
> this all the way to userspace and have two separate attributes for
> errors and warnings in the extended ACK message?
Likely, yes. And perhaps even support multiple messages. That way we
could, for example, parse all attributes and return a list of the all
the offending ones, instead of returning one at a time. Net benefit?
Not clear.. over engineering? Possibly.
I agree with you that in general we should not need this.
> > While for the situation you are describing here, it will set a generic
> > error message in case the inner code didn't do it.
>
> Yes, but that's not a change in semantics as far as the caller of
> nla_parse/nla_validate is concerned - it'll continue to unconditionally
> set a message if an error occurred, only the internal behaviour as to
> which message seems more relevant is at issue, and the whole recursion
> thing and avoiding an outer one overwriting an inner one is IMHO more
> useful because that's the more specific error.
That's fine. My point here was only to clarify the use case, which
would be used in other places too (like in the example below).
>
> > Using the semantics of NLA_SET_WARN_MSG and ERR, then WARN would
> > replace other WARNs but not ERRs, and ERR would replace other WARNs
> > too but not other ERRs. All we need to do handle this is a bit in
> > extack saying if the message is considered a warning or not, or an
> > error/fatal message or not.
>
> I'm still not really sure what the use case for a warning is, so not
> sure I can really comment on this.
Good point. From iproute POV, a warning is a non-fatal message. From
an user perspective, that probably translates are nothing because in
the end the command actually worked. :-)
Seriously, I do think it's more of a hint for developers than anyone
else.
>
> > Okay but we have split parsing of netlink messages and this could be
> > useful in there too:
> > In cls_api.c, tc_new_tfilter() calls nmmsg_parse() and do some
> > processing, and then handle it to a classifier. cls_flower, for
> > example, will then do another parsing. If, for whatever reason, flower
> > failed and did not set an extack msg, tc_new_tfilter() could set a
> > default error message, but at this moment we can't tell if the msg
> > already set was just a warning from the first parsing (or any other
> > code before engaging flower) (which we can overwrite) or if it a
> > message that flower set (which we should not overwrite).
> >
> > Hopefully my description clear.. 8-)
> >
> > I think this is the same situation as with the nested parsing you're
> > proposing.
>
> Yes, I admit that's the same, just not part of pure policy checking, but
> open-coded (in a way).
>
> > Currently it (tc_new_tfilter) doesn't set any default error message,
> > so this issue is/was not noticed.
>
> True.
>
> Except that I'd still say that tc_new_tfilter() can very well assume
> that nothing has set a message before it ran, it's invoked directly by
> the core netlink code after all.
>
> So IMHO we don't have an issue here because there aren't arbitrary
> callers of this and it can't know what the state is; it does in fact
> know very well what the state is when it's called.
Good point.
>
> With nla_validate/nla_parse that have far more callers we can't be as
> certain, although again - I doubt we actually have places today that
> would run into this situation (given how all this stuff is still fairly
> new).
>
> > > From an external API POV though, nla_validate/nla_parse will continue to
> > > unconditionally overwrite any existing "warning" messages with errors,
> > > if such occurred. They just won't overwrite their own messages when
> > > returning from a nested policy validation.
> >
> > Yes, that's fine. I'm not objecting to the behavior. It just feels
> > that extack handling is getting tricky by the day and we could seize
> > the moment to improve it while we can.
>
> Ok, I guess that's fair. I don't think this actually changes the
> "trickiness" of extack handling though; it's purely an internal detail
> of nla_validate/nla_parse due to me wanting to add recursion; from an
> external POV nothing changed.
>
> johannes
>
Thanks,
Marcelo
^ permalink raw reply
* Re: [Patch net-next] ipv4: initialize ra_mutex in inet_init_net()
From: Cong Wang @ 2018-09-19 21:28 UTC (permalink / raw)
To: Kirill Tkhai; +Cc: Linux Kernel Network Developers
In-Reply-To: <b22a5e5f-7a63-04fd-79ed-9b40e09db3af@virtuozzo.com>
On Wed, Sep 19, 2018 at 1:25 AM Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>
> On 18.09.2018 23:17, Cong Wang wrote:
> > On Mon, Sep 17, 2018 at 12:25 AM Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
> >> In inet_init() the order of registration is:
> >>
> >> ip_mr_init();
> >> init_inet_pernet_ops();
> >>
> >> This means, ipmr_net_ops pernet operations are before af_inet_ops
> >> in pernet_list. So, there is a theoretical probability, sometimes
> >> in the future, we will have a problem during a fail of net initialization.
> >>
> >> Say,
> >>
> >> setup_net():
> >> ipmr_net_ops->init() returns 0
> >> xxx->init() returns error
> >> and then we do:
> >> ipmr_net_ops->exit(),
> >>
> >> which could touch ra_mutex (theoretically).
> >
> > How could ra_mutex be touched in this scenario?
> >
> > ra_mutex is only used in ip_ra_control() which is called
> > only by {get,set}sockopt(). I don't see anything related
> > to netns exit() path here.
>
> Currently, it is not touched. But it's an ordinary practice,
> someone closes sockets in pernet ->exit methods. For example,
> we close percpu icmp sockets in icmp_sk_exit(), which are
> also of RAW type, and there is also called ip_ra_control()
> for them. Yes, they differ by their protocol; icmp sockets
> are of IPPROTO_ICMP protocol, while ip_ra_control() acts
> on IPPROTO_RAW sockets, but it's not good anyway. This does
> not look reliable for the future. In case of someone changes
> something here, we may do not notice this for the long time,
> while some users will meet bugs on their places.
First of all, we only consider current code base. Even if you
really planned to changed this in the future, it would be still your
responsibility to take care of it. Why? Simple, FIFO. My patch
comes ahead of any future changes here, obviously.
Secondly, it is certainly not hard to notice. I am pretty sure
you would get a warning/crash if this bug triggered.
>
> Problems on error paths is not easy to detect on testing,
> while user may meet them. We had issue of same type with
> uninitialized xfrm_policy_lock. It was introduced in 2013,
> while the problem was found only in 2017:
Been there, done that, I've fixed multiple IPv6 init code
error path. This is not where we disagree, by the way.
>
> introduced by 283bc9f35bbb
> fixed by c282222a45cb
>
> (Last week I met it on RH7 kernel, which still has no a fix.
> But this talk is not about distribution kernels, just about
> the way).
>
> I just want to say if someone makes some creativity on top
> of this code, it will be to more friendly from us to him/her
> to not force this person to think about such not obvious details,
> but just to implement nice architecture right now.
You keep saying nice architecture, how did you architect
ipv4.ra_mutex into net/core/net_namespace.c? It is apparently
not nice.
Good luck with your future.
I am tired, let's just drop it. I have no interest to fix your mess.
Thanks!
^ permalink raw reply
* [PATCH net-next] nfp: provide a better warning when ring allocation fails
From: Jakub Kicinski @ 2018-09-19 21:42 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, Jakub Kicinski
NFP supports fairly enormous ring sizes (up to 256k descriptors).
In commit 466271703867 ("nfp: use kvcalloc() to allocate SW buffer
descriptor arrays") we have started using kvcalloc() functions to
make sure the allocation of software state arrays doesn't hit
the MAX_ORDER limit. Unfortunately, we can't use virtual mappings
for the DMA region holding HW descriptors. In case this allocation
fails instead of the generic (and fairly scary) warning/splat in
the logs print a helpful message explaining what happened and
suggesting how to fix it.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
.../net/ethernet/netronome/nfp/nfp_net_common.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 1aac55d66404..6dab45c1f21e 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -2180,9 +2180,13 @@ nfp_net_tx_ring_alloc(struct nfp_net_dp *dp, struct nfp_net_tx_ring *tx_ring)
tx_ring->size = array_size(tx_ring->cnt, sizeof(*tx_ring->txds));
tx_ring->txds = dma_zalloc_coherent(dp->dev, tx_ring->size,
- &tx_ring->dma, GFP_KERNEL);
- if (!tx_ring->txds)
+ &tx_ring->dma,
+ GFP_KERNEL | __GFP_NOWARN);
+ if (!tx_ring->txds) {
+ netdev_warn(dp->netdev, "failed to allocate TX descriptor ring memory, requested descriptor count: %d, consider lowering descriptor count\n",
+ tx_ring->cnt);
goto err_alloc;
+ }
tx_ring->txbufs = kvcalloc(tx_ring->cnt, sizeof(*tx_ring->txbufs),
GFP_KERNEL);
@@ -2334,9 +2338,13 @@ nfp_net_rx_ring_alloc(struct nfp_net_dp *dp, struct nfp_net_rx_ring *rx_ring)
rx_ring->cnt = dp->rxd_cnt;
rx_ring->size = array_size(rx_ring->cnt, sizeof(*rx_ring->rxds));
rx_ring->rxds = dma_zalloc_coherent(dp->dev, rx_ring->size,
- &rx_ring->dma, GFP_KERNEL);
- if (!rx_ring->rxds)
+ &rx_ring->dma,
+ GFP_KERNEL | __GFP_NOWARN);
+ if (!rx_ring->rxds) {
+ netdev_warn(dp->netdev, "failed to allocate RX descriptor ring memory, requested descriptor count: %d, consider lowering descriptor count\n",
+ rx_ring->cnt);
goto err_alloc;
+ }
rx_ring->rxbufs = kvcalloc(rx_ring->cnt, sizeof(*rx_ring->rxbufs),
GFP_KERNEL);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next v2 01/10] net: core: netlink: add helper refcount dec and lock function
From: Cong Wang @ 2018-09-19 21:46 UTC (permalink / raw)
To: Vlad Buslov
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller, Stephen Hemminger, Kirill Tkhai, Nicolas Dichtel,
Greg KH, mark.rutland, Leon Romanovsky, Paul E. McKenney,
Florian Westphal, David Ahern, christian, lucien xin,
Jakub Kicinski, Jiri Benc
In-Reply-To: <1537168660-24032-2-git-send-email-vladbu@mellanox.com>
On Mon, Sep 17, 2018 at 12:19 AM Vlad Buslov <vladbu@mellanox.com> wrote:
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -130,6 +130,12 @@ int rtnl_is_locked(void)
> }
> EXPORT_SYMBOL(rtnl_is_locked);
>
> +bool refcount_dec_and_rtnl_lock(refcount_t *r)
> +{
> + return refcount_dec_and_mutex_lock(r, &rtnl_mutex);
> +}
> +EXPORT_SYMBOL(refcount_dec_and_rtnl_lock);
I think you probably want to #include <linux/refcount.h>
explicitly.
^ permalink raw reply
* Re: [PATCH bpf-next] flow_dissector: fix build failure without CONFIG_NET
From: Daniel Borkmann @ 2018-09-19 21:48 UTC (permalink / raw)
To: Willem de Bruijn, netdev; +Cc: ast, rdunlap, Willem de Bruijn
In-Reply-To: <20180918202018.204099-1-willemdebruijn.kernel@gmail.com>
On 09/18/2018 10:20 PM, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> If boolean CONFIG_BPF_SYSCALL is enabled, kernel/bpf/syscall.c will
> call flow_dissector functions from net/core/flow_dissector.c.
>
> This causes this build failure if CONFIG_NET is disabled:
>
> kernel/bpf/syscall.o: In function `__x64_sys_bpf':
> syscall.c:(.text+0x3278): undefined reference to
> `skb_flow_dissector_bpf_prog_attach'
> syscall.c:(.text+0x3310): undefined reference to
> `skb_flow_dissector_bpf_prog_detach'
> kernel/bpf/syscall.o:(.rodata+0x3f0): undefined reference to
> `flow_dissector_prog_ops'
> kernel/bpf/verifier.o:(.rodata+0x250): undefined reference to
> `flow_dissector_verifier_ops'
>
> Analogous to other optional BPF program types in syscall.c, add stubs
> if the relevant functions are not compiled and move the BPF_PROG_TYPE
> definition in the #ifdef CONFIG_NET block.
>
> Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Applied to bpf-next, thanks Willem!
^ permalink raw reply
* Re: [PATCH bpf] tools: bpf: fix license for a compat header file
From: Daniel Borkmann @ 2018-09-19 21:51 UTC (permalink / raw)
To: Jakub Kicinski, alexei.starovoitov; +Cc: netdev, oss-drivers
In-Reply-To: <20180918171359.18750-1-jakub.kicinski@netronome.com>
On 09/18/2018 07:13 PM, Jakub Kicinski wrote:
> libc_compat.h is used by libbpf so make sure it's licensed under
> LGPL or BSD license. The license change should be OK, I'm the only
> author of the file.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
Applied to bpf, thanks Jakub!
^ permalink raw reply
* [PATCH 00/22] various dynamic_debug patches
From: Rasmus Villemoes @ 2018-09-19 22:04 UTC (permalink / raw)
To: Jason Baron, Andrew Morton
Cc: linux-kernel, Rasmus Villemoes, Greg Kroah-Hartman, netdev,
Petr Mladek, Steven Rostedt, linux-btrfs, linux-acpi, x86
This started as an experiment to see how hard it would be to change
the four pointers in struct _ddebug into relative offsets, a la
CONFIG_GENERIC_BUG_RELATIVE_POINTERS, thus saving 16 bytes per
pr_debug site (and thus exactly making up for the extra space used by
the introduction of jump labels in 9049fc74). I stumbled on a few
things that are probably worth fixing regardless of whether the latter
half of this series is deemed worthwhile.
Patch relationships: 1-2, 3-4, 5-6 and 15-16 can be applied
individually, though 2, 4 and 6 probably makes most sense in the
context of the final goal of the series.
7-12 I believe make sense on their own. Patch 13 again only makes
sense if we go all the way, and 14 and 17 depend on 13.
18-21 are more preparatory patches, and finally 22 switch over x86-64
to use CONFIG_DYNAMIC_DEBUG_RELATIVE_POINTERS. I've tested that the
end result boots under virtme and that the dynamic_debug control file
has the expected contents.
Rasmus Villemoes (22):
linux/device.h: use DYNAMIC_DEBUG_BRANCH in dev_dbg_ratelimited
linux/device.h: use unique identifier for each struct _ddebug
linux/net.h: use DYNAMIC_DEBUG_BRANCH in net_dbg_ratelimited
linux/net.h: use unique identifier for each struct _ddebug
linux/printk.h: use DYNAMIC_DEBUG_BRANCH in pr_debug_ratelimited
linux/printk.h: use unique identifier for each struct _ddebug
dynamic_debug: consolidate DEFINE_DYNAMIC_DEBUG_METADATA definitions
dynamic_debug: don't duplicate modname in ddebug_add_module
dynamic_debug: use pointer comparison in ddebug_remove_module
dynamic_debug: remove unused EXPORT_SYMBOLs
dynamic_debug: move pr_err from module.c to ddebug_add_module
dynamic_debug: add static inline stub for ddebug_add_module
dynamic_debug: refactor dynamic_pr_debug and friends
btrfs: implement btrfs_debug* in terms of helper macro
ACPI: use proper DYNAMIC_DEBUG_BRANCH macro
ACPI: remove unused __acpi_handle_debug macro
ACPI: implement acpi_handle_debug in terms of _dynamic_func_call
dynamic_debug: introduce accessors for string members of struct
_ddebug
dynamic_debug: drop use of bitfields in struct _ddebug
dynamic_debug: introduce CONFIG_DYNAMIC_DEBUG_RELATIVE_POINTERS
x86: jump_label: introduce ASM_STATIC_KEY_INIT_{TRUE,FALSE}
x86_64: use relative pointers with dynamic debug
arch/x86/Kconfig | 1 +
arch/x86/include/asm/dynamic_debug.h | 35 +++++++++
arch/x86/include/asm/jump_label.h | 18 +++++
fs/btrfs/ctree.h | 34 +++------
include/linux/acpi.h | 11 +--
include/linux/device.h | 6 +-
include/linux/dynamic_debug.h | 126 +++++++++++++++++++--------------
include/linux/jump_label.h | 2 +
include/linux/net.h | 6 +-
include/linux/printk.h | 6 +-
kernel/module.c | 6 +-
lib/Kconfig.debug | 3 +
lib/dynamic_debug.c | 133 ++++++++++++++++++++++++-----------
13 files changed, 251 insertions(+), 136 deletions(-)
create mode 100644 arch/x86/include/asm/dynamic_debug.h
--
2.16.4
^ permalink raw reply
* [PATCH 04/22] linux/net.h: use unique identifier for each struct _ddebug
From: Rasmus Villemoes @ 2018-09-19 22:04 UTC (permalink / raw)
To: Jason Baron, Andrew Morton; +Cc: linux-kernel, Rasmus Villemoes, netdev
In-Reply-To: <20180919220444.23190-1-linux@rasmusvillemoes.dk>
Changes on x86-64 later in this series require that all struct _ddebug
descriptors in a translation unit uses distinct identifiers. Realize
that for net_dbg_ratelimited by generating such an identifier via
__UNIQUE_ID and pass that to an extra level of macros.
No functional change.
Cc: netdev@vger.kernel.org
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
include/linux/net.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/net.h b/include/linux/net.h
index 651fca72286c..397243a25f56 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -260,7 +260,7 @@ do { \
#define net_info_ratelimited(fmt, ...) \
net_ratelimited_function(pr_info, fmt, ##__VA_ARGS__)
#if defined(CONFIG_DYNAMIC_DEBUG)
-#define net_dbg_ratelimited(fmt, ...) \
+#define _net_dbg_ratelimited(descriptor, fmt, ...) \
do { \
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
if (DYNAMIC_DEBUG_BRANCH(descriptor) && \
@@ -268,6 +268,8 @@ do { \
__dynamic_pr_debug(&descriptor, pr_fmt(fmt), \
##__VA_ARGS__); \
} while (0)
+#define net_dbg_ratelimited(fmt, ...) \
+ _net_dbg_ratelimited(__UNIQUE_ID(ddebug), fmt, ##__VA_ARGS__)
#elif defined(DEBUG)
#define net_dbg_ratelimited(fmt, ...) \
net_ratelimited_function(pr_debug, fmt, ##__VA_ARGS__)
--
2.16.4
^ permalink raw reply related
* Re: [PATCH net-next v2 05/10] net: sched: use Qdisc rcu API instead of relying on rtnl lock
From: Cong Wang @ 2018-09-19 22:04 UTC (permalink / raw)
To: Vlad Buslov
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller, Stephen Hemminger, Kirill Tkhai, Nicolas Dichtel,
Greg KH, mark.rutland, Leon Romanovsky, Paul E. McKenney,
Florian Westphal, David Ahern, christian, lucien xin,
Jakub Kicinski, Jiri Benc
In-Reply-To: <1537168660-24032-6-git-send-email-vladbu@mellanox.com>
On Mon, Sep 17, 2018 at 12:19 AM Vlad Buslov <vladbu@mellanox.com> wrote:
> +static void tcf_qdisc_put(struct Qdisc *q, bool rtnl_held)
> +{
> + if (!q)
> + return;
> +
> + if (rtnl_held)
> + qdisc_put(q);
> + else
> + qdisc_put_unlocked(q);
> +}
This is very ugly. You should know whether RTNL is held or
not when calling it.
What's more, all of your code passes true, so why do you
need a parameter for rtnl_held?
^ permalink raw reply
* Re: [PATCH net-next v2 08/10] net: sched: protect block idr with spinlock
From: Cong Wang @ 2018-09-19 22:09 UTC (permalink / raw)
To: Vlad Buslov
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller, Stephen Hemminger, Kirill Tkhai, Nicolas Dichtel,
Greg KH, mark.rutland, Leon Romanovsky, Paul E. McKenney,
Florian Westphal, David Ahern, christian, lucien xin,
Jakub Kicinski, Jiri Benc
In-Reply-To: <1537168660-24032-9-git-send-email-vladbu@mellanox.com>
On Mon, Sep 17, 2018 at 12:19 AM Vlad Buslov <vladbu@mellanox.com> wrote:
> @@ -482,16 +483,25 @@ static int tcf_block_insert(struct tcf_block *block, struct net *net,
> struct netlink_ext_ack *extack)
> {
> struct tcf_net *tn = net_generic(net, tcf_net_id);
> + int err;
> +
> + idr_preload(GFP_KERNEL);
> + spin_lock(&tn->idr_lock);
> + err = idr_alloc_u32(&tn->idr, block, &block->index, block->index,
> + GFP_NOWAIT);
Why GFP_NOWAIT rather than GFP_ATOMIC here?
^ permalink raw reply
* Re: [RESEND PATCH 0/5] net: Use FIELD_SIZEOF directly instead of reimplementing its function
From: David Miller @ 2018-09-20 3:58 UTC (permalink / raw)
To: zhongjiang
Cc: ubraun, jwi, jhs, xiyou.wangcong, Ariel.Elior, everest-linux-l2,
grygorii.strashko, netdev, linux-kernel, borntraeger
In-Reply-To: <1537356734-51676-1-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com>
Date: Wed, 19 Sep 2018 19:32:09 +0800
> The issue is detected with the help of Coccinelle.
Series applied, thank you.
^ permalink raw reply
* [PATCH] isdn/hisax: Remove unnecessary parenthesis
From: Nathan Chancellor @ 2018-09-20 4:05 UTC (permalink / raw)
To: Karsten Keil, David S. Miller
Cc: netdev, linux-kernel, Nick Desaulniers, Nathan Chancellor
Clang warns when more than one set of parentheses are used for single
conditional statements:
drivers/isdn/hisax/w6692.c:627:30: warning: equality comparison with
extraneous parentheses [-Wparentheses-equality]
if ((cs->dc.w6692.ph_state == W_L1IND_DRD)) {
~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
drivers/isdn/hisax/w6692.c:627:30: note: remove extraneous parentheses
around the comparison to silence this warning
if ((cs->dc.w6692.ph_state == W_L1IND_DRD)) {
~ ^ ~
drivers/isdn/hisax/w6692.c:627:30: note: use '=' to turn this equality
comparison into an assignment
if ((cs->dc.w6692.ph_state == W_L1IND_DRD)) {
^~
=
1 warning generated.
Remove the parentheses to silence this warning.
Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/isdn/hisax/w6692.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/isdn/hisax/w6692.c b/drivers/isdn/hisax/w6692.c
index c4be1644f5bb..bb8e4b7e34ea 100644
--- a/drivers/isdn/hisax/w6692.c
+++ b/drivers/isdn/hisax/w6692.c
@@ -624,7 +624,7 @@ W6692_l1hw(struct PStack *st, int pr, void *arg)
break;
case (HW_RESET | REQUEST):
spin_lock_irqsave(&cs->lock, flags);
- if ((cs->dc.w6692.ph_state == W_L1IND_DRD)) {
+ if (cs->dc.w6692.ph_state == W_L1IND_DRD) {
ph_command(cs, W_L1CMD_ECK);
spin_unlock_irqrestore(&cs->lock, flags);
} else {
--
2.19.0
^ permalink raw reply related
* Re: [PATCH net-next 00/12] net: mvpp2: improve the interrupt usage
From: David Miller @ 2018-09-20 4:13 UTC (permalink / raw)
To: antoine.tenart
Cc: netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
gregory.clement, miquel.raynal, nadavh, stefanc, ymarkman, mw
In-Reply-To: <20180919092711.22296-1-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Wed, 19 Sep 2018 11:26:59 +0200
> This series aims to improve the interrupts descriptions and usage in the
> Marvell PPv2 driver.
>
> - Before the series interrupts were named after their s/w usage,
> which in fact can be configured. The series rename all those
> interrupts and add a description of the ones left over.
>
> - In PPv2 the interrupts are mapped to vectors. Those vectors were
> directly mapped to a given CPU, and per-cpu accesses were done. While
> this worked on our cases, the registers accesses mapped to the vectors
> are not actually linked to a given CPU. They instead are linked to
> what is called a "s/w thread". The series modify this so that the s/w
> threads are used instead of the CPU numbers, by adding an indirection.
> This means we now can have systems with more CPUs than s/w threads.
>
> This is based on today's net-next, and was tested on various boards
> using both versions of the PPv2 engine.
>
> Two more patches will be coming, to update the device trees describing a
> PPv2 engine. The patches are ready, but will go through a different
> tree. I'll send them once this series will be accepted. This is not an
> issue as the PPv2 driver keeps the dt bindings backward compatibility.
Series applied, thanks Antoine.
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: phy: phylink: ensure the carrier is off when starting phylink
From: David Miller @ 2018-09-20 4:15 UTC (permalink / raw)
To: antoine.tenart
Cc: linux, andrew, f.fainelli, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, ymarkman, mw
In-Reply-To: <20180919093933.24411-1-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Wed, 19 Sep 2018 11:39:30 +0200
> Hi Russell,
>
> Following the discussion we had regarding the phylink issue related to
> the carrier link state not being off when starting phylink, I sent a fix
> patch a few days ago for the PPv2 driver:
> https://lkml.org/lkml/2018/9/14/633
>
> The idea was to send a patch which could go to the stable branches, but
> a better solution would be to directly call netif_carrier_off() from
> within phylink_start(). This is the aim of this series.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next] net: marvell: fix return type of ndo_start_xmit function
From: David Miller @ 2018-09-20 4:19 UTC (permalink / raw)
To: yuehaibing
Cc: thomas.petazzoni, antoine.tenart, maxime.chevallier, ymarkman,
stefanc, keescook, allen.lkml, linux-kernel, netdev
In-Reply-To: <20180919101926.25036-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Wed, 19 Sep 2018 18:19:26 +0800
> 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.
>
> Found by coccinelle.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: xilinx: fix return type of ndo_start_xmit function
From: David Miller @ 2018-09-20 4:19 UTC (permalink / raw)
To: yuehaibing
Cc: michal.simek, anirudh, John.Linn, linux-kernel, netdev,
linux-arm-kernel
In-Reply-To: <20180919103240.27708-2-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Wed, 19 Sep 2018 18:32:40 +0800
> 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.
>
> Found by coccinelle.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: broadcom: fix return type of ndo_start_xmit function
From: David Miller @ 2018-09-20 4:19 UTC (permalink / raw)
To: yuehaibing
Cc: f.fainelli, bcm-kernel-feedback-list, jonas.gorski, andrew,
himanshujha199640, keescook, linux-kernel, netdev,
linux-arm-kernel
In-Reply-To: <20180919104512.27068-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Wed, 19 Sep 2018 18:45:12 +0800
> 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.
>
> Found by coccinelle.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: amd: fix return type of ndo_start_xmit function
From: David Miller @ 2018-09-20 4:19 UTC (permalink / raw)
To: yuehaibing
Cc: linux, thomas.lendacky, keescook, allen.lkml, linux-kernel,
netdev, linux-arm-kernel
In-Reply-To: <20180919105017.15304-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Wed, 19 Sep 2018 18:50:17 +0800
> 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.
>
> Found by coccinelle.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: sun: fix return type of ndo_start_xmit function
From: David Miller @ 2018-09-20 4:19 UTC (permalink / raw)
To: yuehaibing
Cc: shannon.nelson, alexander.h.duyck, yanjun.zhu, jeffrey.t.kirsher,
tklauser, linux-kernel, netdev
In-Reply-To: <20180919112132.26616-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Wed, 19 Sep 2018 19:21:32 +0800
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, but the implementation in this
> driver returns an 'int'.
>
> Found by coccinelle.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* [PATCH bpf-next 2/3] bpf: emit RECORD_MMAP events for bpf prog load/unload
From: Alexei Starovoitov @ 2018-09-19 22:39 UTC (permalink / raw)
To: David S . Miller; +Cc: daniel, peterz, acme, netdev, kernel-team
In-Reply-To: <20180919223935.999270-1-ast@kernel.org>
use perf_event_mmap_bpf_prog() helper to notify user space
about JITed bpf programs.
Use RECORD_MMAP perf event to tell user space where JITed bpf program was loaded.
Use empty program name as unload indication.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
---
kernel/bpf/core.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 3f5bf1af0826..ddf11fdafd36 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -384,7 +384,7 @@ bpf_get_prog_addr_region(const struct bpf_prog *prog,
*symbol_end = addr + hdr->pages * PAGE_SIZE;
}
-static void bpf_get_prog_name(const struct bpf_prog *prog, char *sym)
+static char *bpf_get_prog_name(const struct bpf_prog *prog, char *sym)
{
const char *end = sym + KSYM_NAME_LEN;
@@ -402,9 +402,10 @@ static void bpf_get_prog_name(const struct bpf_prog *prog, char *sym)
sym += snprintf(sym, KSYM_NAME_LEN, "bpf_prog_");
sym = bin2hex(sym, prog->tag, sizeof(prog->tag));
if (prog->aux->name[0])
- snprintf(sym, (size_t)(end - sym), "_%s", prog->aux->name);
+ sym += snprintf(sym, (size_t)(end - sym), "_%s", prog->aux->name);
else
*sym = 0;
+ return sym;
}
static __always_inline unsigned long
@@ -480,23 +481,40 @@ static bool bpf_prog_kallsyms_verify_off(const struct bpf_prog *fp)
void bpf_prog_kallsyms_add(struct bpf_prog *fp)
{
+ unsigned long symbol_start, symbol_end;
+ char buf[KSYM_NAME_LEN], *sym;
+
if (!bpf_prog_kallsyms_candidate(fp) ||
!capable(CAP_SYS_ADMIN))
return;
+ bpf_get_prog_addr_region(fp, &symbol_start, &symbol_end);
+ sym = bpf_get_prog_name(fp, buf);
+ sym++; /* sym - buf is the length of the name including trailing 0 */
+ while (!IS_ALIGNED(sym - buf, sizeof(u64)))
+ *sym++ = 0;
spin_lock_bh(&bpf_lock);
bpf_prog_ksym_node_add(fp->aux);
spin_unlock_bh(&bpf_lock);
+ perf_event_mmap_bpf_prog(symbol_start, symbol_end - symbol_start,
+ buf, sym - buf);
}
void bpf_prog_kallsyms_del(struct bpf_prog *fp)
{
+ unsigned long symbol_start, symbol_end;
+ /* mmap_record.filename cannot be NULL and has to be u64 aligned */
+ char buf[sizeof(u64)] = {};
+
if (!bpf_prog_kallsyms_candidate(fp))
return;
spin_lock_bh(&bpf_lock);
bpf_prog_ksym_node_del(fp->aux);
spin_unlock_bh(&bpf_lock);
+ bpf_get_prog_addr_region(fp, &symbol_start, &symbol_end);
+ perf_event_mmap_bpf_prog(symbol_start, symbol_end - symbol_start,
+ buf, sizeof(buf));
}
static struct bpf_prog *bpf_prog_kallsyms_find(unsigned long addr)
--
2.17.1
^ permalink raw reply related
* [PATCH perf 3/3] tools/perf: recognize and process RECORD_MMAP events for bpf progs
From: Alexei Starovoitov @ 2018-09-19 22:39 UTC (permalink / raw)
To: David S . Miller; +Cc: daniel, peterz, acme, netdev, kernel-team
In-Reply-To: <20180919223935.999270-1-ast@kernel.org>
Recognize JITed bpf prog load/unload events.
Add/remove kernel symbols accordingly.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
---
tools/perf/util/machine.c | 27 +++++++++++++++++++++++++++
tools/perf/util/symbol.c | 13 +++++++++++++
tools/perf/util/symbol.h | 1 +
3 files changed, 41 insertions(+)
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index c4acd2001db0..ae4f8a0fdc7e 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -25,6 +25,7 @@
#include "sane_ctype.h"
#include <symbol/kallsyms.h>
#include <linux/mman.h>
+#include <linux/magic.h>
static void __machine__remove_thread(struct machine *machine, struct thread *th, bool lock);
@@ -1460,6 +1461,32 @@ static int machine__process_kernel_mmap_event(struct machine *machine,
enum dso_kernel_type kernel_type;
bool is_kernel_mmap;
+ /* process JITed bpf programs load/unload events */
+ if (event->mmap.pid == ~0u && event->mmap.tid == BPF_FS_MAGIC) {
+ struct symbol *sym;
+ u64 ip;
+
+ map = map_groups__find(&machine->kmaps, event->mmap.start);
+ if (!map) {
+ pr_err("No kernel map for IP %lx\n", event->mmap.start);
+ goto out_problem;
+ }
+ ip = event->mmap.start - map->start + map->pgoff;
+ if (event->mmap.filename[0]) {
+ sym = symbol__new(ip, event->mmap.len, 0, 0,
+ event->mmap.filename);
+ dso__insert_symbol(map->dso, sym);
+ } else {
+ if (symbols__erase(&map->dso->symbols, ip)) {
+ pr_err("No bpf prog at IP %lx/%lx\n",
+ event->mmap.start, ip);
+ goto out_problem;
+ }
+ dso__reset_find_symbol_cache(map->dso);
+ }
+ return 0;
+ }
+
/* If we have maps from kcore then we do not need or want any others */
if (machine__uses_kcore(machine))
return 0;
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index d188b7588152..0653f313661d 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -353,6 +353,19 @@ static struct symbol *symbols__find(struct rb_root *symbols, u64 ip)
return NULL;
}
+int symbols__erase(struct rb_root *symbols, u64 ip)
+{
+ struct symbol *s;
+
+ s = symbols__find(symbols, ip);
+ if (!s)
+ return -ENOENT;
+
+ rb_erase(&s->rb_node, symbols);
+ symbol__delete(s);
+ return 0;
+}
+
static struct symbol *symbols__first(struct rb_root *symbols)
{
struct rb_node *n = rb_first(symbols);
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index f25fae4b5743..92ef31953d9a 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -310,6 +310,7 @@ char *dso__demangle_sym(struct dso *dso, int kmodule, const char *elf_name);
void __symbols__insert(struct rb_root *symbols, struct symbol *sym, bool kernel);
void symbols__insert(struct rb_root *symbols, struct symbol *sym);
+int symbols__erase(struct rb_root *symbols, u64 ip);
void symbols__fixup_duplicate(struct rb_root *symbols);
void symbols__fixup_end(struct rb_root *symbols);
void map_groups__fixup_end(struct map_groups *mg);
--
2.17.1
^ 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