* Re: [PATCH net-next 02/10] dt-bindings: net: ocelot: remove hsio from the list of register address spaces
From: Alexandre Belloni @ 2018-08-27 20:57 UTC (permalink / raw)
To: Quentin Schulz
Cc: Rob Herring, ralf, paul.burton, jhogan, mark.rutland, davem,
kishon, andrew, f.fainelli, linux-mips, devicetree, linux-kernel,
netdev, allan.nielsen, thomas.petazzoni
In-Reply-To: <20180816142514.pf4eiqeditoy4uei@qschulz>
On 16/08/2018 16:25:14+0200, Quentin Schulz wrote:
> Hi Alexandre,
>
> On Tue, Aug 14, 2018 at 02:41:35PM +0200, Alexandre Belloni wrote:
> > On 14/08/2018 08:49:53+0200, Quentin Schulz wrote:
> > > Understood but it's an intermediate patch. Later (patch 8), the SerDes
> > > muxing "controller" is added as a child to this node. There most likely
> > > will be some others in the future (temperature sensor for example).
> > >
> > > Furthermore, there's already a simple-mfd without children in this file:
> > > https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/mips/mscc.txt#L19
> > >
> > > How should we handle this case?
> > >
> >
> > There were child nodes in previous version of the binding. You can
> > remove simple-mfd now. The useful registers that are not used by any
> > drivers are gpr and chipid.
> >
>
> And what about the use case I'm facing? I've got child nodes defined in
> it but with a later patch (but they actually haven't made it to the
> DT binding documentation, so that's for the next version of the patch
> series).
>
I guess you should keep simple-mfd for hsio because it will have child
nodes.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* KASAN: use-after-free Read in ccid_hc_tx_delete
From: syzbot @ 2018-08-27 17:10 UTC (permalink / raw)
To: davem, dccp, gerrit, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: aba16dc5cf93 Merge branch 'ida-4.19' of git://git.infradea..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1750d382400000
kernel config: https://syzkaller.appspot.com/x/.config?x=3b576e333ca31bb2
dashboard link: https://syzkaller.appspot.com/bug?extid=3967c1caf256f4d5aefe
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119d007a400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3967c1caf256f4d5aefe@syzkaller.appspotmail.com
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
hrtimer: interrupt took 33823 ns
==================================================================
BUG: KASAN: use-after-free in ccid_hc_tx_delete+0xe0/0x100
net/dccp/ccid.c:188
Read of size 8 at addr ffff8801b0726b40 by task syz-executor3/6567
CPU: 1 PID: 6567 Comm: syz-executor3 Not tainted 4.18.0+ #210
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+0x1c9/0x2b4 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
ccid_hc_tx_delete+0xe0/0x100 net/dccp/ccid.c:188
dccp_sk_destruct+0x3c/0x80 net/dccp/proto.c:181
__sk_destruct+0x107/0xa60 net/core/sock.c:1560
__rcu_reclaim kernel/rcu/rcu.h:236 [inline]
rcu_do_batch kernel/rcu/tree.c:2576 [inline]
invoke_rcu_callbacks kernel/rcu/tree.c:2880 [inline]
__rcu_process_callbacks kernel/rcu/tree.c:2847 [inline]
rcu_process_callbacks+0xf78/0x27c0 kernel/rcu/tree.c:2864
__do_softirq+0x2eb/0xa74 kernel/softirq.c:292
invoke_softirq kernel/softirq.c:372 [inline]
irq_exit+0x1d6/0x210 kernel/softirq.c:412
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0x18e/0x6a0 arch/x86/kernel/apic/apic.c:1056
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:864
</IRQ>
RIP: 0010:memset_erms+0x9/0x10 arch/x86/lib/memset_64.S:65
Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48
ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 <f3> aa 4c 89 c8
c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01
RSP: 0018:ffff8801b2aa75b0 EFLAGS: 00010246 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000000 RBX: 00000000006080c0 RCX: 0000000000000240
RDX: 0000000000000800 RSI: 0000000000000000 RDI: ffff8801addbc880
RBP: ffff8801b2aa7630 R08: ffff8801d7642a80 R09: ffff8801addbc2c0
R10: ffff8801d7642240 R11: 0000000000000000 R12: ffff8801addbc2c0
R13: ffff8801dac00c40 R14: ffff8801dac00c40 R15: 00000000006080c0
kmalloc include/linux/slab.h:513 [inline]
kzalloc include/linux/slab.h:707 [inline]
perf_event_alloc.part.93+0x1e2/0x33c0 kernel/events/core.c:9927
perf_event_alloc kernel/events/core.c:10399 [inline]
__do_sys_perf_event_open+0xa9c/0x2f30 kernel/events/core.c:10500
__se_sys_perf_event_open kernel/events/core.c:10389 [inline]
__x64_sys_perf_event_open+0xbe/0x150 kernel/events/core.c:10389
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457089
Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fc7df221c78 EFLAGS: 00000246 ORIG_RAX: 000000000000012a
RAX: ffffffffffffffda RBX: 00007fc7df2226d4 RCX: 0000000000457089
RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 000000002001d000
RBP: 00000000009300a0 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffffffffffff R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000004d3300 R14: 00000000004c8290 R15: 0000000000000000
Allocated by task 6568:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
kmem_cache_alloc+0x12e/0x710 mm/slab.c:3554
ccid_new+0x25b/0x3e0 net/dccp/ccid.c:151
dccp_hdlr_ccid+0x27/0x150 net/dccp/feat.c:44
__dccp_feat_activate+0x184/0x270 net/dccp/feat.c:344
dccp_feat_activate_values+0x3b6/0x839 net/dccp/feat.c:1538
dccp_rcv_request_sent_state_process net/dccp/input.c:472 [inline]
dccp_rcv_state_process+0x11dc/0x1a30 net/dccp/input.c:678
dccp_v6_do_rcv+0x26f/0xb80 net/dccp/ipv6.c:638
sk_backlog_rcv include/net/sock.h:931 [inline]
__release_sock+0x12f/0x3a0 net/core/sock.c:2336
release_sock+0xad/0x2c0 net/core/sock.c:2849
inet_wait_for_connect net/ipv4/af_inet.c:588 [inline]
__inet_stream_connect+0x61f/0x1160 net/ipv4/af_inet.c:680
inet_stream_connect+0x58/0xa0 net/ipv4/af_inet.c:719
__sys_connect+0x37d/0x4c0 net/socket.c:1662
__do_sys_connect net/socket.c:1673 [inline]
__se_sys_connect net/socket.c:1670 [inline]
__x64_sys_connect+0x73/0xb0 net/socket.c:1670
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 6582:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kmem_cache_free+0x86/0x280 mm/slab.c:3756
ccid_hc_tx_delete+0xc3/0x100 net/dccp/ccid.c:190
dccp_hdlr_ccid+0x7d/0x150 net/dccp/feat.c:53
__dccp_feat_activate+0x184/0x270 net/dccp/feat.c:344
dccp_feat_activate_values+0x3b6/0x839 net/dccp/feat.c:1538
dccp_create_openreq_child+0x47a/0x620 net/dccp/minisocks.c:127
dccp_v6_request_recv_sock+0x253/0x2040 net/dccp/ipv6.c:466
dccp_check_req+0x46e/0x6c0 net/dccp/minisocks.c:196
dccp_v6_rcv+0x88e/0x1d9c net/dccp/ipv6.c:744
ip6_input_finish+0x407/0x1a40 net/ipv6/ip6_input.c:383
NF_HOOK include/linux/netfilter.h:287 [inline]
ip6_input+0xe9/0x600 net/ipv6/ip6_input.c:426
dst_input include/net/dst.h:450 [inline]
ip6_rcv_finish+0x17a/0x330 net/ipv6/ip6_input.c:76
NF_HOOK include/linux/netfilter.h:287 [inline]
ipv6_rcv+0x11e/0x650 net/ipv6/ip6_input.c:271
__netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4892
__netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002
process_backlog+0x219/0x760 net/core/dev.c:5808
napi_poll net/core/dev.c:6228 [inline]
net_rx_action+0x799/0x1900 net/core/dev.c:6294
__do_softirq+0x2eb/0xa74 kernel/softirq.c:292
The buggy address belongs to the object at ffff8801b0726b40
which belongs to the cache ccid2_hc_tx_sock of size 1240
The buggy address is located 0 bytes inside of
1240-byte region [ffff8801b0726b40, ffff8801b0727018)
The buggy address belongs to the page:
page:ffffea0006c1c980 count:1 mapcount:0 mapping:ffff8801cd8b6680 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffff8801cd8b3648 ffffea0006c1e308 ffff8801cd8b6680
raw: 0000000000000000 ffff8801b0726040 0000000100000005 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801b0726a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801b0726a80: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801b0726b00: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff8801b0726b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801b0726c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
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
* Oops running iptables -F OUTPUT
From: Andreas Schwab @ 2018-08-27 17:11 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev
I'm getting this Oops when running iptables -F OUTPUT:
[ 91.139409] Unable to handle kernel paging request for data at address 0xd0000001fff12f34
[ 91.139414] Faulting instruction address: 0xd0000000016a5718
[ 91.139419] Oops: Kernel access of bad area, sig: 11 [#1]
[ 91.139426] BE SMP NR_CPUS=2 PowerMac
[ 91.139434] Modules linked in: iptable_filter ip_tables x_tables bpfilter nfsd auth_rpcgss lockd grace nfs_acl sunrpc tun af_packet snd_aoa_codec_tas snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_aoa_soundbus snd_pcm_oss snd_pcm snd_seq snd_timer snd_seq_device snd_mixer_oss snd sungem sr_mod firewire_ohci cdrom sungem_phy soundcore firewire_core pata_macio crc_itu_t sg hid_generic usbhid linear md_mod ohci_pci ohci_hcd ehci_pci ehci_hcd usbcore usb_common dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_mod sata_svw
[ 91.139522] CPU: 1 PID: 3620 Comm: iptables Not tainted 4.19.0-rc1 #1
[ 91.139526] NIP: d0000000016a5718 LR: d0000000016a569c CTR: c0000000006f560c
[ 91.139531] REGS: c0000001fa577670 TRAP: 0300 Not tainted (4.19.0-rc1)
[ 91.139534] MSR: 900000000200b032 <SF,HV,VEC,EE,FP,ME,IR,DR,RI> CR: 84002484 XER: 20000000
[ 91.139553] DAR: d0000001fff12f34 DSISR: 40000000 IRQMASK: 0
GPR00: d0000000016a569c c0000001fa5778f0 d0000000016b0400 0000000000000000
GPR04: 0000000000000002 0000000000000000 80000001fa46418e c0000001fa0d05c8
GPR08: d0000000016b0400 d00037fffff13000 00000001ff3e7000 d0000000016a6fb8
GPR12: c0000000006f560c c00000000ffff780 0000000000000000 0000000000000000
GPR16: 0000000011635010 00003fffa1b7aa68 0000000000000000 0000000000000000
GPR20: 0000000000000003 0000000010013918 00000000116350c0 c000000000b88990
GPR24: c000000000b88ba4 0000000000000000 d0000001fff12f34 0000000000000000
GPR28: d0000000016b8000 c0000001fa20f400 c0000001fa20f440 0000000000000000
[ 91.139627] NIP [d0000000016a5718] .alloc_counters.isra.10+0xbc/0x140 [ip_tables]
[ 91.139634] LR [d0000000016a569c] .alloc_counters.isra.10+0x40/0x140 [ip_tables]
[ 91.139638] Call Trace:
[ 91.139645] [c0000001fa5778f0] [d0000000016a569c] .alloc_counters.isra.10+0x40/0x140 [ip_tables] (unreliable)
[ 91.139655] [c0000001fa5779b0] [d0000000016a5b54] .do_ipt_get_ctl+0x110/0x2ec [ip_tables]
[ 91.139666] [c0000001fa577aa0] [c0000000006233e0] .nf_getsockopt+0x68/0x88
[ 91.139674] [c0000001fa577b40] [c000000000631608] .ip_getsockopt+0xbc/0x128
[ 91.139682] [c0000001fa577bf0] [c00000000065adf4] .raw_getsockopt+0x18/0x5c
[ 91.139690] [c0000001fa577c60] [c0000000005b5f60] .sock_common_getsockopt+0x2c/0x40
[ 91.139697] [c0000001fa577cd0] [c0000000005b3394] .__sys_getsockopt+0xa4/0xd0
[ 91.139704] [c0000001fa577d80] [c0000000005b5ab0] .__se_sys_socketcall+0x238/0x2b4
[ 91.139712] [c0000001fa577e30] [c00000000000a31c] system_call+0x5c/0x70
[ 91.139716] Instruction dump:
[ 91.139721] 39290040 7d3d4a14 7fbe4840 409cff98 81380000 2b890001 419d000c 393e0060
[ 91.139736] 48000010 7d57c82a e93e0060 7d295214 <815a0000> 794807e1 41e20010 7c210b78
[ 91.139752] ---[ end trace f5d1d5431651845d ]---
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* RE: [PATCH] sh_eth: Add R7S9210 support
From: Chris Brandt @ 2018-08-27 17:30 UTC (permalink / raw)
To: Sergei Shtylyov, David S . Miller, Rob Herring, Mark Rutland
Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Simon Horman
In-Reply-To: <8efee9e2-2c2c-b02b-db8d-a421a8928448@cogentembedded.com>
Hi Sergei,
On Friday, August 24, 2018 1, linux-renesas-soc-owner@vger.kernel.org wrote:
> On 08/22/2018 11:57 PM, Chris Brandt wrote:
> > +static const u16 sh_eth_offset_fast_rza2[SH_ETH_MAX_REGISTER_OFFSET] =
> {
> > + SH_ETH_OFFSET_DEFAULTS,
> > +
(snip)
> > + [RFCR] = 0x01f4,
> > + [MAFCR] = 0x01f8,
> > +};
> > +
>
> This array is absolutely the same as sh_eth_offset_fast_sh4[], except
> the latter
> is (more or less) sorted.
You're right. I'll just use sh_eth_offset_fast_sh4[].
> > +
> > + switch (mdp->speed) {
> > + case 10: /* 10BASE */
> > + sh_eth_modify(ndev, ECMR, RTM, 0);
> > + break;
> > + case 100:/* 100BASE */
> > + sh_eth_modify(ndev, ECMR, RTM, RTM);
> > + break;
> > + }
> > +}
> > +
>
> Seems the same as sh_eth_set_rate_rcar(), except for the bit name...
You're right.
I looked at the other sh_eth_set_rate_xxx() but didn't seem to find one
that matched.
But, sh_eth_set_rate_rcar() does match. I'll use that one.
Thanks,
Chris
^ permalink raw reply
* [PATCH v2] sh_eth: Add R7S9210 support
From: Chris Brandt @ 2018-08-27 17:42 UTC (permalink / raw)
To: Sergei Shtylyov, David S . Miller, Rob Herring, Mark Rutland
Cc: netdev, devicetree, linux-renesas-soc, Simon Horman, Chris Brandt
Add support for the R7S9210 which is part of the RZ/A2 series.
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
---
v2:
* Use sh_eth_offset_fast_sh4 instead of sh_eth_offset_fast_rza2
* Use sh_eth_set_rate_rcar instead of sh_eth_set_rate_r7s9210()
* Removed enum SH_ETH_REG_FAST_RZA2
---
Documentation/devicetree/bindings/net/sh_eth.txt | 1 +
drivers/net/ethernet/renesas/sh_eth.c | 36 ++++++++++++++++++++++++
2 files changed, 37 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/sh_eth.txt b/Documentation/devicetree/bindings/net/sh_eth.txt
index 76db9f13ad96..abc36274227c 100644
--- a/Documentation/devicetree/bindings/net/sh_eth.txt
+++ b/Documentation/devicetree/bindings/net/sh_eth.txt
@@ -16,6 +16,7 @@ Required properties:
"renesas,ether-r8a7794" if the device is a part of R8A7794 SoC.
"renesas,gether-r8a77980" if the device is a part of R8A77980 SoC.
"renesas,ether-r7s72100" if the device is a part of R7S72100 SoC.
+ "renesas,ether-r7s9210" if the device is a part of R7S9210 SoC.
"renesas,rcar-gen1-ether" for a generic R-Car Gen1 device.
"renesas,rcar-gen2-ether" for a generic R-Car Gen2 or RZ/G1
device.
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index 5573199c4536..2b95f3b1b759 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -809,6 +809,41 @@ static struct sh_eth_cpu_data r8a77980_data = {
.magic = 1,
.cexcr = 1,
};
+
+/* R7S9210 */
+static struct sh_eth_cpu_data r7s9210_data = {
+ .soft_reset = sh_eth_soft_reset,
+
+ .set_duplex = sh_eth_set_duplex,
+ .set_rate = sh_eth_set_rate_rcar,
+
+ .register_type = SH_ETH_REG_FAST_SH4,
+
+ .edtrr_trns = EDTRR_TRNS_ETHER,
+ .ecsr_value = ECSR_ICD,
+ .ecsipr_value = ECSIPR_ICDIP,
+ .eesipr_value = EESIPR_TWBIP | EESIPR_TABTIP | EESIPR_RABTIP |
+ EESIPR_RFCOFIP | EESIPR_ECIIP | EESIPR_FTCIP |
+ EESIPR_TDEIP | EESIPR_TFUFIP | EESIPR_FRIP |
+ EESIPR_RDEIP | EESIPR_RFOFIP | EESIPR_CNDIP |
+ EESIPR_DLCIP | EESIPR_CDIP | EESIPR_TROIP |
+ EESIPR_RMAFIP | EESIPR_RRFIP | EESIPR_RTLFIP |
+ EESIPR_RTSFIP | EESIPR_PREIP | EESIPR_CERFIP,
+
+ .tx_check = EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_TRO,
+ .eesr_err_check = EESR_TWB | EESR_TABT | EESR_RABT | EESR_RFE |
+ EESR_RDE | EESR_RFRMER | EESR_TFE | EESR_TDE,
+
+ .fdr_value = 0x0000070f,
+
+ .apr = 1,
+ .mpr = 1,
+ .tpauser = 1,
+ .hw_swap = 1,
+ .rpadir = 1,
+ .no_ade = 1,
+ .xdfar_rw = 1,
+};
#endif /* CONFIG_OF */
static void sh_eth_set_rate_sh7724(struct net_device *ndev)
@@ -3132,6 +3167,7 @@ static const struct of_device_id sh_eth_match_table[] = {
{ .compatible = "renesas,ether-r8a7794", .data = &rcar_gen2_data },
{ .compatible = "renesas,gether-r8a77980", .data = &r8a77980_data },
{ .compatible = "renesas,ether-r7s72100", .data = &r7s72100_data },
+ { .compatible = "renesas,ether-r7s9210", .data = &r7s9210_data },
{ .compatible = "renesas,rcar-gen1-ether", .data = &rcar_gen1_data },
{ .compatible = "renesas,rcar-gen2-ether", .data = &rcar_gen2_data },
{ }
--
2.16.1
^ permalink raw reply related
* YOUR PRODUCT
From: Rafaa Esawi @ 2018-08-27 17:26 UTC (permalink / raw)
Greetings,
We are rebuilding Iraq after years of conflicts and we are inviting you to
take up contracts. We are determined to purchase your products in large
quantities, for use in all over our 18 governorates(provinces) as the task
of re-building Iraq covers every single sectormand facet of our society.
We'll submit your products information to
the Iraqi Project and Contracting Office. They will examine the propriety
and necessity of your product and approve for bulk supply contracting
relationship.
I am currently on the board of the Iraqi Project and Contracting Office,
With my connections in the corridors of power, we are quite confident of
securing approval. Also of note is the issue of different financial
regulations between my country Iraq and your country. As such you will be
paid 100% through the Iraqi ministry of Finance
before you commence supplies. When you've received payment, we would be
expecting a monthly supply; as the sum budgeted for product may be quite
enormous as to outstrip your capacity and capability to supply.
A consideration also is that your quotation must be CIF Port of Umm Qasr.
Please send response so that I will reveal more procedural information to
you upon your re-confirmation.
Thany You.
Rafaa Esawi
^ permalink raw reply
* Re: [PATCH 0/2] staging: Fix some warnings from strncpy()
From: Greg KH @ 2018-08-27 17:48 UTC (permalink / raw)
To: Larry Finger; +Cc: devel, netdev
In-Reply-To: <20180820175124.23863-1-Larry.Finger@lwfinger.net>
On Mon, Aug 20, 2018 at 12:51:22PM -0500, Larry Finger wrote:
> When the size argument in a call to strncpy() is the size of the
> destimation, gcc8 issues a warning. These patches fix the potential
> problem by replacing the strncpy() with strlcpy().
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>
>
> Larry Finger (2):
> staging: rtl8192e: Fix compiler warning about strncpy
> staging: rtl8712u: Fix compiler warning about strncpy
>
> drivers/staging/rtl8192e/rtllib_softmac.c | 4 ++--
> drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
I'm guessing you will send a second set of this patch series, right?
This one is now dropped, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH] net: mvpp2: initialize port of_node pointer
From: Baruch Siach @ 2018-08-27 18:17 UTC (permalink / raw)
To: Andrew Lunn
Cc: Maxime Chevallier, Antoine Tenart, netdev, Russell King,
Ori Shem-Tov, Jason Cooper, Gregory Clement,
Sebastian Hesselbarth
In-Reply-To: <20180827134723.GD15473@lunn.ch>
Hi Andrew,
Thanks for reviewing.
On Mon, Aug 27, 2018 at 03:47:23PM +0200, Andrew Lunn wrote:
> On Mon, Aug 27, 2018 at 03:12:53PM +0300, Baruch Siach wrote:
> > Without a valid of_node in struct device we can't find the mvpp2 port
> > device by its DT node. Specifically, this breaks
> > of_find_net_device_by_node().
>
> We need to be a little bit careful here. I've seen this done wrongly
> before, breaking DSA support. Is you intention to use DSA? Can you
> quote a section of DT, and indicate which node is port_node.
Yes. This is for the Armada 8K based Clearfog GT-8K. The board has a Marvell
88E6141 switch connected to the &cp1_eth2 port.
Here are the relevant DT nodes:
&cp1_mdio {
...
switch0: switch0@4 {
compatible = "marvell,mv88e6085";
...
ports {
...
port@5 {
reg = <5>;
label = "cpu";
ethernet = <&cp1_eth2>;
};
};
Without this patch, dsa_register_switch() returns -EPROBE_DEFER because
of_find_net_device_by_node() can't find the device_node of the &cp1_eth2
device.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* Re: broken behaviour of TC filter delete
From: Cong Wang @ 2018-08-27 18:30 UTC (permalink / raw)
To: Jiri Pirko
Cc: Roman Mashak, Linux Kernel Network Developers, Jiri Pirko,
Jamal Hadi Salim
In-Reply-To: <20180825130243.GE2931@nanopsycho>
On Sat, Aug 25, 2018 at 6:06 AM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Fri, Aug 24, 2018 at 08:11:07PM CEST, xiyou.wangcong@gmail.com wrote:
> >On Fri, Aug 24, 2018 at 9:21 AM Roman Mashak <mrv@mojatatu.com> wrote:
> >>
> >> So _before_ commit f71e0ca4db187af7c44987e9d21e9042c3046070 step 6 would
> >> return -ENOENT with "Error: Filter with specified priority/protocol not
> >> found." and _after_ the commit it returns -EINVAL (Error: Cannot find
> >> specified filter chain.)
> >>
> >> ENOENT seems to be more logical to return when there's no more filter to delete.
> >
> >Yeah, at least we should keep ENOENT for compatibility.
> >
> >The bug here is chain 0 is gone after the last filter is gone,
> >so when you delete the filter again, it treats it as you specify
> >chain 0 which does not exist, so it hits EINVAL before ENOENT.
>
> I understand. My concern is about consistency with other chains. Perhaps
> -ENOENT for all chains in this case would be doable. What do you think?
Yeah, I think -ENOENT makes more sense than EINVAL here too.
^ permalink raw reply
* Re: [V2][PATCH net] tipc: fix the big/little endian issue in tipc_dest
From: David Miller @ 2018-08-27 22:24 UTC (permalink / raw)
To: Haiqing.Bai; +Cc: netdev, jon.maloy, ying.xue, zhenbo.gao, linux-kernel
In-Reply-To: <1535333546-16753-1-git-send-email-Haiqing.Bai@windriver.com>
From: Haiqing Bai <Haiqing.Bai@windriver.com>
Date: Mon, 27 Aug 2018 09:32:26 +0800
> In function tipc_dest_push, the 32bit variables 'node' and 'port'
> are stored separately in uppper and lower part of 64bit 'value'.
> Then this value is assigned to dst->value which is a union like:
> union
> {
> struct {
> u32 port;
> u32 node;
> };
> u64 value;
> }
> This works on little-endian machines like x86 but fails on big-endian
> machines.
>
> The fix remove the 'value' stack parameter and even the 'value'
> member of the union in tipc_dest, assign the 'node' and 'port' member
> directly with the input parameter to avoid the endian issue.
>
> Fixes: a80ae5306a73 ("tipc: improve destination linked list")
>
> Signed-off-by: Zhenbo Gao <zhenbo.gao@windriver.com>
> Acked-by: Jon Maloy <jon.maloy@ericsson.com>
> Signed-off-by: Haiqing Bai <Haiqing.Bai@windriver.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH 1/4] clk: x86: add "ether_clk" alias for Bay Trail / Cherry Trail
From: Stephen Boyd @ 2018-08-27 18:43 UTC (permalink / raw)
To: David S . Miller, Andy Shevchenko, Hans de Goede, Heiner Kallweit,
Irina Tirdea, Michael Turquette
Cc: Hans de Goede, netdev, Johannes Stezenbach, Carlo Caione,
linux-clk
In-Reply-To: <20180827143200.8597-2-hdegoede@redhat.com>
Quoting Hans de Goede (2018-08-27 07:31:57)
> Commit d31fd43c0f9a ("clk: x86: Do not gate clocks enabled by the
> firmware") causes all unclaimed PMC clocks on Cherry Trail devices to be on
> all the time, resulting on the device not being able to reach S0i2 or S0i3
> when suspended.
>
> The reason for this commit is that on some Bay Trail / Cherry Trail devices
> the ethernet controller uses pmc_plt_clk_4. This commit adds an "ether_clk"
> alias, so that the relevant ethernet drivers can try to (optionally) use
> this, without needing X86 specific code / hacks, thus fixing ethernet on
> these devices without breaking S0i3 support.
>
> This commit uses clkdev_hw_create() to create the alias, mirroring the code
> for the already existing "mclk" alias for pmc_plt_clk_3.
>
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=193891#c102
> Cc: Johannes Stezenbach <js@sig21.net>
> Cc: Carlo Caione <carlo@endlessm.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
Acked-by: Stephen Boyd <sboyd@kernel.org>
^ permalink raw reply
* Re: [PATCH] net: mvpp2: initialize port of_node pointer
From: Andrew Lunn @ 2018-08-27 18:44 UTC (permalink / raw)
To: Baruch Siach
Cc: Maxime Chevallier, Antoine Tenart, netdev, Russell King,
Ori Shem-Tov, Jason Cooper, Gregory Clement,
Sebastian Hesselbarth
In-Reply-To: <20180827181721.usbb2vvaenzxclkq@sapphire.tkos.co.il>
On Mon, Aug 27, 2018 at 09:17:21PM +0300, Baruch Siach wrote:
> Hi Andrew,
>
> Thanks for reviewing.
>
> On Mon, Aug 27, 2018 at 03:47:23PM +0200, Andrew Lunn wrote:
> > On Mon, Aug 27, 2018 at 03:12:53PM +0300, Baruch Siach wrote:
> > > Without a valid of_node in struct device we can't find the mvpp2 port
> > > device by its DT node. Specifically, this breaks
> > > of_find_net_device_by_node().
> >
> > We need to be a little bit careful here. I've seen this done wrongly
> > before, breaking DSA support. Is you intention to use DSA? Can you
> > quote a section of DT, and indicate which node is port_node.
>
> Yes. This is for the Armada 8K based Clearfog GT-8K. The board has a Marvell
> 88E6141 switch connected to the &cp1_eth2 port.
>
> Here are the relevant DT nodes:
>
> &cp1_mdio {
> ...
>
> switch0: switch0@4 {
> compatible = "marvell,mv88e6085";
> ...
>
> ports {
> ...
>
> port@5 {
> reg = <5>;
> label = "cpu";
> ethernet = <&cp1_eth2>;
> };
> };
>
> Without this patch, dsa_register_switch() returns -EPROBE_DEFER because
> of_find_net_device_by_node() can't find the device_node of the &cp1_eth2
> device.
O.K. This all looks correct.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH v2 0/2] staging: Fix some warnings from strncpy()
From: Larry Finger @ 2018-08-27 18:46 UTC (permalink / raw)
To: gregkh; +Cc: netdev, devel, Larry Finger
When the size argument in a call to strncpy() is the size of the
destimation, gcc8 issues a warning. These patches fix the potential
problem.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
v2 - The code is changed to implement the comments of David Laight.
Larry Finger (2):
staging: rtl8192e: Fix compiler warning about strncpy
staging: rtl8712u: Fix compiler warning about strncpy
drivers/staging/rtl8192e/rtllib_softmac.c | 4 ++--
drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--
2.18.0
^ permalink raw reply
* [PATCH v2 1/2] staging: rtl8192e: Fix compiler warning from strncpy()
From: Larry Finger @ 2018-08-27 18:46 UTC (permalink / raw)
To: gregkh; +Cc: netdev, devel, Larry Finger
In-Reply-To: <20180827184646.10276-1-Larry.Finger@lwfinger.net>
When strncpy() is called with source and destination strings the same
length, gcc 8 warns that there may be an unterminated string. This section
is completely reworked to use the known lengths of the strings.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
v2 - David Laight's comments are implemented.
---
drivers/staging/rtl8192e/rtllib_softmac.c | 18 ++++++++++--------
drivers/staging/rtl8192e/rtllib_softmac.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c b/drivers/staging/rtl8192e/rtllib_softmac.c
index 919231fec09c..287d0c11fa38 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -1680,19 +1680,19 @@ inline void rtllib_softmac_new_net(struct rtllib_device *ieee,
(ssidbroad && !ssidset) || (!ssidbroad && ssidset))) ||
(!apset && ssidset && ssidbroad && ssidmatch) ||
(ieee->is_roaming && ssidset && ssidbroad && ssidmatch)) {
- /* if the essid is hidden replace it with the
- * essid provided by the user.
+ /* Save the essid so that if it is hidden, it is
+ * replaced with the essid provided by the user.
*/
if (!ssidbroad) {
- strncpy(tmp_ssid, ieee->current_network.ssid,
- IW_ESSID_MAX_SIZE);
+ memcpy(tmp_ssid, ieee->current_network.ssid,
+ ieee->current_network.ssid_len);
tmp_ssid_len = ieee->current_network.ssid_len;
}
- memcpy(&ieee->current_network, net,
- sizeof(struct rtllib_network));
+ memcpy(&ieee->current_network, net,
+ sizeof(ieee->current_network));
if (!ssidbroad) {
- strncpy(ieee->current_network.ssid, tmp_ssid,
- IW_ESSID_MAX_SIZE);
+ memcpy(ieee->current_network.ssid, tmp_ssid,
+ tmp_ssid_len);
ieee->current_network.ssid_len = tmp_ssid_len;
}
netdev_info(ieee->dev,
--
2.18.0
^ permalink raw reply related
* [PATCH v2 2/2] staging: rtl8712u: Fix compiler warning about strncpy
From: Larry Finger @ 2018-08-27 18:46 UTC (permalink / raw)
To: gregkh; +Cc: netdev, devel, Larry Finger
In-Reply-To: <20180827184646.10276-1-Larry.Finger@lwfinger.net>
When strncpy() is called with source and destination strings the same
length, gcc 8 warns that there may be an unterminated string. Using
strlcpy() rather than strncpy() forces a null at the end and quiets the
warning.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
v2 - No changes.
---
drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index c3ff7c3e6681..08e1c0957a07 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -1789,7 +1789,7 @@ static int r871x_wx_set_enc_ext(struct net_device *dev,
return -ENOMEM;
param->cmd = IEEE_CMD_SET_ENCRYPTION;
eth_broadcast_addr(param->sta_addr);
- strncpy((char *)param->u.crypt.alg, alg_name, IEEE_CRYPT_ALG_NAME_LEN);
+ strlcpy((char *)param->u.crypt.alg, alg_name, IEEE_CRYPT_ALG_NAME_LEN);
if (pext->ext_flags & IW_ENCODE_EXT_GROUP_KEY)
param->u.crypt.set_tx = 0;
if (pext->ext_flags & IW_ENCODE_EXT_SET_TX_KEY)
--
2.18.0
^ permalink raw reply related
* Re: [PATCH 2/4] r8169: Get and enable optional ether_clk clock
From: Stephen Boyd @ 2018-08-27 18:47 UTC (permalink / raw)
To: David S . Miller, Andy Shevchenko, Hans de Goede, Heiner Kallweit,
Irina Tirdea, Michael Turquette
Cc: Hans de Goede, netdev, Johannes Stezenbach, Carlo Caione,
linux-clk
In-Reply-To: <20180827143200.8597-3-hdegoede@redhat.com>
Quoting Hans de Goede (2018-08-27 07:31:58)
> On some boards a platform clock is used as clock for the r8169 chip,
> this commit adds support for getting and enabling this clock (assuming
> it has an "ether_clk" alias set on it).
>
> This is related to commit d31fd43c0f9a ("clk: x86: Do not gate clocks
> enabled by the firmware") which is a previous attempt to fix this for some
> x86 boards, but this causes all Cherry Trail SoC using boards to not reach
> there lowest power states when suspending.
>
> This commit (together with an atom-pmc-clk driver commit adding the alias)
> fixes things properly by making the r8169 get the clock and enable it when
> it needs it.
>
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=193891#c102
> Cc: Johannes Stezenbach <js@sig21.net>
> Cc: Carlo Caione <carlo@endlessm.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
> @@ -7614,6 +7616,11 @@ static void rtl_hw_initialize(struct rtl8169_private *tp)
> }
> }
>
> +static void rtl_disable_clk(void *data)
> +{
> + clk_disable_unprepare(data);
> +}
> +
> static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> {
> const struct rtl_cfg_info *cfg = rtl_cfg_infos + ent->driver_data;
> @@ -7647,6 +7654,32 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> mii->reg_num_mask = 0x1f;
> mii->supports_gmii = cfg->has_gmii;
>
> + /* Get the *optional* external "ether_clk" used on some boards */
> + tp->clk = devm_clk_get(&pdev->dev, "ether_clk");
An "optional" clk API is in flight, but it's easier to wait for that to
merge and then this to be updated, so just take that as an FYI. It would
be interesting to see how to support optional clks with clkdev lookups
though, which would be needed in this case.
How would you know that a clk device driver hasn't probed yet and isn't
the driver that's actually providing the clk to this device on x86
systems? With DT systems we can figure that out by looking at the DT and
seeing if the device driver requesting the clk has the clocks property.
On x86 systems it's all clkdev which doesn't really lend itself to
solving this problem.
> + if (IS_ERR(tp->clk)) {
> + rc = PTR_ERR(tp->clk);
^ permalink raw reply
* Re: KASAN: invalid-free in p9stat_free
From: Dominique Martinet @ 2018-08-27 22:40 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, David Miller, Eric Van Hensbergen, LKML, Latchesar Ionkov,
netdev, syzkaller-bugs, v9fs-developer
In-Reply-To: <CACT4Y+b1B5_Eg+j91GxaVbPk5sb8+SVOU_z5k9HYb4R716X9kQ@mail.gmail.com>
Dmitry Vyukov wrote on Mon, Aug 27, 2018:
> kfree and then null pointer is pretty common, try to run:
>
> find -name "*.c" -exec grep -A 1 "kfree(" {} \; | grep -B 1 " = NULL;"
Hmm, right, it looks like somewhere between 5 and 10% of the kfree()
calls are followed by NULL assignment, that's "common enough" - not
generalized but not rare either.
> Leaving dangling pointers behind is not the best idea.
> And from what I remember a bunch of similar double frees were fixed by
> nulling the pointer after the first kfree.
In this case it really is an error to call p9stat_free again, so let's
just do both.
Will send the patches shortly.
Thanks,
--
Dominique
^ permalink raw reply
* Re: [PATCH 2/4] r8169: Get and enable optional ether_clk clock
From: Hans de Goede @ 2018-08-27 18:53 UTC (permalink / raw)
To: Stephen Boyd, David S . Miller, Andy Shevchenko, Heiner Kallweit,
Irina Tirdea, Michael Turquette
Cc: netdev, Johannes Stezenbach, Carlo Caione, linux-clk
In-Reply-To: <153539565488.129321.2586881199420174235@swboyd.mtv.corp.google.com>
Hi,
On 27-08-18 20:47, Stephen Boyd wrote:
> Quoting Hans de Goede (2018-08-27 07:31:58)
>> On some boards a platform clock is used as clock for the r8169 chip,
>> this commit adds support for getting and enabling this clock (assuming
>> it has an "ether_clk" alias set on it).
>>
>> This is related to commit d31fd43c0f9a ("clk: x86: Do not gate clocks
>> enabled by the firmware") which is a previous attempt to fix this for some
>> x86 boards, but this causes all Cherry Trail SoC using boards to not reach
>> there lowest power states when suspending.
>>
>> This commit (together with an atom-pmc-clk driver commit adding the alias)
>> fixes things properly by making the r8169 get the clock and enable it when
>> it needs it.
>>
>> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=193891#c102
>> Cc: Johannes Stezenbach <js@sig21.net>
>> Cc: Carlo Caione <carlo@endlessm.com>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
> Acked-by: Stephen Boyd <sboyd@kernel.org>
Thanks.
>> @@ -7614,6 +7616,11 @@ static void rtl_hw_initialize(struct rtl8169_private *tp)
>> }
>> }
>>
>> +static void rtl_disable_clk(void *data)
>> +{
>> + clk_disable_unprepare(data);
>> +}
>> +
>> static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> {
>> const struct rtl_cfg_info *cfg = rtl_cfg_infos + ent->driver_data;
>> @@ -7647,6 +7654,32 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>> mii->reg_num_mask = 0x1f;
>> mii->supports_gmii = cfg->has_gmii;
>>
>> + /* Get the *optional* external "ether_clk" used on some boards */
>> + tp->clk = devm_clk_get(&pdev->dev, "ether_clk");
>
> An "optional" clk API is in flight, but it's easier to wait for that to
> merge and then this to be updated, so just take that as an FYI.
That is good to know.
> It would
> be interesting to see how to support optional clks with clkdev lookup > though, which would be needed in this case.
Ack.
> How would you know that a clk device driver hasn't probed yet and isn't
> the driver that's actually providing the clk to this device on x86
> systems? With DT systems we can figure that out by looking at the DT and
> seeing if the device driver requesting the clk has the clocks property.
> On x86 systems it's all clkdev which doesn't really lend itself to
> solving this problem.
Right on x86 the assumption is that the clk driver will be builtin and
will probe before the consumer. In this case that is true as the
pmc-atom-clk driver can only be builtin and its platform device is
instantiated from the acpi_lpss code and acpi init happens before
the PCI bus is scanned.
We have the same problem with ACPI OpRegions and drivers who have
_PS0 / _PS3 methods using those OpRegions and the "solution" so far
is the same, make sure all drivers providing OpRegion handlers are
builtin.
Basically we (x86) miss the nice dependency info and complete hw
description devicetree gives, so we rely on initialization order
for some of this. I added the -EPROBE_DEFER handling for completeness
sake / for other platforms, as you point out it will never trigger
on x86.
Regards,
Hans
>
>> + if (IS_ERR(tp->clk)) {
>> + rc = PTR_ERR(tp->clk);
^ permalink raw reply
* [patch net 0/2] net: sched: couple of small fixes
From: Jiri Pirko @ 2018-08-27 18:58 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, xiyou.wangcong, mrv, mlxsw
From: Jiri Pirko <jiri@mellanox.com>
Jiri Pirko (2):
net: sched: fix extack error message when chain is failed to be
created
net: sched: return -ENOENT when trying to remove filter from
non-existent chain
net/sched/cls_api.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.14.4
^ permalink raw reply
* [patch net 1/2] net: sched: fix extack error message when chain is failed to be created
From: Jiri Pirko @ 2018-08-27 18:58 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, xiyou.wangcong, mrv, mlxsw
In-Reply-To: <20180827185844.4517-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@mellanox.com>
Instead "Cannot find" say "Cannot create".
Fixes: c35a4acc2985 ("net: sched: cls_api: handle generic cls errors")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
net/sched/cls_api.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index 31bd1439cf60..2d41c5b21b48 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -1252,7 +1252,7 @@ static int tc_new_tfilter(struct sk_buff *skb, struct nlmsghdr *n,
}
chain = tcf_chain_get(block, chain_index, true);
if (!chain) {
- NL_SET_ERR_MSG(extack, "Cannot find specified filter chain");
+ NL_SET_ERR_MSG(extack, "Cannot create specified filter chain");
err = -ENOMEM;
goto errout;
}
--
2.14.4
^ permalink raw reply related
* [patch net 2/2] net: sched: return -ENOENT when trying to remove filter from non-existent chain
From: Jiri Pirko @ 2018-08-27 18:58 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, xiyou.wangcong, mrv, mlxsw
In-Reply-To: <20180827185844.4517-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@mellanox.com>
When chain 0 was implicitly created, removal of non-existent filter from
chain 0 gave -ENOENT. Once chain 0 became non-implicit, the same call is
giving -EINVAL. Fix this by returning -ENOENT in that case.
Reported-by: Roman Mashak <mrv@mojatatu.com>
Fixes: f71e0ca4db18 ("net: sched: Avoid implicit chain 0 creation")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
net/sched/cls_api.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index 2d41c5b21b48..1a67af8a6e8c 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -1399,7 +1399,7 @@ static int tc_del_tfilter(struct sk_buff *skb, struct nlmsghdr *n,
goto errout;
}
NL_SET_ERR_MSG(extack, "Cannot find specified filter chain");
- err = -EINVAL;
+ err = -ENOENT;
goto errout;
}
--
2.14.4
^ permalink raw reply related
* [PATCH 1/2] v9fs_dir_readdir: fix double-free on p9stat_read error
From: Dominique Martinet @ 2018-08-27 22:48 UTC (permalink / raw)
To: v9fs-developer
Cc: Dominique Martinet, linux-kernel, netdev, syzkaller-bugs,
Eric Van Hensbergen, Latchesar Ionkov
In-Reply-To: <000000000000af648b057456e234@google.com>
From: Dominique Martinet <dominique.martinet@cea.fr>
p9stat_read will call p9stat_free on error, we should only free the
struct content on success.
There also is no need to "p9stat_init" st as the read function will
zero the whole struct for us anyway, so clean up the code a bit while
we are here.
Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
Reported-by: syzbot+d4252148d198410b864f@syzkaller.appspotmail.com
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Latchesar Ionkov <lucho@ionkov.net>
---
fs/9p/vfs_dir.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/fs/9p/vfs_dir.c b/fs/9p/vfs_dir.c
index b0405d6aac85..48db9a9f13f9 100644
--- a/fs/9p/vfs_dir.c
+++ b/fs/9p/vfs_dir.c
@@ -76,15 +76,6 @@ static inline int dt_type(struct p9_wstat *mistat)
return rettype;
}
-static void p9stat_init(struct p9_wstat *stbuf)
-{
- stbuf->name = NULL;
- stbuf->uid = NULL;
- stbuf->gid = NULL;
- stbuf->muid = NULL;
- stbuf->extension = NULL;
-}
-
/**
* v9fs_alloc_rdir_buf - Allocate buffer used for read and readdir
* @filp: opened file structure
@@ -145,12 +136,10 @@ static int v9fs_dir_readdir(struct file *file, struct dir_context *ctx)
rdir->tail = n;
}
while (rdir->head < rdir->tail) {
- p9stat_init(&st);
err = p9stat_read(fid->clnt, rdir->buf + rdir->head,
rdir->tail - rdir->head, &st);
if (err) {
p9_debug(P9_DEBUG_VFS, "returned %d\n", err);
- p9stat_free(&st);
return -EIO;
}
reclen = st.size+2;
--
2.17.1
^ permalink raw reply related
* [PATCH 2/2] 9p: clear dangling pointers in p9stat_free
From: Dominique Martinet @ 2018-08-27 22:48 UTC (permalink / raw)
To: v9fs-developer
Cc: Dominique Martinet, linux-kernel, netdev, syzkaller-bugs,
Eric Van Hensbergen, Latchesar Ionkov
In-Reply-To: <1535410108-20650-1-git-send-email-asmadeus@codewreck.org>
From: Dominique Martinet <dominique.martinet@cea.fr>
p9stat_free is more of a cleanup function than a 'free' function as it
only frees the content of the struct; there are chances of use-after-free
if it is improperly used (e.g. p9stat_free called twice as it used to be
possible to)
Clearing dangling pointers makes the function idempotent and safer to use.
Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
Reported-by: syzbot+d4252148d198410b864f@syzkaller.appspotmail.com
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Latchesar Ionkov <lucho@ionkov.net>
---
net/9p/protocol.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/9p/protocol.c b/net/9p/protocol.c
index 4a1e1dd30b52..ee32bbf12675 100644
--- a/net/9p/protocol.c
+++ b/net/9p/protocol.c
@@ -46,10 +46,15 @@ p9pdu_writef(struct p9_fcall *pdu, int proto_version, const char *fmt, ...);
void p9stat_free(struct p9_wstat *stbuf)
{
kfree(stbuf->name);
+ stbuf->name = NULL;
kfree(stbuf->uid);
+ stbuf->uid = NULL;
kfree(stbuf->gid);
+ stbuf->gid = NULL;
kfree(stbuf->muid);
+ stbuf->muid = NULL;
kfree(stbuf->extension);
+ stbuf->extension = NULL;
}
EXPORT_SYMBOL(p9stat_free);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 2/4] r8169: Get and enable optional ether_clk clock
From: Stephen Boyd @ 2018-08-27 19:14 UTC (permalink / raw)
To: David S . Miller, Andy Shevchenko, Hans de Goede, Heiner Kallweit,
Irina Tirdea, Michael Turquette
Cc: netdev, Johannes Stezenbach, Carlo Caione, linux-clk
In-Reply-To: <0f52c05a-4f70-3022-3720-07c6bcf29ed8@redhat.com>
Quoting Hans de Goede (2018-08-27 11:53:19)
> On 27-08-18 20:47, Stephen Boyd wrote:
> > How would you know that a clk device driver hasn't probed yet and isn't
> > the driver that's actually providing the clk to this device on x86
> > systems? With DT systems we can figure that out by looking at the DT and
> > seeing if the device driver requesting the clk has the clocks property.
> > On x86 systems it's all clkdev which doesn't really lend itself to
> > solving this problem.
>
> Right on x86 the assumption is that the clk driver will be builtin and
> will probe before the consumer. In this case that is true as the
> pmc-atom-clk driver can only be builtin and its platform device is
> instantiated from the acpi_lpss code and acpi init happens before
> the PCI bus is scanned.
If we can go with this assumption then we can make the optional clk API
work even on clkdev based systems. Maybe if x86 had some way of
indicating that all builtin clks are registered? That might work but
it's not very clean. Or if we could check to see if we're running on an
ACPI based system in clkdev we could use that to assume that clk_get()
will only be called after all providers have registered their lookups.
>
> We have the same problem with ACPI OpRegions and drivers who have
> _PS0 / _PS3 methods using those OpRegions and the "solution" so far
> is the same, make sure all drivers providing OpRegion handlers are
> builtin.
>
> Basically we (x86) miss the nice dependency info and complete hw
> description devicetree gives, so we rely on initialization order
> for some of this. I added the -EPROBE_DEFER handling for completeness
> sake / for other platforms, as you point out it will never trigger
> on x86.
>
Thanks for the info!
^ permalink raw reply
* Re: [PATCH v2 2/2] 9p: Add refcount to p9_req_t
From: Dominique Martinet @ 2018-08-27 23:09 UTC (permalink / raw)
To: Tomas Bortoli
Cc: ericvh, rminnich, lucho, davem, v9fs-developer, netdev,
linux-kernel, syzkaller, Dominique Martinet
In-Reply-To: <20180814174342.11068-2-tomasbortoli@gmail.com>
Tomas Bortoli wrote on Tue, Aug 14, 2018:
> To avoid use-after-free(s), use a refcount to keep track of the
> usable references to any instantiated struct p9_req_t.
>
> This commit adds p9_req_put(), p9_req_get() and p9_req_try_get() as
> wrappers to kref_put(), kref_get() and kref_get_unless_zero().
> These are used by the client and the transports to keep track of
> valid requests' references.
>
> p9_free_req() is added back and used as callback by kref_put().
>
> Add SLAB_TYPESAFE_BY_RCU as it ensures that the memory freed by
> kmem_cache_free() will not be reused for another type until the rcu
> synchronisation period is over, so an address gotten under rcu read
> lock is safe to inc_ref() without corrupting random memory while
> the lock is held.
FWIW, since 4.19-rc1 has been tagged I was going to push this and all
the perrequesites to linux-next, but I've managed to leak some requests
by interrupting them in trans_virtio.
I think I've found why (see below), so I'll push a fixed version after
some more testing and another thorough read -- at some point today, but
this hasn't been 'approved' explicitely so please review! :)
(Jun, I think you'll need to ask again to rename 'req' to 'rreq' if you
think it's important -- I think such a rename should go in a separate
patch anyway, there's plenty of time until the 4.20 merge window)
By "all the prerequesites" I mean this patch "serie":
* 9p: Use a slab for allocating requests
* 9p: Remove p9_idpool
* net/9p: embed fcall in req to round down buffer allocs
* net/9p: add a per-client fcall kmem_cache
* 9p: rename p9_free_req() function
* 9p: Add refcount to p9_req_t
All the other patchs have had some review though, I was just waiting for
the start of this cycle, but if someone has any issue with the above
patches now is a good time to say.
> diff --git a/net/9p/client.c b/net/9p/client.c
> index 7942c0bfcc5b..c9bb5d41afa4 100644
> --- a/net/9p/client.c
> +++ b/net/9p/client.c
> @@ -716,6 +756,8 @@ p9_client_rpc(struct p9_client *c, int8_t type, const char *fmt, ...)
>
> err = c->trans_mod->request(c, req);
> if (err < 0) {
> + /* write won't happen */
> + p9_req_put(req);
> if (err != -ERESTARTSYS && err != -EFAULT)
> c->status = Disconnected;
> goto recalc_sigpending;
p9_client_zc_rpc needs the same put if zc_request failed, I'm not sure
why it wasn't here in my draft
--
Dominique
^ 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