* [PATCH 1/1] sctp: not send SCTP_PEER_ADDR_CHANGE notifications with failed probe
From: Zhu Yanjun @ 2014-11-20 6:04 UTC (permalink / raw)
To: netdev, w, zyjzyj2000, khandelwal.deepak.1987, vyasevich, tuexen,
dborkman
Cc: Zhu Yanjun, David S. Miller
2.6.x kernels require a similar logic change as commit 2c0d6ac894a
[sctp: not send SCTP_PEER_ADDR_CHANGE notifications with failed probe]
introduces for newer kernels.
Since the transport has always been in state SCTP_UNCONFIRMED, it
therefore wasn't active before and hasn't been used before, and it
always has been, so it is unnecessary to bug the user with a
notification.
Reported-by: Deepak Khandelwal <khandelwal.deepak.1987@gmail.com>
Suggested-by: Vlad Yasevich <vyasevich@gmail.com>
Suggested-by: Michael Tuexen <tuexen@fh-muenster.de>
Suggested-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/sctp/associola.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index 7eed77a..0f63396 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -824,6 +824,7 @@ void sctp_assoc_control_transport(struct sctp_association *asoc,
struct sctp_ulpevent *event;
struct sockaddr_storage addr;
int spc_state = 0;
+ bool ulp_notify = true;
/* Record the transition on the transport. */
switch (command) {
@@ -850,6 +851,7 @@ void sctp_assoc_control_transport(struct sctp_association *asoc,
else {
dst_release(transport->dst);
transport->dst = NULL;
+ ulp_notify = false;
}
spc_state = SCTP_ADDR_UNREACHABLE;
@@ -862,12 +864,14 @@ void sctp_assoc_control_transport(struct sctp_association *asoc,
/* Generate and send a SCTP_PEER_ADDR_CHANGE notification to the
* user.
*/
- memset(&addr, 0, sizeof(struct sockaddr_storage));
- memcpy(&addr, &transport->ipaddr, transport->af_specific->sockaddr_len);
- event = sctp_ulpevent_make_peer_addr_change(asoc, &addr,
+ if (ulp_notify) {
+ memset(&addr, 0, sizeof(struct sockaddr_storage));
+ memcpy(&addr, &transport->ipaddr, transport->af_specific->sockaddr_len);
+ event = sctp_ulpevent_make_peer_addr_change(asoc, &addr,
0, spc_state, error, GFP_ATOMIC);
- if (event)
- sctp_ulpq_tail_event(&asoc->ulpq, event);
+ if (event)
+ sctp_ulpq_tail_event(&asoc->ulpq, event);
+ }
/* Select new active and retran paths. */
--
1.9.1
^ permalink raw reply related
* [PATCH net V3] virtio-net: validate features during probe
From: Jason Wang @ 2014-11-20 6:10 UTC (permalink / raw)
To: rusty, mst, virtualization, netdev, linux-kernel
We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
is not set but one of features depending on it is.
That's not a friendly way to report errors to
hypervisors.
Let's check, and fail probe instead.
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
Changes from V2:
- only check the features for ctrl vq (this fix the real bug)
- better error message and simplify API
---
drivers/net/virtio_net.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index ec2a8b4..a6bcfce 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1673,6 +1673,40 @@ static const struct attribute_group virtio_net_mrg_rx_group = {
};
#endif
+static bool virtnet_fail_on_feature(struct virtio_device *vdev,
+ unsigned int fbit,
+ const char *fname, const char *dname)
+{
+ if (!virtio_has_feature(vdev, fbit))
+ return false;
+
+ dev_err(&vdev->dev, "Hypervisor bug: advertise feature %s but not %s",
+ fname, dname);
+
+ return true;
+}
+
+#define VIRTNET_FAIL_ON(vdev, fbit, dbit) \
+ virtnet_fail_on_feature(vdev, fbit, #fbit, #dbit)
+
+static bool virtnet_validate_features(struct virtio_device *vdev)
+{
+ if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ) &&
+ (VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_RX,
+ VIRTIO_NET_F_CTRL_VQ) ||
+ VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_VLAN,
+ VIRTIO_NET_F_CTRL_VQ) ||
+ VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_GUEST_ANNOUNCE,
+ VIRTIO_NET_F_TRL_VQ) ||
+ VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_MQ, VIRTIO_NET_F_CTRL_VQ) ||
+ VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_MAC_ADDR,
+ VIRTIO_NET_F_CTRL_VQ))) {
+ return false;
+ }
+
+ return true;
+}
+
static int virtnet_probe(struct virtio_device *vdev)
{
int i, err;
@@ -1680,6 +1714,9 @@ static int virtnet_probe(struct virtio_device *vdev)
struct virtnet_info *vi;
u16 max_queue_pairs;
+ if (!virtnet_validate_features(vdev))
+ return -EINVAL;
+
/* Find if host supports multiqueue virtio_net device */
err = virtio_cread_feature(vdev, VIRTIO_NET_F_MQ,
struct virtio_net_config,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/1] sctp: not send SCTP_PEER_ADDR_CHANGE notifications with failed probe
From: Willy Tarreau @ 2014-11-20 6:14 UTC (permalink / raw)
To: Zhu Yanjun
Cc: netdev, khandelwal.deepak.1987, vyasevich, tuexen, dborkman,
Zhu Yanjun, David S. Miller
In-Reply-To: <1416463480-29036-1-git-send-email-Yanjun.Zhu@windriver.com>
Hi,
On Thu, Nov 20, 2014 at 02:04:40PM +0800, Zhu Yanjun wrote:
> 2.6.x kernels require a similar logic change as commit 2c0d6ac894a
> [sctp: not send SCTP_PEER_ADDR_CHANGE notifications with failed probe]
> introduces for newer kernels.
(...)
Queued for 2.6.32.64, thanks!
Willy
^ permalink raw reply
* Re: [PATCH net] tcp: fix connect() invalid -EADDRNOTAVAIL error
From: Eric Dumazet @ 2014-11-20 6:33 UTC (permalink / raw)
To: Jonathan Maxwell
Cc: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel,
Jon Maxwell
In-Reply-To: <CAGHK07BrUmWxbNA3FzYtEqUOji_qn816=dmi_J40S_CKE3kMnA@mail.gmail.com>
On Thu, 2014-11-20 at 14:44 +1100, Jonathan Maxwell wrote:
> > > Prerequisites for this to happen:
> > > 1) The local tcp port range must be exhausted.
> > > 2) A process must have called bind() followed by connect() for all
> > > local ports.
> >
> > How the bind() is done exactly ? How SO_REUSEADDR is used ?
>
> It fails regardless. I tried both with and without for the client and
> server programs.
>
This is the missing part from the programs.
By not using SO_REUSEADDR, programs basically do not allow another
programs to use same port.
> But removing the bind() and just calling connect() from the initial
> program
> then a subsequent connect() from a separate program succeeds. It seems
> that
> this is inconsistent behaviour. The proposed fix makes it behave the
> same for
>
> both cases.
This not consistent behavior is well known and somehow expected by some
applications.
bind() requests the kernel that this socket has a reserved port.
It means the socket can later disconnect from the target, and reconnect
to another, using _same_ source port, or chose to listen() on this port.
That is why kernel is so picky, otherwise the listen() might fail
later...
This is part of BSD socket semantic.
You have to use SO_REUSEADDR on both programs to relax these
constraints.
Your change might break existing programs, really expecting kernel
to behave as requested.
^ permalink raw reply
* Re: [PATCH] bonding: clear header_ops when last slave detached (v2)
From: Eric Dumazet @ 2014-11-20 6:41 UTC (permalink / raw)
To: Cong Wang; +Cc: Wengang, netdev
In-Reply-To: <CAHA+R7OyA_V149bpE8qUgG9epU-5UG8cf=zOgh5ZXVB3ZFZHUw@mail.gmail.com>
On Wed, 2014-11-19 at 14:26 -0800, Cong Wang wrote:
> On Tue, Nov 18, 2014 at 11:00 PM, Wengang <wen.gang.wang@oracle.com> wrote:
> >
> > Yes, that's true. So the simplest way is move ipoib_header_ops to vmlinux.
> >
>
> That is not an option. Perhaps you need RCU to protect the dev->header_ops
> pointer.
This _is_ a reasonable option, especially for stable kernels
ipoib_hard_header() is 100 bytes or less. Adding infrastructure all over
the kernel to be able to use RCU or module refcounting will cost much
more.
Tell me why it is ok for eth_header_ops() being static (while its _much_
bigger), and not for ipoib_header_ops. This looks pretty arbitrary to
me.
^ permalink raw reply
* Re: [PATCH net V3] virtio-net: validate features during probe
From: Michael S. Tsirkin @ 2014-11-20 7:02 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <1416463835-7364-1-git-send-email-jasowang@redhat.com>
On Thu, Nov 20, 2014 at 02:10:35PM +0800, Jason Wang wrote:
> We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
> is not set but one of features depending on it is.
> That's not a friendly way to report errors to
> hypervisors.
> Let's check, and fail probe instead.
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
> Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Looks good, minor nits below:
> ---
> Changes from V2:
> - only check the features for ctrl vq (this fix the real bug)
> - better error message and simplify API
> ---
> drivers/net/virtio_net.c | 37 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index ec2a8b4..a6bcfce 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1673,6 +1673,40 @@ static const struct attribute_group virtio_net_mrg_rx_group = {
> };
> #endif
>
> +static bool virtnet_fail_on_feature(struct virtio_device *vdev,
> + unsigned int fbit,
> + const char *fname, const char *dname)
> +{
> + if (!virtio_has_feature(vdev, fbit))
> + return false;
> +
> + dev_err(&vdev->dev, "Hypervisor bug: advertise feature %s but not %s",
Well we don't know it's a hypervisor. How about:
Device bug: advertises feature %s but not %s.
> + fname, dname);
> +
> + return true;
> +}
> +
> +#define VIRTNET_FAIL_ON(vdev, fbit, dbit) \
> + virtnet_fail_on_feature(vdev, fbit, #fbit, #dbit)
I would pass dbit directly, and supply a string from caller,
instead if #dbit, this way it can be any string.
> +
> +static bool virtnet_validate_features(struct virtio_device *vdev)
> +{
> + if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ) &&
> + (VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_RX,
> + VIRTIO_NET_F_CTRL_VQ) ||
> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_VLAN,
> + VIRTIO_NET_F_CTRL_VQ) ||
> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_GUEST_ANNOUNCE,
> + VIRTIO_NET_F_TRL_VQ) ||
Typo: VIRTIO_NET_F_CTRL_VQ.
> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_MQ, VIRTIO_NET_F_CTRL_VQ) ||
> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_MAC_ADDR,
> + VIRTIO_NET_F_CTRL_VQ))) {
> + return false;
> + }
> +
> + return true;
> +}
> +
> static int virtnet_probe(struct virtio_device *vdev)
> {
> int i, err;
> @@ -1680,6 +1714,9 @@ static int virtnet_probe(struct virtio_device *vdev)
> struct virtnet_info *vi;
> u16 max_queue_pairs;
>
> + if (!virtnet_validate_features(vdev))
> + return -EINVAL;
> +
> /* Find if host supports multiqueue virtio_net device */
> err = virtio_cread_feature(vdev, VIRTIO_NET_F_MQ,
> struct virtio_net_config,
> --
> 1.9.1
^ permalink raw reply
* Re: [PATCH net V3] virtio-net: validate features during probe
From: Jason Wang @ 2014-11-20 7:13 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <20141120070244.GE30994@redhat.com>
On 11/20/2014 03:02 PM, Michael S. Tsirkin wrote:
> On Thu, Nov 20, 2014 at 02:10:35PM +0800, Jason Wang wrote:
>> We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
>> is not set but one of features depending on it is.
>> That's not a friendly way to report errors to
>> hypervisors.
>> Let's check, and fail probe instead.
>>
>> Cc: Rusty Russell <rusty@rustcorp.com.au>
>> Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
>> Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>
> Looks good, minor nits below:
>
>> ---
>> Changes from V2:
>> - only check the features for ctrl vq (this fix the real bug)
>> - better error message and simplify API
>> ---
>> drivers/net/virtio_net.c | 37 +++++++++++++++++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index ec2a8b4..a6bcfce 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -1673,6 +1673,40 @@ static const struct attribute_group virtio_net_mrg_rx_group = {
>> };
>> #endif
>>
>> +static bool virtnet_fail_on_feature(struct virtio_device *vdev,
>> + unsigned int fbit,
>> + const char *fname, const char *dname)
>> +{
>> + if (!virtio_has_feature(vdev, fbit))
>> + return false;
>> +
>> + dev_err(&vdev->dev, "Hypervisor bug: advertise feature %s but not %s",
> Well we don't know it's a hypervisor. How about:
> Device bug: advertises feature %s but not %s.
Ok.
>> + fname, dname);
>> +
>> + return true;
>> +}
>> +
>> +#define VIRTNET_FAIL_ON(vdev, fbit, dbit) \
>> + virtnet_fail_on_feature(vdev, fbit, #fbit, #dbit)
> I would pass dbit directly, and supply a string from caller,
> instead if #dbit, this way it can be any string.
Right, this is better.
>> +
>> +static bool virtnet_validate_features(struct virtio_device *vdev)
>> +{
>> + if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ) &&
>> + (VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_RX,
>> + VIRTIO_NET_F_CTRL_VQ) ||
>> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_VLAN,
>> + VIRTIO_NET_F_CTRL_VQ) ||
>> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_GUEST_ANNOUNCE,
>> + VIRTIO_NET_F_TRL_VQ) ||
> Typo: VIRTIO_NET_F_CTRL_VQ.
>
>
Wil fix this and post V4.
Thanks
^ permalink raw reply
* Re: [PATCH] crypto: aesni-intel - avoid IPsec re-ordering
From: Steffen Klassert @ 2014-11-20 7:26 UTC (permalink / raw)
To: Herbert Xu; +Cc: Ming Liu, davem, ying.xue, linux-crypto, netdev
In-Reply-To: <20141115031549.GA19208@gondor.apana.org.au>
On Sat, Nov 15, 2014 at 11:15:50AM +0800, Herbert Xu wrote:
> On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote:
> >
> > Everything below the local_bh_enable() should not run in atomic context
> > as the subsequent functions may set the CRYPTO_TFM_REQ_MAY_SLEEP flag.
>
> Actually I'm thinking of doing exactly that (disabling softirq in
> cryptd) to fix the reordering problem.
>
> Most threads do not use the FPU/SIMD so cryptd is only ever needed
> when we have a user-space app that touches the FPU/SIMD which then
> gets an interrupt to perform crypto in softirq. So forcing cryptd
> on everyone just because some apps touch the FPU/SIMD is a non-
> starter.
>
> The most straightforward solution is to always defer to cryptd once
> it gets started. This is bad because if a rarely used app that
> touches FPU/SIMD runs then we'll end up stuck in cryptd long after
> the app goes away.
>
> So what I'm thinking of is to have the softirq path forcibly regain
> control from cryptd where possible. This is tricky because cryptd
> might be in the middle of processing a request. So that's why I'd
> like to disable softirqs while we're processing a request.
>
What about to use a fallback algorithm that does not need to touch
FPU/SIMD in such cases? We would not need cryptd at all and it would
keep the requests in the right order because we don't defer them.
^ permalink raw reply
* Re: [PATCH] crypto: aesni-intel - avoid IPsec re-ordering
From: Herbert Xu @ 2014-11-20 7:43 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Ming Liu, davem, ying.xue, linux-crypto, netdev
In-Reply-To: <20141120072650.GT6390@secunet.com>
On Thu, Nov 20, 2014 at 08:26:51AM +0100, Steffen Klassert wrote:
>
> What about to use a fallback algorithm that does not need to touch
> FPU/SIMD in such cases? We would not need cryptd at all and it would
> keep the requests in the right order because we don't defer them.
This would be bad for throughput since the fallback is many orders
of magnitude slower than aesni.
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] crypto: aesni-intel - avoid IPsec re-ordering
From: Steffen Klassert @ 2014-11-20 7:59 UTC (permalink / raw)
To: Herbert Xu; +Cc: Ming Liu, davem, ying.xue, linux-crypto, netdev
In-Reply-To: <20141120074342.GA29544@gondor.apana.org.au>
On Thu, Nov 20, 2014 at 03:43:42PM +0800, Herbert Xu wrote:
> On Thu, Nov 20, 2014 at 08:26:51AM +0100, Steffen Klassert wrote:
> >
> > What about to use a fallback algorithm that does not need to touch
> > FPU/SIMD in such cases? We would not need cryptd at all and it would
> > keep the requests in the right order because we don't defer them.
>
> This would be bad for throughput since the fallback is many orders
> of magnitude slower than aesni.
Sure, but could be an option if this is really a rare case.
Anyway, I don't mind too much about the solution as long as we
get it to work :)
^ permalink raw reply
* Re: Query about Dynamic Right Sizing implementation in linux-kernel
From: cprasad @ 2014-11-20 8:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1416410264.14060.45.camel@edumazet-glaptop2.roam.corp.google.com>
Hi,
Could you please tell how can i get access to the logs prior to Linux-2.6.12-rc2. I had already gone through the git logs. This was the last line in the logs.
Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Thanks
^ permalink raw reply
* Re: [PATCH] crypto: aesni-intel - avoid IPsec re-ordering
From: Herbert Xu @ 2014-11-20 8:02 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Ming Liu, davem, ying.xue, linux-crypto, netdev
In-Reply-To: <20141120075943.GU6390@secunet.com>
On Thu, Nov 20, 2014 at 08:59:44AM +0100, Steffen Klassert wrote:
>
> Sure, but could be an option if this is really a rare case.
Well it's rare but when it does hit it'll probably be there all
the time for that system. IOW you either have no apps using the
FPU, but when you do, it's probably going to be hogging it.
> Anyway, I don't mind too much about the solution as long as we
> get it to work :)
:)
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
* mlx5: don't duplicate kvfree()
From: Al Viro @ 2014-11-20 8:13 UTC (permalink / raw)
To: Eli Cohen
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
Signed-off-by: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
---
drivers/infiniband/hw/mlx5/cq.c | 8 ++++----
drivers/infiniband/hw/mlx5/mr.c | 4 ++--
drivers/infiniband/hw/mlx5/qp.c | 8 ++++----
drivers/infiniband/hw/mlx5/srq.c | 6 +++---
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 4 ++--
drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c | 4 ++--
drivers/net/ethernet/mellanox/mlx5/core/port.c | 4 ++--
include/linux/mlx5/driver.h | 8 --------
9 files changed, 21 insertions(+), 35 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/cq.c b/drivers/infiniband/hw/mlx5/cq.c
index 10cfce5..c463e7b 100644
--- a/drivers/infiniband/hw/mlx5/cq.c
+++ b/drivers/infiniband/hw/mlx5/cq.c
@@ -805,14 +805,14 @@ struct ib_cq *mlx5_ib_create_cq(struct ib_device *ibdev, int entries,
}
- mlx5_vfree(cqb);
+ kvfree(cqb);
return &cq->ibcq;
err_cmd:
mlx5_core_destroy_cq(dev->mdev, &cq->mcq);
err_cqb:
- mlx5_vfree(cqb);
+ kvfree(cqb);
if (context)
destroy_cq_user(cq, context);
else
@@ -1159,11 +1159,11 @@ int mlx5_ib_resize_cq(struct ib_cq *ibcq, int entries, struct ib_udata *udata)
}
mutex_unlock(&cq->resize_mutex);
- mlx5_vfree(in);
+ kvfree(in);
return 0;
ex_alloc:
- mlx5_vfree(in);
+ kvfree(in);
ex_resize:
if (udata)
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index 8ee7cb4..4c89b64 100644
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -853,14 +853,14 @@ static struct mlx5_ib_mr *reg_create(struct ib_pd *pd, u64 virt_addr,
goto err_2;
}
mr->umem = umem;
- mlx5_vfree(in);
+ kvfree(in);
mlx5_ib_dbg(dev, "mkey = 0x%x\n", mr->mmr.key);
return mr;
err_2:
- mlx5_vfree(in);
+ kvfree(in);
err_1:
kfree(mr);
diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
index e261a53..0e2ef9f 100644
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -647,7 +647,7 @@ err_unmap:
mlx5_ib_db_unmap_user(context, &qp->db);
err_free:
- mlx5_vfree(*in);
+ kvfree(*in);
err_umem:
if (qp->umem)
@@ -761,7 +761,7 @@ err_wrid:
kfree(qp->rq.wrid);
err_free:
- mlx5_vfree(*in);
+ kvfree(*in);
err_buf:
mlx5_buf_free(dev->mdev, &qp->buf);
@@ -971,7 +971,7 @@ static int create_qp_common(struct mlx5_ib_dev *dev, struct ib_pd *pd,
goto err_create;
}
- mlx5_vfree(in);
+ kvfree(in);
/* Hardware wants QPN written in big-endian order (after
* shifting) for send doorbell. Precompute this value to save
* a little bit when posting sends.
@@ -988,7 +988,7 @@ err_create:
else if (qp->create_type == MLX5_QP_KERNEL)
destroy_qp_kernel(dev, qp);
- mlx5_vfree(in);
+ kvfree(in);
return err;
}
diff --git a/drivers/infiniband/hw/mlx5/srq.c b/drivers/infiniband/hw/mlx5/srq.c
index 97cc1ba..41fec66 100644
--- a/drivers/infiniband/hw/mlx5/srq.c
+++ b/drivers/infiniband/hw/mlx5/srq.c
@@ -141,7 +141,7 @@ static int create_srq_user(struct ib_pd *pd, struct mlx5_ib_srq *srq,
return 0;
err_in:
- mlx5_vfree(*in);
+ kvfree(*in);
err_umem:
ib_umem_release(srq->umem);
@@ -209,7 +209,7 @@ static int create_srq_kernel(struct mlx5_ib_dev *dev, struct mlx5_ib_srq *srq,
return 0;
err_in:
- mlx5_vfree(*in);
+ kvfree(*in);
err_buf:
mlx5_buf_free(dev->mdev, &srq->buf);
@@ -306,7 +306,7 @@ struct ib_srq *mlx5_ib_create_srq(struct ib_pd *pd,
in->ctx.pd = cpu_to_be32(to_mpd(pd)->pdn);
in->ctx.db_record = cpu_to_be64(srq->db.dma);
err = mlx5_core_create_srq(dev->mdev, &srq->msrq, in, inlen);
- mlx5_vfree(in);
+ kvfree(in);
if (err) {
mlx5_ib_dbg(dev, "create SRQ failed, err %d\n", err);
goto err_usr_kern_srq;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eq.c b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
index a278238..eb3aa15 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
@@ -391,7 +391,7 @@ int mlx5_create_map_eq(struct mlx5_core_dev *dev, struct mlx5_eq *eq, u8 vecidx,
*/
eq_update_ci(eq, 1);
- mlx5_vfree(in);
+ kvfree(in);
return 0;
err_irq:
@@ -401,7 +401,7 @@ err_eq:
mlx5_cmd_destroy_eq(dev, eq->eqn);
err_in:
- mlx5_vfree(in);
+ kvfree(in);
err_buf:
mlx5_buf_free(dev, &eq->buf);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c b/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
index d476918..4fdaae9 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
@@ -349,7 +349,7 @@ out_4k:
for (i--; i >= 0; i--)
free_4k(dev, be64_to_cpu(in->pas[i]));
out_free:
- mlx5_vfree(in);
+ kvfree(in);
return err;
}
@@ -400,7 +400,7 @@ static int reclaim_pages(struct mlx5_core_dev *dev, u32 func_id, int npages,
}
out_free:
- mlx5_vfree(out);
+ kvfree(out);
return err;
}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/port.c b/drivers/net/ethernet/mellanox/mlx5/core/port.c
index 3139658..72c2d00 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/port.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/port.c
@@ -68,9 +68,9 @@ int mlx5_core_access_reg(struct mlx5_core_dev *dev, void *data_in,
memcpy(data_out, out->data, size_out);
ex2:
- mlx5_vfree(out);
+ kvfree(out);
ex1:
- mlx5_vfree(in);
+ kvfree(in);
return err;
}
EXPORT_SYMBOL_GPL(mlx5_core_access_reg);
diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
index 246310d..b1bf415 100644
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -633,14 +633,6 @@ static inline void *mlx5_vzalloc(unsigned long size)
return rtn;
}
-static inline void mlx5_vfree(const void *addr)
-{
- if (addr && is_vmalloc_addr(addr))
- vfree(addr);
- else
- kfree(addr);
-}
-
static inline u32 mlx5_base_mkey(const u32 key)
{
return key & 0xffffff00u;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: Query about Dynamic Right Sizing implementation in linux-kernel
From: Eric Dumazet @ 2014-11-20 8:15 UTC (permalink / raw)
To: cprasad; +Cc: netdev
In-Reply-To: <1264093102.132748.1416470440737.JavaMail.root@mail.cse.iitm.ac.in>
On Thu, 2014-11-20 at 13:30 +0530, cprasad@cse.iitm.ac.in wrote:
> Hi,
>
> Could you please tell how can i get access to the logs prior to Linux-2.6.12-rc2. I had already gone through the git logs. This was the last line in the logs.
I did a Google search with "linux git history"
And found this :
https://archive.org/details/git-history-of-linux
^ permalink raw reply
* mlx4: don't duplicate kvfree()
From: Al Viro @ 2014-11-20 8:15 UTC (permalink / raw)
To: Amir Vadai; +Cc: linux-kernel, netdev
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/drivers/net/ethernet/mellanox/mlx4/mr.c b/drivers/net/ethernet/mellanox/mlx4/mr.c
index 193a6ad..d6f5496 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mr.c
+++ b/drivers/net/ethernet/mellanox/mlx4/mr.c
@@ -130,10 +130,7 @@ static int mlx4_buddy_init(struct mlx4_buddy *buddy, int max_order)
err_out_free:
for (i = 0; i <= buddy->max_order; ++i)
- if (buddy->bits[i] && is_vmalloc_addr(buddy->bits[i]))
- vfree(buddy->bits[i]);
- else
- kfree(buddy->bits[i]);
+ kvfree(buddy->bits[i]);
err_out:
kfree(buddy->bits);
@@ -147,10 +144,7 @@ static void mlx4_buddy_cleanup(struct mlx4_buddy *buddy)
int i;
for (i = 0; i <= buddy->max_order; ++i)
- if (is_vmalloc_addr(buddy->bits[i]))
- vfree(buddy->bits[i]);
- else
- kfree(buddy->bits[i]);
+ kvfree(buddy->bits[i]);
kfree(buddy->bits);
kfree(buddy->num_free);
^ permalink raw reply related
* Re: mlx5: don't duplicate kvfree()
From: Al Viro @ 2014-11-20 8:17 UTC (permalink / raw)
To: Eli Cohen
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141120081357.GI7996-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
On Thu, Nov 20, 2014 at 08:13:57AM +0000, Al Viro wrote:
> 9 files changed, 21 insertions(+), 35 deletions(-)
grr... 8 files changed, actually - that was from the diff that included mlx4
bits. Patch split correctly and sent in two pieces, summary left as is ;-/
Sorry about the confusion it might cause...
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 net] virtio-net: validate features during probe
From: Jason Wang @ 2014-11-20 8:27 UTC (permalink / raw)
To: rusty, mst, virtualization, netdev, linux-kernel
We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
is not set but one of features depending on it is.
That's not a friendly way to report errors to
hypervisors.
Let's check, and fail probe instead.
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
Changes from V1:
- Drop NETIF_F_*_UFO from checklist
Changes from V2:
- only check the features for ctrl vq (this fix the real bug)
- better error message and simplify API
Changes from V3:
- pass dbit directly and even better error message
- typo fix
---
drivers/net/virtio_net.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index ec2a8b4..cc53ff1 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1673,6 +1673,40 @@ static const struct attribute_group virtio_net_mrg_rx_group = {
};
#endif
+static bool virtnet_fail_on_feature(struct virtio_device *vdev,
+ unsigned int fbit,
+ const char *fname, const char *dname)
+{
+ if (!virtio_has_feature(vdev, fbit))
+ return false;
+
+ dev_err(&vdev->dev, "advertise feature %s but not %s",
+ fname, dname);
+
+ return true;
+}
+
+#define VIRTNET_FAIL_ON(vdev, fbit, dbit) \
+ virtnet_fail_on_feature(vdev, fbit, #fbit, dbit)
+
+static bool virtnet_validate_features(struct virtio_device *vdev)
+{
+ if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ) &&
+ (VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_RX,
+ "VIRTIO_NET_F_CTRL_VQ") ||
+ VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_VLAN,
+ "VIRTIO_NET_F_CTRL_VQ") ||
+ VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_GUEST_ANNOUNCE,
+ "VIRTIO_NET_F_CTRL_VQ") ||
+ VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_MQ, "VIRTIO_NET_F_CTRL_VQ") ||
+ VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_MAC_ADDR,
+ "VIRTIO_NET_F_CTRL_VQ"))) {
+ return false;
+ }
+
+ return true;
+}
+
static int virtnet_probe(struct virtio_device *vdev)
{
int i, err;
@@ -1680,6 +1714,9 @@ static int virtnet_probe(struct virtio_device *vdev)
struct virtnet_info *vi;
u16 max_queue_pairs;
+ if (!virtnet_validate_features(vdev))
+ return -EINVAL;
+
/* Find if host supports multiqueue virtio_net device */
err = virtio_cread_feature(vdev, VIRTIO_NET_F_MQ,
struct virtio_net_config,
--
1.9.1
^ permalink raw reply related
* [PATCH net-next] macvtap: advance iov iterator when needed in macvtap_put_user()
From: Jason Wang @ 2014-11-20 8:31 UTC (permalink / raw)
To: davem, netdev, linux-kernel; +Cc: Jason Wang, Herbert Xu
When mergeable buffer is used, vnet_hdr_sz is greater than sizeof struct
virtio_net_hdr. So we need advance the iov iterators in this case.
Fixes 6c36d2e26cda1ad3e2c4b90dd843825fc62fe5b4 ("macvtap: Use iovec iterators")
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/macvtap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index cea99d4..42a80d3 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -797,6 +797,8 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
if (copy_to_iter(&vnet_hdr, sizeof(vnet_hdr), iter) !=
sizeof(vnet_hdr))
return -EFAULT;
+
+ iov_iter_advance(iter, vnet_hdr_len - sizeof(vnet_hdr));
}
total = vnet_hdr_len;
total += skb->len;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next] macvtap: advance iov iterator when needed in macvtap_put_user()
From: Herbert Xu @ 2014-11-20 8:34 UTC (permalink / raw)
To: Jason Wang; +Cc: davem, netdev, linux-kernel
In-Reply-To: <1416472265-10151-1-git-send-email-jasowang@redhat.com>
On Thu, Nov 20, 2014 at 04:31:05PM +0800, Jason Wang wrote:
> When mergeable buffer is used, vnet_hdr_sz is greater than sizeof struct
> virtio_net_hdr. So we need advance the iov iterators in this case.
>
> Fixes 6c36d2e26cda1ad3e2c4b90dd843825fc62fe5b4 ("macvtap: Use iovec iterators")
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks,
--
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: mlx4: don't duplicate kvfree()
From: Amir Vadai @ 2014-11-20 8:38 UTC (permalink / raw)
To: Al Viro; +Cc: Amir Vadai, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <20141120081538.GJ7996@ZenIV.linux.org.uk>
On Thu, Nov 20, 2014 at 10:15 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> ---
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/mr.c b/drivers/net/ethernet/mellanox/mlx4/mr.c
> index 193a6ad..d6f5496 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/mr.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/mr.c
> @@ -130,10 +130,7 @@ static int mlx4_buddy_init(struct mlx4_buddy *buddy, int max_order)
>
> err_out_free:
> for (i = 0; i <= buddy->max_order; ++i)
> - if (buddy->bits[i] && is_vmalloc_addr(buddy->bits[i]))
> - vfree(buddy->bits[i]);
> - else
> - kfree(buddy->bits[i]);
> + kvfree(buddy->bits[i]);
>
> err_out:
> kfree(buddy->bits);
> @@ -147,10 +144,7 @@ static void mlx4_buddy_cleanup(struct mlx4_buddy *buddy)
> int i;
>
> for (i = 0; i <= buddy->max_order; ++i)
> - if (is_vmalloc_addr(buddy->bits[i]))
> - vfree(buddy->bits[i]);
> - else
> - kfree(buddy->bits[i]);
> + kvfree(buddy->bits[i]);
>
> kfree(buddy->bits);
> kfree(buddy->num_free);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Thanks Al
Acked-by: Amir Vadai <amirv@mellanox.com>
^ permalink raw reply
* Re: mlx5: don't duplicate kvfree()
From: Eli Cohen @ 2014-11-20 8:41 UTC (permalink / raw)
To: Al Viro, roland, davem; +Cc: linux-kernel, linux-rdma, netdev
In-Reply-To: <20141120081357.GI7996@ZenIV.linux.org.uk>
Acked-by: Eli Cohen <eli@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next] macvtap: advance iov iterator when needed in macvtap_put_user()
From: Al Viro @ 2014-11-20 8:41 UTC (permalink / raw)
To: Herbert Xu; +Cc: Jason Wang, davem, netdev, linux-kernel
In-Reply-To: <20141120083426.GA30001@gondor.apana.org.au>
On Thu, Nov 20, 2014 at 04:34:26PM +0800, Herbert Xu wrote:
> On Thu, Nov 20, 2014 at 04:31:05PM +0800, Jason Wang wrote:
> > When mergeable buffer is used, vnet_hdr_sz is greater than sizeof struct
> > virtio_net_hdr. So we need advance the iov iterators in this case.
> >
> > Fixes 6c36d2e26cda1ad3e2c4b90dd843825fc62fe5b4 ("macvtap: Use iovec iterators")
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
I'm not sure it's a good behaviour, actually - should we just leave an
unmodified gap in userland buffer there, with whatever garbage it might
have contained?
I do realize that this is what we used to do, but it might end up a source
of hard to debug userland bugs... Perhaps that iov_iter_advance(iter, size)
would better be replaced with iov_iter_zero(size, iter)?
^ permalink raw reply
* Re: Query about Dynamic Right Sizing implementation in linux-kernel
From: Daniel Baluta @ 2014-11-20 8:43 UTC (permalink / raw)
To: cprasad; +Cc: Eric Dumazet, netdev@vger.kernel.org
In-Reply-To: <1264093102.132748.1416470440737.JavaMail.root@mail.cse.iitm.ac.in>
On Thu, Nov 20, 2014 at 10:00 AM, <cprasad@cse.iitm.ac.in> wrote:
> Hi,
>
> Could you please tell how can i get access to the logs prior to Linux-2.6.12-rc2. I had already gone through the git logs. This was the last line in the logs.
>
> Linux-2.6.12-rc2
>
> Initial git repository build. I'm not bothering with the full history,
> even though we have it. We can create a separate "historical" git
> archive of that later if we want to, and in the meantime it's about
> 3.2GB when imported into git - space that would just make the early
> git days unnecessarily complicated, when we don't have a lot of good
> infrastructure for it.
>
> Let it rip!
Try this:
https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/
Daniel.
^ permalink raw reply
* Re: net: sched: Deletion of an unnecessary check before the function call "kfree"
From: Julia Lawall @ 2014-11-20 8:47 UTC (permalink / raw)
To: SF Markus Elfring
Cc: John Fastabend, David S. Miller, Jamal Hadi Salim, netdev, LKML,
kernel-janitors
In-Reply-To: <546CE650.6080205@users.sourceforge.net>
On Wed, 19 Nov 2014, SF Markus Elfring wrote:
> > Marcus, what tree are you looking at?
>
> I dared to base this update suggestion on the source files
> for Linux 3.17.3. Are newer software developments relevant here?
You should always use linux-next. You should update it every day.
julia
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/net/sched/
>
> Regards,
> Markus
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net-next] macvtap: advance iov iterator when needed in macvtap_put_user()
From: Jason Wang @ 2014-11-20 8:53 UTC (permalink / raw)
To: Al Viro, Herbert Xu; +Cc: davem, netdev, linux-kernel
In-Reply-To: <20141120084152.GL7996@ZenIV.linux.org.uk>
On 11/20/2014 04:41 PM, Al Viro wrote:
> On Thu, Nov 20, 2014 at 04:34:26PM +0800, Herbert Xu wrote:
>> On Thu, Nov 20, 2014 at 04:31:05PM +0800, Jason Wang wrote:
>>> When mergeable buffer is used, vnet_hdr_sz is greater than sizeof struct
>>> virtio_net_hdr. So we need advance the iov iterators in this case.
>>>
>>> Fixes 6c36d2e26cda1ad3e2c4b90dd843825fc62fe5b4 ("macvtap: Use iovec iterators")
>>> Cc: Herbert Xu <herbert@gondor.apana.org.au>
>>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
> I'm not sure it's a good behaviour, actually - should we just leave an
> unmodified gap in userland buffer there, with whatever garbage it might
> have contained?
Anyway it's the users(qemu or vhost_net) responsibility to fill the gap
here.
> I do realize that this is what we used to do, but it might end up a source
> of hard to debug userland bugs... Perhaps that iov_iter_advance(iter, size)
> would better be replaced with iov_iter_zero(size, iter)?
Not sure, macvtap or tun behave like this in the past. It's easy to dump
the header in guest for debugging. Zero the gap probably only help the
case that the gap was forgot to be filled which looks rare.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox