* [PATCH net-next] net: bridge: Fix improper taking over HW learned FDB
From: Arkadi Sharshevsky @ 2017-04-27 8:08 UTC (permalink / raw)
To: netdev
Cc: davem, stephen, bridge, Arkadi Sharshevsky, Ido Schimmel,
Nikolay Aleksandrov
Commit 7e26bf45e4cb ("net: bridge: allow SW learn to take over HW fdb
entries") added the ability to "take over an entry which was previously
learned via HW when it shows up from a SW port".
However, if an entry was learned via HW and then a control packet
(e.g., ARP request) was trapped to the CPU, the bridge driver will
update the entry and remove the externally learned flag, although the
entry is still present in HW. Instead, only clear the externally learned
flag in case of roaming.
Fixes: 7e26bf45e4cb ("net: bridge: allow SW learn to take over HW fdb entries")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Arkadi Sharashevsky <arkadis@mellanox.com>
Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
net/bridge/br_fdb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 5a40a87..ab0c7cc 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -589,14 +589,14 @@ void br_fdb_update(struct net_bridge *br, struct net_bridge_port *source,
if (unlikely(source != fdb->dst)) {
fdb->dst = source;
fdb_modified = true;
+ /* Take over HW learned entry */
+ if (unlikely(fdb->added_by_external_learn))
+ fdb->added_by_external_learn = 0;
}
if (now != fdb->updated)
fdb->updated = now;
if (unlikely(added_by_user))
fdb->added_by_user = 1;
- /* Take over HW learned entry */
- if (unlikely(fdb->added_by_external_learn))
- fdb->added_by_external_learn = 0;
if (unlikely(fdb_modified))
fdb_notify(br, fdb, RTM_NEWNEIGH);
}
--
2.4.11
^ permalink raw reply related
* pull-request: can-next 2017-04-25
From: Marc Kleine-Budde @ 2017-04-27 7:54 UTC (permalink / raw)
To: netdev; +Cc: David Miller, kernel@pengutronix.de, linux-can@vger.kernel.org
[-- Attachment #1.1: Type: text/plain, Size: 1318 bytes --]
Hello David,
this is a pull request of 1 patch for net-next/master.
This patch by Oliver Hartkopp fixes the build of the broad cast manager
with CONFIG_PROC_FS disabled.
regards,
Marc
---
The following changes since commit b1513c35317c106a1588f3ab32f6888f0e2afd71:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-04-26 22:39:08 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git tags/linux-can-next-for-4.12-20170427
for you to fetch changes up to c2701b370e6b4d0022043691b5ac7adad015e4fc:
can: fix CAN BCM build with CONFIG_PROC_FS disabled (2017-04-27 09:34:13 +0200)
----------------------------------------------------------------
linux-can-next-for-4.12-20170427
----------------------------------------------------------------
Oliver Hartkopp (1):
can: fix CAN BCM build with CONFIG_PROC_FS disabled
net/can/bcm.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] can: fix CAN BCM build with CONFIG_PROC_FS disabled
From: Marc Kleine-Budde @ 2017-04-27 7:52 UTC (permalink / raw)
To: Oliver Hartkopp, linux-can, davem, rdunlap; +Cc: netdev
In-Reply-To: <20170426181434.9635-1-socketcan@hartkopp.net>
[-- Attachment #1.1: Type: text/plain, Size: 1119 bytes --]
On 04/26/2017 08:14 PM, Oliver Hartkopp wrote:
> The introduced namespace support moved the BCM variables for procfs into a
> per-net data structure. This leads to a build failure with disabled procfs:
>
> on x86_64:
>
> when CONFIG_PROC_FS is not enabled:
>
> ../net/can/bcm.c:1541:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
> ../net/can/bcm.c:1601:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
> ../net/can/bcm.c:1696:11: error: 'struct netns_can' has no member named 'bcmproc_dir'
> ../net/can/bcm.c:1707:15: error: 'struct netns_can' has no member named 'bcmproc_dir'
>
> http://marc.info/?l=linux-can&m=149321842526524&w=2
>
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Applied to can-next.
Thanks,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 4/6] bpf: track if the bpf program was loaded with SYS_ADMIN capabilities
From: kbuild test robot @ 2017-04-27 7:27 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: kbuild-all, netdev, ast, daniel, jbenc, aconole
In-Reply-To: <20170426182419.14574-5-hannes@stressinduktion.org>
[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]
Hi Hannes,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Hannes-Frederic-Sowa/bpf-list-all-loaded-ebpf-programs-in-proc-bpf-programs/20170427-090839
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
lib/test_bpf.c: In function 'generate_filter':
>> lib/test_bpf.c:5613:8: error: too few arguments to function 'bpf_prog_alloc'
fp = bpf_prog_alloc(bpf_prog_size(flen), 0);
^~~~~~~~~~~~~~
In file included from lib/test_bpf.c:20:0:
include/linux/filter.h:619:18: note: declared here
struct bpf_prog *bpf_prog_alloc(unsigned int size, gfp_t gfp_extra_flags,
^~~~~~~~~~~~~~
vim +/bpf_prog_alloc +5613 lib/test_bpf.c
10f18e0b Daniel Borkmann 2014-05-23 5607 *err, fprog.len);
10f18e0b Daniel Borkmann 2014-05-23 5608 return NULL;
64a8946b Alexei Starovoitov 2014-05-08 5609 }
10f18e0b Daniel Borkmann 2014-05-23 5610 break;
10f18e0b Daniel Borkmann 2014-05-23 5611
10f18e0b Daniel Borkmann 2014-05-23 5612 case INTERNAL:
60a3b225 Daniel Borkmann 2014-09-02 @5613 fp = bpf_prog_alloc(bpf_prog_size(flen), 0);
10f18e0b Daniel Borkmann 2014-05-23 5614 if (fp == NULL) {
10f18e0b Daniel Borkmann 2014-05-23 5615 pr_cont("UNEXPECTED_FAIL no memory left\n");
10f18e0b Daniel Borkmann 2014-05-23 5616 *err = -ENOMEM;
:::::: The code at line 5613 was first introduced by commit
:::::: 60a3b2253c413cf601783b070507d7dd6620c954 net: bpf: make eBPF interpreter images read-only
:::::: TO: Daniel Borkmann <dborkman@redhat.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 38891 bytes --]
^ permalink raw reply
* Re: [PATCH net] xfrm: do the garbage collection after flushing policy
From: Steffen Klassert @ 2017-04-27 7:27 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem, Herbert Xu, fw
In-Reply-To: <b55e4ad516bc1be8fe70f68de028a4b32055e43f.1493019219.git.lucien.xin@gmail.com>
On Mon, Apr 24, 2017 at 03:33:39PM +0800, Xin Long wrote:
> Now xfrm garbage collection can be triggered by 'ip xfrm policy del'.
> These is no reason not to do it after flushing policies, especially
> considering that 'garbage collection deferred' is only triggered
> when it reaches gc_thresh.
>
> It's no good that the policy is gone but the xdst still hold there.
> The worse thing is that xdst->route/orig_dst is also hold and can
> not be released even if the orig_dst is already expired.
>
> This patch is to do the garbage collection if there is any policy
> removed in xfrm_policy_flush.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied to the ipsec tree, thanks!
^ permalink raw reply
* Re: [RFC net-next 2/2] bpf: Test for bpf_prog ID and BPF_PROG_GET_NEXT_ID
From: Alexander Alemayhu @ 2017-04-27 7:23 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: netdev, Daniel Borkmann, Hannes Frederic Sowa, Alexei Starovoitov,
kernel-team
In-Reply-To: <20170427062449.80290-3-kafai@fb.com>
On Wed, Apr 26, 2017 at 11:24:49PM -0700, Martin KaFai Lau wrote:
> Add test to exercise the bpf_prog id generation
> and iteration.
>
Could test_prog_id be a function in tools/testing/selftests/bpf/test_progs.c
instead? bpf_prog_load is already available there.
--
Mit freundlichen Grüßen
Alexander Alemayhu
^ permalink raw reply
* [PATCH net-next v2] net: ipv6: make sure multicast packets are not forwarded beyond the different scopes
From: Donatas Abraitis @ 2017-04-27 7:12 UTC (permalink / raw)
To: davem; +Cc: netdev, stable, donatas.abraitis
RFC4291 2.7 Routers must not forward any multicast packets
beyond of the scope indicated by the scop field in the
destination multicast address.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
---
net/ipv6/ip6_input.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 9ee208a..cbe5eef 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -165,6 +165,14 @@ int ipv6_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt
IPV6_ADDR_MC_SCOPE(&hdr->daddr) == 0)
goto err;
+ /* RFC4291 2.7
+ * Routers must not forward any multicast packets beyond of the scope
+ * indicated by the scop field in the destination multicast address.
+ */
+ if (ipv6_addr_is_multicast(&hdr->daddr) &&
+ IPV6_ADDR_MC_SCOPE(&hdr->daddr) != IPV6_ADDR_MC_SCOPE(&hdr->saddr))
+ goto err;
+
/*
* RFC4291 2.7
* Multicast addresses must not be used as source addresses in IPv6
--
2.10.0
^ permalink raw reply related
* Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions
From: Christoph Hellwig @ 2017-04-27 6:53 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: Christoph Hellwig, linux-kernel, linux-crypto, linux-media,
dri-devel, intel-gfx, linux-raid, linux-mmc, linux-nvdimm,
linux-scsi, open-iscsi, megaraidlinux.pdl, sparmaintainer, devel,
target-devel, netdev, linux-rdma, dm-devel, Martin K. Petersen,
James E.J. Bottomley, Jens Axboe, Greg Kroah-Hartman,
Dan Williams, Ross Zwisler
In-Reply-To: <4736d44e-bbcf-5d59-a1a9-317d0f4da847@deltatee.com>
On Wed, Apr 26, 2017 at 12:11:33PM -0600, Logan Gunthorpe wrote:
> Ok, well for starters I think you are mistaken about kmap being able to
> fail. I'm having a hard time finding many users of that function that
> bother to check for an error when calling it.
A quick audit of the arch code shows you're right - kmap can't fail
anywhere anymore.
> The main difficulty we
> have now is that neither of those functions are expected to fail and we
> need them to be able to in cases where the page doesn't map to system
> RAM. This patch series is trying to address it for users of scatterlist.
> I'm certainly open to other suggestions.
I think you'll need to follow the existing kmap semantics and never
fail the iomem version either. Otherwise you'll have a special case
that's almost never used that has a different error path.
> There are a fair number of cases in the kernel that do something like:
>
> if (something)
> x = kmap(page);
> else
> x = kmap_atomic(page);
> ...
> if (something)
> kunmap(page)
> else
> kunmap_atomic(x)
>
> Which just seems cumbersome to me.
Passing a different flag based on something isn't really much better.
> In any case, if you can accept an sg_kmap and sg_kmap_atomic api just
> say so and I'll make the change. But I'll still need a flags variable
> for SG_MAP_MUST_NOT_FAIL to support legacy cases that have no fail path
> and both of those functions will need to be pretty nearly replicas of
> each other.
Again, wrong way. Suddenly making things fail for your special case
that normally don't fail is a receipe for bugs.
^ permalink raw reply
* Re: [PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it
From: Christoph Hellwig @ 2017-04-27 6:47 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Christoph Hellwig, Byczkowski, Jakub, Bjorn Helgaas,
Cabiddu, Giovanni, Benedetto, Salvatore, Marciniszyn, Mike,
Dalessandro, Dennis, Derek Chickles, Satanand Burla,
Felix Manlunas, Raghu Vatsavayi, Kirsher, Jeffrey T,
linux-pci@vger.kernel.org, qat-linux,
linux-crypto@vger.kernel.org,
"linux-rdma@vger.kernel.org" <l
In-Reply-To: <20170425193955.GC29024@bhelgaas-glaptop.roam.corp.google.com>
On Tue, Apr 25, 2017 at 02:39:55PM -0500, Bjorn Helgaas wrote:
> This still leaves these:
>
> [PATCH 4/7] ixgbe: use pcie_flr instead of duplicating it
> [PATCH 6/7] crypto: qat: use pcie_flr instead of duplicating it
> [PATCH 7/7] liquidio: use pcie_flr instead of duplicating it
>
> I haven't seen any response to 4 and 6. Felix reported an unused
> variable in 7. Let me know if you'd like me to do anything with
> these.
Now that Jeff ACKed 4 it might be worth to add it to the pci tree last
minute. I'll resend liquidio and qat to the respective maintainers for
the next merge window.
^ permalink raw reply
* RE: [iproute2] iplink: add support for IFLA_CARRIER attribute
From: 张胜举 @ 2017-04-27 6:35 UTC (permalink / raw)
To: 'Stephen Hemminger'; +Cc: netdev
In-Reply-To: <20170426080732.51f56b8c@xeon-e3>
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Wednesday, April 26, 2017 11:08 PM
> To: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
> Cc: netdev@vger.kernel.org
> Subject: Re: [iproute2] iplink: add support for IFLA_CARRIER attribute
>
> On Wed, 26 Apr 2017 15:08:39 +0800
> Zhang Shengju <zhangshengju@cmss.chinamobile.com> wrote:
>
> > Add support to set IFLA_CARRIER attribute.
> >
> > Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
> > ---
> > ip/iplink.c | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/ip/iplink.c b/ip/iplink.c index 866ad72..263bfdd 100644
> > --- a/ip/iplink.c
> > +++ b/ip/iplink.c
> > @@ -72,6 +72,7 @@ void iplink_usage(void)
> > " [ allmulticast { on | off } ]\n"
> > " [ promisc { on | off } ]\n"
> > " [ trailers { on | off } ]\n"
> > + " [ carrier { on | off } ]\n"
> > " [ txqueuelen PACKETS ]\n"
> > " [ name NEWNAME ]\n"
> > " [ address LLADDR ]\n"
> > @@ -673,6 +674,17 @@ int iplink_parse(int argc, char **argv, struct
> iplink_req *req,
> > req->i.ifi_flags |= IFF_NOARP;
> > else
> > return on_off("arp", *argv);
> > + } else if (strcmp(*argv, "carrier") == 0) {
> > + int carrier;
> > + NEXT_ARG();
> > + if (strcmp(*argv, "on") == 0)
> > + carrier = 1;
> > + else if (strcmp(*argv, "off") == 0)
> > + carrier = 0;
> > + else
> > + return on_off("carrier", *argv);
> > +
> > + addattr8(&req->n, sizeof(*req), IFLA_CARRIER,
> carrier);
> > } else if (strcmp(*argv, "vf") == 0) {
> > struct rtattr *vflist;
> >
>
> The general policy of ip link command is all options should be invertable.
Yes, so I add 'on' and 'off' subcommand to make sure that it can be
invertable.
> There are some VPN's that use this to save and restore state. So if you
add
> an option to set something there should be similar output under the
detailed
> show command.
Currently, "show command" already can display 'carrier' status. Such as:
dummy0: <NO-CARRIER...>
^ permalink raw reply
* Re: [PATCH net-next v8 2/3] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: Jiri Pirko @ 2017-04-27 6:30 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: davem, xiyou.wangcong, eric.dumazet, netdev, Simon Horman,
Benjamin LaHaise
In-Reply-To: <b32fb2fb-ffb1-aee8-5f1d-1f1e3c82b347@mojatatu.com>
Wed, Apr 26, 2017 at 10:07:08PM CEST, jhs@mojatatu.com wrote:
>On 17-04-26 09:56 AM, Jiri Pirko wrote:
>> Wed, Apr 26, 2017 at 03:14:38PM CEST, jhs@mojatatu.com wrote:
>> > On 17-04-26 08:08 AM, Jiri Pirko wrote:
>
>[..]
>
[...]
>
>> > Again: You are looking at this from a manageability point of view which
>> > is useful but not the only input into a design. If i can squeeze more
>> > data without killing usability - I am all for it. It just doesnt
>> > compute that it is ok to use a flag per attribute because it looks
>> > beautiful.
>>
>> Hmm. Now that I'm thinking about it, why don't we have NLA_FLAGS with
>> couple of helpers around it? It will be obvious what the attr is, all
>> kernel code would use the same helpers. Would be nice.
>>
>
>I think to have flags at that level is useful but it
>is a different hierarchy level. I am not sure the
>"actions dump large messages" is a fit for that level.
Jamal, the idea is to have exactly what you want to have. Only does not
use NLA_U32 attr for that but a special attr NLA_FLAGS which would have
well defined semantics and set of helpers to work with and enforce it.
Then, this could be easily reused in other subsystem that uses netlink
^ permalink raw reply
* [RFC net-next 1/2] bpf: Introduce bpf_prog ID
From: Martin KaFai Lau @ 2017-04-27 6:24 UTC (permalink / raw)
To: netdev
Cc: Daniel Borkmann, Hannes Frederic Sowa, Alexei Starovoitov,
kernel-team
In-Reply-To: <20170427062449.80290-1-kafai@fb.com>
The ID is generated by the existing idr_alloc_cyclic().
This patch also adds BPF_PROG_GET_NEXT_ID to allow userspace to iterate
all bpf_prog id(s). The API is trying to be consistent with the
existing BPF_MAP_GET_NEXT_KEY.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
---
include/linux/filter.h | 1 +
include/uapi/linux/bpf.h | 6 ++++++
kernel/bpf/syscall.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 9a7786db14fa..6eeeb83c4013 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -417,6 +417,7 @@ struct bpf_prog {
kmemcheck_bitfield_end(meta);
enum bpf_prog_type type; /* Type of BPF program */
u32 len; /* Number of filter blocks */
+ u32 id;
u8 tag[BPF_TAG_SIZE];
struct bpf_prog_aux *aux; /* Auxiliary fields */
struct sock_fprog_kern *orig_prog; /* Original BPF program */
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index e553529929f6..270f501c5597 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -82,6 +82,7 @@ enum bpf_cmd {
BPF_PROG_ATTACH,
BPF_PROG_DETACH,
BPF_PROG_TEST_RUN,
+ BPF_PROG_GET_NEXT_ID,
};
enum bpf_map_type {
@@ -201,6 +202,11 @@ union bpf_attr {
__u32 repeat;
__u32 duration;
} test;
+
+ struct { /* anonymous struct used by BPF_PROG_GET_NEXT_ID */
+ __u32 start_id;
+ __aligned_u64 next_id;
+ };
} __attribute__((aligned(8)));
/* BPF helper function descriptions:
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 13642c73dca0..6a654e17bd3c 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -22,8 +22,11 @@
#include <linux/filter.h>
#include <linux/version.h>
#include <linux/kernel.h>
+#include <linux/idr.h>
DEFINE_PER_CPU(int, bpf_prog_active);
+DEFINE_IDR(prog_idr);
+DEFINE_SPINLOCK(prog_idr_lock);
int sysctl_unprivileged_bpf_disabled __read_mostly;
@@ -663,6 +666,9 @@ static void __bpf_prog_put_rcu(struct rcu_head *rcu)
void bpf_prog_put(struct bpf_prog *prog)
{
if (atomic_dec_and_test(&prog->aux->refcnt)) {
+ spin_lock(&prog_idr_lock);
+ idr_remove(&prog_idr, prog->id);
+ spin_unlock(&prog_idr_lock);
trace_bpf_prog_put_rcu(prog);
bpf_prog_kallsyms_del(prog);
call_rcu(&prog->aux->rcu, __bpf_prog_put_rcu);
@@ -790,7 +796,7 @@ static int bpf_prog_load(union bpf_attr *attr)
{
enum bpf_prog_type type = attr->prog_type;
struct bpf_prog *prog;
- int err;
+ int err, id;
char license[128];
bool is_gpl;
@@ -848,6 +854,15 @@ static int bpf_prog_load(union bpf_attr *attr)
if (err < 0)
goto free_used_maps;
+ spin_lock(&prog_idr_lock);
+ id = idr_alloc_cyclic(&prog_idr, prog, 1, INT_MAX, GFP_USER);
+ spin_unlock(&prog_idr_lock);
+ if (id < 0) {
+ err = id;
+ goto free_used_maps;
+ }
+ prog->id = id;
+
/* eBPF program is ready to be JITed */
prog = bpf_prog_select_runtime(prog, &err);
if (err < 0)
@@ -995,6 +1010,33 @@ static int bpf_prog_test_run(const union bpf_attr *attr,
return ret;
}
+#define BPF_PROG_GET_NEXT_ID_LAST_FIELD next_id
+
+static int bpf_prog_get_next_id(union bpf_attr *attr)
+{
+ u64 __user *unext_id = u64_to_user_ptr(attr->next_id);
+ u32 next_id = attr->start_id;
+ struct bpf_prog *prog;
+
+ if (CHECK_ATTR(BPF_PROG_GET_NEXT_ID))
+ return -EINVAL;
+
+ if (next_id++ >= INT_MAX)
+ return -EINVAL;
+
+ spin_lock(&prog_idr_lock);
+ prog = idr_get_next(&prog_idr, &next_id);
+ spin_unlock(&prog_idr_lock);
+
+ if (!prog)
+ return -ENOENT;
+
+ if (copy_to_user(unext_id, &next_id, sizeof(next_id)))
+ return -EFAULT;
+
+ return 0;
+}
+
SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, size)
{
union bpf_attr attr = {};
@@ -1072,6 +1114,9 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, siz
case BPF_PROG_TEST_RUN:
err = bpf_prog_test_run(&attr, uattr);
break;
+ case BPF_PROG_GET_NEXT_ID:
+ err = bpf_prog_get_next_id(&attr);
+ break;
default:
err = -EINVAL;
break;
--
2.9.3
^ permalink raw reply related
* [RFC net-next 2/2] bpf: Test for bpf_prog ID and BPF_PROG_GET_NEXT_ID
From: Martin KaFai Lau @ 2017-04-27 6:24 UTC (permalink / raw)
To: netdev
Cc: Daniel Borkmann, Hannes Frederic Sowa, Alexei Starovoitov,
kernel-team
In-Reply-To: <20170427062449.80290-1-kafai@fb.com>
Add test to exercise the bpf_prog id generation
and iteration.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
---
tools/include/uapi/linux/bpf.h | 6 ++
tools/lib/bpf/bpf.c | 11 ++++
tools/lib/bpf/bpf.h | 1 +
tools/testing/selftests/bpf/Makefile | 2 +-
tools/testing/selftests/bpf/test_prog_id.c | 93 ++++++++++++++++++++++++++++++
5 files changed, 112 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/bpf/test_prog_id.c
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index e553529929f6..270f501c5597 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -82,6 +82,7 @@ enum bpf_cmd {
BPF_PROG_ATTACH,
BPF_PROG_DETACH,
BPF_PROG_TEST_RUN,
+ BPF_PROG_GET_NEXT_ID,
};
enum bpf_map_type {
@@ -201,6 +202,11 @@ union bpf_attr {
__u32 repeat;
__u32 duration;
} test;
+
+ struct { /* anonymous struct used by BPF_PROG_GET_NEXT_ID */
+ __u32 start_id;
+ __aligned_u64 next_id;
+ };
} __attribute__((aligned(8)));
/* BPF helper function descriptions:
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 4fe444b8092e..e23011f88fb4 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -235,3 +235,14 @@ int bpf_prog_test_run(int prog_fd, int repeat, void *data, __u32 size,
*duration = attr.test.duration;
return ret;
}
+
+int bpf_prog_get_next_id(__u32 start_id, __u32 *next_id)
+{
+ union bpf_attr attr;
+
+ bzero(&attr, sizeof(attr));
+ attr.start_id = start_id;
+ attr.next_id = ptr_to_u64(next_id);
+
+ return sys_bpf(BPF_PROG_GET_NEXT_ID, &attr, sizeof(attr));
+}
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index edb4daeff7a5..200f1ffc9cf9 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -50,5 +50,6 @@ int bpf_prog_detach(int attachable_fd, enum bpf_attach_type type);
int bpf_prog_test_run(int prog_fd, int repeat, void *data, __u32 size,
void *data_out, __u32 *size_out, __u32 *retval,
__u32 *duration);
+int bpf_prog_get_next_id(__u32 start_id, __u32 *next_id);
#endif
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index d8d94b9bd76c..68c4a920cb56 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -11,7 +11,7 @@ endif
CFLAGS += -Wall -O2 -I$(APIDIR) -I$(LIBDIR) -I$(GENDIR) $(GENFLAGS) -I../../../include
LDLIBS += -lcap -lelf
-TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_lpm_map test_progs
+TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_lpm_map test_progs test_prog_id
TEST_GEN_FILES = test_pkt_access.o test_xdp.o test_l4lb.o
diff --git a/tools/testing/selftests/bpf/test_prog_id.c b/tools/testing/selftests/bpf/test_prog_id.c
new file mode 100644
index 000000000000..f6c56c649d72
--- /dev/null
+++ b/tools/testing/selftests/bpf/test_prog_id.c
@@ -0,0 +1,93 @@
+/* Copyright (c) 2017 Facebook
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include <linux/types.h>
+#include <linux/bpf.h>
+#include <linux/err.h>
+#include <bpf/bpf.h>
+#include <sys/resource.h>
+#include <unistd.h>
+#include <bpf/libbpf.h>
+#include <assert.h>
+
+#include "bpf_util.h"
+
+static int bpf_prog_load(const char *file, enum bpf_prog_type type,
+ struct bpf_object **pobj, int *prog_fd)
+{
+ struct bpf_program *prog;
+ struct bpf_object *obj;
+ int err;
+
+ obj = bpf_object__open(file);
+ if (IS_ERR(obj))
+ return -ENOENT;
+
+ prog = bpf_program__next(NULL, obj);
+ if (!prog) {
+ bpf_object__close(obj);
+ return -ENOENT;
+ }
+
+ bpf_program__set_type(prog, type);
+ err = bpf_object__load(obj);
+ if (err) {
+ bpf_object__close(obj);
+ return -EINVAL;
+ }
+
+ *pobj = obj;
+ *prog_fd = bpf_program__fd(prog);
+ return 0;
+}
+
+int main(void)
+{
+ struct rlimit rinf = { RLIM_INFINITY, RLIM_INFINITY };
+ const char *file = "./test_pkt_access.o";
+ const int nr_iters = 16;
+ int bpf_prog_fds[nr_iters];
+ int i, err = 0;
+ uint32_t next_id = 0;
+
+ if (setrlimit(RLIMIT_MEMLOCK, &rinf)) {
+ perror("setrlimit");
+ return -1;
+ }
+
+ memset(bpf_prog_fds, -1, sizeof(bpf_prog_fds));
+
+ for (i = 0; i < nr_iters; i++) {
+ struct bpf_object *obj;
+ int prog_fd;
+
+ err = bpf_prog_load(file, BPF_PROG_TYPE_SCHED_CLS, &obj,
+ &prog_fd);
+ if (err) {
+ perror("bpf_prog_load");
+ goto done;
+ }
+
+ bpf_prog_fds[i] = prog_fd;
+ }
+
+ i = 0;
+ while (!bpf_prog_get_next_id(next_id, &next_id)) {
+ printf("prog_uid:%08u\n", next_id);
+ i++;
+ assert(i <= nr_iters);
+ }
+ assert(i == nr_iters);
+
+done:
+ for (i = 0; i < nr_iters; i++) {
+ if (bpf_prog_fds[i] != -1) {
+ close(bpf_prog_fds[i]);
+ }
+ }
+
+ return err ? -1 : 0;
+}
--
2.9.3
^ permalink raw reply related
* [RFC net-next 0/2] Introduce bpf_prog ID and iteration
From: Martin KaFai Lau @ 2017-04-27 6:24 UTC (permalink / raw)
To: netdev
Cc: Daniel Borkmann, Hannes Frederic Sowa, Alexei Starovoitov,
kernel-team
This patchset introduces the bpf_prog ID and a new bpf cmd to
iterate all bpf_prog in the system.
It is still incomplete. The idea can be extended to bpf_map.
Martin KaFai Lau (2):
bpf: Introduce bpf_prog ID
bpf: Test for bpf_prog ID and BPF_PROG_GET_NEXT_ID
include/linux/filter.h | 1 +
include/uapi/linux/bpf.h | 6 ++
kernel/bpf/syscall.c | 47 ++++++++++++++-
tools/include/uapi/linux/bpf.h | 6 ++
tools/lib/bpf/bpf.c | 11 ++++
tools/lib/bpf/bpf.h | 1 +
tools/testing/selftests/bpf/Makefile | 2 +-
tools/testing/selftests/bpf/test_prog_id.c | 93 ++++++++++++++++++++++++++++++
8 files changed, 165 insertions(+), 2 deletions(-)
create mode 100644 tools/testing/selftests/bpf/test_prog_id.c
--
2.9.3
^ permalink raw reply
* rhashtable - Cap total number of entries to 2^31
From: Herbert Xu @ 2017-04-27 5:44 UTC (permalink / raw)
To: David Miller; +Cc: fw, netdev, Thomas Graf
In-Reply-To: <20170425.104822.1395000926293799711.davem@davemloft.net>
On Tue, Apr 25, 2017 at 10:48:22AM -0400, David Miller wrote:
> From: Florian Westphal <fw@strlen.de>
> Date: Tue, 25 Apr 2017 16:17:49 +0200
>
> > I'd have less of an issue with this if we'd be talking about
> > something computationally expensive, but this is about storing
> > an extra value inside a struct just to avoid one "shr" in insert path...
>
> Agreed, this shift is probably filling an available cpu cycle :-)
OK, but we need to have an extra field for another reason anyway.
The problem is that we're not capping the total number of elements
in the hashtable when max_size is not set, this means that nelems
can overflow which will cause havoc with the automatic shrinking
when it tries to fit 2^32 entries into a minimum-sized table.
So I'm taking that hole back for now :)
---8<---
When max_size is not set or if it set to a sufficiently large
value, the nelems counter can overflow. This would cause havoc
with the automatic shrinking as it would then attempt to fit a
huge number of entries into a tiny hash table.
This patch fixes this by adding max_elems to struct rhashtable
to cap the number of elements. This is set to 2^31 as nelems is
not a precise count. This is sufficiently smaller than UINT_MAX
that it should be safe.
When max_size is set max_elems will be lowered to at most twice
max_size as is the status quo.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/include/linux/rhashtable.h b/include/linux/rhashtable.h
index ae93b65..45f8936 100644
--- a/include/linux/rhashtable.h
+++ b/include/linux/rhashtable.h
@@ -155,6 +155,7 @@ struct rhashtable_params {
* @nelems: Number of elements in table
* @key_len: Key length for hashfn
* @p: Configuration parameters
+ * @max_elems: Maximum number of elements in table
* @rhlist: True if this is an rhltable
* @run_work: Deferred worker to expand/shrink asynchronously
* @mutex: Mutex to protect current/future table swapping
@@ -165,6 +166,7 @@ struct rhashtable {
atomic_t nelems;
unsigned int key_len;
struct rhashtable_params p;
+ unsigned int max_elems;
bool rhlist;
struct work_struct run_work;
struct mutex mutex;
@@ -327,8 +329,7 @@ static inline bool rht_grow_above_100(const struct rhashtable *ht,
static inline bool rht_grow_above_max(const struct rhashtable *ht,
const struct bucket_table *tbl)
{
- return ht->p.max_size &&
- (atomic_read(&ht->nelems) / 2u) >= ht->p.max_size;
+ return atomic_read(&ht->nelems) >= ht->max_elems;
}
/* The bucket lock is selected based on the hash and protects mutations
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index f3b82e0..751630b 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -961,6 +961,11 @@ int rhashtable_init(struct rhashtable *ht,
if (params->max_size)
ht->p.max_size = rounddown_pow_of_two(params->max_size);
+ /* Cap total entries at 2^31 to avoid nelems overflow. */
+ ht->max_elems = 1u << 31;
+ if (ht->p.max_size < ht->max_elems / 2)
+ ht->max_elems = ht->p.max_size * 2;
+
ht->p.min_size = max(ht->p.min_size, HASH_MIN_SIZE);
if (params->nelem_hint)
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: ipsec doesn't route TCP with 4.11 kernel
From: Cong Wang @ 2017-04-27 5:01 UTC (permalink / raw)
To: Don Bowman
Cc: linux-kernel@vger.kernel.org, Steffen Klassert, Herbert Xu,
Linux Kernel Network Developers
In-Reply-To: <CADJev78Cs0VBdagtfU-71pv3HHC5Vq41UXQee856aVbUqEqAYg@mail.gmail.com>
(Cc'ing netdev and IPSec maintainers)
On Tue, Apr 25, 2017 at 6:08 PM, Don Bowman <db@donbowman.ca> wrote:
> I'm not sure how to describe this.
>
> 4.11rc2 worked, after that, no.
>
> My ipsec tunnel comes up ok. ICMP works. UDP works. But TCP, the
> sender [which is the ipsec client] does not reach the destination.
>
> Its not a routing rule issue (since ICMP/UDP work).
> Its not a traffic selector just selecting TCP (I think) since ipsec
> status shows just a subnet, no protocol.
>
> Using tcpdump:
> # iptables -t mangle -I PREROUTING -m policy --pol ipsec --dir in -j
> NFLOG --nflog-group 5
> # iptables -t mangle -I POSTROUTING -m policy --pol ipsec --dir out -j
> NFLOG --nflog-group 5
> # tcpdump -s 0 -n -i nflog:5
>
> I see that it thinks it is sending the TCP packet, but the server end
> does not receive.
>
> Does anyone have any suggestion to try?
>
> strongswan is 5.5.1 [on ubuntu 17.04]
> kernel is 4.11.0-041100rc8-generic
>
> My rightsubnet is
> rightsubnet = 192.168.128.0/17,10.0.0.0/8
>
> so no specific protocol selected, the result is:
> CHILD_SA sv{1} established with SPIs c05f1b6c_i 0d58815a_o and TS
> 192.168.130.4/32 === 10.0.0.0/8 192.168.128.0/17
>
> I tried changing charondebug net=3, but i'm not sure how to interpret
> the output:
>
> Apr 25 21:06:34 office charon: 04[NET] received packet: from
> 64.7.137.180[4500] to 172.16.0.8[4500] (80 bytes)
> Apr 25 21:06:34 office charon: 04[ENC] parsed INFORMATIONAL request 4 [ ]
> Apr 25 21:06:34 office charon: 04[ENC] generating INFORMATIONAL response 4 [ ]
> Apr 25 21:06:34 office charon: 04[NET] sending packet: from
> 172.16.0.8[4500] to 64.7.137.180[4500] (80 bytes)
^ permalink raw reply
* Re: [PATCH net-next 1/9] drivers: net: xgene: Protect indirect MAC access
From: Iyappan Subramanian @ 2017-04-27 4:12 UTC (permalink / raw)
To: Florian Fainelli
Cc: David Miller, netdev, Quan Nguyen, patches,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <d23578a5-fedd-accd-c49b-12200440b9ca@gmail.com>
On Wed, Apr 26, 2017 at 5:06 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 04/26/2017 04:38 PM, Iyappan Subramanian wrote:
>> From: Quan Nguyen <qnguyen@apm.com>
>>
>> This patch adds lock to protect indirect mac access sequence.
>>
>> Signed-off-by: Quan Nguyen <qnguyen@apm.com>
>> Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
>> ---
>> drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 2 ++
>> drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 1 +
>> drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 1 +
>> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c | 7 ++++++-
>> drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c | 2 ++
>> 5 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
>> index 2a835e0..3697ba7 100644
>> --- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
>> +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
>> @@ -365,9 +365,11 @@ static void xgene_enet_rd_mcx_mac(struct xgene_enet_pdata *pdata,
>> cmd = pdata->mcx_mac_addr + MAC_COMMAND_REG_OFFSET;
>> cmd_done = pdata->mcx_mac_addr + MAC_COMMAND_DONE_REG_OFFSET;
>>
>> + spin_lock(&pdata->mac_lock);
>> if (!xgene_enet_rd_indirect(addr, rd, cmd, cmd_done, rd_addr, rd_data))
>> netdev_err(pdata->ndev, "MCX mac read failed, addr: %04x\n",
>> rd_addr);
>> + spin_unlock(&pdata->mac_lock);
>
> Why not fold the spinlock manipulation within xgenet_enet_rd_indirect()?
> That way the caller does not have to know that acquiring the spinlock is
> required and you avoid potential bugs in the future where you are
> missing the spinlock on indirect accesses?
Thanks. We'll do that and post the next version.
> --
> Florian
^ permalink raw reply
* [PATCH net-next] tcp: tcp_rack_reo_timeout() must update tp->tcp_mstamp
From: Eric Dumazet @ 2017-04-27 4:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Soheil Hassas Yeganeh, Neal Cardwell, Yuchung Cheng
From: Eric Dumazet <edumazet@google.com>
I wrongly assumed tp->tcp_mstamp was up to date at the time
tcp_rack_reo_timeout() was called.
It is not true, since we only update tcp->tcp_mstamp when receiving
a packet (as initially done in commit 69e996c58a35 ("tcp: add
tp->tcp_mstamp field")
tcp_rack_reo_timeout() being called by a timer and not an incoming
packet, we need to refresh tp->tcp_mstamp
Fixes: 7c1c7308592f ("tcp: do not pass timestamp to tcp_rack_detect_loss()")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Soheil Hassas Yeganeh <soheil@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
---
net/ipv4/tcp_recovery.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/tcp_recovery.c b/net/ipv4/tcp_recovery.c
index cd72b3d3879e88181c8a4639f0334a24e4cda852..362b8c75bfab44cf87c2a01398a146a271bc1119 100644
--- a/net/ipv4/tcp_recovery.c
+++ b/net/ipv4/tcp_recovery.c
@@ -166,6 +166,7 @@ void tcp_rack_reo_timeout(struct sock *sk)
u32 timeout, prior_inflight;
prior_inflight = tcp_packets_in_flight(tp);
+ skb_mstamp_get(&tp->tcp_mstamp);
tcp_rack_detect_loss(sk, &timeout);
if (prior_inflight != tcp_packets_in_flight(tp)) {
if (inet_csk(sk)->icsk_ca_state != TCP_CA_Recovery) {
^ permalink raw reply related
* Re: [PATCH v1 net-next 3/6] net: add new control message for incoming HW-timestamped packets
From: kbuild test robot @ 2017-04-27 4:09 UTC (permalink / raw)
To: Miroslav Lichvar
Cc: kbuild-all, netdev, Richard Cochran, Willem de Bruijn,
Soheil Hassas Yeganeh, Keller, Jacob E, Denny Page, Jiri Benc
In-Reply-To: <20170426145035.25846-4-mlichvar@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]
Hi Miroslav,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Miroslav-Lichvar/Extend-socket-timestamping-API/20170427-093243
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All errors (new ones prefixed by >>):
net/socket.c: In function 'put_ts_pktinfo':
>> net/socket.c:680:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use in this function)
put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
^
net/socket.c:680:28: note: each undeclared identifier is reported only once for each function it appears in
vim +/SCM_TIMESTAMPING_PKTINFO +680 net/socket.c
674 orig_dev = dev_get_by_napi_id(skb->napi_id);
675 if (!orig_dev)
676 return;
677
678 ts_pktinfo.if_index = orig_dev->ifindex;
679 ts_pktinfo.pkt_length = skb->len - skb_mac_offset(skb);
> 680 put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
681 sizeof(ts_pktinfo), &ts_pktinfo);
682 #endif
683 }
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 49232 bytes --]
^ permalink raw reply
* Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function
From: Herbert Xu @ 2017-04-27 3:56 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: linux-kernel, linux-crypto, linux-media, dri-devel, intel-gfx,
linux-raid, linux-mmc, linux-nvdimm, linux-scsi, open-iscsi,
megaraidlinux.pdl, sparmaintainer, devel, target-devel, netdev,
linux-rdma, dm-devel, Christoph Hellwig, Martin K. Petersen,
James E.J. Bottomley, Jens Axboe, Greg Kroah-Hartman,
Dan Williams, Ross Zwisler
In-Reply-To: <1493144468-22493-8-git-send-email-logang@deltatee.com>
On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote:
> Very straightforward conversion to the new function in the caam driver
> and shash library.
>
> Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: "David S. Miller" <davem@davemloft.net>
> ---
> crypto/shash.c | 9 ++++++---
> drivers/crypto/caam/caamalg.c | 8 +++-----
> 2 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/crypto/shash.c b/crypto/shash.c
> index 5e31c8d..5914881 100644
> --- a/crypto/shash.c
> +++ b/crypto/shash.c
> @@ -283,10 +283,13 @@ int shash_ahash_digest(struct ahash_request *req, struct shash_desc *desc)
> if (nbytes < min(sg->length, ((unsigned int)(PAGE_SIZE)) - offset)) {
> void *data;
>
> - data = kmap_atomic(sg_page(sg));
> - err = crypto_shash_digest(desc, data + offset, nbytes,
> + data = sg_map(sg, 0, SG_KMAP_ATOMIC);
> + if (IS_ERR(data))
> + return PTR_ERR(data);
> +
> + err = crypto_shash_digest(desc, data, nbytes,
> req->result);
> - kunmap_atomic(data);
> + sg_unmap(sg, data, 0, SG_KMAP_ATOMIC);
> crypto_yield(desc->flags);
> } else
> err = crypto_shash_init(desc) ?:
Nack. This is an optimisation for the special case of a single
SG list entry. In fact in the common case the kmap_atomic should
disappear altogether in the no-highmem case. So replacing it
with sg_map is not acceptable.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH net-next] net: vrf: Do not allow looback to be moved to a VRF
From: Greg Rose @ 2017-04-27 2:44 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, rshearma
In-Reply-To: <1493218702-10906-1-git-send-email-dsa@cumulusnetworks.com>
On Wed, 2017-04-26 at 07:58 -0700, David Ahern wrote:
> Moving the loopback into a VRF breaks networking for the default VRF.
> Since the VRF device is the loopback for VRF domains, there is no
> reason to move the loopback. Given the repercussions, block attempts
> to set lo into a VRF.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
> ---
> drivers/net/vrf.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
> index aa5d30428bba..ceda5861da78 100644
> --- a/drivers/net/vrf.c
> +++ b/drivers/net/vrf.c
> @@ -877,6 +877,12 @@ static int do_vrf_add_slave(struct net_device *dev, struct net_device *port_dev)
> {
> int ret;
>
> + /* do not allow loopback device to be enslaved to a VRF.
> + * The vrf device acts as the loopback for the vrf.
> + */
> + if (port_dev == dev_net(dev)->loopback_dev)
> + return -EOPNOTSUPP;
> +
> port_dev->priv_flags |= IFF_L3MDEV_SLAVE;
> ret = netdev_master_upper_dev_link(port_dev, dev, NULL, NULL);
> if (ret < 0)
I think that's a great idea.
Reviewed-by: Greg Rose <gvrose8192@gmail.com>
^ permalink raw reply
* [PATCH net v4 3/3] net: hns: fixed bug that skb used after kfree
From: Yankejian @ 2017-04-27 2:44 UTC (permalink / raw)
To: davem, salil.mehta, yisen.zhuang, matthias.bgg, yankejian,
lipeng321, zhouhuiru, huangdaode
Cc: netdev, linuxarm
In-Reply-To: <1493261053-68197-1-git-send-email-yankejian@huawei.com>
From: lipeng <lipeng321@huawei.com>
There is KASAN warning which turn out it's a skb used after free:
BUG: KASAN: use-after-free in hns_nic_net_xmit_hw+0x62c/0x940...
[17659.112635] alloc_debug_processing+0x18c/0x1a0
[17659.117208] __slab_alloc+0x52c/0x560
[17659.120909] kmem_cache_alloc_node+0xac/0x2c0
[17659.125309] __alloc_skb+0x6c/0x260
[17659.128837] tcp_send_ack+0x8c/0x280
[17659.132449] __tcp_ack_snd_check+0x9c/0xf0
[17659.136587] tcp_rcv_established+0x5a4/0xa70
[17659.140899] tcp_v4_do_rcv+0x27c/0x620
[17659.144687] tcp_prequeue_process+0x108/0x170
[17659.149085] tcp_recvmsg+0x940/0x1020
[17659.152787] inet_recvmsg+0x124/0x180
[17659.156488] sock_recvmsg+0x64/0x80
[17659.160012] SyS_recvfrom+0xd8/0x180
[17659.163626] __sys_trace_return+0x0/0x4
[17659.167506] INFO: Freed in kfree_skbmem+0xa0/0xb0 age=23 cpu=1 pid=13
[17659.174000] free_debug_processing+0x1d4/0x2c0
[17659.178486] __slab_free+0x240/0x390
[17659.182100] kmem_cache_free+0x24c/0x270
[17659.186062] kfree_skbmem+0xa0/0xb0
[17659.189587] __kfree_skb+0x28/0x40
[17659.193025] napi_gro_receive+0x168/0x1c0
[17659.197074] hns_nic_rx_up_pro+0x58/0x90
[17659.201038] hns_nic_rx_poll_one+0x518/0xbc0
[17659.205352] hns_nic_common_poll+0x94/0x140
[17659.209576] net_rx_action+0x458/0x5e0
[17659.213363] __do_softirq+0x1b8/0x480
[17659.217062] run_ksoftirqd+0x64/0x80
[17659.220679] smpboot_thread_fn+0x224/0x310
[17659.224821] kthread+0x150/0x170
[17659.228084] ret_from_fork+0x10/0x40
BUG: KASAN: use-after-free in hns_nic_net_xmit+0x8c/0xc0...
[17751.080490] __slab_alloc+0x52c/0x560
[17751.084188] kmem_cache_alloc+0x244/0x280
[17751.088238] __build_skb+0x40/0x150
[17751.091764] build_skb+0x28/0x100
[17751.095115] __alloc_rx_skb+0x94/0x150
[17751.098900] __napi_alloc_skb+0x34/0x90
[17751.102776] hns_nic_rx_poll_one+0x180/0xbc0
[17751.107097] hns_nic_common_poll+0x94/0x140
[17751.111333] net_rx_action+0x458/0x5e0
[17751.115123] __do_softirq+0x1b8/0x480
[17751.118823] run_ksoftirqd+0x64/0x80
[17751.122437] smpboot_thread_fn+0x224/0x310
[17751.126575] kthread+0x150/0x170
[17751.129838] ret_from_fork+0x10/0x40
[17751.133454] INFO: Freed in kfree_skbmem+0xa0/0xb0 age=19 cpu=7 pid=43
[17751.139951] free_debug_processing+0x1d4/0x2c0
[17751.144436] __slab_free+0x240/0x390
[17751.148051] kmem_cache_free+0x24c/0x270
[17751.152014] kfree_skbmem+0xa0/0xb0
[17751.155543] __kfree_skb+0x28/0x40
[17751.159022] napi_gro_receive+0x168/0x1c0
[17751.163074] hns_nic_rx_up_pro+0x58/0x90
[17751.167041] hns_nic_rx_poll_one+0x518/0xbc0
[17751.171358] hns_nic_common_poll+0x94/0x140
[17751.175585] net_rx_action+0x458/0x5e0
[17751.179373] __do_softirq+0x1b8/0x480
[17751.183076] run_ksoftirqd+0x64/0x80
[17751.186691] smpboot_thread_fn+0x224/0x310
[17751.190826] kthread+0x150/0x170
[17751.194093] ret_from_fork+0x10/0x40
in drivers/net/ethernet/hisilicon/hns/hns_enet.c
static netdev_tx_t hns_nic_net_xmit(struct sk_buff *skb,
struct net_device *ndev)
{
struct hns_nic_priv *priv = netdev_priv(ndev);
int ret;
assert(skb->queue_mapping < ndev->ae_handle->q_num);
ret = hns_nic_net_xmit_hw(ndev, skb,
&tx_ring_data(priv, skb->queue_mapping));
if (ret == NETDEV_TX_OK) {
netif_trans_update(ndev);
ndev->stats.tx_bytes += skb->len;
ndev->stats.tx_packets++;
}
return (netdev_tx_t)ret;
}
skb maybe freed in hns_nic_net_xmit_hw() and return NETDEV_TX_OK:
out_err_tx_ok:
dev_kfree_skb_any(skb);
return NETDEV_TX_OK;
This patch fix this bug.
Reported-by: Jun He <hjat2005@huawei.com>
Signed-off-by: lipeng <lipeng321@huawei.com>
Reviewed-by: Yisen Zhuang <yisen.zhuang@huawei.com>
---
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 22 ++++++++++------------
drivers/net/ethernet/hisilicon/hns/hns_enet.h | 6 +++---
2 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index fca37e2..1e04df6 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -300,9 +300,9 @@ static void fill_tso_desc(struct hnae_ring *ring, void *priv,
mtu);
}
-int hns_nic_net_xmit_hw(struct net_device *ndev,
- struct sk_buff *skb,
- struct hns_nic_ring_data *ring_data)
+netdev_tx_t hns_nic_net_xmit_hw(struct net_device *ndev,
+ struct sk_buff *skb,
+ struct hns_nic_ring_data *ring_data)
{
struct hns_nic_priv *priv = netdev_priv(ndev);
struct hnae_ring *ring = ring_data->ring;
@@ -361,6 +361,10 @@ int hns_nic_net_xmit_hw(struct net_device *ndev,
dev_queue = netdev_get_tx_queue(ndev, skb->queue_mapping);
netdev_tx_sent_queue(dev_queue, skb->len);
+ netif_trans_update(ndev);
+ ndev->stats.tx_bytes += skb->len;
+ ndev->stats.tx_packets++;
+
wmb(); /* commit all data before submit */
assert(skb->queue_mapping < priv->ae_handle->q_num);
hnae_queue_xmit(priv->ae_handle->qs[skb->queue_mapping], buf_num);
@@ -1474,17 +1478,11 @@ static netdev_tx_t hns_nic_net_xmit(struct sk_buff *skb,
struct net_device *ndev)
{
struct hns_nic_priv *priv = netdev_priv(ndev);
- int ret;
assert(skb->queue_mapping < ndev->ae_handle->q_num);
- ret = hns_nic_net_xmit_hw(ndev, skb,
- &tx_ring_data(priv, skb->queue_mapping));
- if (ret == NETDEV_TX_OK) {
- netif_trans_update(ndev);
- ndev->stats.tx_bytes += skb->len;
- ndev->stats.tx_packets++;
- }
- return (netdev_tx_t)ret;
+
+ return hns_nic_net_xmit_hw(ndev, skb,
+ &tx_ring_data(priv, skb->queue_mapping));
}
static int hns_nic_change_mtu(struct net_device *ndev, int new_mtu)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.h b/drivers/net/ethernet/hisilicon/hns/hns_enet.h
index 5b412de..7bc6a6e 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.h
@@ -91,8 +91,8 @@ struct hns_nic_priv {
void hns_nic_net_reset(struct net_device *ndev);
void hns_nic_net_reinit(struct net_device *netdev);
int hns_nic_init_phy(struct net_device *ndev, struct hnae_handle *h);
-int hns_nic_net_xmit_hw(struct net_device *ndev,
- struct sk_buff *skb,
- struct hns_nic_ring_data *ring_data);
+netdev_tx_t hns_nic_net_xmit_hw(struct net_device *ndev,
+ struct sk_buff *skb,
+ struct hns_nic_ring_data *ring_data);
#endif /**__HNS_ENET_H */
--
1.9.1
^ permalink raw reply related
* [PATCH net v4 0/3] net: hns: bug fix for HNS driver
From: Yankejian @ 2017-04-27 2:44 UTC (permalink / raw)
To: davem, salil.mehta, yisen.zhuang, matthias.bgg, yankejian,
lipeng321, zhouhuiru, huangdaode
Cc: netdev, linuxarm
From: lipeng <lipeng321@huawei.com>
The first two patches [1/3] [2/3] of this serie add support defered
dsaf probe when mdio and mbigen module is not insmod. The third
patch [3/3] fixes a bug that skb still be used after freed, which will
cuase panic.
For more details, please refer to individual patch.
change log:
V3 -> V4:
1. Delete redundant commit message;
2. add Reviewed-by: Matthias Brugger <mbrugger@suse.com>;
V2 -> V3:
1. Check return value when platform_get_irq in hns_rcb_get_cfg;
V1 -> V2:
1. Return appropriate errno in hns_mac_register_phy;
lipeng (3):
net: hns: support deferred probe when can not obtain irq
net: hns: support deferred probe when no mdio
net: hns: fixed bug that skb used after kfree
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 39 +++++++++++++++++++----
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 4 ++-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 8 ++++-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 22 ++++++-------
drivers/net/ethernet/hisilicon/hns/hns_enet.h | 6 ++--
6 files changed, 57 insertions(+), 24 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH net v4 1/3] net: hns: support deferred probe when can not obtain irq
From: Yankejian @ 2017-04-27 2:44 UTC (permalink / raw)
To: davem, salil.mehta, yisen.zhuang, matthias.bgg, yankejian,
lipeng321, zhouhuiru, huangdaode
Cc: netdev, linuxarm
In-Reply-To: <1493261053-68197-1-git-send-email-yankejian@huawei.com>
From: lipeng <lipeng321@huawei.com>
In the hip06 and hip07 SoCs, the interrupt lines from the
DSAF controllers are connected to mbigen hw module.
The mbigen module is probed with module_init, and, as such,
is not guaranteed to probe before the HNS driver. So we need
to support deferred probe.
Signed-off-by: lipeng <lipeng321@huawei.com>
Reviewed-by: Yisen Zhuang <yisen.zhuang@huawei.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
---
change log:
V3 -> V4:
1. Delete redundant commit message;
2. add Reviewed-by: Matthias Brugger <mbrugger@suse.com>;
V2 -> V3:
1. Check return value when platform_get_irq in hns_rcb_get_cfg;
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 4 +++-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 8 +++++++-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h | 2 +-
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
index 6ea8722..a41cf95 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -510,7 +510,9 @@ int hns_ppe_init(struct dsaf_device *dsaf_dev)
hns_ppe_get_cfg(dsaf_dev->ppe_common[i]);
- hns_rcb_get_cfg(dsaf_dev->rcb_common[i]);
+ ret = hns_rcb_get_cfg(dsaf_dev->rcb_common[i]);
+ if (ret)
+ goto get_rcb_cfg_fail;
}
for (i = 0; i < HNS_PPE_COM_NUM; i++)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index f0ed80d6..673a5d3 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -452,7 +452,7 @@ static int hns_rcb_get_base_irq_idx(struct rcb_common_cb *rcb_common)
*hns_rcb_get_cfg - get rcb config
*@rcb_common: rcb common device
*/
-void hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
+int hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
{
struct ring_pair_cb *ring_pair_cb;
u32 i;
@@ -477,10 +477,16 @@ void hns_rcb_get_cfg(struct rcb_common_cb *rcb_common)
ring_pair_cb->virq[HNS_RCB_IRQ_IDX_RX] =
is_ver1 ? platform_get_irq(pdev, base_irq_idx + i * 2 + 1) :
platform_get_irq(pdev, base_irq_idx + i * 3);
+ if ((ring_pair_cb->virq[HNS_RCB_IRQ_IDX_TX] == -EPROBE_DEFER) ||
+ (ring_pair_cb->virq[HNS_RCB_IRQ_IDX_RX] == -EPROBE_DEFER))
+ return -EPROBE_DEFER;
+
ring_pair_cb->q.phy_base =
RCB_COMM_BASE_TO_RING_BASE(rcb_common->phy_base, i);
hns_rcb_ring_pair_get_cfg(ring_pair_cb);
}
+
+ return 0;
}
/**
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
index 99b4e1b..3d7b484 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
@@ -110,7 +110,7 @@ struct rcb_common_cb {
void hns_rcb_common_free_cfg(struct dsaf_device *dsaf_dev, u32 comm_index);
int hns_rcb_common_init_hw(struct rcb_common_cb *rcb_common);
void hns_rcb_start(struct hnae_queue *q, u32 val);
-void hns_rcb_get_cfg(struct rcb_common_cb *rcb_common);
+int hns_rcb_get_cfg(struct rcb_common_cb *rcb_common);
void hns_rcb_get_queue_mode(enum dsaf_mode dsaf_mode,
u16 *max_vfn, u16 *max_q_per_vf);
--
1.9.1
^ permalink raw reply related
* [PATCH net v4 2/3] net: hns: support deferred probe when no mdio
From: Yankejian @ 2017-04-27 2:44 UTC (permalink / raw)
To: davem, salil.mehta, yisen.zhuang, matthias.bgg, yankejian,
lipeng321, zhouhuiru, huangdaode
Cc: netdev, linuxarm
In-Reply-To: <1493261053-68197-1-git-send-email-yankejian@huawei.com>
From: lipeng <lipeng321@huawei.com>
In the hip06 and hip07 SoCs, phy connect to mdio bus.The mdio
module is probed with module_init, and, as such,
is not guaranteed to probe before the HNS driver. So we need
to support deferred probe.
We check for probe deferral in the mac init, so we not init DSAF
when there is no mdio, and free all resource, to later learn that
we need to defer the probe.
Signed-off-by: lipeng <lipeng321@huawei.com>
Reviewed-by: Yisen Zhuang <yisen.zhuang@huawei.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 39 +++++++++++++++++++----
1 file changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index bdd8cdd..8c00e09 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -735,6 +735,8 @@ static int hns_mac_init_ex(struct hns_mac_cb *mac_cb)
rc = phy_device_register(phy);
if (rc) {
phy_device_free(phy);
+ dev_err(&mdio->dev, "registered phy fail at address %i\n",
+ addr);
return -ENODEV;
}
@@ -745,7 +747,7 @@ static int hns_mac_init_ex(struct hns_mac_cb *mac_cb)
return 0;
}
-static void hns_mac_register_phy(struct hns_mac_cb *mac_cb)
+static int hns_mac_register_phy(struct hns_mac_cb *mac_cb)
{
struct acpi_reference_args args;
struct platform_device *pdev;
@@ -755,24 +757,39 @@ static void hns_mac_register_phy(struct hns_mac_cb *mac_cb)
/* Loop over the child nodes and register a phy_device for each one */
if (!to_acpi_device_node(mac_cb->fw_port))
- return;
+ return -ENODEV;
rc = acpi_node_get_property_reference(
mac_cb->fw_port, "mdio-node", 0, &args);
if (rc)
- return;
+ return rc;
addr = hns_mac_phy_parse_addr(mac_cb->dev, mac_cb->fw_port);
if (addr < 0)
- return;
+ return addr;
/* dev address in adev */
pdev = hns_dsaf_find_platform_device(acpi_fwnode_handle(args.adev));
+ if (!pdev) {
+ dev_err(mac_cb->dev, "mac%d mdio pdev is NULL\n",
+ mac_cb->mac_id);
+ return -EINVAL;
+ }
+
mii_bus = platform_get_drvdata(pdev);
+ if (!mii_bus) {
+ dev_err(mac_cb->dev,
+ "mac%d mdio is NULL, dsaf will probe again later\n",
+ mac_cb->mac_id);
+ return -EPROBE_DEFER;
+ }
+
rc = hns_mac_register_phydev(mii_bus, mac_cb, addr);
if (!rc)
dev_dbg(mac_cb->dev, "mac%d register phy addr:%d\n",
mac_cb->mac_id, addr);
+
+ return rc;
}
#define MAC_MEDIA_TYPE_MAX_LEN 16
@@ -793,7 +810,7 @@ static void hns_mac_register_phy(struct hns_mac_cb *mac_cb)
*@np:device node
* return: 0 --success, negative --fail
*/
-static int hns_mac_get_info(struct hns_mac_cb *mac_cb)
+static int hns_mac_get_info(struct hns_mac_cb *mac_cb)
{
struct device_node *np;
struct regmap *syscon;
@@ -903,7 +920,15 @@ static int hns_mac_get_info(struct hns_mac_cb *mac_cb)
}
}
} else if (is_acpi_node(mac_cb->fw_port)) {
- hns_mac_register_phy(mac_cb);
+ ret = hns_mac_register_phy(mac_cb);
+ /*
+ * Mac can work well if there is phy or not.If the port don't
+ * connect with phy, the return value will be ignored. Only
+ * when there is phy but can't find mdio bus, the return value
+ * will be handled.
+ */
+ if (ret == -EPROBE_DEFER)
+ return ret;
} else {
dev_err(mac_cb->dev, "mac%d cannot find phy node\n",
mac_cb->mac_id);
@@ -1065,6 +1090,7 @@ int hns_mac_init(struct dsaf_device *dsaf_dev)
dsaf_dev->mac_cb[port_id] = mac_cb;
}
}
+
/* init mac_cb for all port */
for (port_id = 0; port_id < max_port_num; port_id++) {
mac_cb = dsaf_dev->mac_cb[port_id];
@@ -1074,6 +1100,7 @@ int hns_mac_init(struct dsaf_device *dsaf_dev)
ret = hns_mac_get_cfg(dsaf_dev, mac_cb);
if (ret)
return ret;
+
ret = hns_mac_init_ex(mac_cb);
if (ret)
return ret;
--
1.9.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