* Re: [PATCH] selftests: bpf: fix urandom_read build issue
From: Y Song @ 2018-06-08 5:08 UTC (permalink / raw)
To: Anders Roxell
Cc: Alexei Starovoitov, Daniel Borkmann, Shuah Khan, netdev, LKML,
linux-kselftest
In-Reply-To: <CADYN=9Ly5UU34CxZFnWfQhNrS8V3gG7=Bdfn9n0h5XphZ8EiVQ@mail.gmail.com>
On Thu, Jun 7, 2018 at 2:43 PM, Anders Roxell <anders.roxell@linaro.org> wrote:
> On 7 June 2018 at 23:17, Y Song <ys114321@gmail.com> wrote:
>> On Thu, Jun 7, 2018 at 12:07 PM, Anders Roxell <anders.roxell@linaro.org> wrote:
>>> On 7 June 2018 at 19:52, Y Song <ys114321@gmail.com> wrote:
>>>> On Thu, Jun 7, 2018 at 3:57 AM, Anders Roxell <anders.roxell@linaro.org> wrote:
>>>>> gcc complains that urandom_read gets built twice.
>>>>>
>>>>> gcc -o tools/testing/selftests/bpf/urandom_read
>>>>> -static urandom_read.c -Wl,--build-id
>>>>> gcc -Wall -O2 -I../../../include/uapi -I../../../lib -I../../../lib/bpf
>>>>> -I../../../../include/generated -I../../../include urandom_read.c
>>>>> urandom_read -lcap -lelf -lrt -lpthread -o
>>>>> tools/testing/selftests/bpf/urandom_read
>>>>> gcc: fatal error: input file
>>>>> ‘tools/testing/selftests/bpf/urandom_read’ is the
>>>>> same as output file
>>>>> compilation terminated.
>>>>> ../lib.mk:110: recipe for target
>>>>> 'tools/testing/selftests/bpf/urandom_read' failed
>>>>
>>>> What is the build/make command to reproduce the above failure?
>>>
>>> make -C tools/testing/selftests
>>
>> Thanks. The patch will break
>> make -C tools/testing/selftests/bpf
>>
>> [yhs@localhost bpf-next]$ make -C tools/testing/selftests/bpf
>> make: Entering directory '/home/yhs/work/bpf-next/tools/testing/selftests/bpf'
>> gcc -o /urandom_read -static urandom_read.c -Wl,--build-id
>> /usr/bin/ld: cannot open output file /urandom_read: Permission denied
>> collect2: error: ld returned 1 exit status
>> make: *** [Makefile:20: /urandom_read] Error 1
>> make: Leaving directory '/home/yhs/work/bpf-next/tools/testing/selftests/bpf'
>> [yhs@localhost bpf-next]$
>
> urgh, I'm sorry, missed that.
>
>>
>> Could you still make the above command work?
>
> $(TEST_CUSTOM_PROGS): $(OUTPUT)/%: %.c
> $(CC) -o $(TEST_CUSTOM_PROGS) -static $< -Wl,--build-id
>
> That worked both with:
> make -C tools/testing/selftests
> and
> make -C tools/testing/selftests/bpf
>
> for me.
>
> what do you think?
This indeed works. You can submit a revised patch and add my Ack.
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* Re: [PATCH net] vhost_net: remove VHOST_NET_F_VIRTIO_NET_HDR support
From: Jason Wang @ 2018-06-08 5:07 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20180608074115-mutt-send-email-mst@kernel.org>
On 2018年06月08日 12:46, Michael S. Tsirkin wrote:
> On Fri, Jun 08, 2018 at 11:50:42AM +0800, Jason Wang wrote:
>> This feature bit is duplicated with VIRTIO_F_ANY_LAYOUT, this means if
>> a userpsace want to enable VRITIO_F_ANY_LAYOUT,
>> VHOST_NET_F_VIRTIO_NET_HDR will be implied too. This is wrong and will
>> break networking.
> What breaks networking exactly? VHOST_NET supported ANY_LAYOUT
> from day one. For this reason it does not need to know about
> VRITIO_F_ANY_LAYOUT and we reused the bit for other purposes.
It's the knowledge of vhost_net code it self but not userspace. For
userspace, it should depends on the value of returned by
VHOST_GET_FEATURES. So when userspace can set_features with ANY_LAYOUT,
vhost may think it wants VHOST_NET_F_VIRTIO_NET_HDR.
>
>
>
>> Fixing this by safely removing
>> VHOST_NET_F_VIRTIO_NET_HDR support. There should be very few or even
>> no userspace can use this.
> Quite possibly, but it is hard to be sure. It seems safer to
> maintain it unless there's an actual reason something's broken.
I think not since the feature is negotiated not mandatory?
>
>> Further cleanups could be done for
>> -net-next for safety.
>>
>> In the future, we need a vhost dedicated feature set/get ioctl()
>> instead of reusing virtio ones.
> Not just in the future, we might want to switch iommu
> to a sane structure without the 64 bit padding bug
> right now.
Yes, I hit this bug when introducing V2 of msg IOTLB message.
>
>> Fixes: 4e9fa50c6ccbe ("vhost: move features to core")
> This tag makes no sense here IMHO. Looks like people are using some tool
> that just looks at the earliest version where patch won't apply. The
> commit in question just moved some code around.
Looks not, before this commit, vhost_net won't return ANY_LAYOUT.
Thanks
>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> drivers/vhost/net.c | 15 +++++----------
>> 1 file changed, 5 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
>> index 986058a..83eef52 100644
>> --- a/drivers/vhost/net.c
>> +++ b/drivers/vhost/net.c
>> @@ -69,7 +69,6 @@ MODULE_PARM_DESC(experimental_zcopytx, "Enable Zero Copy TX;"
>>
>> enum {
>> VHOST_NET_FEATURES = VHOST_FEATURES |
>> - (1ULL << VHOST_NET_F_VIRTIO_NET_HDR) |
>> (1ULL << VIRTIO_NET_F_MRG_RXBUF) |
>> (1ULL << VIRTIO_F_IOMMU_PLATFORM)
>> };
>> @@ -1255,15 +1254,11 @@ static int vhost_net_set_features(struct vhost_net *n, u64 features)
>> (1ULL << VIRTIO_F_VERSION_1))) ?
>> sizeof(struct virtio_net_hdr_mrg_rxbuf) :
>> sizeof(struct virtio_net_hdr);
>> - if (features & (1 << VHOST_NET_F_VIRTIO_NET_HDR)) {
>> - /* vhost provides vnet_hdr */
>> - vhost_hlen = hdr_len;
>> - sock_hlen = 0;
>> - } else {
>> - /* socket provides vnet_hdr */
>> - vhost_hlen = 0;
>> - sock_hlen = hdr_len;
>> - }
>> +
>> + /* socket provides vnet_hdr */
>> + vhost_hlen = 0;
>> + sock_hlen = hdr_len;
>> +
>> mutex_lock(&n->dev.mutex);
>> if ((features & (1 << VHOST_F_LOG_ALL)) &&
>> !vhost_log_access_ok(&n->dev))
>> --
>> 2.7.4
^ permalink raw reply
* Re: [PATCH net] vhost_net: remove VHOST_NET_F_VIRTIO_NET_HDR support
From: Michael S. Tsirkin @ 2018-06-08 4:46 UTC (permalink / raw)
To: Jason Wang; +Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <1528429842-22835-1-git-send-email-jasowang@redhat.com>
On Fri, Jun 08, 2018 at 11:50:42AM +0800, Jason Wang wrote:
> This feature bit is duplicated with VIRTIO_F_ANY_LAYOUT, this means if
> a userpsace want to enable VRITIO_F_ANY_LAYOUT,
> VHOST_NET_F_VIRTIO_NET_HDR will be implied too. This is wrong and will
> break networking.
What breaks networking exactly? VHOST_NET supported ANY_LAYOUT
from day one. For this reason it does not need to know about
VRITIO_F_ANY_LAYOUT and we reused the bit for other purposes.
> Fixing this by safely removing
> VHOST_NET_F_VIRTIO_NET_HDR support. There should be very few or even
> no userspace can use this.
Quite possibly, but it is hard to be sure. It seems safer to
maintain it unless there's an actual reason something's broken.
> Further cleanups could be done for
> -net-next for safety.
>
> In the future, we need a vhost dedicated feature set/get ioctl()
> instead of reusing virtio ones.
Not just in the future, we might want to switch iommu
to a sane structure without the 64 bit padding bug
right now.
>
> Fixes: 4e9fa50c6ccbe ("vhost: move features to core")
This tag makes no sense here IMHO. Looks like people are using some tool
that just looks at the earliest version where patch won't apply. The
commit in question just moved some code around.
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/vhost/net.c | 15 +++++----------
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 986058a..83eef52 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -69,7 +69,6 @@ MODULE_PARM_DESC(experimental_zcopytx, "Enable Zero Copy TX;"
>
> enum {
> VHOST_NET_FEATURES = VHOST_FEATURES |
> - (1ULL << VHOST_NET_F_VIRTIO_NET_HDR) |
> (1ULL << VIRTIO_NET_F_MRG_RXBUF) |
> (1ULL << VIRTIO_F_IOMMU_PLATFORM)
> };
> @@ -1255,15 +1254,11 @@ static int vhost_net_set_features(struct vhost_net *n, u64 features)
> (1ULL << VIRTIO_F_VERSION_1))) ?
> sizeof(struct virtio_net_hdr_mrg_rxbuf) :
> sizeof(struct virtio_net_hdr);
> - if (features & (1 << VHOST_NET_F_VIRTIO_NET_HDR)) {
> - /* vhost provides vnet_hdr */
> - vhost_hlen = hdr_len;
> - sock_hlen = 0;
> - } else {
> - /* socket provides vnet_hdr */
> - vhost_hlen = 0;
> - sock_hlen = hdr_len;
> - }
> +
> + /* socket provides vnet_hdr */
> + vhost_hlen = 0;
> + sock_hlen = hdr_len;
> +
> mutex_lock(&n->dev.mutex);
> if ((features & (1 << VHOST_F_LOG_ALL)) &&
> !vhost_log_access_ok(&n->dev))
> --
> 2.7.4
^ permalink raw reply
* RE: [v3, 00/10] Support DPAA PTP clock and timestamping
From: Y.b. Lu @ 2018-06-08 4:45 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev@vger.kernel.org, Madalin-cristian Bucur, Rob Herring,
Shawn Guo, David S . Miller, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20180608042706.7gfg5p6574ntc2lq@localhost>
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Friday, June 8, 2018 12:27 PM
> To: Y.b. Lu <yangbo.lu@nxp.com>
> Cc: netdev@vger.kernel.org; Madalin-cristian Bucur
> <madalin.bucur@nxp.com>; Rob Herring <robh+dt@kernel.org>; Shawn Guo
> <shawnguo@kernel.org>; David S . Miller <davem@davemloft.net>;
> devicetree@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [v3, 00/10] Support DPAA PTP clock and timestamping
>
> On Thu, Jun 07, 2018 at 05:20:40PM +0800, Yangbo Lu wrote:
> > This patchset is to support DPAA FMAN PTP clock and HW timestamping.
> > It had been verified on both ARM platform and PPC platform.
> > - The patch #1 to patch #5 are to support DPAA FMAN 1588 timer in
> > ptp_qoriq driver.
> > - The patch #6 to patch #10 are to add HW timestamping support in
> > DPAA ethernet driver.
>
> Right now, net-next is closed for new stuff. You will have to post the series
> again after the merge window closes. You can check the status here:
>
>
> https://emea01.safelinks.protection.outlook.com/?url=http:%2F%2Fvger.kern
> el.org%2F~davem%2Fnet-next.html&data=02%7C01%7Cyangbo.lu%40nxp.co
> m%7Cbaab0b22e7444386c37008d5ccf81b37%7C686ea1d3bc2b4c6fa92cd99
> c5c301635%7C0%7C0%7C636640288347563742&sdata=jCmNlwoeWA50PV4
> w3lKZ%2Fs4akPjw0VV2OrJ3t4FizJ0%3D&reserved=0
>
> When you do re-post, you can add my:
>
> Acked-by: Richard Cochran <richardcochran@gmail.com>
[Y.b. Lu] Get it. And thanks a lot 😊
^ permalink raw reply
* Re: [v3, 00/10] Support DPAA PTP clock and timestamping
From: Richard Cochran @ 2018-06-08 4:27 UTC (permalink / raw)
To: Yangbo Lu
Cc: netdev, madalin.bucur, Rob Herring, Shawn Guo, David S . Miller,
devicetree, linuxppc-dev, linux-arm-kernel, linux-kernel
In-Reply-To: <20180607092050.46128-1-yangbo.lu@nxp.com>
On Thu, Jun 07, 2018 at 05:20:40PM +0800, Yangbo Lu wrote:
> This patchset is to support DPAA FMAN PTP clock and HW timestamping.
> It had been verified on both ARM platform and PPC platform.
> - The patch #1 to patch #5 are to support DPAA FMAN 1588 timer in
> ptp_qoriq driver.
> - The patch #6 to patch #10 are to add HW timestamping support in
> DPAA ethernet driver.
Right now, net-next is closed for new stuff. You will have to post
the series again after the merge window closes. You can check the
status here:
http://vger.kernel.org/~davem/net-next.html
When you do re-post, you can add my:
Acked-by: Richard Cochran <richardcochran@gmail.com>
^ permalink raw reply
* [PATCH net] vhost_net: remove VHOST_NET_F_VIRTIO_NET_HDR support
From: Jason Wang @ 2018-06-08 3:50 UTC (permalink / raw)
To: mst, jasowang; +Cc: kvm, virtualization, netdev, linux-kernel
This feature bit is duplicated with VIRTIO_F_ANY_LAYOUT, this means if
a userpsace want to enable VRITIO_F_ANY_LAYOUT,
VHOST_NET_F_VIRTIO_NET_HDR will be implied too. This is wrong and will
break networking. Fixing this by safely removing
VHOST_NET_F_VIRTIO_NET_HDR support. There should be very few or even
no userspace can use this. Further cleanups could be done for
-net-next for safety.
In the future, we need a vhost dedicated feature set/get ioctl()
instead of reusing virtio ones.
Fixes: 4e9fa50c6ccbe ("vhost: move features to core")
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/net.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 986058a..83eef52 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -69,7 +69,6 @@ MODULE_PARM_DESC(experimental_zcopytx, "Enable Zero Copy TX;"
enum {
VHOST_NET_FEATURES = VHOST_FEATURES |
- (1ULL << VHOST_NET_F_VIRTIO_NET_HDR) |
(1ULL << VIRTIO_NET_F_MRG_RXBUF) |
(1ULL << VIRTIO_F_IOMMU_PLATFORM)
};
@@ -1255,15 +1254,11 @@ static int vhost_net_set_features(struct vhost_net *n, u64 features)
(1ULL << VIRTIO_F_VERSION_1))) ?
sizeof(struct virtio_net_hdr_mrg_rxbuf) :
sizeof(struct virtio_net_hdr);
- if (features & (1 << VHOST_NET_F_VIRTIO_NET_HDR)) {
- /* vhost provides vnet_hdr */
- vhost_hlen = hdr_len;
- sock_hlen = 0;
- } else {
- /* socket provides vnet_hdr */
- vhost_hlen = 0;
- sock_hlen = hdr_len;
- }
+
+ /* socket provides vnet_hdr */
+ vhost_hlen = 0;
+ sock_hlen = hdr_len;
+
mutex_lock(&n->dev.mutex);
if ((features & (1 << VHOST_F_LOG_ALL)) &&
!vhost_log_access_ok(&n->dev))
--
2.7.4
^ permalink raw reply related
* Re: linux-next: manual merge of the scsi tree with the net-next tree
From: Stephen Rothwell @ 2018-06-08 3:11 UTC (permalink / raw)
To: James Bottomley, Martin K. Petersen, linux-scsi
Cc: Mark Brown, Chad Dupuis, David S. Miller, netdev,
Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20180525013810.GG4828@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]
Hi all,
On Fri, 25 May 2018 02:38:10 +0100 Mark Brown <broonie@kernel.org> wrote:
>
> Today's linux-next merge of the scsi tree got a conflict in:
>
> drivers/scsi/qedf/qedf.h
>
> between commit:
>
> 8673daf4f55bf3b91 ("qedf: Add get_generic_tlv_data handler.")
>
> from the net-next tree and commit:
>
> 4b9b7fabb39b3e9d7 ("scsi: qedf: Improve firmware debug dump handling")
>
> from the scsi tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc drivers/scsi/qedf/qedf.h
> index cabb6af60fb8,2372a40326f8..000000000000
> --- a/drivers/scsi/qedf/qedf.h
> +++ b/drivers/scsi/qedf/qedf.h
> @@@ -501,9 -499,8 +504,10 @@@ extern int qedf_post_io_req(struct qedf
> extern void qedf_process_seq_cleanup_compl(struct qedf_ctx *qedf,
> struct fcoe_cqe *cqe, struct qedf_ioreq *io_req);
> extern int qedf_send_flogi(struct qedf_ctx *qedf);
> +extern void qedf_get_protocol_tlv_data(void *dev, void *data);
> extern void qedf_fp_io_handler(struct work_struct *work);
> +extern void qedf_get_generic_tlv_data(void *dev, struct qed_generic_tlvs *data);
> + extern void qedf_wq_grcdump(struct work_struct *work);
>
> #define FCOE_WORD_TO_BYTE 4
> #define QEDF_MAX_TASK_NUM 0xFFFF
This is now a conflict between the scsi tree and Linus' tree.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH net v2] net/sched: act_simple: fix parsing of TCA_DEF_DATA
From: Davide Caratti @ 2018-06-08 3:02 UTC (permalink / raw)
To: Jamal Hadi Salim, Cong Wang, Jiri Pirko; +Cc: David S. Miller, netdev
use nla_strlcpy() to avoid copying data beyond the length of TCA_DEF_DATA
netlink attribute, in case it is less than SIMP_MAX_DATA and it does not
end with '\0' character.
v2: fix errors in the commit message, thanks Hangbin Liu
Fixes: fa1b1cff3d06 ("net_cls_act: Make act_simple use of netlink policy.")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
net/sched/act_simple.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/net/sched/act_simple.c b/net/sched/act_simple.c
index 9618b4a83cee..98c4afe7c15b 100644
--- a/net/sched/act_simple.c
+++ b/net/sched/act_simple.c
@@ -53,22 +53,22 @@ static void tcf_simp_release(struct tc_action *a)
kfree(d->tcfd_defdata);
}
-static int alloc_defdata(struct tcf_defact *d, char *defdata)
+static int alloc_defdata(struct tcf_defact *d, const struct nlattr *defdata)
{
d->tcfd_defdata = kzalloc(SIMP_MAX_DATA, GFP_KERNEL);
if (unlikely(!d->tcfd_defdata))
return -ENOMEM;
- strlcpy(d->tcfd_defdata, defdata, SIMP_MAX_DATA);
+ nla_strlcpy(d->tcfd_defdata, defdata, SIMP_MAX_DATA);
return 0;
}
-static void reset_policy(struct tcf_defact *d, char *defdata,
+static void reset_policy(struct tcf_defact *d, const struct nlattr *defdata,
struct tc_defact *p)
{
spin_lock_bh(&d->tcf_lock);
d->tcf_action = p->action;
memset(d->tcfd_defdata, 0, SIMP_MAX_DATA);
- strlcpy(d->tcfd_defdata, defdata, SIMP_MAX_DATA);
+ nla_strlcpy(d->tcfd_defdata, defdata, SIMP_MAX_DATA);
spin_unlock_bh(&d->tcf_lock);
}
@@ -87,7 +87,6 @@ static int tcf_simp_init(struct net *net, struct nlattr *nla,
struct tcf_defact *d;
bool exists = false;
int ret = 0, err;
- char *defdata;
if (nla == NULL)
return -EINVAL;
@@ -110,8 +109,6 @@ static int tcf_simp_init(struct net *net, struct nlattr *nla,
return -EINVAL;
}
- defdata = nla_data(tb[TCA_DEF_DATA]);
-
if (!exists) {
ret = tcf_idr_create(tn, parm->index, est, a,
&act_simp_ops, bind, false);
@@ -119,7 +116,7 @@ static int tcf_simp_init(struct net *net, struct nlattr *nla,
return ret;
d = to_defact(*a);
- ret = alloc_defdata(d, defdata);
+ ret = alloc_defdata(d, tb[TCA_DEF_DATA]);
if (ret < 0) {
tcf_idr_release(*a, bind);
return ret;
@@ -133,7 +130,7 @@ static int tcf_simp_init(struct net *net, struct nlattr *nla,
if (!ovr)
return -EEXIST;
- reset_policy(d, defdata, parm);
+ reset_policy(d, tb[TCA_DEF_DATA], parm);
}
if (ret == ACT_P_CREATED)
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net] net/sched: act_simple: fix parsing of TCA_DEFDATA
From: Davide Caratti @ 2018-06-08 3:00 UTC (permalink / raw)
To: Hangbin Liu; +Cc: netdev, jhs, xiyou.wangcong, jiri, davem
In-Reply-To: <20180608020754.GT8958@leo.usersys.redhat.com>
On Fri, 2018-06-08 at 10:07 +0800, Hangbin Liu wrote:
> On Thu, Jun 07, 2018 at 03:46:43PM +0200, Davide Caratti wrote:
> > use nla_strlcpy() to avoid copying data beyond the length of TCA_DEFDATA
>
> s/TCA_DEFDATA/TCA_DEF_DATA/, incase someone search the commit history but
> could not find it.
>
> Thanks
> Hangbin
sure, thanks, and after another look I think also the 'Fixes:' tag is
wrong. More probably it was introduced with
fa1b1cff3d06 "net_cls_act: Make act_simple use of netlink policy."
I will send a v2 in minutes.
regards,
--
davide
^ permalink raw reply
* [PATCH v2 net] net: fddi: fix a possible null-ptr-deref
From: YueHaibing @ 2018-06-08 2:58 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, YueHaibing
bp->SharedMemAddr is set to NULL while bp->SharedMemSize lesser-or-equal 0,
then memset will trigger null-ptr-deref.
fix it by replacing pci_alloc_consistent with dma_zalloc_coherent.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
v1->v2: move from pci_dma* to dma_* as Christoph suggested
---
drivers/net/fddi/skfp/skfddi.c | 55 +++++++++++++++++++++---------------------
1 file changed, 28 insertions(+), 27 deletions(-)
diff --git a/drivers/net/fddi/skfp/skfddi.c b/drivers/net/fddi/skfp/skfddi.c
index 2414f1d..72433f3e 100644
--- a/drivers/net/fddi/skfp/skfddi.c
+++ b/drivers/net/fddi/skfp/skfddi.c
@@ -297,11 +297,11 @@ static int skfp_init_one(struct pci_dev *pdev,
return 0;
err_out5:
if (smc->os.SharedMemAddr)
- pci_free_consistent(pdev, smc->os.SharedMemSize,
- smc->os.SharedMemAddr,
- smc->os.SharedMemDMA);
- pci_free_consistent(pdev, MAX_FRAME_SIZE,
- smc->os.LocalRxBuffer, smc->os.LocalRxBufferDMA);
+ dma_free_coherent(&pdev->dev, smc->os.SharedMemSize,
+ smc->os.SharedMemAddr,
+ smc->os.SharedMemDMA);
+ dma_free_coherent(&pdev->dev, MAX_FRAME_SIZE,
+ smc->os.LocalRxBuffer, smc->os.LocalRxBufferDMA);
err_out4:
free_netdev(dev);
err_out3:
@@ -328,17 +328,17 @@ static void skfp_remove_one(struct pci_dev *pdev)
unregister_netdev(p);
if (lp->os.SharedMemAddr) {
- pci_free_consistent(&lp->os.pdev,
- lp->os.SharedMemSize,
- lp->os.SharedMemAddr,
- lp->os.SharedMemDMA);
+ dma_free_coherent(&pdev->dev,
+ lp->os.SharedMemSize,
+ lp->os.SharedMemAddr,
+ lp->os.SharedMemDMA);
lp->os.SharedMemAddr = NULL;
}
if (lp->os.LocalRxBuffer) {
- pci_free_consistent(&lp->os.pdev,
- MAX_FRAME_SIZE,
- lp->os.LocalRxBuffer,
- lp->os.LocalRxBufferDMA);
+ dma_free_coherent(&pdev->dev,
+ MAX_FRAME_SIZE,
+ lp->os.LocalRxBuffer,
+ lp->os.LocalRxBufferDMA);
lp->os.LocalRxBuffer = NULL;
}
#ifdef MEM_MAPPED_IO
@@ -394,7 +394,9 @@ static int skfp_driver_init(struct net_device *dev)
spin_lock_init(&bp->DriverLock);
// Allocate invalid frame
- bp->LocalRxBuffer = pci_alloc_consistent(&bp->pdev, MAX_FRAME_SIZE, &bp->LocalRxBufferDMA);
+ bp->LocalRxBuffer = dma_alloc_coherent(&bp->pdev.dev, MAX_FRAME_SIZE,
+ &bp->LocalRxBufferDMA,
+ GFP_ATOMIC);
if (!bp->LocalRxBuffer) {
printk("could not allocate mem for ");
printk("LocalRxBuffer: %d byte\n", MAX_FRAME_SIZE);
@@ -407,23 +409,22 @@ static int skfp_driver_init(struct net_device *dev)
if (bp->SharedMemSize > 0) {
bp->SharedMemSize += 16; // for descriptor alignment
- bp->SharedMemAddr = pci_alloc_consistent(&bp->pdev,
- bp->SharedMemSize,
- &bp->SharedMemDMA);
+ bp->SharedMemAddr = dma_zalloc_coherent(&bp->pdev.dev,
+ bp->SharedMemSize,
+ &bp->SharedMemDMA,
+ GFP_ATOMIC);
if (!bp->SharedMemAddr) {
printk("could not allocate mem for ");
printk("hardware module: %ld byte\n",
bp->SharedMemSize);
goto fail;
}
- bp->SharedMemHeap = 0; // Nothing used yet.
} else {
bp->SharedMemAddr = NULL;
- bp->SharedMemHeap = 0;
- } // SharedMemSize > 0
+ }
- memset(bp->SharedMemAddr, 0, bp->SharedMemSize);
+ bp->SharedMemHeap = 0;
card_stop(smc); // Reset adapter.
@@ -442,15 +443,15 @@ static int skfp_driver_init(struct net_device *dev)
fail:
if (bp->SharedMemAddr) {
- pci_free_consistent(&bp->pdev,
- bp->SharedMemSize,
- bp->SharedMemAddr,
- bp->SharedMemDMA);
+ dma_free_coherent(&bp->pdev.dev,
+ bp->SharedMemSize,
+ bp->SharedMemAddr,
+ bp->SharedMemDMA);
bp->SharedMemAddr = NULL;
}
if (bp->LocalRxBuffer) {
- pci_free_consistent(&bp->pdev, MAX_FRAME_SIZE,
- bp->LocalRxBuffer, bp->LocalRxBufferDMA);
+ dma_free_coherent(&bp->pdev.dev, MAX_FRAME_SIZE,
+ bp->LocalRxBuffer, bp->LocalRxBufferDMA);
bp->LocalRxBuffer = NULL;
}
return err;
--
2.7.0
^ permalink raw reply related
* Re: [PATCH net-next] net: ipv6: Generate random IID for addresses on RAWIP devices
From: Lorenzo Colitti @ 2018-06-08 2:52 UTC (permalink / raw)
To: YOSHIFUJI Hideaki
Cc: Subash Abhinov Kasiviswanathan, David Miller, netdev,
YOSHIFUJI Hideaki
In-Reply-To: <CAPA1RqBmffQObdTWMxNSNMRTgM9gPjD4KGqk2+MTwdbR34Wkhw@mail.gmail.com>
On Mon, Jun 4, 2018 at 8:51 AM 吉藤英明 <hideaki.yoshifuji@miraclelinux.com> wrote:
>
> > + if (ipv6_get_lladdr(dev, &lladdr, IFA_F_TENTATIVE))
> > + get_random_bytes(eui, 8);
>
> Please be aware of I/G bit and G/L bit.
Actually, I think this is fine. RFC 7136 clarified this, and says:
======
Thus, we can conclude that the value of the "u" bit in IIDs has no
particular meaning. In the case of an IID created from a MAC address
according to RFC 4291, its value is determined by the MAC address,
but that is all.
[...]
Specifications of other forms of 64-bit IIDs MUST specify how all 64
bits are set, but a generic semantic meaning for the "u" and "g" bits
MUST NOT be defined. However, the method of generating IIDs for
specific link types MAY define some local significance for certain
bits.
In all cases, the bits in an IID have no generic semantics; in other
words, they have opaque values. In fact, the whole IID value MUST be
viewed as an opaque bit string by third parties, except possibly in
the local context.
======
That said - we already have a way to form all-random IIDs:
IN6_ADDR_GEN_MODE_RANDOM. Can't you just ensure that links of type
ARPHRD_RAWIP always use IN6_ADDR_GEN_MODE_RANDOM? That might lead to
less special-casing.
^ permalink raw reply
* [iproute2 1/1] tipc: TIPC_NLA_LINK_NAME value pass on nesting entry TIPC_NLA_LINK
From: Hoang Le @ 2018-06-08 2:19 UTC (permalink / raw)
To: netdev, tipc-discussion, jon.maloy, maloy, ying.xue
In the commit 94f6a80 on next-net, TIPC_NLA_LINK_NAME attribute should be
retrieved and validated via TIPC_NLA_LINK nesting entry in
tipc_nl_node_get_link().
According to that commit, TIPC_NLA_LINK_NAME value passing via
tipc link get command must follow above hierachy.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
---
tipc/link.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tipc/link.c b/tipc/link.c
index 02f14aadefa6..a2d7c0016bc1 100644
--- a/tipc/link.c
+++ b/tipc/link.c
@@ -97,6 +97,7 @@ static int cmd_link_get_prop(struct nlmsghdr *nlh, const struct cmd *cmd,
{
int prop;
char buf[MNL_SOCKET_BUFFER_SIZE];
+ struct nlattr *attrs;
struct opt *opt;
struct opt opts[] = {
{ "link", OPT_KEYVAL, NULL },
@@ -131,7 +132,9 @@ static int cmd_link_get_prop(struct nlmsghdr *nlh, const struct cmd *cmd,
fprintf(stderr, "error, missing link\n");
return -EINVAL;
}
+ attrs = mnl_attr_nest_start(nlh, TIPC_NLA_LINK);
mnl_attr_put_strz(nlh, TIPC_NLA_LINK_NAME, opt->val);
+ mnl_attr_nest_end(nlh, attrs);
return msg_doit(nlh, link_get_cb, &prop);
}
--
2.1.4
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply related
* Re: [PATCH net] net/sched: act_simple: fix parsing of TCA_DEFDATA
From: Hangbin Liu @ 2018-06-08 2:07 UTC (permalink / raw)
To: Davide Caratti; +Cc: netdev
In-Reply-To: <bfe72bc56c5caba64cafaea1e19bccf80b6d563b.1528379074.git.dcaratti@redhat.com>
On Thu, Jun 07, 2018 at 03:46:43PM +0200, Davide Caratti wrote:
> use nla_strlcpy() to avoid copying data beyond the length of TCA_DEFDATA
s/TCA_DEFDATA/TCA_DEF_DATA/, incase someone search the commit history but
could not find it.
Thanks
Hangbin
^ permalink raw reply
* Proposal
From: Mr. Fawaz KhE. Al Saleh @ 2018-06-08 1:41 UTC (permalink / raw)
--
Good day,
i know you do not know me personally but i have checked your profile
and i see generosity in you, There's an urgent offer attach
to your name here in the office of Mr. Fawaz KhE. Al Saleh Member of
the Board of Directors, Kuveyt Türk Participation Bank (Turkey) and
head of private banking and wealth management
Regards,
Mr. Fawaz KhE. Al Saleh
^ permalink raw reply
* Re: [Bug 199637] New: UBSAN: Undefined behaviour in net/ipv4/fib_trie.c:503:6
From: David Ahern @ 2018-06-08 1:27 UTC (permalink / raw)
To: Jakub Kicinski, Stephen Hemminger; +Cc: netdev, David Miller
In-Reply-To: <20180607170759.176186fd@cakuba.netronome.com>
On 6/7/18 5:07 PM, Jakub Kicinski wrote:
>> After recompiling the 4.16.7 kernel with gcc 8.1, UBSAN reports the following:
>>
>> [ 25.427424]
>> ================================================================================
>> [ 25.429680] UBSAN: Undefined behaviour in net/ipv4/fib_trie.c:503:6
>> [ 25.431920] member access within null pointer of type 'struct tnode'
>> [ 25.434153] CPU: 3 PID: 1 Comm: systemd Not tainted 4.16.7-CUSTOM #1
>> [ 25.436384] Hardware name: Gigabyte Technology Co., Ltd.
>> H67MA-UD2H-B3/H67MA-UD2H-B3, BIOS F8 03/27/2012
>> [ 25.438647] Call Trace:
>> [ 25.440889] dump_stack+0x62/0x9f
>> [ 25.443104] ubsan_epilogue+0x9/0x35
>> [ 25.445293] handle_null_ptr_deref+0x80/0x90
>> [ 25.447464] __ubsan_handle_type_mismatch_v1+0x6a/0x80
>> [ 25.449628] tnode_free+0xce/0x120
arguably this one should be guarded:
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 5bc0c89e81e4..32c589059fb3 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -501,7 +501,8 @@ static void tnode_free(struct key_vector *tn)
tnode_free_size += TNODE_SIZE(1ul << tn->bits);
node_free(tn);
- tn = container_of(head, struct tnode, rcu)->kv;
+ if (head)
+ tn = container_of(head, struct tnode, rcu)->kv;
}
if (tnode_free_size >= PAGE_SIZE * sync_pages) {
but if head is NULL, tn is set but not dereferenced as the loop breaks.
^ permalink raw reply related
* Re: [Bug 199643] New: UBSAN: Undefined behaviour in ./include/net/route.h:240:2
From: Jakub Kicinski @ 2018-06-08 1:02 UTC (permalink / raw)
To: Andrey Ryabinin; +Cc: David Ahern, Eric Dumazet, David Miller, stephen, netdev
In-Reply-To: <e6d18d55-2e35-b888-040f-b31117e38daf@gmail.com>
CC: Andrey
On Thu, 7 Jun 2018 17:53:35 -0700, David Ahern wrote:
> On 6/7/18 5:49 PM, Jakub Kicinski wrote:
> > On Thu, 7 Jun 2018 17:28:59 -0700, Eric Dumazet wrote:
> >> On 06/07/2018 05:11 PM, David Miller wrote:
> >>> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> >>> Date: Thu, 7 Jun 2018 17:06:23 -0700
> >>>
> >>>> [ 293.213661] ip_send_unicast_reply+0x1b67/0x1d0e
> >>>
> >>> This calls ip_setup_cork() which can NULL out the 'rt' route
> >>> pointer. Hmmm... :-/
> >>
> >> UBSAN seems unhappy with dst being NULL in :
> >>
> >> dst_release(&rt->dst);
> >>
> >> But the code obviously is ready for dst being NULL, it is even documented :)
> >
> > Oh, so the code depends on dst being the first member? Would it make
> > sense to just cast the pointer instead?
> >
>
> I've been going the other way with 'rt to dst' and 'dst to rt'
> transformations.
>
> Perhaps UBSAN should be updated to understand that NULL + 0 is ok.
^ permalink raw reply
* Re: [Bug 199643] New: UBSAN: Undefined behaviour in ./include/net/route.h:240:2
From: David Ahern @ 2018-06-08 0:53 UTC (permalink / raw)
To: Jakub Kicinski, Eric Dumazet; +Cc: David Miller, stephen, netdev
In-Reply-To: <20180607174923.13a11d08@cakuba.netronome.com>
On 6/7/18 5:49 PM, Jakub Kicinski wrote:
> On Thu, 7 Jun 2018 17:28:59 -0700, Eric Dumazet wrote:
>> On 06/07/2018 05:11 PM, David Miller wrote:
>>> From: Jakub Kicinski <jakub.kicinski@netronome.com>
>>> Date: Thu, 7 Jun 2018 17:06:23 -0700
>>>
>>>> [ 293.213661] ip_send_unicast_reply+0x1b67/0x1d0e
>>>
>>> This calls ip_setup_cork() which can NULL out the 'rt' route
>>> pointer. Hmmm... :-/
>>>
>>
>>
>> UBSAN seems unhappy with dst being NULL in :
>>
>> dst_release(&rt->dst);
>>
>> But the code obviously is ready for dst being NULL, it is even documented :)
>
> Oh, so the code depends on dst being the first member? Would it make
> sense to just cast the pointer instead?
>
I've been going the other way with 'rt to dst' and 'dst to rt'
transformations.
Perhaps UBSAN should be updated to understand that NULL + 0 is ok.
^ permalink raw reply
* Re: next-20180605 - BUG in ipv6_add_addr
From: David Ahern @ 2018-06-08 0:51 UTC (permalink / raw)
To: valdis.kletnieks; +Cc: netdev, linux-kernel
In-Reply-To: <10902.1528416198@turing-police.cc.vt.edu>
On 6/7/18 5:03 PM, valdis.kletnieks@vt.edu wrote:
> On Thu, 07 Jun 2018 16:49:07 -0700, David Ahern said:
>> On 6/7/18 1:17 PM, valdis.kletnieks@vt.edu wrote:
>
>>> [ 1820.832682] BUG: unable to handle kernel NULL pointer dereference at 0000000000000209
>>> [ 1820.832728] RIP: 0010:ipv6_add_addr+0x280/0xd10
>
>>> [ 1820.832888] Call Trace:
>>> [ 1820.832898] ? __local_bh_enable_ip+0x119/0x260
>>> [ 1820.832904] ? ipv6_create_tempaddr+0x259/0x5a0
>>> [ 1820.832912] ? __local_bh_enable_ip+0x139/0x260
>>> [ 1820.832921] ipv6_create_tempaddr+0x2da/0x5a0
>>> [ 1820.832926] ? ipv6_create_tempaddr+0x2da/0x5a0
>>> [ 1820.832941] manage_tempaddrs+0x1a5/0x240
>>> [ 1820.832951] inet6_addr_del+0x20b/0x3b0
>>> [ 1820.832959] ? nla_parse+0xce/0x1e0
>>> [ 1820.832968] inet6_rtm_deladdr+0xd9/0x210
>>> [ 1820.832981] rtnetlink_rcv_msg+0x1d4/0x5f0
>>
>> I am the most likely guilty party. I have been staring at the code for
>> this stack trace for a while and nothing jumps out. Can you send me the
>> kernel config?
>
> Attached. Note that this one happened while I was on wireless at work,
> where we're *heavily* IPv6 (I've had days where I'll work for 2-3 hours before
> I notice that IPv4 didn't dhcp and I've been ipv6-only the whole time.
>
> Also, the interface was config'ed as:
>
> conf/wlp3s0b1/temp_prefered_lft:86400
> conf/wlp3s0b1/temp_valid_lft:604800
> conf/wlp3s0b1/use_tempaddr:2
>
I know you don't have a reliable reproducer, but I did find one spot
where I was too clever and did not initialize a new cfg variable:
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 89019bf59f46..59c22a25e654 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1324,6 +1324,7 @@ static int ipv6_create_tempaddr(struct
inet6_ifaddr *ifp,
}
}
+ memset(&cfg, 0, sizeof(cfg));
cfg.valid_lft = min_t(__u32, ifp->valid_lft,
idev->cnf.temp_valid_lft + age);
cfg.preferred_lft = cnf_temp_preferred_lft + age -
idev->desync_factor;
^ permalink raw reply related
* Re: [Bug 199643] New: UBSAN: Undefined behaviour in ./include/net/route.h:240:2
From: Jakub Kicinski @ 2018-06-08 0:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, dsahern, stephen, netdev
In-Reply-To: <e05416a5-b4fe-6e9f-cefc-86848fb146cf@gmail.com>
On Thu, 7 Jun 2018 17:28:59 -0700, Eric Dumazet wrote:
> On 06/07/2018 05:11 PM, David Miller wrote:
> > From: Jakub Kicinski <jakub.kicinski@netronome.com>
> > Date: Thu, 7 Jun 2018 17:06:23 -0700
> >
> >> [ 293.213661] ip_send_unicast_reply+0x1b67/0x1d0e
> >
> > This calls ip_setup_cork() which can NULL out the 'rt' route
> > pointer. Hmmm... :-/
> >
>
>
> UBSAN seems unhappy with dst being NULL in :
>
> dst_release(&rt->dst);
>
> But the code obviously is ready for dst being NULL, it is even documented :)
Oh, so the code depends on dst being the first member? Would it make
sense to just cast the pointer instead?
^ permalink raw reply
* Re: [Bug 199643] New: UBSAN: Undefined behaviour in ./include/net/route.h:240:2
From: Eric Dumazet @ 2018-06-08 0:28 UTC (permalink / raw)
To: David Miller, jakub.kicinski; +Cc: dsahern, stephen, netdev
In-Reply-To: <20180607.201142.389815374334636334.davem@davemloft.net>
On 06/07/2018 05:11 PM, David Miller wrote:
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Date: Thu, 7 Jun 2018 17:06:23 -0700
>
>> [ 293.213661] ip_send_unicast_reply+0x1b67/0x1d0e
>
> This calls ip_setup_cork() which can NULL out the 'rt' route
> pointer. Hmmm... :-/
>
UBSAN seems unhappy with dst being NULL in :
dst_release(&rt->dst);
But the code obviously is ready for dst being NULL, it is even documented :)
^ permalink raw reply
* Re: [PATCH v2] net-fq: Add WARN_ON check for null flow.
From: Cong Wang @ 2018-06-08 0:13 UTC (permalink / raw)
To: Ben Greear; +Cc: Linux Kernel Network Developers
In-Reply-To: <1528415316-6379-1-git-send-email-greearb@candelatech.com>
On Thu, Jun 7, 2018 at 4:48 PM, <greearb@candelatech.com> wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> While testing an ath10k firmware that often crashed under load,
> I was seeing kernel crashes as well. One of them appeared to
> be a dereference of a NULL flow object in fq_tin_dequeue.
>
> I have since fixed the firmware flaw, but I think it would be
> worth adding the WARN_ON in case the problem appears again.
>
> BUG: unable to handle kernel NULL pointer dereference at 000000000000003c
> IP: ieee80211_tx_dequeue+0xfb/0xb10 [mac80211]
Instead of adding WARN_ON(), you need to think about
the locking there, it is suspicious:
fq is from struct ieee80211_local:
struct fq *fq = &local->fq;
tin is from struct txq_info:
struct fq_tin *tin = &txqi->tin;
I don't know if fq and tin are supposed to be 1:1, if not there is
a bug in the locking, because ->new_flows and ->old_flows are
both inside tin instead of fq, but they are protected by fq->lock....
^ permalink raw reply
* Re: [Bug 199643] New: UBSAN: Undefined behaviour in ./include/net/route.h:240:2
From: David Miller @ 2018-06-08 0:11 UTC (permalink / raw)
To: jakub.kicinski; +Cc: dsahern, stephen, netdev
In-Reply-To: <20180607170623.6e5d56b5@cakuba.netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Thu, 7 Jun 2018 17:06:23 -0700
> [ 293.213661] ip_send_unicast_reply+0x1b67/0x1d0e
This calls ip_setup_cork() which can NULL out the 'rt' route
pointer. Hmmm... :-/
^ permalink raw reply
* Re: [Bug 199637] New: UBSAN: Undefined behaviour in net/ipv4/fib_trie.c:503:6
From: Jakub Kicinski @ 2018-06-08 0:07 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, David Ahern, David Miller
In-Reply-To: <20180507103345.08e3992d@xeon-e3>
On Mon, 7 May 2018 10:33:45 -0700, Stephen Hemminger wrote:
> Begin forwarded message:
>
> Date: Mon, 07 May 2018 16:07:24 +0000
> From: bugzilla-daemon@bugzilla.kernel.org
> To: stephen@networkplumber.org
> Subject: [Bug 199637] New: UBSAN: Undefined behaviour in net/ipv4/fib_trie.c:503:6
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=199637
>
> Bug ID: 199637
> Summary: UBSAN: Undefined behaviour in
> net/ipv4/fib_trie.c:503:6
> Product: Networking
> Version: 2.5
> Kernel Version: 4.16.7
> Hardware: x86-64
> OS: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> Assignee: stephen@networkplumber.org
> Reporter: combuster@archlinux.us
> Regression: No
>
> After recompiling the 4.16.7 kernel with gcc 8.1, UBSAN reports the following:
>
> [ 25.427424]
> ================================================================================
> [ 25.429680] UBSAN: Undefined behaviour in net/ipv4/fib_trie.c:503:6
> [ 25.431920] member access within null pointer of type 'struct tnode'
> [ 25.434153] CPU: 3 PID: 1 Comm: systemd Not tainted 4.16.7-CUSTOM #1
> [ 25.436384] Hardware name: Gigabyte Technology Co., Ltd.
> H67MA-UD2H-B3/H67MA-UD2H-B3, BIOS F8 03/27/2012
> [ 25.438647] Call Trace:
> [ 25.440889] dump_stack+0x62/0x9f
> [ 25.443104] ubsan_epilogue+0x9/0x35
> [ 25.445293] handle_null_ptr_deref+0x80/0x90
> [ 25.447464] __ubsan_handle_type_mismatch_v1+0x6a/0x80
> [ 25.449628] tnode_free+0xce/0x120
> [ 25.451749] ? replace+0xa0/0x1f0
> [ 25.453833] ? resize+0x4e2/0xb70
> [ 25.455916] ? __kmalloc+0x1fe/0x2d0
> [ 25.457997] ? tnode_new+0x66/0x160
> [ 25.460072] ? fib_insert_alias+0x4a8/0x9e0
> [ 25.462145] ? fib_table_insert+0x208/0x690
> [ 25.464214] ? fib_magic+0x20c/0x310
> [ 25.466280] ? fib_netdev_event+0x81/0x200
> [ 25.468339] ? notifier_call_chain+0x63/0x110
> [ 25.470407] ? __dev_notify_flags+0xa8/0x170
> [ 25.472472] ? dev_change_flags+0x56/0x80
> [ 25.474538] ? do_setlink+0x3c2/0x1a00
> [ 25.476603] ? fib_magic+0x20c/0x310
> [ 25.478666] ? rtnl_setlink+0x129/0x1e0
> [ 25.480728] ? rtnetlink_rcv_msg+0x2a4/0x7d0
> [ 25.482765] ? rtnetlink_rcv+0x10/0x10
> [ 25.484757] ? netlink_rcv_skb+0x6f/0x170
> [ 25.486741] ? netlink_unicast+0x1c0/0x2d0
> [ 25.488716] ? netlink_sendmsg+0x2c1/0x630
> [ 25.490661] ? sock_sendmsg+0x49/0xb0
> [ 25.492564] ? SyS_sendto+0x12b/0x1d0
> [ 25.494449] ? do_syscall_64+0xad/0x5cc
> [ 25.496305] ? page_fault+0x2f/0x50
> [ 25.498140] ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> [ 25.499974]
> ================================================================================
>
> UBSAN reported nothing when the same kernel was compiled with gcc 7.3.1 from
> Arch Linux repositories.
>
> I have three more similar reports to make, if I continue to c/p in each I'm
> gonna feel like a fuzzbot...
>
And this one I'm seeing too (once at boot):
[ 32.459535] ================================================================================
[ 32.469133] UBSAN: Undefined behaviour in ../net/ipv4/fib_trie.c:504:6
[ 32.476534] member access within null pointer of type 'struct tnode'
[ 32.483733] CPU: 8 PID: 1 Comm: systemd Not tainted 4.17.0-rc7-debug-01088-g47bffcfef048 #9
[ 32.493191] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.3.4 11/08/2016
[ 32.501680] Call Trace:
[ 32.504513] dump_stack+0xe6/0x1a0
[ 32.508412] ? dump_stack_print_info.cold.0+0x1b/0x1b
[ 32.514164] ? do_raw_spin_lock+0xcf/0x220
[ 32.518848] ubsan_epilogue+0x9/0x7a
[ 32.522940] handle_null_ptr_deref+0x16b/0x1e0
[ 32.528008] ? ucs2_as_utf8+0x6b0/0x6b0
[ 32.532397] ? __x64_sys_sendto+0xe6/0x1d0
[ 32.537079] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 32.543025] __ubsan_handle_type_mismatch_v1+0x16b/0x19e
[ 32.549054] ? ubsan_type_mismatch_common.part.5.cold.9+0x1bb/0x1bb
[ 32.556168] ? fib_find_node+0x350/0x350
[ 32.560655] tnode_free+0x115/0x180
[ 32.564655] replace+0x21d/0x5e0
[ 32.568361] ? fib_insert_alias+0x1b20/0x1b20
[ 32.573332] ? put_child+0x546/0x7b0
[ 32.577427] ? __kmalloc+0x1b1/0x5f0
[ 32.581520] ? fib_trie_seq_start+0x510/0x510
[ 32.586497] resize+0x1253/0x2150
[ 32.590299] ? netlink_sendmsg+0x7b5/0x10c0
[ 32.595074] ? __sys_sendto+0x340/0x680
[ 32.599460] ? do_syscall_64+0x14b/0x720
[ 32.603954] ? __node_free_rcu+0x70/0x70
[ 32.608442] ? rcu_lockdep_current_cpu_online+0x1e7/0x2c0
[ 32.614578] ? rcu_dynticks_curr_cpu_in_eqs+0xd6/0x1f0
[ 32.620435] ? lockdep_rtnl_is_held+0x16/0x20
[ 32.625401] ? put_child+0x546/0x7b0
[ 32.629494] ? __kmalloc+0x1b1/0x5f0
[ 32.633586] ? fib_trie_seq_start+0x510/0x510
[ 32.638561] ? tnode_new+0x6c/0x310
[ 32.642561] fib_insert_alias+0xe9c/0x1b20
[ 32.647246] ? resize+0x2150/0x2150
[ 32.651238] ? __atomic_notifier_call_chain+0xb0/0x150
[ 32.657081] ? __atomic_notifier_call_chain+0x5/0x150
[ 32.662827] ? lock_downgrade+0x750/0x750
[ 32.667412] ? rcu_read_lock_bh_held+0xc0/0xc0
[ 32.672481] ? rcu_dynticks_curr_cpu_in_eqs+0xd6/0x1f0
[ 32.678338] ? __atomic_notifier_call_chain+0xcd/0x150
[ 32.684187] ? call_fib_notifiers+0x3d/0x90
[ 32.688955] ? call_fib_entry_notifiers+0x2a8/0x3f0
[ 32.694508] ? tnode_free+0x180/0x180
[ 32.698701] ? kmem_cache_alloc+0x37d/0x530
[ 32.703477] ? fib_net_init+0x3d0/0x3d0
[ 32.707866] fib_table_insert+0x8b2/0x18d0
[ 32.712552] ? fib_new_table+0xd1/0x5c0
[ 32.716929] ? inet_addr_type_dev_table+0x420/0x420
[ 32.722470] ? rcu_dynticks_curr_cpu_in_eqs+0xd6/0x1f0
[ 32.728314] ? replace+0x5e0/0x5e0
[ 32.732213] ? rcu_read_lock_bh_held+0xc0/0xc0
[ 32.737279] ? rcu_dynticks_curr_cpu_in_eqs+0xd6/0x1f0
[ 32.743126] ? fib_magic+0x5dd/0x980
[ 32.747222] fib_magic+0x5dd/0x980
[ 32.751124] ? fib_new_table+0x5c0/0x5c0
[ 32.755620] ? fib_add_ifaddr+0x38c/0x4a0
[ 32.760205] fib_netdev_event+0x114/0x390
[ 32.764786] notifier_call_chain+0x127/0x2c0
[ 32.769664] ? __se_sys_setns.cold.2+0x15/0x15
[ 32.774730] ? rtnl_is_locked+0x61/0xc0
[ 32.779115] ? rtnl_trylock+0x20/0x20
[ 32.783298] ? netlink_broadcast+0xf/0x20
[ 32.787876] ? nlmsg_notify+0x84/0x190
[ 32.792173] __dev_notify_flags+0x13f/0x410
[ 32.796943] ? dev_change_name+0xd90/0xd90
[ 32.801621] ? rtnl_bridge_getlink+0xcb0/0xcb0
[ 32.806686] ? __lock_acquire+0x6ad/0x3b10
[ 32.811369] ? print_irqtrace_events+0x280/0x280
[ 32.816625] ? __lock_acquire+0x6ad/0x3b10
[ 32.821310] dev_change_flags+0xea/0x140
[ 32.825792] do_setlink+0xb27/0x4300
[ 32.829885] ? debug_check_no_locks_freed+0x260/0x260
[ 32.835635] ? rtnl_link_get_net_capable.constprop.10+0x2b0/0x2b0
[ 32.842546] ? print_irqtrace_events+0x280/0x280
[ 32.847804] ? debug_check_no_locks_freed+0x260/0x260
[ 32.853551] ? debug_check_no_locks_freed+0x260/0x260
[ 32.859297] ? print_irqtrace_events+0x280/0x280
[ 32.864553] ? __lock_acquire+0x6ad/0x3b10
[ 32.869230] ? debug_check_no_locks_freed+0x260/0x260
[ 32.874964] ? debug_check_no_locks_freed+0x260/0x260
[ 32.880712] ? debug_check_no_locks_freed+0x260/0x260
[ 32.886463] ? __lock_acquire+0x6ad/0x3b10
[ 32.891135] ? print_irqtrace_events+0x280/0x280
[ 32.896399] ? __is_insn_slot_addr+0x238/0x490
[ 32.901474] ? lock_acquire+0x1a2/0x5a0
[ 32.905859] ? rtnetlink_rcv_msg+0x359/0xb10
[ 32.910733] ? lock_release+0x980/0x980
[ 32.915124] ? finish_task_switch+0xc10/0xc10
[ 32.920096] ? __bpf_trace_xdp_cpumap_enqueue+0x10/0x10
[ 32.926046] ? __mutex_lock+0xd17/0x1b50
[ 32.930529] ? rtnetlink_rcv_msg+0x359/0xb10
[ 32.935398] ? __lock_acquire+0x6ad/0x3b10
[ 32.940080] ? __ww_mutex_wakeup_for_backoff+0x330/0x330
[ 32.946120] ? memset+0x1f/0x40
[ 32.949729] ? nla_parse+0x7d/0x4e0
[ 32.953726] ? nla_validate+0x360/0x360
[ 32.958121] rtnl_setlink+0x256/0x400
[ 32.962313] ? do_setlink+0x4300/0x4300
[ 32.966732] ? rcu_dynticks_curr_cpu_in_eqs+0xd6/0x1f0
[ 32.972582] ? security_capable+0x4e/0x90
[ 32.977167] rtnetlink_rcv_msg+0x3aa/0xb10
[ 32.981848] ? rtnl_get_link+0x2c0/0x2c0
[ 32.986333] ? netlink_lookup+0xb9/0x140
[ 32.990813] ? netlink_seq_show+0x620/0x620
[ 32.995592] netlink_rcv_skb+0x13a/0x390
[ 33.000071] ? rtnl_get_link+0x2c0/0x2c0
[ 33.004554] ? finish_task_switch+0xc10/0xc10
[ 33.009512] ? netlink_ack+0xa90/0xa90
[ 33.013815] netlink_unicast+0x45f/0x6e0
[ 33.018302] ? netlink_sendskb+0x60/0x60
[ 33.022787] ? aa_af_perm+0x520/0x520
[ 33.026975] ? lock_downgrade+0x750/0x750
[ 33.031554] ? lock_release+0x980/0x980
[ 33.035935] ? security_socket_getpeersec_dgram+0x52/0xa0
[ 33.042074] netlink_sendmsg+0x7b5/0x10c0
[ 33.046660] ? nlmsg_notify+0x190/0x190
[ 33.051052] ? nlmsg_notify+0x190/0x190
[ 33.055435] sock_sendmsg+0xdf/0x180
[ 33.059528] __sys_sendto+0x340/0x680
[ 33.063723] ? __ia32_sys_getpeername+0xc0/0xc0
[ 33.068921] ? kernel_setsockopt+0x340/0x340
[ 33.073885] ? __sys_socket+0x148/0x220
[ 33.078275] ? __bpf_trace_sys_enter+0x10/0x10
[ 33.083344] __x64_sys_sendto+0xe6/0x1d0
[ 33.087827] ? trace_hardirqs_on_caller+0x3d0/0x630
[ 33.093378] do_syscall_64+0x14b/0x720
[ 33.097668] ? syscall_return_slowpath+0x560/0x560
[ 33.103126] ? syscall_return_slowpath+0x38d/0x560
[ 33.108582] ? entry_SYSCALL_64_after_hwframe+0x59/0xbe
[ 33.114528] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 33.119890] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 33.125636] RIP: 0033:0x7fc408e74da7
[ 33.129730] RSP: 002b:00007ffd4f2cf4e8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
[ 33.138319] RAX: ffffffffffffffda RBX: 000055e490a09390 RCX: 00007fc408e74da7
[ 33.146397] RDX: 0000000000000020 RSI: 000055e490a07890 RDI: 0000000000000004
[ 33.154476] RBP: 000055e490a0dad0 R08: 00007ffd4f2cf4f0 R09: 0000000000000010
[ 33.162544] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
[ 33.170622] R13: 00007ffd4f2cf564 R14: 00007ffd4f2cf5d0 R15: 000055e490a07a60
[ 33.178717] ================================================================================
^ permalink raw reply
* Re: [PATCH net] bpfilter: fix race in pipe access
From: David Miller @ 2018-06-08 0:07 UTC (permalink / raw)
To: ast; +Cc: daniel, netdev, dvyukov, willy, kernel-team
In-Reply-To: <20180607223114.189970-1-ast@kernel.org>
From: Alexei Starovoitov <ast@kernel.org>
Date: Thu, 7 Jun 2018 15:31:14 -0700
> syzbot reported the following crash
> [ 338.293946] bpfilter: read fail -512
> [ 338.304515] kasan: GPF could be caused by NULL-ptr deref or user memory access
> [ 338.311863] general protection fault: 0000 [#1] SMP KASAN
> [ 338.344360] RIP: 0010:__vfs_write+0x4a6/0x960
> [ 338.426363] Call Trace:
> [ 338.456967] __kernel_write+0x10c/0x380
> [ 338.460928] __bpfilter_process_sockopt+0x1d8/0x35b
> [ 338.487103] bpfilter_mbox_request+0x4d/0xb0
> [ 338.491492] bpfilter_ip_get_sockopt+0x6b/0x90
>
> This can happen when multiple cpus trying to talk to user mode process
> via bpfilter_mbox_request(). One cpu grabs the mutex while another goes to
> sleep on the same mutex. Then former cpu sees that umh pipe is down and
> shuts down the pipes. Later cpu finally acquires the mutex and crashes
> on freed pipe.
> Fix the race by using info.pid as an indicator that umh and pipes are healthy
> and check it after acquiring the mutex.
>
> Fixes: d2ba09c17a06 ("net: add skeleton of bpfilter kernel module")
> Reported-by: syzbot+7ade6c94abb2774c0fee@syzkaller.appspotmail.com
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Applied, thanks Alexei.
^ permalink raw reply
* Re: pull-request: bpf 2018-06-08
From: David Miller @ 2018-06-08 0:06 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <20180607233000.9699-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Fri, 8 Jun 2018 01:30:00 +0200
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
...
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Pulled, thanks Daniel.
^ 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