* [PATCH v2 19/22] arm64: dts: ls104x: add missing dma ranges property
From: laurentiu.tudor @ 2018-09-26 13:22 UTC (permalink / raw)
To: devicetree, netdev, linux-kernel, linux-arm-kernel
Cc: roy.pledge, madalin.bucur, davem, shawnguo, leoyang.li,
robin.murphy, bharat.bhushan, Laurentiu Tudor
In-Reply-To: <20180926132247.10971-1-laurentiu.tudor@nxp.com>
From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
These chips have a 48-bit address size so make sure that the dma-ranges
reflects this. Otherwise the linux kernel's dma sub-system will set
the default dma masks to full 64-bit, badly breaking dmas.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 1 +
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 1f9b385007a8..0e8fc8f29997 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -214,6 +214,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+ dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
clockgen: clocking@1ee1000 {
compatible = "fsl,ls1043a-clockgen";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 22bf3975492a..29b07bdd4207 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -187,6 +187,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+ dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
ddr: memory-controller@1080000 {
compatible = "fsl,qoriq-memory-controller";
--
2.17.1
^ permalink raw reply related
* [PATCH v2 20/22] arm64: dts: ls104x: add iommu-map to pci controllers
From: laurentiu.tudor @ 2018-09-26 13:22 UTC (permalink / raw)
To: devicetree, netdev, linux-kernel, linux-arm-kernel
Cc: roy.pledge, madalin.bucur, davem, shawnguo, leoyang.li,
robin.murphy, bharat.bhushan, Laurentiu Tudor
In-Reply-To: <20180926132247.10971-1-laurentiu.tudor@nxp.com>
From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
The pci controllers are also behind the smmu so add the iommu-map
property to reflect this. The bootloader needs to patch the stream id
ranges to some sane values.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 +++
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 3 +++
2 files changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 0e8fc8f29997..ccadc40a36f4 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -716,6 +716,7 @@
#size-cells = <2>;
device_type = "pci";
dma-coherent;
+ iommu-map = <0 &mmu 0 1>;
num-lanes = <4>;
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x00000000 0x40 0x00010000 0x0 0x00010000 /* downstream I/O */
@@ -741,6 +742,7 @@
#size-cells = <2>;
device_type = "pci";
dma-coherent;
+ iommu-map = <0 &mmu 0 1>;
num-lanes = <2>;
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x00000000 0x48 0x00010000 0x0 0x00010000 /* downstream I/O */
@@ -766,6 +768,7 @@
#size-cells = <2>;
device_type = "pci";
dma-coherent;
+ iommu-map = <0 &mmu 0 1>;
num-lanes = <2>;
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x00000000 0x50 0x00010000 0x0 0x00010000 /* downstream I/O */
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 29b07bdd4207..a12d33362554 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -685,6 +685,7 @@
#size-cells = <2>;
device_type = "pci";
dma-coherent;
+ iommu-map = <0 &mmu 0 1>;
num-lanes = <4>;
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x00000000 0x40 0x00010000 0x0 0x00010000 /* downstream I/O */
@@ -710,6 +711,7 @@
#size-cells = <2>;
device_type = "pci";
dma-coherent;
+ iommu-map = <0 &mmu 0 1>;
num-lanes = <2>;
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x00000000 0x48 0x00010000 0x0 0x00010000 /* downstream I/O */
@@ -735,6 +737,7 @@
#size-cells = <2>;
device_type = "pci";
dma-coherent;
+ iommu-map = <0 &mmu 0 1>;
num-lanes = <2>;
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x00000000 0x50 0x00010000 0x0 0x00010000 /* downstream I/O */
--
2.17.1
^ permalink raw reply related
* [PATCH v2 21/22] arm64: dts: ls104x: make dma-coherent global to the SoC
From: laurentiu.tudor @ 2018-09-26 13:22 UTC (permalink / raw)
To: devicetree, netdev, linux-kernel, linux-arm-kernel
Cc: roy.pledge, madalin.bucur, davem, shawnguo, leoyang.li,
robin.murphy, bharat.bhushan, Laurentiu Tudor
In-Reply-To: <20180926132247.10971-1-laurentiu.tudor@nxp.com>
From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
These SoCs are really completely dma coherent in their entirety so add
the dma-coherent property at the soc level in the device tree and drop
the instances where it's specifically added to a few select devices.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 5 +----
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 1 +
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index ccadc40a36f4..9fb3ac0fa87c 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -215,6 +215,7 @@
#size-cells = <2>;
ranges;
dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
+ dma-coherent;
clockgen: clocking@1ee1000 {
compatible = "fsl,ls1043a-clockgen";
@@ -680,7 +681,6 @@
reg-names = "ahci", "sata-ecc";
interrupts = <0 69 0x4>;
clocks = <&clockgen 4 0>;
- dma-coherent;
};
msi1: msi-controller1@1571000 {
@@ -715,7 +715,6 @@
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
- dma-coherent;
iommu-map = <0 &mmu 0 1>;
num-lanes = <4>;
bus-range = <0x0 0xff>;
@@ -741,7 +740,6 @@
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
- dma-coherent;
iommu-map = <0 &mmu 0 1>;
num-lanes = <2>;
bus-range = <0x0 0xff>;
@@ -767,7 +765,6 @@
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
- dma-coherent;
iommu-map = <0 &mmu 0 1>;
num-lanes = <2>;
bus-range = <0x0 0xff>;
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index a12d33362554..f19cf6087235 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -188,6 +188,7 @@
#size-cells = <2>;
ranges;
dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
+ dma-coherent;
ddr: memory-controller@1080000 {
compatible = "fsl,qoriq-memory-controller";
--
2.17.1
^ permalink raw reply related
* [PATCH v2 22/22] arm64: dts: ls104x: use a pseudo-bus to constrain usb dma size
From: laurentiu.tudor @ 2018-09-26 13:22 UTC (permalink / raw)
To: devicetree, netdev, linux-kernel, linux-arm-kernel
Cc: roy.pledge, madalin.bucur, davem, shawnguo, leoyang.li,
robin.murphy, bharat.bhushan, Laurentiu Tudor
In-Reply-To: <20180926132247.10971-1-laurentiu.tudor@nxp.com>
From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Wrap the usb controllers in an intermediate simple-bus and use it to
constrain the dma address size of these usb controllers to the 40 bits
that they generate toward the interconnect.
This is required because the SoC uses 48 bits address sizes and this
mismatch would lead to smmu context faults because the usb generates
40-bit addresses while the smmu page tables are populated with 48-bit
wide addresses.
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
---
.../arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 58 +++++++++++--------
.../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 58 +++++++++++--------
2 files changed, 66 insertions(+), 50 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 9fb3ac0fa87c..44a1964e560b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -647,31 +647,39 @@
<&clockgen 4 0>;
};
- usb0: usb3@2f00000 {
- compatible = "snps,dwc3";
- reg = <0x0 0x2f00000 0x0 0x10000>;
- interrupts = <0 60 0x4>;
- dr_mode = "host";
- snps,quirk-frame-length-adjustment = <0x20>;
- snps,dis_rxdet_inp3_quirk;
- };
-
- usb1: usb3@3000000 {
- compatible = "snps,dwc3";
- reg = <0x0 0x3000000 0x0 0x10000>;
- interrupts = <0 61 0x4>;
- dr_mode = "host";
- snps,quirk-frame-length-adjustment = <0x20>;
- snps,dis_rxdet_inp3_quirk;
- };
-
- usb2: usb3@3100000 {
- compatible = "snps,dwc3";
- reg = <0x0 0x3100000 0x0 0x10000>;
- interrupts = <0 63 0x4>;
- dr_mode = "host";
- snps,quirk-frame-length-adjustment = <0x20>;
- snps,dis_rxdet_inp3_quirk;
+ usb_aux_bus: usb_aux_bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ compatible = "simple-bus";
+ ranges;
+ dma-ranges = <0x0 0x0 0x0 0x0 0x100 0x00000000>;
+
+ usb0: usb3@2f00000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0x2f00000 0x0 0x10000>;
+ interrupts = <0 60 0x4>;
+ dr_mode = "host";
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,dis_rxdet_inp3_quirk;
+ };
+
+ usb1: usb3@3000000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0x3000000 0x0 0x10000>;
+ interrupts = <0 61 0x4>;
+ dr_mode = "host";
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,dis_rxdet_inp3_quirk;
+ };
+
+ usb2: usb3@3100000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0x3100000 0x0 0x10000>;
+ interrupts = <0 63 0x4>;
+ dr_mode = "host";
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,dis_rxdet_inp3_quirk;
+ };
};
sata: sata@3200000 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index f19cf6087235..edee071aaefd 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -608,31 +608,39 @@
<&clockgen 4 1>;
};
- usb0: usb@2f00000 {
- compatible = "snps,dwc3";
- reg = <0x0 0x2f00000 0x0 0x10000>;
- interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
- dr_mode = "host";
- snps,quirk-frame-length-adjustment = <0x20>;
- snps,dis_rxdet_inp3_quirk;
- };
-
- usb1: usb@3000000 {
- compatible = "snps,dwc3";
- reg = <0x0 0x3000000 0x0 0x10000>;
- interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
- dr_mode = "host";
- snps,quirk-frame-length-adjustment = <0x20>;
- snps,dis_rxdet_inp3_quirk;
- };
-
- usb2: usb@3100000 {
- compatible = "snps,dwc3";
- reg = <0x0 0x3100000 0x0 0x10000>;
- interrupts = <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>;
- dr_mode = "host";
- snps,quirk-frame-length-adjustment = <0x20>;
- snps,dis_rxdet_inp3_quirk;
+ usb_aux_bus: usb_aux_bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ compatible = "simple-bus";
+ ranges;
+ dma-ranges = <0x0 0x0 0x0 0x0 0x100 0x00000000>;
+
+ usb0: usb@2f00000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0x2f00000 0x0 0x10000>;
+ interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ dr_mode = "host";
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,dis_rxdet_inp3_quirk;
+ };
+
+ usb1: usb@3000000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0x3000000 0x0 0x10000>;
+ interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+ dr_mode = "host";
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,dis_rxdet_inp3_quirk;
+ };
+
+ usb2: usb@3100000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0x3100000 0x0 0x10000>;
+ interrupts = <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>;
+ dr_mode = "host";
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,dis_rxdet_inp3_quirk;
+ };
};
sata: sata@3200000 {
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
From: Jason A. Donenfeld @ 2018-09-26 13:32 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Jean-Philippe Aumasson, Russell King - ARM Linux,
linux-arm-kernel
In-Reply-To: <CAKv+Gu9mVAfdBvOMCFqRJj+wBiWu3JVOgPZdkcdjzqSdQQ5Jrw@mail.gmail.com>
Hi Ard,
On Wed, Sep 26, 2018 at 10:59 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> > +static inline bool chacha20_arch(struct chacha20_ctx *state, u8 *dst,
> > + const u8 *src, size_t len,
> > + simd_context_t *simd_context)
> > +{
> > +#if defined(CONFIG_KERNEL_MODE_NEON)
> > + if (chacha20_use_neon && len >= CHACHA20_BLOCK_SIZE * 3 &&
> > + simd_use(simd_context))
> > + chacha20_neon(dst, src, len, state->key, state->counter);
> > + else
> > +#endif
>
> Better to use IS_ENABLED() here:
>
> > + if (IS_ENABLED(CONFIG_KERNEL_MODE_NEON)) &&
> > + chacha20_use_neon && len >= CHACHA20_BLOCK_SIZE * 3 &&
> > + simd_use(simd_context))
Good idea. I'll fix that up.
>
> Also, this still has unbounded worst case scheduling latency, given
> that the outer library function passes its entire input straight into
> the NEON routine.
The vast majority of crypto routines in arch/*/crypto/ follow this
same exact pattern, actually. I realize a few don't -- probably the
ones you had a hand in :) -- but I think this is up to the caller to
handle. I made a change so that in chacha20poly1305.c, it calls
simd_relax after handling each scatter-gather element, so a
"construction" will handle this gracefully. But I believe it's up to
the caller to decide on what sizes of information it wants to pass to
primitives. Put differently, this also hasn't ever been an issue
before -- the existing state of the tree indicates this -- and so I
don't anticipate this will be a real issue now. And if it becomes one,
this is something we can address *later*, but certainly there's no use
of adding additional complexity to the initial patchset to do this
now.
Jason
^ permalink raw reply
* KASAN: slab-out-of-bounds Read in tls_push_record
From: syzbot @ 2018-09-26 7:49 UTC (permalink / raw)
To: aviadye, borisp, davejwatson, davem, linux-kernel, netdev,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 739d0def85ca Merge branch 'hv_netvsc-Support-LRO-RSC-in-th..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13aa179e400000
kernel config: https://syzkaller.appspot.com/x/.config?x=e79b9299baeb2298
dashboard link: https://syzkaller.appspot.com/bug?extid=942a1909765f0413329b
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+942a1909765f0413329b@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-out-of-bounds in sg_mark_end
include/linux/scatterlist.h:195 [inline]
BUG: KASAN: slab-out-of-bounds in tls_push_record+0x1243/0x1330
net/tls/tls_sw.c:521
Read of size 8 at addr ffff8801a4d235f8 by task syz-executor1/7668
CPU: 1 PID: 7668 Comm: syz-executor1 Not tainted 4.19.0-rc4+ #228
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
sg_mark_end include/linux/scatterlist.h:195 [inline]
tls_push_record+0x1243/0x1330 net/tls/tls_sw.c:521
tls_sw_push_pending_record+0x22/0x30 net/tls/tls_sw.c:558
tls_handle_open_record net/tls/tls_main.c:155 [inline]
tls_sk_proto_close+0x439/0x750 net/tls/tls_main.c:272
inet_release+0x104/0x1f0 net/ipv4/af_inet.c:428
inet6_release+0x50/0x70 net/ipv6/af_inet6.c:458
__sock_release+0xd7/0x250 net/socket.c:579
sock_close+0x19/0x20 net/socket.c:1141
__fput+0x385/0xa30 fs/file_table.c:278
____fput+0x15/0x20 fs/file_table.c:309
task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:193 [inline]
exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x411151
Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 34 19 00 00 c3 48
83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48
89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
RSP: 002b:00007fff8ba9e200 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 0000000000000005 RCX: 0000000000411151
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001
R10: 00007fff8ba9e130 R11: 0000000000000293 R12: 000000000000000f
R13: 0000000000086e3d R14: 0000000000000412 R15: badc0ffeebadface
Allocated by task 0:
(stack is not available)
Freed by task 0:
(stack is not available)
The buggy address belongs to the object at ffff8801a4d22d80
which belongs to the cache kmalloc-2048 of size 2048
The buggy address is located 120 bytes to the right of
2048-byte region [ffff8801a4d22d80, ffff8801a4d23580)
The buggy address belongs to the page:
page:ffffea0006934880 count:1 mapcount:0 mapping:ffff8801da800c40 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea000717fd08 ffff8801da801948 ffff8801da800c40
raw: 0000000000000000 ffff8801a4d22500 0000000100000003 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801a4d23480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801a4d23500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801a4d23580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8801a4d23600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8801a4d23680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: [PATCH] mt76: fix building without CONFIG_MT76x0U
From: Stanislaw Gruszka @ 2018-09-26 14:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kalle Valo, Felix Fietkau, Lorenzo Bianconi, David S. Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20180926125356.2026635-1-arnd@arndb.de>
On Wed, Sep 26, 2018 at 02:51:59PM +0200, Arnd Bergmann wrote:
> The recent rework of the mt76 driver caused build failures in
> configurations that leave the mt76x0u support disabled:
>
> ERROR: "mt76u_mcu_deinit" [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined!
> ERROR: "mt76x02u_set_txinfo" [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined!
> ERROR: "mt76u_queues_deinit" [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined!
> ERROR: "mt76u_stop_stat_wk" [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined!
>
> The mt76x0_push_txwi()/mt76x0_tx_prepare_skb()/mt76x0_cleanup() functions
> that cause some of these are only called from the usb portion, and can
> be hidden in an #ifdef in this case.
>
> mt76u_stop_stat_wk() is called mt76x0_mac_stop(), which is in turn
> shared between multiple callers. Calling it only when the USB driver
> is enabled avoids the link error but it is not clear to me whether this
> can be called from a context where it would not do the right thing.
I think there not yet posted Lorenzo patches that fix this build
problem.
Regards
Stanislaw
^ permalink raw reply
* Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
From: Andrew Lunn @ 2018-09-26 14:36 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Ard Biesheuvel, Jean-Philippe Aumasson, Netdev, LKML,
Russell King - ARM Linux, Samuel Neves, Linux Crypto Mailing List,
Andrew Lutomirski, Greg Kroah-Hartman, David Miller,
linux-arm-kernel
In-Reply-To: <CAHmME9r9KppoFwwNVpzpYbU+9dCPzb7Pit+4iRa4MY_ouJBWrA@mail.gmail.com>
> > Also, this still has unbounded worst case scheduling latency, given
> > that the outer library function passes its entire input straight into
> > the NEON routine.
>
> The vast majority of crypto routines in arch/*/crypto/ follow this
> same exact pattern, actually. I realize a few don't -- probably the
> ones you had a hand in :) -- but I think this is up to the caller to
> handle. I made a change so that in chacha20poly1305.c, it calls
> simd_relax after handling each scatter-gather element, so a
> "construction" will handle this gracefully. But I believe it's up to
> the caller to decide on what sizes of information it wants to pass to
> primitives. Put differently, this also hasn't ever been an issue
> before -- the existing state of the tree indicates this -- and so I
> don't anticipate this will be a real issue now. And if it becomes one,
> this is something we can address *later*, but certainly there's no use
> of adding additional complexity to the initial patchset to do this
> now.
Hi Jason
This is not my area of expertise, so you should verify what i'm say
here...
My guess is, IPSEC will mostly ask the crypto code to work on 1500
byte full MTU packets and 64 byte TCP ACK packets. Disk encryption i
guess works on 4K blocks. So these requests are all quite small,
keeping the latency reasonably bounded.
The wireguard interface claims it is GSO capable. This means the
network stack will pass it big chunks of data and leave it to the
network interface to perform the segmentation into 1500 byte MTU
frames on the wire. I've not looked at how wireguard actually handles
these big chunks. But to get maximum performance, it should try to
keep them whole, just add a header and/or trailer. Will wireguard pass
these big chunks of data to the crypto code? Do we now have 64K blocks
being worked on? Does the latency jump from 4K to 64K? That might be
new, so the existing state of the tree does not help you here.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] phy: mscc: fix printf format
From: Alexandre Belloni @ 2018-09-26 14:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Lunn, Florian Fainelli, David S. Miller, Quentin Schulz,
netdev, linux-kernel
In-Reply-To: <20180926132021.2933754-1-arnd@arndb.de>
On 26/09/2018 15:20:11+0200, Arnd Bergmann wrote:
> gcc points out that the length of the temporary buffer may not be sufficient for
> large numbers of leds:
>
> drivers/net/phy/mscc.c: In function 'vsc85xx_probe':
> drivers/net/phy/mscc.c:460:45: error: '-mode' directive writing 5 bytes into a region of size between 0 and 9 [-Werror=format-overflow=]
> ret = sprintf(led_dt_prop, "vsc8531,led-%d-mode", i);
> ^~~~~
> drivers/net/phy/mscc.c:460:9: note: 'sprintf' output between 19 and 28 bytes into a destination of size 22
> ret = sprintf(led_dt_prop, "vsc8531,led-%d-mode", i);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> While we can make a reasonable assumption that the number of LEDs is small,
> the cost of making the buffer a little bigger is insignificant as well.
>
> Fixes: 11bfdabb7ff5 ("net: phy: mscc: factorize code for LEDs mode")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> drivers/net/phy/mscc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
> index 2d9676d78d3f..7d0384e26c99 100644
> --- a/drivers/net/phy/mscc.c
> +++ b/drivers/net/phy/mscc.c
> @@ -453,7 +453,7 @@ static int vsc85xx_dt_led_modes_get(struct phy_device *phydev,
> u32 *default_mode)
> {
> struct vsc8531_private *priv = phydev->priv;
> - char led_dt_prop[19];
> + char led_dt_prop[28];
> int i, ret;
>
> for (i = 0; i < priv->nleds; i++) {
> --
> 2.18.0
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [RFC 2/3 net] lorawan: Add macro and definition for LoRaWAN class modlue
From: Jian-Hong Pan @ 2018-09-26 14:46 UTC (permalink / raw)
To: Andreas Färber
Cc: netdev, <linux-arm-kernel@lists.infradead.org\,
linux-kernel@vger.kernel.org>,, Jiri Pirko, Marcel Holtmann,
David S. Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm,
Jan Jongboom, Jon Ortego, linux-kernel@vger.kernel.org>,,
Ben Whitten, Brian Ray, lora
In-Reply-To: <f74c033a-fadc-fb8c-9469-6e6a32339cd8@suse.de>
Andreas Färber <afaerber@suse.de> 於 2018年9月24日 週一 上午12:06寫道：
>
> Hi Jian-Hong,
>
> Many thanks and sorry for the delay. This patch mostly looks good and
> should go in before its first uses, so I would like to queue it soon for
> my hardware-MAC module drivers - but some questions below. Also a typo
> in the subject, and we should probably prepend "net: " and I would
> personally not mention the module here as it's a userspace API.
>
> Am 23.08.18 um 19:15 schrieb Jian-Hong Pan:
> > This patch add the macro and definition for the implementation of
> > LoRaWAN protocol.
>
> I would fix up the grammar nits in my tree then.
Oh! The grammar things should be fixed. Thanks
And, I am preparing V2 patch, too.
> >
> > Signed-off-by: Jian-Hong Pan <starnight@g.ncu.edu.tw>
> > ---
> > include/linux/socket.h | 5 ++++-
> > include/uapi/linux/if_arp.h | 1 +
> > include/uapi/linux/if_ether.h | 1 +
> > net/core/dev.c | 4 ++--
> > security/selinux/hooks.c | 4 +++-
> > security/selinux/include/classmap.h | 4 +++-
> > 6 files changed, 14 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/linux/socket.h b/include/linux/socket.h
> > index aa1e288b1659..e5c8381fd1aa 100644
> > --- a/include/linux/socket.h
> > +++ b/include/linux/socket.h
> > @@ -209,8 +209,9 @@ struct ucred {
> > */
> > #define AF_XDP 44 /* XDP sockets */
> > #define AF_LORA 45 /* LoRa sockets */
> > +#define AF_LORAWAN 46 /* LoRaWAN sockets */
> >
> > -#define AF_MAX 46 /* For now.. */
> > +#define AF_MAX 47 /* For now.. */
> >
> > /* Protocol families, same as address families. */
> > #define PF_UNSPEC AF_UNSPEC
> > @@ -261,6 +262,7 @@ struct ucred {
> > #define PF_SMC AF_SMC
> > #define PF_XDP AF_XDP
> > #define PF_LORA AF_LORA
> > +#define PF_LORAWAN AF_LORAWAN
> > #define PF_MAX AF_MAX
> >
> > /* Maximum queue length specifiable by listen. */
> > @@ -343,6 +345,7 @@ struct ucred {
> > #define SOL_KCM 281
> > #define SOL_TLS 282
> > #define SOL_XDP 283
> > +#define SOL_LORAWAN 284
> >
> > /* IPX options */
> > #define IPX_TYPE 1
> > diff --git a/include/uapi/linux/if_arp.h b/include/uapi/linux/if_arp.h
> > index 1ed7cb3f2129..2376f7839355 100644
> > --- a/include/uapi/linux/if_arp.h
> > +++ b/include/uapi/linux/if_arp.h
> > @@ -99,6 +99,7 @@
> > #define ARPHRD_6LOWPAN 825 /* IPv6 over LoWPAN */
> > #define ARPHRD_VSOCKMON 826 /* Vsock monitor header */
> > #define ARPHRD_LORA 827 /* LoRa */
> > +#define ARPHRD_LORAWAN 828 /* LoRaWAN */
> >
> > #define ARPHRD_VOID 0xFFFF /* Void type, nothing is known */
> > #define ARPHRD_NONE 0xFFFE /* zero header length */
> > diff --git a/include/uapi/linux/if_ether.h b/include/uapi/linux/if_ether.h
> > index 45644dcf5b39..b1ac70d4a377 100644
> > --- a/include/uapi/linux/if_ether.h
> > +++ b/include/uapi/linux/if_ether.h
> > @@ -148,6 +148,7 @@
> > * aggregation protocol
> > */
> > #define ETH_P_LORA 0x00FA /* LoRa */
> > +#define ETH_P_LORAWAN 0x00FB /* LoRaWAN */
> >
> > /*
> > * This is an Ethernet frame header.
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index f68122f0ab02..b95ce79ec5a8 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -297,7 +297,7 @@ static const unsigned short netdev_lock_type[] = {
> > ARPHRD_IRDA, ARPHRD_FCPP, ARPHRD_FCAL, ARPHRD_FCPL,
> > ARPHRD_FCFABRIC, ARPHRD_IEEE80211, ARPHRD_IEEE80211_PRISM,
> > ARPHRD_IEEE80211_RADIOTAP, ARPHRD_PHONET, ARPHRD_PHONET_PIPE,
> > - ARPHRD_IEEE802154, ARPHRD_VOID, ARPHRD_NONE};
> > + ARPHRD_IEEE802154, ARPHRD_LORAWAN, ARPHRD_VOID, ARPHRD_NONE};
> >
> > static const char *const netdev_lock_name[] = {
> > "_xmit_NETROM", "_xmit_ETHER", "_xmit_EETHER", "_xmit_AX25",
> > @@ -314,7 +314,7 @@ static const char *const netdev_lock_name[] = {
> > "_xmit_IRDA", "_xmit_FCPP", "_xmit_FCAL", "_xmit_FCPL",
> > "_xmit_FCFABRIC", "_xmit_IEEE80211", "_xmit_IEEE80211_PRISM",
> > "_xmit_IEEE80211_RADIOTAP", "_xmit_PHONET", "_xmit_PHONET_PIPE",
> > - "_xmit_IEEE802154", "_xmit_VOID", "_xmit_NONE"};
> > + "_xmit_IEEE802154", "_xmit_LORAWAN", "_xmit_VOID", "_xmit_NONE"};
> >
> > static struct lock_class_key netdev_xmit_lock_key[ARRAY_SIZE(netdev_lock_type)];
> > static struct lock_class_key netdev_addr_lock_key[ARRAY_SIZE(netdev_lock_type)];
>
> All your new constants except SOL_LORAWAN are always next to a LoRa one,
> but not in these two arrays. I don't have such changes in my original
> LoRa patch - am I missing such an array extension for ARPHRD_LORA then,
> or what is the criteria for when to add this?
That is for "ip" related commands or something else I did not discover.
For example:
$ ip link show lora0
4: lora0: <NOARP,UP,LOWER_UP> mtu 20 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/[828] 01:02:03:04 brd ff:ff:ff:ff
The 828 is ARPHRD_LORAWAN.
Regards,
Jian-Hong Pan
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: support combinations of FEC modes
From: Ariel Almog @ 2018-09-26 8:47 UTC (permalink / raw)
To: ecree
Cc: linville, Linux Netdev List, ganeshgr, jakub.kicinski, dustin,
dirk.vandermerwe, shayag, ariela
In-Reply-To: <811cf92b-51ed-4a8f-4b69-113cdd8473df@mellanox.com>
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -4967,20 +4967,48 @@ static int do_set_phy_tunable(struct cmd_context
> *ctx)
> static int fecmode_str_to_type(const char *str)
> {
> + if (!strcasecmp(str, "auto"))
> + return ETHTOOL_FEC_AUTO;
> + if (!strcasecmp(str, "off"))
> + return ETHTOOL_FEC_OFF;
> + if (!strcasecmp(str, "rs"))
> + return ETHTOOL_FEC_RS;
> + if (!strcasecmp(str, "baser"))
> + return ETHTOOL_FEC_BASER;
> +
> + return 0;
> +}
I was won
> +
> +/* Takes a comma-separated list of FEC modes, returns the bitwise OR of
> their
> + * corresponding ETHTOOL_FEC_* constants.
> + * Accepts repetitions (e.g. 'auto,auto') and trailing comma (e.g. 'off,').
> + */
> +static int parse_fecmode(const char *str)
> +{
> int fecmode = 0;
> + char buf[6];
> if (!str)
> - return fecmode;
> -
> - if (!strcasecmp(str, "auto"))
> - fecmode |= ETHTOOL_FEC_AUTO;
> - else if (!strcasecmp(str, "off"))
> - fecmode |= ETHTOOL_FEC_OFF;
> - else if (!strcasecmp(str, "rs"))
> - fecmode |= ETHTOOL_FEC_RS;
> - else if (!strcasecmp(str, "baser"))
> - fecmode |= ETHTOOL_FEC_BASER;
> + return 0;
> + while (*str) {
> + size_t next;
> + int mode;
> + next = strcspn(str, ",");
> + if (next >= 6) /* Bad mode, longest name is 5 chars */
> + return 0;
> + /* Copy into temp buffer and nul-terminate */
> + memcpy(buf, str, next);
> + buf[next] = 0;
> + mode = fecmode_str_to_type(buf);
> + if (!mode) /* Bad mode encountered */
> + return 0;
> + fecmode |= mode;
> + str += next;
> + /* Skip over ',' (but not nul) */
> + if (*str)
> + str++;
> + }
> return fecmode;
I would like to apologize for my late response.
I find the ability to set off, auto and specific FEC mode in the same
command confusing.
Here are some examples
1. What is the expected result of 'off' & other FEC mode such as 'RS'?
-'off'?
-'RS'?
-automatic selection {'off','RS'}? w/o setting of auto?
2. What is the expected result of 'off', 'RS' and 'auto'?
- automatic selection from the set of {'RS','off'}
- if that is the case, what is the different from 'off' and 'RS'
with out 'auto'?
- allowing the device to use all three modes
- automatic selection {auto, rs, off}. what is the meaning of auto of auto?
I think that we shall have some mutual configuration limitation :
1. if 'auto' was set, any other configuration from within the set
{'off', 'RS', 'base-r'}
will imply the set of configuration to be selected by auto mode
i.e. 'auto', 'RS' and 'off' configuration will result with
automatic selection between {'off', 'RS'}
2. if 'auto' was not set, only one configuration from within {'off',
'RS', 'base-r'} can
be set (and from that, 'off' cannot be set with other configuration)
Thanks
Ariel Almog
Mellanox technologies
^ permalink raw reply
* KMSAN: uninit-value in gre_rcv (2)
From: syzbot @ 2018-09-26 15:04 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: eb2e67596de2 kmsan: minor code cleanup
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=12b763fa400000
kernel config: https://syzkaller.appspot.com/x/.config?x=94a9ed72288f7fef
dashboard link: https://syzkaller.appspot.com/bug?extid=841c053d026900055032
compiler: clang version 8.0.0 (trunk 339414)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12aac356400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16346711400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+841c053d026900055032@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
==================================================================
BUG: KMSAN: uninit-value in __arch_swab32
arch/x86/include/uapi/asm/swab.h:10 [inline]
BUG: KMSAN: uninit-value in __fswab32 include/uapi/linux/swab.h:59 [inline]
BUG: KMSAN: uninit-value in erspan_rcv net/ipv4/ip_gre.c:285 [inline]
BUG: KMSAN: uninit-value in gre_rcv+0x11d0/0x1920 net/ipv4/ip_gre.c:425
CPU: 0 PID: 4713 Comm: syz-executor382 Not tainted 4.19.0-rc4+ #58
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x2f6/0x430 lib/dump_stack.c:113
kmsan_report+0x183/0x2b0 mm/kmsan/kmsan.c:917
__msan_warning+0x70/0xc0 mm/kmsan/kmsan_instr.c:500
__arch_swab32 arch/x86/include/uapi/asm/swab.h:10 [inline]
__fswab32 include/uapi/linux/swab.h:59 [inline]
erspan_rcv net/ipv4/ip_gre.c:285 [inline]
gre_rcv+0x11d0/0x1920 net/ipv4/ip_gre.c:425
gre_rcv+0x2d5/0x3b0 net/ipv4/gre_demux.c:142
ip_local_deliver_finish+0x90e/0xfa0 net/ipv4/ip_input.c:215
NF_HOOK include/linux/netfilter.h:287 [inline]
ip_local_deliver+0x438/0x4d0 net/ipv4/ip_input.c:256
dst_input include/net/dst.h:450 [inline]
ip_rcv_finish net/ipv4/ip_input.c:415 [inline]
NF_HOOK include/linux/netfilter.h:287 [inline]
ip_rcv+0x65f/0x6d0 net/ipv4/ip_input.c:524
__netif_receive_skb_one_core net/core/dev.c:4891 [inline]
__netif_receive_skb net/core/dev.c:5001 [inline]
process_backlog+0xd89/0x11a0 net/core/dev.c:5807
napi_poll net/core/dev.c:6227 [inline]
net_rx_action+0x935/0x1c00 net/core/dev.c:6293
__do_softirq+0x614/0xa72 kernel/softirq.c:292
do_softirq_own_stack+0x49/0x80 arch/x86/entry/entry_64.S:1055
</IRQ>
do_softirq kernel/softirq.c:336 [inline]
__local_bh_enable_ip+0x119/0x150 kernel/softirq.c:189
local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
rcu_read_unlock_bh include/linux/rcupdate.h:723 [inline]
ip_finish_output2+0x13cd/0x14f0 net/ipv4/ip_output.c:231
ip_do_fragment+0x37b8/0x3fd0 net/ipv4/ip_output.c:678
ip_fragment+0x249/0x3f0 net/ipv4/ip_output.c:561
ip_finish_output+0xfbb/0x10a0 net/ipv4/ip_output.c:315
NF_HOOK_COND include/linux/netfilter.h:276 [inline]
ip_output+0x50f/0x5d0 net/ipv4/ip_output.c:405
dst_output include/net/dst.h:444 [inline]
ip_local_out net/ipv4/ip_output.c:124 [inline]
ip_send_skb+0x178/0x350 net/ipv4/ip_output.c:1441
udp_send_skb+0x10b9/0x18d0 net/ipv4/udp.c:829
udp_push_pending_frames net/ipv4/udp.c:857 [inline]
udp_sendmsg+0xac6/0x3cd0 net/ipv4/udp.c:1148
udpv6_sendmsg+0x12e2/0x4cf0 net/ipv6/udp.c:1196
inet_sendmsg+0x4c5/0x7d0 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg net/socket.c:631 [inline]
__sys_sendto+0x868/0xa30 net/socket.c:1786
__do_sys_sendto net/socket.c:1798 [inline]
__se_sys_sendto+0x107/0x130 net/socket.c:1794
__x64_sys_sendto+0x6e/0x90 net/socket.c:1794
do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291
entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x441319
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 db 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fff698f4638 EFLAGS: 00000286 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000441319
RDX: 000000000000000e RSI: 0000000020000100 RDI: 0000000000000003
RBP: 00000000006cc018 R08: 0000000020000180 R09: 000000000000001c
R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000402280
R13: 0000000000402310 R14: 0000000000000000 R15: 0000000000000000
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:255 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:270 [inline]
kmsan_internal_chain_origin+0x128/0x210 mm/kmsan/kmsan.c:572
kmsan_memcpy_origins+0x13d/0x1b0 mm/kmsan/kmsan.c:396
__msan_memcpy+0xc3/0x130 mm/kmsan/kmsan_instr.c:286
pskb_expand_head+0x49f/0x1e10 net/core/skbuff.c:1470
__skb_cow include/linux/skbuff.h:2911 [inline]
skb_cow_head include/linux/skbuff.h:2945 [inline]
ip_tunnel_xmit+0x3217/0x3870 net/ipv4/ip_tunnel.c:771
__gre_xmit net/ipv4/ip_gre.c:454 [inline]
erspan_xmit+0x1af6/0x3380 net/ipv4/ip_gre.c:752
__netdev_start_xmit include/linux/netdevice.h:4287 [inline]
netdev_start_xmit include/linux/netdevice.h:4296 [inline]
xmit_one net/core/dev.c:3216 [inline]
dev_hard_start_xmit+0x68b/0xd50 net/core/dev.c:3232
sch_direct_xmit+0x52b/0x860 net/sched/sch_generic.c:327
qdisc_restart net/sched/sch_generic.c:390 [inline]
__qdisc_run+0x1ab7/0x3490 net/sched/sch_generic.c:398
qdisc_run include/net/pkt_sched.h:120 [inline]
__dev_xmit_skb net/core/dev.c:3411 [inline]
__dev_queue_xmit+0x1bc3/0x3c60 net/core/dev.c:3770
dev_queue_xmit+0x4b/0x60 net/core/dev.c:3835
neigh_resolve_output+0xaa2/0xb40 net/core/neighbour.c:1364
neigh_output include/net/neighbour.h:483 [inline]
ip_finish_output2+0x13b7/0x14f0 net/ipv4/ip_output.c:229
ip_do_fragment+0x37b8/0x3fd0 net/ipv4/ip_output.c:678
ip_fragment+0x249/0x3f0 net/ipv4/ip_output.c:561
ip_finish_output+0xfbb/0x10a0 net/ipv4/ip_output.c:315
NF_HOOK_COND include/linux/netfilter.h:276 [inline]
ip_output+0x50f/0x5d0 net/ipv4/ip_output.c:405
dst_output include/net/dst.h:444 [inline]
ip_local_out net/ipv4/ip_output.c:124 [inline]
ip_send_skb+0x178/0x350 net/ipv4/ip_output.c:1441
udp_send_skb+0x10b9/0x18d0 net/ipv4/udp.c:829
udp_push_pending_frames net/ipv4/udp.c:857 [inline]
udp_sendmsg+0xac6/0x3cd0 net/ipv4/udp.c:1148
udpv6_sendmsg+0x12e2/0x4cf0 net/ipv6/udp.c:1196
inet_sendmsg+0x4c5/0x7d0 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg net/socket.c:631 [inline]
__sys_sendto+0x868/0xa30 net/socket.c:1786
__do_sys_sendto net/socket.c:1798 [inline]
__se_sys_sendto+0x107/0x130 net/socket.c:1794
__x64_sys_sendto+0x6e/0x90 net/socket.c:1794
do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291
entry_SYSCALL_64_after_hwframe+0x63/0xe7
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:255 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:180
kmsan_kmalloc+0x98/0x100 mm/kmsan/kmsan_hooks.c:91
kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan_hooks.c:100
slab_post_alloc_hook mm/slab.h:446 [inline]
slab_alloc_node mm/slub.c:2718 [inline]
__kmalloc_node_track_caller+0xb55/0x1380 mm/slub.c:4351
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x40d/0xe50 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:996 [inline]
alloc_skb_with_frags+0x1d0/0xac0 net/core/skbuff.c:5273
sock_alloc_send_pskb+0xe28/0x1420 net/core/sock.c:2082
sock_alloc_send_skb+0xca/0xe0 net/core/sock.c:2099
__ip_append_data+0x2d54/0x4460 net/ipv4/ip_output.c:981
ip_append_data+0x2fb/0x440 net/ipv4/ip_output.c:1196
udp_sendmsg+0x6f9/0x3cd0 net/ipv4/udp.c:1142
udpv6_sendmsg+0x12e2/0x4cf0 net/ipv6/udp.c:1196
inet_sendmsg+0x4c5/0x7d0 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg net/socket.c:631 [inline]
__sys_sendto+0x868/0xa30 net/socket.c:1786
__do_sys_sendto net/socket.c:1798 [inline]
__se_sys_sendto+0x107/0x130 net/socket.c:1794
__x64_sys_sendto+0x6e/0x90 net/socket.c:1794
do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291
entry_SYSCALL_64_after_hwframe+0x63/0xe7
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Attractive interest rate @ (2.75%) for project funding/Loan/finance from Coutts & Co U.K !!
From: COUTTS & CO @ 2018-09-26 3:38 UTC (permalink / raw)
To: Recipients
Coutts & Co Ltd
440 Strand, London, WC2R 0QS
Website: https://www.coutts.com
Telephone:+4420 3389 7785 & +4420 7753 1000
Fax:+44 872 110 3479
OUR REF: Coutts/UK/2018/LOANAPP
YOUR REF:LOANAPPT/Coutts/SEP/2018
TO WHOM IT MAY CONCERN
We give out both Local/International Loan starting from 2.75%* rate of interest annually.We offer non-collateral loans to both firms and individuals.
Our Loans can be taken over a term of 6 months to 25 years. Funds available For Most Projects Covering Real Estate, Industry And Other Forms Of Creativity In Some Major Countries.
You Might Be Interested In Submitting Your Business Proposal And Study For Evaluation.
We Do Not Promise Success Of Funding But We Shall Do Our Best To Help And Assist.
No Upfront Fees Or Payments.We Can Also Provide Bank Guarantees And SBLC's For Your Projects Including Monetization.
Please Contact Us For An Application And For More Instruction Please Email Us with the following information-FULL NAMES/COMPANY NAME,TELEPHONE NUMBER,PURPOSE OF LOAN/FINANCE AND PRESENT LOCATION At Email address:coutts.finance@mail.uk
Quick approvals | Disbursal in 72 hours* | FUND DIRECTLY DEPOSITED
© Copyright Coutts & Co 2018
^ permalink raw reply
* Re: r8169 hang on 4.18
From: Ortwin Glück @ 2018-09-26 15:17 UTC (permalink / raw)
To: Heiner Kallweit, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <9fb89abb-917a-44b6-5dff-9c4a0ed1fd6b@gmail.com>
On 25.09.18 20:44, Heiner Kallweit wrote:
> Unfortunately the lspci info doesn't allow to determine the exact chip type.
> Relevant would be the syslog info as you provided it in your first mail:
> r8169 0000:07:00.0 eth4: RTL8168h/8111h, 50:9a:4c:2e:92:be, XID 54100800, IRQ 16
> Are the chips on the extension card the same as the on-board chip?
They are different: G and H versions.
[ 1.696997] r8169 0000:03:00.0 eth0: RTL8168g/8111g at 0x (ptrval), 00:0a:cd:31:60:1f, XID
0c000800 IRQ 17
[ 1.712910] r8169 0000:04:00.0 eth1: RTL8168g/8111g at 0x (ptrval), 00:0a:cd:31:60:20, XID
0c000800 IRQ 18
[ 1.724969] r8169 0000:05:00.0 eth2: RTL8168g/8111g at 0x (ptrval), 00:0a:cd:31:60:21, XID
0c000800 IRQ 19
[ 1.736923] r8169 0000:06:00.0 eth3: RTL8168g/8111g at 0x (ptrval), 00:0a:cd:31:60:22, XID
0c000800 IRQ 16
[ 1.753031] r8169 0000:07:00.0 eth4: RTL8168h/8111h at 0x (ptrval), 50:9a:4c:2e:92:be, XID
14100800 IRQ 16
I am going to try your patch against 4.18.10 and report back!
Thanks,
Ortwin
^ permalink raw reply
* Re: [PATCH] Documentation: Add HOWTO Korean translation into BPF and XDP Reference Guide.
From: Chang-an Song @ 2018-09-26 9:11 UTC (permalink / raw)
To: Jonathan Corbet, tj; +Cc: netdev, daniel, davem
In-Reply-To: <20180924122033.16c63907@lwn.net>
Hello,
Thank you very much to Tejun and Jon for the review first.
I have summarized the my action items as below,
> I think this would still be helpful and a step in the right direction;
> however, I think it'd be helpful to explicitly note, in korean, that
> the translation is still work-in-progress and the readers are
> recommended to refer back to the english copy when there's any doubt.
1. I will add to comment in the NOTE explicitly that "the translation is still
work-in-progress and the readers are recommended to refer back to the
english copy when there's any doubt".
Thank you very much for your advice, Tejun.
> - Since you're adding a new document, could you please format it as RST
> and add it to index.rst with the other Korean translations? The
> original will have been in RST, so this should be relatively easy to
> do.
2. I need to convert the document format to rst file and
add a list of my current documents to the index.rst file, again.
> - The original document has a copyright assertion but no associated
> license. Do we know what the license is? I assume it's something
> that is free and GPL-compatible, but that would be good to know for
> sure.
3. I asked to main author Daniel that apache 2.0 license for this document.
I will need to do additional work for 1 and 2, and need to regenerate the patch.
Thank you very much for your advice, Jon.
If I have something to fix, please feel free to tell me.
BR/Leo
2018-09-25 3:20 GMT+09:00 Jonathan Corbet <corbet@lwn.net>:
> On Fri, 21 Sep 2018 13:22:38 +0900
> Changan Song <csongxdp@gmail.com> wrote:
>
>> Signed-off-by: Changan Song <csongxdp@gmail.com>
>> ---
>> Documentation/translations/ko_KR/bpf-xdp.txt | 3511 ++++++++++++++++++
>> 1 file changed, 3511 insertions(+)
>> create mode 100644 Documentation/translations/ko_KR/bpf-xdp.txt
>
> I can't judge the quality of the translation, of course, but I do have a
> couple of related questions:
>
> - Since you're adding a new document, could you please format it as RST
> and add it to index.rst with the other Korean translations? The
> original will have been in RST, so this should be relatively easy to
> do.
>
> - The original document has a copyright assertion but no associated
> license. Do we know what the license is? I assume it's something
> that is free and GPL-compatible, but that would be good to know for
> sure.
>
> Thanks for doing this work,
>
> jon
^ permalink raw reply
* Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
From: Jason A. Donenfeld @ 2018-09-26 15:25 UTC (permalink / raw)
To: Andrew Lunn
Cc: Ard Biesheuvel, Jean-Philippe Aumasson, Netdev, LKML,
Russell King - ARM Linux, Samuel Neves, Linux Crypto Mailing List,
Andrew Lutomirski, Greg Kroah-Hartman, David Miller,
linux-arm-kernel
In-Reply-To: <20180926143614.GL1676@lunn.ch>
On Wed, Sep 26, 2018 at 4:36 PM Andrew Lunn <andrew@lunn.ch> wrote:
> The wireguard interface claims it is GSO capable. This means the
> network stack will pass it big chunks of data and leave it to the
> network interface to perform the segmentation into 1500 byte MTU
> frames on the wire. I've not looked at how wireguard actually handles
> these big chunks. But to get maximum performance, it should try to
> keep them whole, just add a header and/or trailer. Will wireguard pass
> these big chunks of data to the crypto code? Do we now have 64K blocks
> being worked on? Does the latency jump from 4K to 64K? That might be
> new, so the existing state of the tree does not help you here.
No, it only requests GSO superpackets so that it can group the pieces
and encrypt them on the same core. But they're each encrypted
separately (broken up immediately after ndo_start_xmit), and so they
wind up being ~1420 bytes each to encrypt. I spoke about this at
netdev2.2 if you're interested in the architecture; there's a paper:
https://www.wireguard.com/papers/wireguard-netdev22.pdf
https://www.youtube.com/watch?v=54orFwtQ1XY
https://www.wireguard.com/talks/netdev2017-slides.pdf
^ permalink raw reply
* [PATCH v3 0/5] netlink: nested policy validation
From: Johannes Berg @ 2018-09-26 9:15 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
This adds nested policy validation, which lets you specify the
nested attribute type, e.g. NLA_NESTED with sub-policy, or the
new NLA_NESTED_ARRAY with sub-sub-policy.
Changes in v2:
* move setting the bad attr pointer/message into validate_nla()
* remove the recursion patch since that's no longer needed
* simply skip the generic bad attr pointer/message setting in
case of nested nla_validate() failing since that could fail
only due to validate_nla() failing inside, which already sets
the extack information
Changes in v3:
* fix NLA_REJECT to have an error message if none is in policy
johannes
^ permalink raw reply
* [PATCH v3 1/5] netlink: remove NLA_NESTED_COMPAT
From: Johannes Berg @ 2018-09-26 9:15 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Johannes Berg
In-Reply-To: <20180926091534.22876-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
This isn't used anywhere, so we might as well get rid of it.
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/netlink.h | 2 --
lib/nlattr.c | 11 -----------
2 files changed, 13 deletions(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index 318b1ded3833..b680fe365e91 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -172,7 +172,6 @@ enum {
NLA_FLAG,
NLA_MSECS,
NLA_NESTED,
- NLA_NESTED_COMPAT,
NLA_NUL_STRING,
NLA_BINARY,
NLA_S8,
@@ -203,7 +202,6 @@ enum {
* NLA_BINARY Maximum length of attribute payload
* NLA_NESTED Don't use `len' field -- length verification is
* done by checking len of nested header (or empty)
- * NLA_NESTED_COMPAT Minimum length of structure payload
* NLA_U8, NLA_U16,
* NLA_U32, NLA_U64,
* NLA_S8, NLA_S16,
diff --git a/lib/nlattr.c b/lib/nlattr.c
index bb6fe5ed4ecf..120ad569e13d 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -140,17 +140,6 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
return -ERANGE;
break;
- case NLA_NESTED_COMPAT:
- if (attrlen < pt->len)
- return -ERANGE;
- if (attrlen < NLA_ALIGN(pt->len))
- break;
- if (attrlen < NLA_ALIGN(pt->len) + NLA_HDRLEN)
- return -ERANGE;
- nla = nla_data(nla) + NLA_ALIGN(pt->len);
- if (attrlen < NLA_ALIGN(pt->len) + NLA_HDRLEN + nla_len(nla))
- return -ERANGE;
- break;
case NLA_NESTED:
/* a nested attributes is allowed to be empty; if its not,
* it must have a size of at least NLA_HDRLEN.
--
2.14.4
^ permalink raw reply related
* [PATCH v3 3/5] netlink: move extack setting into validate_nla()
From: Johannes Berg @ 2018-09-26 9:15 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Johannes Berg
In-Reply-To: <20180926091534.22876-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
This unifies the code between nla_parse() which sets the bad
attribute pointer and an error message, and nla_validate()
which only sets the bad attribute pointer.
It also cleans up the code for NLA_REJECT and paves the way
for nested policy validation, as it will allow us to easily
skip setting the "generic" message without any extra args
like the **error_msg now, just passing the extack through is
now enough.
While at it, remove the unnecessary label in nla_parse().
Suggested-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
lib/nlattr.c | 68 ++++++++++++++++++++++++++++++++----------------------------
1 file changed, 36 insertions(+), 32 deletions(-)
diff --git a/lib/nlattr.c b/lib/nlattr.c
index e2e5b38394d5..6e03d650bec4 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -69,10 +69,11 @@ static int validate_nla_bitfield32(const struct nlattr *nla,
static int validate_nla(const struct nlattr *nla, int maxtype,
const struct nla_policy *policy,
- const char **error_msg)
+ struct netlink_ext_ack *extack)
{
const struct nla_policy *pt;
int minlen = 0, attrlen = nla_len(nla), type = nla_type(nla);
+ int err = -ERANGE;
if (type <= 0 || type > maxtype)
return 0;
@@ -90,24 +91,31 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
switch (pt->type) {
case NLA_EXACT_LEN:
if (attrlen != pt->len)
- return -ERANGE;
+ goto out_err;
break;
case NLA_REJECT:
- if (pt->validation_data && error_msg)
- *error_msg = pt->validation_data;
- return -EINVAL;
+ if (extack && pt->validation_data) {
+ NL_SET_BAD_ATTR(extack, nla);
+ extack->_msg = pt->validation_data;
+ return -EINVAL;
+ }
+ err = -EINVAL;
+ goto out_err;
case NLA_FLAG:
if (attrlen > 0)
- return -ERANGE;
+ goto out_err;
break;
case NLA_BITFIELD32:
if (attrlen != sizeof(struct nla_bitfield32))
- return -ERANGE;
+ goto out_err;
- return validate_nla_bitfield32(nla, pt->validation_data);
+ err = validate_nla_bitfield32(nla, pt->validation_data);
+ if (err)
+ goto out_err;
+ break;
case NLA_NUL_STRING:
if (pt->len)
@@ -115,13 +123,15 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
else
minlen = attrlen;
- if (!minlen || memchr(nla_data(nla), '\0', minlen) == NULL)
- return -EINVAL;
+ if (!minlen || memchr(nla_data(nla), '\0', minlen) == NULL) {
+ err = -EINVAL;
+ goto out_err;
+ }
/* fall through */
case NLA_STRING:
if (attrlen < 1)
- return -ERANGE;
+ goto out_err;
if (pt->len) {
char *buf = nla_data(nla);
@@ -130,13 +140,13 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
attrlen--;
if (attrlen > pt->len)
- return -ERANGE;
+ goto out_err;
}
break;
case NLA_BINARY:
if (pt->len && attrlen > pt->len)
- return -ERANGE;
+ goto out_err;
break;
case NLA_NESTED:
@@ -152,10 +162,13 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
minlen = nla_attr_minlen[pt->type];
if (attrlen < minlen)
- return -ERANGE;
+ goto out_err;
}
return 0;
+out_err:
+ NL_SET_ERR_MSG_ATTR(extack, nla, "Attribute failed policy validation");
+ return err;
}
/**
@@ -180,12 +193,10 @@ int nla_validate(const struct nlattr *head, int len, int maxtype,
int rem;
nla_for_each_attr(nla, head, len, rem) {
- int err = validate_nla(nla, maxtype, policy, NULL);
+ int err = validate_nla(nla, maxtype, policy, extack);
- if (err < 0) {
- NL_SET_BAD_ATTR(extack, nla);
+ if (err < 0)
return err;
- }
}
return 0;
@@ -241,7 +252,7 @@ int nla_parse(struct nlattr **tb, int maxtype, const struct nlattr *head,
struct netlink_ext_ack *extack)
{
const struct nlattr *nla;
- int rem, err;
+ int rem;
memset(tb, 0, sizeof(struct nlattr *) * (maxtype + 1));
@@ -249,17 +260,12 @@ int nla_parse(struct nlattr **tb, int maxtype, const struct nlattr *head,
u16 type = nla_type(nla);
if (type > 0 && type <= maxtype) {
- static const char _msg[] = "Attribute failed policy validation";
- const char *msg = _msg;
-
if (policy) {
- err = validate_nla(nla, maxtype, policy, &msg);
- if (err < 0) {
- NL_SET_BAD_ATTR(extack, nla);
- if (extack)
- extack->_msg = msg;
- goto errout;
- }
+ int err = validate_nla(nla, maxtype, policy,
+ extack);
+
+ if (err < 0)
+ return err;
}
tb[type] = (struct nlattr *)nla;
@@ -270,9 +276,7 @@ int nla_parse(struct nlattr **tb, int maxtype, const struct nlattr *head,
pr_warn_ratelimited("netlink: %d bytes leftover after parsing attributes in process `%s'.\n",
rem, current->comm);
- err = 0;
-errout:
- return err;
+ return 0;
}
EXPORT_SYMBOL(nla_parse);
--
2.14.4
^ permalink raw reply related
* [PATCH v3 2/5] netlink: make validation_data const
From: Johannes Berg @ 2018-09-26 9:15 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Johannes Berg
In-Reply-To: <20180926091534.22876-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
The validation data is only used within the policy that
should usually already be const, and isn't changed in any
code that uses it. Therefore, make the validation_data
pointer const.
While at it, remove the duplicate variable in the bitfield
validation that I'd otherwise have to change to const.
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/netlink.h | 2 +-
lib/nlattr.c | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index b680fe365e91..0d698215d4d9 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -237,7 +237,7 @@ enum {
struct nla_policy {
u16 type;
u16 len;
- void *validation_data;
+ const void *validation_data;
};
#define NLA_POLICY_EXACT_LEN(_len) { .type = NLA_EXACT_LEN, .len = _len }
diff --git a/lib/nlattr.c b/lib/nlattr.c
index 120ad569e13d..e2e5b38394d5 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -45,12 +45,11 @@ static const u8 nla_attr_minlen[NLA_TYPE_MAX+1] = {
};
static int validate_nla_bitfield32(const struct nlattr *nla,
- u32 *valid_flags_allowed)
+ const u32 *valid_flags_mask)
{
const struct nla_bitfield32 *bf = nla_data(nla);
- u32 *valid_flags_mask = valid_flags_allowed;
- if (!valid_flags_allowed)
+ if (!valid_flags_mask)
return -EINVAL;
/*disallow invalid bit selector */
--
2.14.4
^ permalink raw reply related
* [PATCH v3 5/5] netlink: add nested array policy validation
From: Johannes Berg @ 2018-09-26 9:15 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Johannes Berg
In-Reply-To: <20180926091534.22876-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Sometimes nested netlink attributes are just used as arrays, with
the nla_type() of each not being used; we have this in nl80211 and
e.g. NFTA_SET_ELEM_LIST_ELEMENTS.
Add the ability to validate this type of message directly in the
policy, by adding the type NLA_NESTED_ARRAY which does exactly
this: require a first level of nesting but ignore the attribute
type, and then inside each require a second level of nested and
validate those attributes against a given policy (if present).
Note that some nested array types actually require that all of
the entries have the same index, this is possible to express in
a nested policy already, apart from the validation that only the
one allowed type is used.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/netlink.h | 12 +++++++++++-
lib/nlattr.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index 91907852da1c..3698ca8ff92c 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -172,6 +172,7 @@ enum {
NLA_FLAG,
NLA_MSECS,
NLA_NESTED,
+ NLA_NESTED_ARRAY,
NLA_NUL_STRING,
NLA_BINARY,
NLA_S8,
@@ -200,7 +201,8 @@ enum {
* NLA_NUL_STRING Maximum length of string (excluding NUL)
* NLA_FLAG Unused
* NLA_BINARY Maximum length of attribute payload
- * NLA_NESTED Length verification is done by checking len of
+ * NLA_NESTED,
+ * NLA_NESTED_ARRAY Length verification is done by checking len of
* nested header (or empty); len field is used if
* validation_data is also used, for the max attr
* number in the nested policy.
@@ -230,6 +232,12 @@ enum {
* `len' to the max attribute number.
* Note that nla_parse() will validate, but of course not
* parse, the nested sub-policies.
+ * NLA_NESTED_ARRAY Points to a nested policy to validate, must also set
+ * `len' to the max attribute number. The difference to
+ * NLA_NESTED is the structure - NLA_NESTED has the
+ * nested attributes directly inside, while an array has
+ * the nested attributes at another level down and the
+ * attributes directly in the nesting don't matter.
* All other Unused
*
* Example:
@@ -255,6 +263,8 @@ struct nla_policy {
#define NLA_POLICY_NESTED(maxattr, policy) \
{ .type = NLA_NESTED, .validation_data = policy, .len = maxattr }
+#define NLA_POLICY_NESTED_ARRAY(maxattr, policy) \
+ { .type = NLA_NESTED_ARRAY, .validation_data = policy, .len = maxattr }
/**
* struct nl_info - netlink source information
diff --git a/lib/nlattr.c b/lib/nlattr.c
index 04750f88477c..2f8feff669a7 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -67,6 +67,34 @@ static int validate_nla_bitfield32(const struct nlattr *nla,
return 0;
}
+static int nla_validate_array(const struct nlattr *head, int len, int maxtype,
+ const struct nla_policy *policy,
+ struct netlink_ext_ack *extack)
+{
+ const struct nlattr *entry;
+ int rem;
+
+ nla_for_each_attr(entry, head, len, rem) {
+ int ret;
+
+ if (nla_len(entry) == 0)
+ continue;
+
+ if (nla_len(entry) < NLA_HDRLEN) {
+ NL_SET_ERR_MSG_ATTR(extack, entry,
+ "Array element too short");
+ return -ERANGE;
+ }
+
+ ret = nla_validate(nla_data(entry), nla_len(entry),
+ maxtype, policy, extack);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
static int validate_nla(const struct nlattr *nla, int maxtype,
const struct nla_policy *policy,
struct netlink_ext_ack *extack)
@@ -169,6 +197,29 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
}
}
break;
+ case NLA_NESTED_ARRAY:
+ /* a nested array attribute is allowed to be empty; if its not,
+ * it must have a size of at least NLA_HDRLEN.
+ */
+ if (attrlen == 0)
+ break;
+ if (attrlen < NLA_HDRLEN)
+ goto out_err;
+ if (pt->validation_data) {
+ int err;
+
+ err = nla_validate_array(nla_data(nla), nla_len(nla),
+ pt->len, pt->validation_data,
+ extack);
+ if (err < 0) {
+ /*
+ * return directly to preserve the inner
+ * error message/attribute pointer
+ */
+ return err;
+ }
+ }
+ break;
default:
if (pt->len)
minlen = pt->len;
--
2.14.4
^ permalink raw reply related
* [PATCH v3 4/5] netlink: allow NLA_NESTED to specify nested policy to validate
From: Johannes Berg @ 2018-09-26 9:15 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Johannes Berg
In-Reply-To: <20180926091534.22876-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Now that we have a validation_data pointer, and the len field in
the policy is unused for NLA_NESTED, we can allow using them both
to have nested validation. This can be nice in code, although we
still have to use nla_parse_nested() or similar which would also
take a policy; however, it also serves as documentation in the
policy without requiring a look at the code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/netlink.h | 13 +++++++++++--
lib/nlattr.c | 14 ++++++++++++++
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index 0d698215d4d9..91907852da1c 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -200,8 +200,10 @@ enum {
* NLA_NUL_STRING Maximum length of string (excluding NUL)
* NLA_FLAG Unused
* NLA_BINARY Maximum length of attribute payload
- * NLA_NESTED Don't use `len' field -- length verification is
- * done by checking len of nested header (or empty)
+ * NLA_NESTED Length verification is done by checking len of
+ * nested header (or empty); len field is used if
+ * validation_data is also used, for the max attr
+ * number in the nested policy.
* NLA_U8, NLA_U16,
* NLA_U32, NLA_U64,
* NLA_S8, NLA_S16,
@@ -224,6 +226,10 @@ enum {
* NLA_REJECT This attribute is always rejected and validation data
* may point to a string to report as the error instead
* of the generic one in extended ACK.
+ * NLA_NESTED Points to a nested policy to validate, must also set
+ * `len' to the max attribute number.
+ * Note that nla_parse() will validate, but of course not
+ * parse, the nested sub-policies.
* All other Unused
*
* Example:
@@ -247,6 +253,9 @@ struct nla_policy {
#define NLA_POLICY_ETH_ADDR NLA_POLICY_EXACT_LEN(ETH_ALEN)
#define NLA_POLICY_ETH_ADDR_COMPAT NLA_POLICY_EXACT_LEN_WARN(ETH_ALEN)
+#define NLA_POLICY_NESTED(maxattr, policy) \
+ { .type = NLA_NESTED, .validation_data = policy, .len = maxattr }
+
/**
* struct nl_info - netlink source information
* @nlh: Netlink message header of original request
diff --git a/lib/nlattr.c b/lib/nlattr.c
index 6e03d650bec4..04750f88477c 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -155,6 +155,20 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
*/
if (attrlen == 0)
break;
+ if (attrlen < NLA_HDRLEN)
+ goto out_err;
+ if (pt->validation_data) {
+ err = nla_validate(nla_data(nla), nla_len(nla), pt->len,
+ pt->validation_data, extack);
+ if (err < 0) {
+ /*
+ * return directly to preserve the inner
+ * error message/attribute pointer
+ */
+ return err;
+ }
+ }
+ break;
default:
if (pt->len)
minlen = pt->len;
--
2.14.4
^ permalink raw reply related
* [PATCH net-next] net: xen-netback: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-26 9:18 UTC (permalink / raw)
To: davem, wei.liu2, paul.durrant; +Cc: linux-kernel, netdev, xen-devel, YueHaibing
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
---
drivers/net/xen-netback/interface.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 92274c2..7e3ea39 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -165,7 +165,8 @@ static u16 xenvif_select_queue(struct net_device *dev, struct sk_buff *skb,
return vif->hash.mapping[skb_get_hash_raw(skb) % size];
}
-static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct xenvif *vif = netdev_priv(dev);
struct xenvif_queue *queue = NULL;
--
1.8.3.1
^ permalink raw reply related
* Fw: [Bug 201233] New: e1000e
From: Stephen Hemminger @ 2018-09-26 9:26 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Tue, 25 Sep 2018 19:44:31 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 201233] New: e1000e
https://bugzilla.kernel.org/show_bug.cgi?id=201233
Bug ID: 201233
Summary: e1000e
Product: Networking
Version: 2.5
Kernel Version: 4.17.2
Hardware: Intel
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: Other
Assignee: stephen@networkplumber.org
Reporter: pawel.ciejka@gmail.com
Regression: No
[39066.374367] ------------[ cut here ]------------
[39066.374372] NETDEV WATCHDOG: enp0s31f6 (e1000e): transmit queue 0 timed out
[39066.374399] WARNING: CPU: 5 PID: 0 at net/sched/sch_generic.c:473
dev_watchdog+0x21a/0x220
[39066.374401] Modules linked in: tun snd_hda_codec_hdmi cfg80211 rfkill 8021q
mrp xt_tcpudp xt_conntrack ip6table_filter ip6_tables iptable_filter
openvswitch nsh nf_conntrack_ipv6 nf_nat_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_defrag_ipv6 nf_nat nf_conntrack libcrc32c snd_hda_codec_realtek
snd_hda_codec_generic nls_iso8859_1 nls_cp437 vfat fat nouveau intel_rapl
x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel input_leds kvm
i2c_algo_bit ttm drm_kms_helper irqbypass crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel pcbc drm aesni_intel snd_hda_intel aes_x86_64 crypto_simd
cryptd glue_helper snd_hda_codec iTCO_wdt iTCO_vendor_support intel_cstate
agpgart intel_uncore snd_hda_core syscopyarea sysfillrect sysimgblt fb_sys_fops
mxm_wmi intel_rapl_perf led_class e1000e snd_hwdep r8169
[39066.374498] snd_pcm pcspkr mii snd_timer mei_me snd hid_generic mei
i2c_i801 soundcore intel_pch_thermal shpchp wmi rtc_cmos evdev mac_hid
ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto sd_mod
usbhid hid ahci libahci xhci_pci xhci_hcd libata crc32c_intel usbcore scsi_mod
usb_common
[39066.374552] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.17.2-1-ARCH #1
[39066.374554] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./Z170 Pro4S, BIOS P7.50 01/23/2018
[39066.374559] RIP: 0010:dev_watchdog+0x21a/0x220
[39066.374562] RSP: 0018:ffff9585b6543e78 EFLAGS: 00010286
[39066.374567] RAX: 0000000000000000 RBX: 0000000000000000 RCX:
0000000000000103
[39066.374569] RDX: 0000000080000103 RSI: ffffffff93e83166 RDI:
00000000ffffffff
[39066.374572] RBP: ffff9585a1a0845c R08: 0000000000000050 R09:
0000000000000388
[39066.374575] R10: 0000000000000000 R11: 0000000000000001 R12:
ffff9585a1a08478
[39066.374577] R13: ffff9585a1a08000 R14: 0000000000000001 R15:
ffff9585a1116680
[39066.374581] FS: 0000000000000000(0000) GS:ffff9585b6540000(0000)
knlGS:0000000000000000
[39066.374584] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[39066.374587] CR2: 00007f95007b9000 CR3: 000000033100a002 CR4:
00000000003626e0
[39066.374590] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[39066.374593] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[39066.374595] Call Trace:
[39066.374599] <IRQ>
[39066.374607] ? qdisc_reset+0xe0/0xe0
[39066.374611] ? qdisc_reset+0xe0/0xe0
[39066.374619] call_timer_fn+0x2b/0x150
[39066.374624] ? qdisc_reset+0xe0/0xe0
[39066.374630] expire_timers+0x99/0x110
[39066.374637] run_timer_softirq+0x8a/0x160
[39066.374646] ? sched_clock+0x5/0x10
[39066.374654] ? sched_clock_cpu+0xe/0xd0
[39066.374662] __do_softirq+0xf1/0x2e0
[39066.374669] irq_exit+0xc9/0xe0
[39066.374676] smp_apic_timer_interrupt+0x73/0x160
[39066.374682] apic_timer_interrupt+0xf/0x20
[39066.374685] </IRQ>
[39066.374692] RIP: 0010:cpuidle_enter_state+0xb7/0x2e0
[39066.374695] RSP: 0018:ffffb7f00196be98 EFLAGS: 00000246 ORIG_RAX:
ffffffffffffff13
[39066.374700] RAX: ffff9585b6540000 RBX: 00002387d95da598 RCX:
000000000000001f
[39066.374702] RDX: 00002387d95da598 RSI: ffffffff93e83166 RDI:
ffffffff93e833c4
[39066.374705] RBP: 0000000000000006 R08: 00009d769b1b300b R09:
0000000000000dfa
[39066.374707] R10: 00000000000050ed R11: ffff9585b6560928 R12:
ffff9585b656bb00
[39066.374710] R13: ffffffff940adc38 R14: 00002387d92f6191 R15:
0000000000000000
[39066.374720] ? cpuidle_enter_state+0x92/0x2e0
[39066.374725] do_idle+0x20a/0x240
[39066.374731] cpu_startup_entry+0x6f/0x80
[39066.374738] start_secondary+0x1aa/0x200
[39066.374745] secondary_startup_64+0xa5/0xb0
[39066.374750] Code: 00 49 63 4c 24 e8 eb 8c 4c 89 ef c6 05 97 54 ad 00 01 e8
da 18 fd ff 89 d9 4c 89 ee 48 c7 c7 40 5e ef 93 48 89 c2 e8 00 1b a5 ff <0f> 0b
eb be 66 90 0f 1f 44 00 00 48 c7 47 08 00 00 00 00 48 c7
[39066.374840] ---[ end trace 69426933339b594f ]---
[66649.036433] e1000e 0000:00:1f.6 enp0s31f6: Detected Hardware Unit Hang:
TDH <cf>
TDT <ef>
next_to_use <ef>
next_to_clean <cf>
buffer_info[next_to_clean]:
time_stamp <1012faef5>
next_to_watch <d0>
jiffies <1012fb940>
next_to_watch.status <0>
MAC Status <40080083>
PHY Status <796d>
PHY 1000BASE-T Status <7800>
PHY Extended Status <3000>
PCI Status <10>
[66650.102864] e1000e 0000:00:1f.6 enp0s31f6: Reset adapter unexpectedly
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
From: Jason A. Donenfeld @ 2018-09-26 15:41 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Herbert Xu, Thomas Gleixner, LKML, Netdev,
Linux Crypto Mailing List, David Miller, Greg Kroah-Hartman,
Samuel Neves, Andrew Lutomirski, Jean-Philippe Aumasson,
Russell King - ARM Linux, linux-arm-kernel
In-Reply-To: <CAKv+Gu8ih-TsASRGqK+ST_5+EQ0=Zo-zhGCadOdGyPjucMFTCg@mail.gmail.com>
On Wed, Sep 26, 2018 at 4:02 PM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> I don't think it makes sense to keep
> it simple now and add the complexity later (and the same concern
> applies to async support btw).
Ugh, no. I don't want to add needless complexity, period. Zinc is
synchronous, not asynchronous. It provides software implementations.
That's what it does. While many of your reviews have been useful, many
of your comments indicate some desire to change and mold the purpose
and focus of Zinc away from Zinc's intents. Stop that. It's not going
to become a bloated mess of "things Ard wanted and quipped about on
LKML." Things like these only serve to filibuster the patchset
indefinitely. But maybe that's what you'd like all along? Hard to
tell, honestly. So, no, sorry, Zinc isn't gaining an async interface
right now.
^ 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