* Re: [PATCH] dt-bindings: net: dwmac: fix 'mac-mode' type
From: Florian Fainelli @ 2019-09-21 3:02 UTC (permalink / raw)
To: Jakub Kicinski, Alexandru Ardelean
Cc: netdev, devicetree, linux-kernel, davem, robh+dt, peppe.cavallaro,
alexandre.torgue, andrew
In-Reply-To: <20190920181141.52cfee67@cakuba.netronome.com>
On 9/20/2019 6:11 PM, Jakub Kicinski wrote:
> On Tue, 17 Sep 2019 13:30:52 +0300, Alexandru Ardelean wrote:
>> The 'mac-mode' property is similar to 'phy-mode' and 'phy-connection-type',
>> which are enums of mode strings.
>>
>> The 'dwmac' driver supports almost all modes declared in the 'phy-mode'
>> enum (except for 1 or 2). But in general, there may be a case where
>> 'mac-mode' becomes more generic and is moved as part of phylib or netdev.
>>
>> In any case, the 'mac-mode' field should be made an enum, and it also makes
>> sense to just reference the 'phy-connection-type' from
>> 'ethernet-controller.yaml'. That will also make it more future-proof for new
>> modes.
>>
>> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
>
> Applied, thank you!
>
> FWIW I had to add the Fixes tag by hand, either ozlabs patchwork or my
> git-pw doesn't have the automagic handling there, yet.
AFAICT the ozlabs patchwork instance does not do it, but if you have
patchwork administrative rights (the jango administration panel I mean)
then it is simple to add the regular expression to the list of tags that
patchwork already recognized. Had tried getting that included by
default, but it also counted all of those tags and therefore was not
particularly fine grained:
https://lists.ozlabs.org/pipermail/patchwork/2017-January/003910.html
--
Florian
^ permalink raw reply
* Re: Verify ACK packets in handshake in kernel module (Access TCP state table)
From: Willy Tarreau @ 2019-09-21 3:15 UTC (permalink / raw)
To: Swarm; +Cc: netdev
In-Reply-To: <20190920234346.kz22qswwvjxjins7@chillin-at-nou>
On Fri, Sep 20, 2019 at 11:43:50PM +0000, Swarm wrote:
> First time emailing to this mailing list so please let me know if I made a
> mistake in how I sent it. I'm trying to receive a notification from the
> kernel once it verifies an ACK packet in a handshake. Problem is, there is no
> API or kernel resource I've seen that supports this feature for both
> syncookies and normal handshakes. Where exactly in the kernel does the ACK
> get verified? If there isn't a way to be notified of it, where should I start
> adding that feature into the kernel?
Just searching for TCP_ESTABLISHED immediately brought me to tcp_input.c
(tcp_rcv_state_process() to be precise), so I'm not sure you've searched
that much. As you've noticed there's nothing specifically called in this
case, but in practice a caller of accept() on a listening socket will be
woken up.
Hoping this helps,
Willy
^ permalink raw reply
* Re: Verify ACK packets in handshake in kernel module (Access TCP state table)
From: Yadunandan Pillai @ 2019-09-21 4:18 UTC (permalink / raw)
To: w; +Cc: netdev, thesw4rm
In-Reply-To: <20190921031529.GG1889@1wt.eu>
You're right. I clearly need to be more aware of where I am looking. I think I got tripped up because I was trying to only look at header files like a noob. There is a tcp_ack function there with flags for this purpose. Appreciate it!
Just one question, would it be acceptable to directly include the C file in a kernel module?
^ permalink raw reply
* Re: [PATCH -net] zd1211rw: zd_usb: Use "%zu" to format size_t
From: Kalle Valo @ 2019-09-21 5:57 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Gustavo A . R . Silva, Daniel Drake, Ulrich Kunitz,
David S . Miller, linux-wireless, netdev, linux-kernel,
Geert Uytterhoeven
In-Reply-To: <20190919091532.24951-1-geert@linux-m68k.org>
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On 32-bit:
>
> drivers/net/wireless/zydas/zd1211rw/zd_usb.c: In function ‘check_read_regs’:
> drivers/net/wireless/zydas/zd1211rw/zd_def.h:18:25: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 6 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
> dev_printk(level, dev, "%s() " fmt, __func__, ##args)
> ^~~~~~~
> drivers/net/wireless/zydas/zd1211rw/zd_def.h:22:4: note: in expansion of macro ‘dev_printk_f’
> dev_printk_f(KERN_DEBUG, dev, fmt, ## args)
> ^~~~~~~~~~~~
> drivers/net/wireless/zydas/zd1211rw/zd_usb.c:1635:3: note: in expansion of macro ‘dev_dbg_f’
> dev_dbg_f(zd_usb_dev(usb),
> ^~~~~~~~~
> drivers/net/wireless/zydas/zd1211rw/zd_usb.c:1636:51: note: format string is defined here
> "error: actual length %d less than expected %ld\n",
> ~~^
> %d
>
> Fixes: 84b0b66352470e64 ("zd1211rw: zd_usb: Use struct_size() helper")
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Patch applied to wireless-drivers.git, thanks.
6355592e6b55 zd1211rw: zd_usb: Use "%zu" to format size_t
--
https://patchwork.kernel.org/patch/11151959/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH net] ionic: Fix an error code in ionic_lif_alloc()
From: Dan Carpenter @ 2019-09-21 5:59 UTC (permalink / raw)
To: Shannon Nelson; +Cc: Pensando Drivers, David S. Miller, netdev, kernel-janitors
We need to set the error code on this path. Otherwise it probably
results in a NULL dereference down the line.
Fixes: aa3198819bea ("ionic: Add RSS support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
drivers/net/ethernet/pensando/ionic/ionic_lif.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/pensando/ionic/ionic_lif.c b/drivers/net/ethernet/pensando/ionic/ionic_lif.c
index db7c82742828..72107a0627a9 100644
--- a/drivers/net/ethernet/pensando/ionic/ionic_lif.c
+++ b/drivers/net/ethernet/pensando/ionic/ionic_lif.c
@@ -1704,6 +1704,7 @@ static struct ionic_lif *ionic_lif_alloc(struct ionic *ionic, unsigned int index
GFP_KERNEL);
if (!lif->rss_ind_tbl) {
+ err = -ENOMEM;
dev_err(dev, "Failed to allocate rss indirection table, aborting\n");
goto err_out_free_qcqs;
}
--
2.20.1
^ permalink raw reply related
* [PATCH] hdlc: Simplify code in 'pvc_xmit()'
From: Christophe JAILLET @ 2019-09-21 6:17 UTC (permalink / raw)
To: khc, davem; +Cc: netdev, linux-kernel, kernel-janitors, Christophe JAILLET
Use __skb_pad instead of rewriting it, this saves some LoC.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
Compile tested only.
---
drivers/net/wan/hdlc_fr.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c
index 9acad651ea1f..30f20b667c8b 100644
--- a/drivers/net/wan/hdlc_fr.c
+++ b/drivers/net/wan/hdlc_fr.c
@@ -414,16 +414,12 @@ static netdev_tx_t pvc_xmit(struct sk_buff *skb, struct net_device *dev)
if (dev->type == ARPHRD_ETHER) {
int pad = ETH_ZLEN - skb->len;
if (pad > 0) { /* Pad the frame with zeros */
- int len = skb->len;
- if (skb_tailroom(skb) < pad)
- if (pskb_expand_head(skb, 0, pad,
- GFP_ATOMIC)) {
- dev->stats.tx_dropped++;
- dev_kfree_skb(skb);
- return NETDEV_TX_OK;
- }
+ if (__skb_pad(skb, pad, false) < 0) {
+ dev->stats.tx_dropped++;
+ dev_kfree_skb(skb);
+ return NETDEV_TX_OK;
+ }
skb_put(skb, pad);
- memset(skb->data + len, 0, pad);
}
skb->protocol = cpu_to_be16(ETH_P_802_3);
}
--
2.20.1
^ permalink raw reply related
* Re: Fwd: [PATCH] bonding/802.3ad: fix slave initialization states race
From: Jay Vosburgh @ 2019-09-21 7:06 UTC (permalink / raw)
To: =?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JfQsNGF0LDRgNC+0LI=?=; +Cc: netdev
In-Reply-To: <CAJYOGF-L0bEF_BqbyeKqv4xmLV=e2VKUvo5zPx4rULWdwt8e0Q@mail.gmail.com>
Алексей Захаров wrote:
>>
>> Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
>> [...]
>> > In any event, I think I see what the failure is, I'm working up
>> >a patch to test and will post it when I have it ready.
>>
>> Aleksei,
>>
>> Would you be able to test the following patch and see if it
>> resolves the issue in your testing? This is against current net-next,
>> but applies to current net as well. Your kernel appears to be a bit
>> older (as the message formats differ), so hopefully it will apply there
>> as well. I've tested this a bit (but not the ARP mon portion), and it
>> seems to do the right thing, but I can't reproduce the original issue
>> locally.
>We're testing on ubuntu-bionic 4.15 kernel.
I believe the following will apply for the Ubuntu 4.15 kernels;
this is against 4.15.0-60, so you may have some fuzz if your version is
far removed. I've not tested this as I'm travelling at the moment, but
the only real difference is the netdev_err vs. slave_err changes in
bonding that aren't relevant to the fix itself.
-J
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 8cd25eb26a9a..b159a6595e11 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2057,8 +2057,7 @@ static int bond_miimon_inspect(struct bonding *bond)
ignore_updelay = !rcu_dereference(bond->curr_active_slave);
bond_for_each_slave_rcu(bond, slave, iter) {
- slave->new_link = BOND_LINK_NOCHANGE;
- slave->link_new_state = slave->link;
+ bond_propose_link_state(slave, BOND_LINK_NOCHANGE);
link_state = bond_check_dev_link(bond, slave->dev, 0);
@@ -2094,7 +2093,7 @@ static int bond_miimon_inspect(struct bonding *bond)
}
if (slave->delay <= 0) {
- slave->new_link = BOND_LINK_DOWN;
+ bond_propose_link_state(slave, BOND_LINK_DOWN);
commit++;
continue;
}
@@ -2133,7 +2132,7 @@ static int bond_miimon_inspect(struct bonding *bond)
slave->delay = 0;
if (slave->delay <= 0) {
- slave->new_link = BOND_LINK_UP;
+ bond_propose_link_state(slave, BOND_LINK_UP);
commit++;
ignore_updelay = false;
continue;
@@ -2153,7 +2152,7 @@ static void bond_miimon_commit(struct bonding *bond)
struct slave *slave, *primary;
bond_for_each_slave(bond, slave, iter) {
- switch (slave->new_link) {
+ switch (slave->link_new_state) {
case BOND_LINK_NOCHANGE:
continue;
@@ -2237,8 +2236,8 @@ static void bond_miimon_commit(struct bonding *bond)
default:
netdev_err(bond->dev, "invalid new link %d on slave %s\n",
- slave->new_link, slave->dev->name);
- slave->new_link = BOND_LINK_NOCHANGE;
+ slave->link_new_state, slave->dev->name);
+ bond_propose_link_state(slave, BOND_LINK_NOCHANGE);
continue;
}
@@ -2638,13 +2637,13 @@ static void bond_loadbalance_arp_mon(struct bonding *bond)
bond_for_each_slave_rcu(bond, slave, iter) {
unsigned long trans_start = dev_trans_start(slave->dev);
- slave->new_link = BOND_LINK_NOCHANGE;
+ bond_propose_link_state(slave, BOND_LINK_NOCHANGE);
if (slave->link != BOND_LINK_UP) {
if (bond_time_in_interval(bond, trans_start, 1) &&
bond_time_in_interval(bond, slave->last_rx, 1)) {
- slave->new_link = BOND_LINK_UP;
+ bond_propose_link_state(slave, BOND_LINK_UP);
slave_state_changed = 1;
/* primary_slave has no meaning in round-robin
@@ -2671,7 +2670,7 @@ static void bond_loadbalance_arp_mon(struct bonding *bond)
if (!bond_time_in_interval(bond, trans_start, 2) ||
!bond_time_in_interval(bond, slave->last_rx, 2)) {
- slave->new_link = BOND_LINK_DOWN;
+ bond_propose_link_state(slave, BOND_LINK_DOWN);
slave_state_changed = 1;
if (slave->link_failure_count < UINT_MAX)
@@ -2703,8 +2702,8 @@ static void bond_loadbalance_arp_mon(struct bonding *bond)
goto re_arm;
bond_for_each_slave(bond, slave, iter) {
- if (slave->new_link != BOND_LINK_NOCHANGE)
- slave->link = slave->new_link;
+ if (slave->link_new_state != BOND_LINK_NOCHANGE)
+ slave->link = slave->link_new_state;
}
if (slave_state_changed) {
@@ -2727,9 +2726,9 @@ static void bond_loadbalance_arp_mon(struct bonding *bond)
}
/* Called to inspect slaves for active-backup mode ARP monitor link state
- * changes. Sets new_link in slaves to specify what action should take
- * place for the slave. Returns 0 if no changes are found, >0 if changes
- * to link states must be committed.
+ * changes. Sets proposed link state in slaves to specify what action
+ * should take place for the slave. Returns 0 if no changes are found, >0
+ * if changes to link states must be committed.
*
* Called with rcu_read_lock held.
*/
@@ -2741,12 +2740,12 @@ static int bond_ab_arp_inspect(struct bonding *bond)
int commit = 0;
bond_for_each_slave_rcu(bond, slave, iter) {
- slave->new_link = BOND_LINK_NOCHANGE;
+ bond_propose_link_state(slave, BOND_LINK_NOCHANGE);
last_rx = slave_last_rx(bond, slave);
if (slave->link != BOND_LINK_UP) {
if (bond_time_in_interval(bond, last_rx, 1)) {
- slave->new_link = BOND_LINK_UP;
+ bond_propose_link_state(slave, BOND_LINK_UP);
commit++;
}
continue;
@@ -2774,7 +2773,7 @@ static int bond_ab_arp_inspect(struct bonding *bond)
if (!bond_is_active_slave(slave) &&
!rcu_access_pointer(bond->current_arp_slave) &&
!bond_time_in_interval(bond, last_rx, 3)) {
- slave->new_link = BOND_LINK_DOWN;
+ bond_propose_link_state(slave, BOND_LINK_DOWN);
commit++;
}
@@ -2787,7 +2786,7 @@ static int bond_ab_arp_inspect(struct bonding *bond)
if (bond_is_active_slave(slave) &&
(!bond_time_in_interval(bond, trans_start, 2) ||
!bond_time_in_interval(bond, last_rx, 2))) {
- slave->new_link = BOND_LINK_DOWN;
+ bond_propose_link_state(slave, BOND_LINK_DOWN);
commit++;
}
}
@@ -2807,7 +2806,7 @@ static void bond_ab_arp_commit(struct bonding *bond)
struct slave *slave;
bond_for_each_slave(bond, slave, iter) {
- switch (slave->new_link) {
+ switch (slave->link_new_state) {
case BOND_LINK_NOCHANGE:
continue;
@@ -2859,8 +2858,8 @@ static void bond_ab_arp_commit(struct bonding *bond)
continue;
default:
- netdev_err(bond->dev, "impossible: new_link %d on slave %s\n",
- slave->new_link, slave->dev->name);
+ netdev_err(bond->dev, "impossible: link_new_state %d on slave %s\n",
+ slave->link_new_state, slave->dev->name);
continue;
}
diff --git a/include/net/bonding.h b/include/net/bonding.h
index af927d97c1c1..65361d56109e 100644
--- a/include/net/bonding.h
+++ b/include/net/bonding.h
@@ -149,7 +149,6 @@ struct slave {
unsigned long target_last_arp_rx[BOND_MAX_ARP_TARGETS];
s8 link; /* one of BOND_LINK_XXXX */
s8 link_new_state; /* one of BOND_LINK_XXXX */
- s8 new_link;
u8 backup:1, /* indicates backup slave. Value corresponds with
BOND_STATE_ACTIVE and BOND_STATE_BACKUP */
inactive:1, /* indicates inactive slave */
@@ -519,7 +518,7 @@ static inline void bond_propose_link_state(struct slave *slave, int state)
static inline void bond_commit_link_state(struct slave *slave, bool notify)
{
- if (slave->link == slave->link_new_state)
+ if (slave->link_new_state == BOND_LINK_NOCHANGE)
return;
slave->link = slave->link_new_state;
--
2.23.0
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply related
* Re: [0/2] net: dsa: vsc73xx: Adjustments for vsc73xx_platform_probe()
From: Markus Elfring @ 2019-09-21 7:12 UTC (permalink / raw)
To: Jakub Kicinski, netdev
Cc: Florian Fainelli, Andrew Lunn, David S. Miller, Pawel Dembicki,
Vivien Didelot, Linus Walleij, kernel-janitors, LKML
In-Reply-To: <20190920151230.0d290654@cakuba.netronome.com>
> Indeed, looks like we have a mix of clean ups of varying clarity here.
> I will just drop all, including the devm_platform_ioremap_resource()
> conversion patches from patchwork for now.
I would prefer an other patch management in this case.
> Markus, please repost them all once net-next opens.
> Sorry for inconvenience.
I would find it nicer if presented change possibilities can be
automatically reconsidered on demand after each closed period.
https://patchwork.ozlabs.org/project/netdev/list/?submitter=76334&state=*
https://patchwork.ozlabs.org/project/netdev/list/?submitter=65077&state=*&archive=both
Regards,
Markus
^ permalink raw reply
* [PATCH] mt7601u: fix bbp version check in mt7601u_wait_bbp_ready
From: Lorenzo Bianconi @ 2019-09-21 8:44 UTC (permalink / raw)
To: kvalo; +Cc: lorenzo.bianconi, linux-wireless, netdev, kubakici
Fix bbp ready check in mt7601u_wait_bbp_ready. The issue is reported by
coverity with the following error:
Logical vs. bitwise operator
The expression's value does not depend on the operands; inadvertent use
of the wrong operator is a likely logic error.
Addresses-Coverity-ID: 1309441 ("Logical vs. bitwise operator")
Fixes: c869f77d6abb ("add mt7601u driver")
Acked-by: Jakub Kicinski <kubakici@wp.pl>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt7601u/phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt7601u/phy.c b/drivers/net/wireless/mediatek/mt7601u/phy.c
index 06f5702ab4bd..d863ab4a66c9 100644
--- a/drivers/net/wireless/mediatek/mt7601u/phy.c
+++ b/drivers/net/wireless/mediatek/mt7601u/phy.c
@@ -213,7 +213,7 @@ int mt7601u_wait_bbp_ready(struct mt7601u_dev *dev)
do {
val = mt7601u_bbp_rr(dev, MT_BBP_REG_VERSION);
- if (val && ~val)
+ if (val && val != 0xff)
break;
} while (--i);
--
2.21.0
^ permalink raw reply related
* Re: KASAN: use-after-free Read in rxrpc_release_call
From: syzbot @ 2019-09-21 11:08 UTC (permalink / raw)
To: davem, dhowells, linux-afs, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <000000000000727bd10590c9cf6c@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: f97c81dc Merge tag 'armsoc-late' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=110c16a1600000
kernel config: https://syzkaller.appspot.com/x/.config?x=61f948934213449f
dashboard link: https://syzkaller.appspot.com/bug?extid=eed305768ece6682bb7f
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16cf8ea1600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+eed305768ece6682bb7f@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in rxrpc_release_call+0x3f3/0x540
net/rxrpc/call_object.c:493
Read of size 8 at addr ffff88809cea9450 by task syz-executor.2/15263
CPU: 1 PID: 15263 Comm: syz-executor.2 Not tainted 5.3.0+ #0
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+0x1d8/0x2f8 lib/dump_stack.c:113
print_address_description+0x75/0x5b0 mm/kasan/report.c:351
__kasan_report+0x14b/0x1c0 mm/kasan/report.c:482
kasan_report+0x26/0x50 mm/kasan/common.c:618
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
rxrpc_release_call+0x3f3/0x540 net/rxrpc/call_object.c:493
rxrpc_release_calls_on_socket+0x6b7/0x7e0 net/rxrpc/call_object.c:523
rxrpc_release_sock net/rxrpc/af_rxrpc.c:897 [inline]
rxrpc_release+0x2dc/0x460 net/rxrpc/af_rxrpc.c:927
__sock_release net/socket.c:590 [inline]
sock_close+0xe1/0x260 net/socket.c:1268
__fput+0x2e4/0x740 fs/file_table.c:280
____fput+0x15/0x20 fs/file_table.c:313
task_work_run+0x17e/0x1b0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:188 [inline]
exit_to_usermode_loop arch/x86/entry/common.c:163 [inline]
prepare_exit_to_usermode+0x459/0x580 arch/x86/entry/common.c:194
syscall_return_slowpath+0x113/0x4a0 arch/x86/entry/common.c:274
do_syscall_64+0x11f/0x1c0 arch/x86/entry/common.c:300
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4136f1
Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 04 1b 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:00007ffe548af320 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 0000000000000004 RCX: 00000000004136f1
RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 0000000000000000 R08: ffffffffffffffff R09: ffffffffffffffff
R10: 00007ffe548af400 R11: 0000000000000293 R12: 000000000075bfc8
R13: 000000000018139a R14: 00000000007608b0 R15: 000000000075bfd4
Allocated by task 15276:
save_stack mm/kasan/common.c:69 [inline]
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc+0x11c/0x1b0 mm/kasan/common.c:493
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:507
kmem_cache_alloc_trace+0x221/0x2f0 mm/slab.c:3550
kmalloc include/linux/slab.h:552 [inline]
kzalloc include/linux/slab.h:748 [inline]
rxrpc_alloc_connection+0x79/0x490 net/rxrpc/conn_object.c:41
rxrpc_alloc_client_connection net/rxrpc/conn_client.c:176 [inline]
rxrpc_get_client_conn net/rxrpc/conn_client.c:339 [inline]
rxrpc_connect_call+0xb30/0x2c40 net/rxrpc/conn_client.c:697
rxrpc_new_client_call+0x6d5/0xb60 net/rxrpc/call_object.c:289
rxrpc_new_client_call_for_sendmsg net/rxrpc/sendmsg.c:595 [inline]
rxrpc_do_sendmsg+0xf2b/0x19b0 net/rxrpc/sendmsg.c:652
rxrpc_sendmsg+0x5eb/0x8b0 net/rxrpc/af_rxrpc.c:585
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg net/socket.c:657 [inline]
___sys_sendmsg+0x60d/0x910 net/socket.c:2311
__sys_sendmmsg+0x239/0x470 net/socket.c:2413
__do_sys_sendmmsg net/socket.c:2442 [inline]
__se_sys_sendmmsg net/socket.c:2439 [inline]
__x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2439
do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 9:
save_stack mm/kasan/common.c:69 [inline]
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x12a/0x1e0 mm/kasan/common.c:455
kasan_slab_free+0xe/0x10 mm/kasan/common.c:463
__cache_free mm/slab.c:3425 [inline]
kfree+0x115/0x200 mm/slab.c:3756
rxrpc_destroy_connection+0x1ec/0x240 net/rxrpc/conn_object.c:372
__rcu_reclaim kernel/rcu/rcu.h:222 [inline]
rcu_do_batch kernel/rcu/tree.c:2157 [inline]
rcu_core+0x843/0x1050 kernel/rcu/tree.c:2377
rcu_core_si+0x9/0x10 kernel/rcu/tree.c:2386
__do_softirq+0x333/0x7c4 arch/x86/include/asm/paravirt.h:766
The buggy address belongs to the object at ffff88809cea9200
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 592 bytes inside of
1024-byte region [ffff88809cea9200, ffff88809cea9600)
The buggy address belongs to the page:
page:ffffea000273aa00 refcount:1 mapcount:0 mapping:ffff8880aa400c40
index:0x0 compound_mapcount: 0
flags: 0x1fffc0000010200(slab|head)
raw: 01fffc0000010200 ffffea00026b4908 ffffea0002a64588 ffff8880aa400c40
raw: 0000000000000000 ffff88809cea8000 0000000100000007 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88809cea9300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88809cea9380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff88809cea9400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88809cea9480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88809cea9500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
^ permalink raw reply
* Re: Fwd: [PATCH] bonding/802.3ad: fix slave initialization states race
From: Алексей Захаров @ 2019-09-21 11:17 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev
In-Reply-To: <10497.1569049560@nyx>
сб, 21 сент. 2019 г. в 10:06, Jay Vosburgh <jay.vosburgh@canonical.com>:
>
> Алексей Захаров wrote:
>
> >>
> >> Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
> >> [...]
> >> > In any event, I think I see what the failure is, I'm working up
> >> >a patch to test and will post it when I have it ready.
> >>
> >> Aleksei,
> >>
> >> Would you be able to test the following patch and see if it
> >> resolves the issue in your testing? This is against current net-next,
> >> but applies to current net as well. Your kernel appears to be a bit
> >> older (as the message formats differ), so hopefully it will apply there
> >> as well. I've tested this a bit (but not the ARP mon portion), and it
> >> seems to do the right thing, but I can't reproduce the original issue
> >> locally.
> >We're testing on ubuntu-bionic 4.15 kernel.
>
> I believe the following will apply for the Ubuntu 4.15 kernels;
> this is against 4.15.0-60, so you may have some fuzz if your version is
> far removed. I've not tested this as I'm travelling at the moment, but
> the only real difference is the netdev_err vs. slave_err changes in
> bonding that aren't relevant to the fix itself.
Thanks! But I've already applied previous patch. Changed slave_err to
netdev_err.
As I mentioned in the previous email, we have another issue now.
With this patch one slave is in broken state right after boot.
Right after reboot one of the slaves hangs with actor port state 71
and partner port state 1.
It doesn't send lacpdu and seems to be broken.
Setting link down and up again fixes slave state.
Dmesg after boot:
[Fri Sep 20 17:56:53 2019] bond-san: Enslaving eth3 as a backup
interface with an up link
[Fri Sep 20 17:56:53 2019] bond-san: Enslaving eth2 as a backup
interface with an up link
[Fri Sep 20 17:56:54 2019] bond-san: Warning: No 802.3ad response from
the link partner for any adapters in the bond
[Fri Sep 20 17:56:54 2019] IPv6: ADDRCONF(NETDEV_UP): bond-san: link
is not ready
[Fri Sep 20 17:56:54 2019] 8021q: adding VLAN 0 to HW filter on device bond-san
[Fri Sep 20 17:56:54 2019] IPv6: ADDRCONF(NETDEV_CHANGE): bond-san:
link becomes ready
[Fri Sep 20 17:56:54 2019] bond-san: link status definitely up for
interface eth3, 10000 Mbps full duplex
[Fri Sep 20 17:56:54 2019] bond-san: first active interface up!
Broken link here is eth2. After set it down and up:
[Fri Sep 20 18:02:04 2019] mlx4_en: eth2: Link Up
[Fri Sep 20 18:02:04 2019] bond-san: link status up again after -200
ms for interface eth2
[Fri Sep 20 18:02:04 2019] bond-san: link status definitely up for
interface eth2, 10000 Mbps full duplex
If I'm trying to reproduce previous behavior, I get different messages
from time to time:
[Fri Sep 20 18:04:48 2019] mlx4_en: eth2: Link Up
[Fri Sep 20 18:04:48 2019] bond-san: link status up for interface
eth2, enabling it in 500 ms
[Fri Sep 20 18:04:48 2019] bond-san: invalid new link 3 on slave eth2
[Fri Sep 20 18:04:49 2019] bond-san: link status definitely up for
interface eth2, 10000 Mbps full duplex
or:
[Fri Sep 20 18:05:48 2019] mlx4_en: eth2: Link Up
[Fri Sep 20 18:05:49 2019] bond-san: link status up again after 0 ms
for interface eth2
[Fri Sep 20 18:05:49 2019] bond-san: link status definitely up for
interface eth2, 10000 Mbps full duplex
In both cases this slave works after up.
>
> -J
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 8cd25eb26a9a..b159a6595e11 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -2057,8 +2057,7 @@ static int bond_miimon_inspect(struct bonding *bond)
> ignore_updelay = !rcu_dereference(bond->curr_active_slave);
>
> bond_for_each_slave_rcu(bond, slave, iter) {
> - slave->new_link = BOND_LINK_NOCHANGE;
> - slave->link_new_state = slave->link;
> + bond_propose_link_state(slave, BOND_LINK_NOCHANGE);
>
> link_state = bond_check_dev_link(bond, slave->dev, 0);
>
> @@ -2094,7 +2093,7 @@ static int bond_miimon_inspect(struct bonding *bond)
> }
>
> if (slave->delay <= 0) {
> - slave->new_link = BOND_LINK_DOWN;
> + bond_propose_link_state(slave, BOND_LINK_DOWN);
> commit++;
> continue;
> }
> @@ -2133,7 +2132,7 @@ static int bond_miimon_inspect(struct bonding *bond)
> slave->delay = 0;
>
> if (slave->delay <= 0) {
> - slave->new_link = BOND_LINK_UP;
> + bond_propose_link_state(slave, BOND_LINK_UP);
> commit++;
> ignore_updelay = false;
> continue;
> @@ -2153,7 +2152,7 @@ static void bond_miimon_commit(struct bonding *bond)
> struct slave *slave, *primary;
>
> bond_for_each_slave(bond, slave, iter) {
> - switch (slave->new_link) {
> + switch (slave->link_new_state) {
> case BOND_LINK_NOCHANGE:
> continue;
>
> @@ -2237,8 +2236,8 @@ static void bond_miimon_commit(struct bonding *bond)
>
> default:
> netdev_err(bond->dev, "invalid new link %d on slave %s\n",
> - slave->new_link, slave->dev->name);
> - slave->new_link = BOND_LINK_NOCHANGE;
> + slave->link_new_state, slave->dev->name);
> + bond_propose_link_state(slave, BOND_LINK_NOCHANGE);
>
> continue;
> }
> @@ -2638,13 +2637,13 @@ static void bond_loadbalance_arp_mon(struct bonding *bond)
> bond_for_each_slave_rcu(bond, slave, iter) {
> unsigned long trans_start = dev_trans_start(slave->dev);
>
> - slave->new_link = BOND_LINK_NOCHANGE;
> + bond_propose_link_state(slave, BOND_LINK_NOCHANGE);
>
> if (slave->link != BOND_LINK_UP) {
> if (bond_time_in_interval(bond, trans_start, 1) &&
> bond_time_in_interval(bond, slave->last_rx, 1)) {
>
> - slave->new_link = BOND_LINK_UP;
> + bond_propose_link_state(slave, BOND_LINK_UP);
> slave_state_changed = 1;
>
> /* primary_slave has no meaning in round-robin
> @@ -2671,7 +2670,7 @@ static void bond_loadbalance_arp_mon(struct bonding *bond)
> if (!bond_time_in_interval(bond, trans_start, 2) ||
> !bond_time_in_interval(bond, slave->last_rx, 2)) {
>
> - slave->new_link = BOND_LINK_DOWN;
> + bond_propose_link_state(slave, BOND_LINK_DOWN);
> slave_state_changed = 1;
>
> if (slave->link_failure_count < UINT_MAX)
> @@ -2703,8 +2702,8 @@ static void bond_loadbalance_arp_mon(struct bonding *bond)
> goto re_arm;
>
> bond_for_each_slave(bond, slave, iter) {
> - if (slave->new_link != BOND_LINK_NOCHANGE)
> - slave->link = slave->new_link;
> + if (slave->link_new_state != BOND_LINK_NOCHANGE)
> + slave->link = slave->link_new_state;
> }
>
> if (slave_state_changed) {
> @@ -2727,9 +2726,9 @@ static void bond_loadbalance_arp_mon(struct bonding *bond)
> }
>
> /* Called to inspect slaves for active-backup mode ARP monitor link state
> - * changes. Sets new_link in slaves to specify what action should take
> - * place for the slave. Returns 0 if no changes are found, >0 if changes
> - * to link states must be committed.
> + * changes. Sets proposed link state in slaves to specify what action
> + * should take place for the slave. Returns 0 if no changes are found, >0
> + * if changes to link states must be committed.
> *
> * Called with rcu_read_lock held.
> */
> @@ -2741,12 +2740,12 @@ static int bond_ab_arp_inspect(struct bonding *bond)
> int commit = 0;
>
> bond_for_each_slave_rcu(bond, slave, iter) {
> - slave->new_link = BOND_LINK_NOCHANGE;
> + bond_propose_link_state(slave, BOND_LINK_NOCHANGE);
> last_rx = slave_last_rx(bond, slave);
>
> if (slave->link != BOND_LINK_UP) {
> if (bond_time_in_interval(bond, last_rx, 1)) {
> - slave->new_link = BOND_LINK_UP;
> + bond_propose_link_state(slave, BOND_LINK_UP);
> commit++;
> }
> continue;
> @@ -2774,7 +2773,7 @@ static int bond_ab_arp_inspect(struct bonding *bond)
> if (!bond_is_active_slave(slave) &&
> !rcu_access_pointer(bond->current_arp_slave) &&
> !bond_time_in_interval(bond, last_rx, 3)) {
> - slave->new_link = BOND_LINK_DOWN;
> + bond_propose_link_state(slave, BOND_LINK_DOWN);
> commit++;
> }
>
> @@ -2787,7 +2786,7 @@ static int bond_ab_arp_inspect(struct bonding *bond)
> if (bond_is_active_slave(slave) &&
> (!bond_time_in_interval(bond, trans_start, 2) ||
> !bond_time_in_interval(bond, last_rx, 2))) {
> - slave->new_link = BOND_LINK_DOWN;
> + bond_propose_link_state(slave, BOND_LINK_DOWN);
> commit++;
> }
> }
> @@ -2807,7 +2806,7 @@ static void bond_ab_arp_commit(struct bonding *bond)
> struct slave *slave;
>
> bond_for_each_slave(bond, slave, iter) {
> - switch (slave->new_link) {
> + switch (slave->link_new_state) {
> case BOND_LINK_NOCHANGE:
> continue;
>
> @@ -2859,8 +2858,8 @@ static void bond_ab_arp_commit(struct bonding *bond)
> continue;
>
> default:
> - netdev_err(bond->dev, "impossible: new_link %d on slave %s\n",
> - slave->new_link, slave->dev->name);
> + netdev_err(bond->dev, "impossible: link_new_state %d on slave %s\n",
> + slave->link_new_state, slave->dev->name);
> continue;
> }
>
> diff --git a/include/net/bonding.h b/include/net/bonding.h
> index af927d97c1c1..65361d56109e 100644
> --- a/include/net/bonding.h
> +++ b/include/net/bonding.h
> @@ -149,7 +149,6 @@ struct slave {
> unsigned long target_last_arp_rx[BOND_MAX_ARP_TARGETS];
> s8 link; /* one of BOND_LINK_XXXX */
> s8 link_new_state; /* one of BOND_LINK_XXXX */
> - s8 new_link;
> u8 backup:1, /* indicates backup slave. Value corresponds with
> BOND_STATE_ACTIVE and BOND_STATE_BACKUP */
> inactive:1, /* indicates inactive slave */
> @@ -519,7 +518,7 @@ static inline void bond_propose_link_state(struct slave *slave, int state)
>
> static inline void bond_commit_link_state(struct slave *slave, bool notify)
> {
> - if (slave->link == slave->link_new_state)
> + if (slave->link_new_state == BOND_LINK_NOCHANGE)
> return;
>
> slave->link = slave->link_new_state;
> --
> 2.23.0
>
> ---
> -Jay Vosburgh, jay.vosburgh@canonical.com
--
Best Regards,
Aleksei Zakharov
System administrator
^ permalink raw reply
* Re: [PATCH] ieee802154: mcr20a: simplify a bit 'mcr20a_handle_rx_read_buf_complete()'
From: Stefan Schmidt @ 2019-09-21 11:52 UTC (permalink / raw)
To: Christophe JAILLET, liuxuenetmail, alex.aring, davem
Cc: linux-wpan, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20190920194533.5886-1-christophe.jaillet@wanadoo.fr>
Hello Xue.
On 20.09.19 21:45, Christophe JAILLET wrote:
> Use a 'skb_put_data()' variant instead of rewritting it.
> The __skb_put_data variant is safe here. It is obvious that the skb can
> not overflow. It has just been allocated a few lines above with the same
> 'len'.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> drivers/net/ieee802154/mcr20a.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
> index 17f2300e63ee..8dc04e2590b1 100644
> --- a/drivers/net/ieee802154/mcr20a.c
> +++ b/drivers/net/ieee802154/mcr20a.c
> @@ -800,7 +800,7 @@ mcr20a_handle_rx_read_buf_complete(void *context)
> if (!skb)
> return;
>
> - memcpy(skb_put(skb, len), lp->rx_buf, len);
> + __skb_put_data(skb, lp->rx_buf, len);
> ieee802154_rx_irqsafe(lp->hw, skb, lp->rx_lqi[0]);
>
> print_hex_dump_debug("mcr20a rx: ", DUMP_PREFIX_OFFSET, 16, 1,
>
Could you please review and ACK this? If you are happy I will take it
through my tree.
regards
Stefan Schmidt
^ permalink raw reply
* Re: [PATCH 4/5] ieee802154: enforce CAP_NET_RAW for raw sockets
From: Stefan Schmidt @ 2019-09-21 11:58 UTC (permalink / raw)
To: Greg Kroah-Hartman, netdev; +Cc: isdn, jreuter, ralf, alex.aring, orinimron123
In-Reply-To: <20190920073549.517481-5-gregkh@linuxfoundation.org>
Hello.
On 20.09.19 09:35, Greg Kroah-Hartman wrote:
> From: Ori Nimron <orinimron123@gmail.com>
>
> When creating a raw AF_IEEE802154 socket, CAP_NET_RAW needs to be
> checked first.
>
> Signed-off-by: Ori Nimron <orinimron123@gmail.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> net/ieee802154/socket.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c
> index badc5cfe4dc6..d93d4531aa9b 100644
> --- a/net/ieee802154/socket.c
> +++ b/net/ieee802154/socket.c
> @@ -1008,6 +1008,9 @@ static int ieee802154_create(struct net *net, struct socket *sock,
>
> switch (sock->type) {
> case SOCK_RAW:
> + rc = -EPERM;
> + if (!capable(CAP_NET_RAW))
> + goto out;
> proto = &ieee802154_raw_prot;
> ops = &ieee802154_raw_ops;
> break;
>
I assume this will go as a whole series into net. If you want me to pick
it up into my tree directly let me know.
Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>
regards
Stefan Schmidt
^ permalink raw reply
* Re: [PATCH 4/5] ieee802154: enforce CAP_NET_RAW for raw sockets
From: Greg Kroah-Hartman @ 2019-09-21 12:30 UTC (permalink / raw)
To: Stefan Schmidt; +Cc: netdev, isdn, jreuter, ralf, alex.aring, orinimron123
In-Reply-To: <5c100446-037a-cdc2-5491-fd10385a98fd@datenfreihafen.org>
On Sat, Sep 21, 2019 at 01:58:55PM +0200, Stefan Schmidt wrote:
> Hello.
>
> On 20.09.19 09:35, Greg Kroah-Hartman wrote:
> > From: Ori Nimron <orinimron123@gmail.com>
> >
> > When creating a raw AF_IEEE802154 socket, CAP_NET_RAW needs to be
> > checked first.
> >
> > Signed-off-by: Ori Nimron <orinimron123@gmail.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> > net/ieee802154/socket.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c
> > index badc5cfe4dc6..d93d4531aa9b 100644
> > --- a/net/ieee802154/socket.c
> > +++ b/net/ieee802154/socket.c
> > @@ -1008,6 +1008,9 @@ static int ieee802154_create(struct net *net, struct socket *sock,
> >
> > switch (sock->type) {
> > case SOCK_RAW:
> > + rc = -EPERM;
> > + if (!capable(CAP_NET_RAW))
> > + goto out;
> > proto = &ieee802154_raw_prot;
> > ops = &ieee802154_raw_ops;
> > break;
> >
>
> I assume this will go as a whole series into net. If you want me to pick
> it up into my tree directly let me know.
>
> Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>
That's up to the networking maintainer, if he does not suck it in, I'll
resend and ask you to take it.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net,stable] usbnet: ignore endpoints with invalid wMaxPacketSize
From: Bjørn Mork @ 2019-09-21 12:54 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, linux-usb, Oliver Neukum
In-Reply-To: <20190920190303.149da58a@cakuba.netronome.com>
Jakub Kicinski <jakub.kicinski@netronome.com> writes:
> On Wed, 18 Sep 2019 14:17:38 +0200, Bjørn Mork wrote:
>> Endpoints with zero wMaxPacketSize are not usable for transferring
>> data. Ignore such endpoints when looking for valid in, out and
>> status pipes, to make the drivers more robust against invalid and
>> meaningless descriptors.
>>
>> The wMaxPacketSize of these endpoints are used for memory allocations
>> and as divisors in many usbnet minidrivers. Avoiding zero is therefore
>> critical.
>>
>> Signed-off-by: Bjørn Mork <bjorn@mork.no>
>
> Fixes tag would be useful. I'm not sure how far into stable we should
> backport this.
That would be commit 1da177e4c3f4 ("Linux-2.6.12-rc2"), so I don't think
a Fixes tag is very useful...
I haven't verified how deep into the code you have been able to get with
wMaxPacketSize being zero. But I don't think there ever has been much
protection since it's so obviously "insane". There was no point in
protecting against this as long as we considered the USB port a security
barrier.
I see that the v2.6.12-rc2 version of drivers/usb/net/usbnet.c (sic)
already had this in it's genelink_tx_fixup():
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1984) // add padding byte
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1985) if ((skb->len % dev->maxpacket) == 0)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1986) skb_put (skb, 1);
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1987)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1988) return skb;
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1989) }
And this in usbnet_start_xmit():
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 3564) /* don't assume the hardware handles USB_ZERO_PACKET
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 3565) * NOTE: strictly conforming cdc-ether devices should expect
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 3566) * the ZLP here, but ignore the one-byte packet.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 3567) *
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 3568) * FIXME zero that byte, if it doesn't require a new skb.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 3569) */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 3570) if ((length % dev->maxpacket) == 0)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 3571) urb->transfer_buffer_length++;
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 3572)
usbnet_probe() calculated dev->maxpacket as
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 3826) dev->maxpacket = usb_maxpacket (dev->udev, dev->out, 1);
without any sanity checking. And usb_maxpacket() hasn't changed much.
It was pretty much the same then as now:
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1123) usb_maxpacket(struct usb_device *udev, int pipe, int is_out)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1124) {
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1125) struct usb_host_endpoint *ep;
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1126) unsigned epnum = usb_pipeendpoint(pipe);
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1127)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1128) if (is_out) {
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1129) WARN_ON(usb_pipein(pipe));
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1130) ep = udev->ep_out[epnum];
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1131) } else {
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1132) WARN_ON(usb_pipeout(pipe));
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1133) ep = udev->ep_in[epnum];
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1134) }
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1135) if (!ep)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1136) return 0;
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1137)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1138) /* NOTE: only 0x07ff bits are for packet size... */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1139) return le16_to_cpu(ep->desc.wMaxPacketSize);
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1140) }
So, to summarize: I believe the fix is valid for all stable versions.
I'll leave it up to the more competent stable maintainers to decide how
many, if any, it should be backported to. I will not cry if the answer
is none.
> Is this something that occurs on real devices or protection from
> malicious ones?
Only malicious ones AFAICS.
I don't necessarily agree, but I believe the current policy makes this a
"security" issue. CVEs have previously been allocated for similar
crashes triggered by buggy USB descriptors. For some reason we are
supposed to protect the system against *some* types of malicious
hardware.
I am looking forward to the fixes coming up next to protect against
malicious CPUs and microcode ;-)
Bjørn
^ permalink raw reply
* [PATCH] net: dsa: b53: Use the correct style for SPDX License Identifier
From: Nishad Kamdar @ 2019-09-21 13:30 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn, Vivien Didelot, David S. Miller,
Greg Kroah-Hartman, Joe Perches, Uwe Kleine-König
Cc: netdev, linux-kernel
This patch corrects the SPDX License Identifier style
in header file for Broadcom BCM53xx managed switch driver.
For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used)
Changes made by using a script provided by Joe Perches here:
https://lkml.org/lkml/2019/2/7/46.
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com>
---
drivers/net/dsa/b53/b53_serdes.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_serdes.h b/drivers/net/dsa/b53/b53_serdes.h
index 3bb4f91aec9e..55d280fe38e4 100644
--- a/drivers/net/dsa/b53/b53_serdes.h
+++ b/drivers/net/dsa/b53/b53_serdes.h
@@ -1,5 +1,5 @@
-/* SPDX-License-Identifier: GPL-2.0 or BSD-3-Clause
- *
+/* SPDX-License-Identifier: GPL-2.0 or BSD-3-Clause */
+/*
* Northstar Plus switch SerDes/SGMII PHY definitions
*
* Copyright (C) 2018 Florian Fainelli <f.fainelli@gmail.com>
--
2.17.1
^ permalink raw reply related
* [PATCH] net: dsa: Use the correct style for SPDX License Identifier
From: Nishad Kamdar @ 2019-09-21 13:45 UTC (permalink / raw)
To: Hauke Mehrtens, Florian Fainelli, Andrew Lunn, Vivien Didelot,
David S. Miller, Greg Kroah-Hartman, Joe Perches,
Uwe Kleine-König
Cc: netdev, linux-kernel
This patch corrects the SPDX License Identifier style
in header file for Distributed Switch Architecture drivers.
For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used)
Changes made by using a script provided by Joe Perches here:
https://lkml.org/lkml/2019/2/7/46.
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com>
---
drivers/net/dsa/lantiq_pce.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/lantiq_pce.h b/drivers/net/dsa/lantiq_pce.h
index 180663138e75..e2be31f3672a 100644
--- a/drivers/net/dsa/lantiq_pce.h
+++ b/drivers/net/dsa/lantiq_pce.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0
+/* SPDX-License-Identifier: GPL-2.0 */
/*
* PCE microcode extracted from UGW 7.1.1 switch api
*
--
2.17.1
^ permalink raw reply related
* [PATCH net] net: openvswitch: fix possible memleak on create vport fails
From: xiangxia.m.yue @ 2019-09-17 15:40 UTC (permalink / raw)
To: gvrose8192, pshelar; +Cc: netdev, Tonghao Zhang, Taehee Yoo
From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
If we register a net device which name is not valid
(dev_get_valid_name), register_netdevice will return err
codes and will not run dev->priv_destructor. The memory
will leak. This patch adds check in ovs_vport_free and
set the vport NULL.
Fixes: 309b66970ee2 ("net: openvswitch: do not free vport if register_netdevice() is failed.")
Cc: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
---
net/openvswitch/vport-internal_dev.c | 8 ++------
net/openvswitch/vport.c | 9 +++++++++
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/net/openvswitch/vport-internal_dev.c b/net/openvswitch/vport-internal_dev.c
index d2437b5..074c43f 100644
--- a/net/openvswitch/vport-internal_dev.c
+++ b/net/openvswitch/vport-internal_dev.c
@@ -159,7 +159,6 @@ static struct vport *internal_dev_create(const struct vport_parms *parms)
struct internal_dev *internal_dev;
struct net_device *dev;
int err;
- bool free_vport = true;
vport = ovs_vport_alloc(0, &ovs_internal_vport_ops, parms);
if (IS_ERR(vport)) {
@@ -190,10 +189,8 @@ static struct vport *internal_dev_create(const struct vport_parms *parms)
rtnl_lock();
err = register_netdevice(vport->dev);
- if (err) {
- free_vport = false;
+ if (err)
goto error_unlock;
- }
dev_set_promiscuity(vport->dev, 1);
rtnl_unlock();
@@ -207,8 +204,7 @@ static struct vport *internal_dev_create(const struct vport_parms *parms)
error_free_netdev:
free_netdev(dev);
error_free_vport:
- if (free_vport)
- ovs_vport_free(vport);
+ ovs_vport_free(vport);
error:
return ERR_PTR(err);
}
diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c
index 3fc38d1..281259a 100644
--- a/net/openvswitch/vport.c
+++ b/net/openvswitch/vport.c
@@ -157,11 +157,20 @@ struct vport *ovs_vport_alloc(int priv_size, const struct vport_ops *ops,
*/
void ovs_vport_free(struct vport *vport)
{
+ /* We should check whether vport is NULL.
+ * We may free it again, for example in internal_dev_create
+ * if register_netdevice fails, vport may have been freed via
+ * internal_dev_destructor.
+ */
+ if (unlikely(!vport))
+ return;
+
/* vport is freed from RCU callback or error path, Therefore
* it is safe to use raw dereference.
*/
kfree(rcu_dereference_raw(vport->upcall_portids));
kfree(vport);
+ vport = NULL;
}
EXPORT_SYMBOL_GPL(ovs_vport_free);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] net: dsa: Use the correct style for SPDX License Identifier
From: Vivien Didelot @ 2019-09-21 16:01 UTC (permalink / raw)
To: Nishad Kamdar
Cc: Hauke Mehrtens, Florian Fainelli, Andrew Lunn, David S. Miller,
Greg Kroah-Hartman, Joe Perches, Uwe Kleine-König, netdev,
linux-kernel
In-Reply-To: <20190921134522.GA3575@nishad>
On Sat, 21 Sep 2019 19:15:25 +0530, Nishad Kamdar <nishadkamdar@gmail.com> wrote:
> This patch corrects the SPDX License Identifier style
> in header file for Distributed Switch Architecture drivers.
> For C header files Documentation/process/license-rules.rst
> mandates C-like comments (opposed to C source files where
> C++ style should be used)
>
> Changes made by using a script provided by Joe Perches here:
> https://lkml.org/lkml/2019/2/7/46.
>
> Suggested-by: Joe Perches <joe@perches.com>
> Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com>
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
^ permalink raw reply
* Re: [PATCH] net: dsa: b53: Use the correct style for SPDX License Identifier
From: Vivien Didelot @ 2019-09-21 16:01 UTC (permalink / raw)
To: Nishad Kamdar
Cc: Florian Fainelli, Andrew Lunn, David S. Miller,
Greg Kroah-Hartman, Joe Perches, Uwe Kleine-König, netdev,
linux-kernel
In-Reply-To: <20190921133011.GA2994@nishad>
On Sat, 21 Sep 2019 19:00:16 +0530, Nishad Kamdar <nishadkamdar@gmail.com> wrote:
> This patch corrects the SPDX License Identifier style
> in header file for Broadcom BCM53xx managed switch driver.
> For C header files Documentation/process/license-rules.rst
> mandates C-like comments (opposed to C source files where
> C++ style should be used)
>
> Changes made by using a script provided by Joe Perches here:
> https://lkml.org/lkml/2019/2/7/46.
>
> Suggested-by: Joe Perches <joe@perches.com>
> Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com>
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
^ permalink raw reply
* Re: INFO: task hung in p9_fd_close
From: syzbot @ 2019-09-21 16:19 UTC (permalink / raw)
To: asmadeus, davem, ericvh, linux-kernel, lucho, netdev,
syzkaller-bugs, v9fs-developer
In-Reply-To: <00000000000039af4d05915a9f56@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: f97c81dc Merge tag 'armsoc-late' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=171a1555600000
kernel config: https://syzkaller.appspot.com/x/.config?x=61f948934213449f
dashboard link: https://syzkaller.appspot.com/bug?extid=8b41a1365f1106fd0f33
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1641d429600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11eff9ad600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+8b41a1365f1106fd0f33@syzkaller.appspotmail.com
INFO: task syz-executor635:8085 blocked for more than 143 seconds.
Not tainted 5.3.0+ #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor635 D27848 8085 8070 0x00004004
Call Trace:
context_switch kernel/sched/core.c:3384 [inline]
__schedule+0x82e/0xc50 kernel/sched/core.c:4056
schedule+0x131/0x1e0 kernel/sched/core.c:4123
schedule_timeout+0x46/0x240 kernel/time/timer.c:1869
do_wait_for_common+0x2e7/0x4d0 kernel/sched/completion.c:83
__wait_for_common kernel/sched/completion.c:104 [inline]
wait_for_common kernel/sched/completion.c:115 [inline]
wait_for_completion+0x47/0x60 kernel/sched/completion.c:136
__flush_work+0xd4/0x150 kernel/workqueue.c:3040
__cancel_work_timer+0x420/0x570 kernel/workqueue.c:3127
cancel_work_sync+0x17/0x20 kernel/workqueue.c:3163
p9_conn_destroy net/9p/trans_fd.c:868 [inline]
p9_fd_close+0x297/0x3c0 net/9p/trans_fd.c:898
p9_client_create+0x974/0xee0 net/9p/client.c:1068
v9fs_session_init+0x192/0x18e0 fs/9p/v9fs.c:406
v9fs_mount+0x82/0x860 fs/9p/vfs_super.c:124
legacy_get_tree+0xf9/0x1a0 fs/fs_context.c:659
vfs_get_tree+0x8f/0x380 fs/super.c:1542
do_new_mount fs/namespace.c:2825 [inline]
do_mount+0x16c7/0x2510 fs/namespace.c:3145
ksys_mount+0xcc/0x100 fs/namespace.c:3354
__do_sys_mount fs/namespace.c:3368 [inline]
__se_sys_mount fs/namespace.c:3365 [inline]
__x64_sys_mount+0xbf/0xd0 fs/namespace.c:3365
do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x447909
Code: e8 5c 14 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 9b 0c fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007eff1aea0db8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00000000006ddc78 RCX: 0000000000447909
RDX: 00000000200005c0 RSI: 0000000020000540 RDI: 0000000000000000
RBP: 00000000006ddc70 R08: 0000000020000680 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006ddc7c
R13: 00007ffc4e6377ef R14: 00007eff1aea19c0 R15: 000000000000002d
Showing all locks held in the system:
2 locks held by kworker/1:1/22:
#0: ffff8880aa4278e8 ((wq_completion)events){+.+.}, at: spin_unlock_irq
include/linux/spinlock.h:388 [inline]
#0: ffff8880aa4278e8 ((wq_completion)events){+.+.}, at:
process_one_work+0x75d/0x10e0 kernel/workqueue.c:2242
#1: ffff8880a9a3fd78 ((work_completion)(&m->wq)){+.+.}, at:
process_one_work+0x79f/0x10e0 kernel/workqueue.c:2244
1 lock held by khungtaskd/1053:
#0: ffffffff888d3900 (rcu_read_lock){....}, at: rcu_lock_acquire+0x4/0x30
include/linux/rcupdate.h:207
1 lock held by rsyslogd/7959:
#0: ffff8880a99f1e20 (&f->f_pos_lock){+.+.}, at: __fdget_pos+0x243/0x2e0
fs/file.c:801
2 locks held by getty/8049:
#0: ffff8880a602d450 (&tty->ldisc_sem){++++}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: ffffc90005f212e0 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x221/0x1b00 drivers/tty/n_tty.c:2156
2 locks held by getty/8050:
#0: ffff8880a902ac50 (&tty->ldisc_sem){++++}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: ffffc90005f092e0 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x221/0x1b00 drivers/tty/n_tty.c:2156
2 locks held by getty/8051:
#0: ffff88809c0f1750 (&tty->ldisc_sem){++++}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: ffffc90005f312e0 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x221/0x1b00 drivers/tty/n_tty.c:2156
2 locks held by getty/8052:
#0: ffff88809e344b90 (&tty->ldisc_sem){++++}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: ffffc90005f152e0 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x221/0x1b00 drivers/tty/n_tty.c:2156
2 locks held by getty/8053:
#0: ffff88809e344310 (&tty->ldisc_sem){++++}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: ffffc90005f1d2e0 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x221/0x1b00 drivers/tty/n_tty.c:2156
2 locks held by getty/8054:
#0: ffff88809c8aa410 (&tty->ldisc_sem){++++}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: ffffc90005f2d2e0 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x221/0x1b00 drivers/tty/n_tty.c:2156
2 locks held by getty/8055:
#0: ffff8880a0267310 (&tty->ldisc_sem){++++}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: ffffc90005f012e0 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x221/0x1b00 drivers/tty/n_tty.c:2156
=============================================
NMI backtrace for cpu 0
CPU: 0 PID: 1053 Comm: khungtaskd Not tainted 5.3.0+ #0
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+0x1d8/0x2f8 lib/dump_stack.c:113
nmi_cpu_backtrace+0xaf/0x1a0 lib/nmi_backtrace.c:101
nmi_trigger_cpumask_backtrace+0x174/0x290 lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x10/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_all_cpu_backtrace+0x17/0x20 include/linux/nmi.h:146
check_hung_uninterruptible_tasks kernel/hung_task.c:205 [inline]
watchdog+0xbb9/0xbd0 kernel/hung_task.c:289
kthread+0x332/0x350 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.3.0+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:check_preemption_disabled+0x6/0x2a0 lib/smp_processor_id.c:13
Code: 90 90 90 90 55 48 89 e5 e8 a7 b2 2e fe 48 c7 c7 79 91 38 88 48 c7 c6
10 72 4e 88 e8 04 00 00 00 5d c3 66 90 55 48 89 e5 41 57 <41> 56 41 55 41
54 53 48 83 ec 10 49 89 f6 49 89 ff e8 74 b2 2e fe
RSP: 0018:ffff8880aeb09ee0 EFLAGS: 00000093
RAX: ffffffff83448fc9 RBX: 0000000000000004 RCX: ffff8880a98c2340
RDX: 0000000000000000 RSI: ffffffff884e7210 RDI: ffffffff88389179
RBP: ffff8880aeb09ee8 R08: ffffffff816701e0 R09: fffffbfff117c3cd
R10: fffffbfff117c3cd R11: 0000000000000000 R12: 1ffff11015d64eaf
R13: ffff8880aeb00000 R14: dffffc0000000000 R15: ffff8880aeb2757c
FS: 0000000000000000(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffff600400 CR3: 00000000a3d38000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
debug_smp_processor_id+0x1c/0x20 lib/smp_processor_id.c:57
tick_nohz_stop_idle kernel/time/tick-sched.c:535 [inline]
tick_nohz_irq_enter kernel/time/tick-sched.c:1255 [inline]
tick_irq_enter+0xbd/0x3e0 kernel/time/tick-sched.c:1274
irq_enter+0x52/0xc0 kernel/softirq.c:354
scheduler_ipi+0xb3/0x4a0 kernel/sched/core.c:2337
smp_reschedule_interrupt+0x7a/0xa0 arch/x86/kernel/smp.c:244
reschedule_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:854
</IRQ>
RIP: 0010:native_safe_halt+0xe/0x10 arch/x86/include/asm/irqflags.h:61
Code: 3c fa eb ae 89 d9 80 e1 07 80 c1 03 38 c1 7c ba 48 89 df e8 94 ab 3c
fa eb b0 90 90 e9 07 00 00 00 0f 00 2d b6 99 52 00 fb f4 <c3> 90 e9 07 00
00 00 0f 00 2d a6 99 52 00 f4 c3 90 90 55 48 89 e5
RSP: 0018:ffff8880a98cfe10 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff02
RAX: 1ffffffff1115179 RBX: ffff8880a98c2340 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: ffffffff812ba81a RDI: ffff8880a98c2b80
RBP: ffff8880a98cfe18 R08: ffff8880a98c2b98 R09: ffffed1015318469
R10: ffffed1015318469 R11: 0000000000000000 R12: dffffc0000000000
R13: 1ffff11015318468 R14: dffffc0000000000 R15: 1ffffffff1115177
arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:571
default_idle_call+0x59/0xa0 kernel/sched/idle.c:94
cpuidle_idle_call kernel/sched/idle.c:154 [inline]
do_idle+0x140/0x670 kernel/sched/idle.c:264
cpu_startup_entry+0x25/0x30 kernel/sched/idle.c:356
start_secondary+0x384/0x410 arch/x86/kernel/smpboot.c:264
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
^ permalink raw reply
* [next] regression: WiFi doesn't work after "nl80211: Add support for EDMG channels"
From: Dmitry Osipenko @ 2019-09-21 17:12 UTC (permalink / raw)
To: Johannes Berg, Alexei Avshalom Lazar, Kalle Valo; +Cc: linux-wireless, netdev
Hello,
Patch "nl80211: Add support for EDMG channels" broke brcmfmac driver on one of my devices, the newly
introduced cfg80211_chandef_is_edmg() erroneously returns "true" because chandef->edmg.bw_config !=
NULL. Apparently this happens because "chandef" is allocated on stack in nl80211.c (and other places),
the "edmg" field isn't zeroed while it should be. Please fix, thanks in advance.
WARNING: CPU: 0 PID: 409 at net/wireless/nl80211.c:3118 nl80211_send_chandef+0xd3/0xd8
Modules linked in:
CPU: 0 PID: 409 Comm: NetworkManager Tainted: G W
5.3.0-next-20190920-00177-g89b36954c24f #2381
Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
(show_stack+0x11/0x14)
(dump_stack+0x7f/0x8c)
(__warn+0xc1/0xc4)
(warn_slowpath_fmt+0x45/0x78)
(nl80211_send_chandef+0xd3/0xd8)
(nl80211_send_iface+0x4db/0x6a0)
(nl80211_get_interface+0x39/0x68)
(genl_rcv_msg+0x14d/0x33c)
(netlink_rcv_skb+0x85/0xb8)
(genl_rcv+0x21/0x30)
(netlink_unicast+0xf3/0x144)
(netlink_sendmsg+0x12b/0x27c)
(sock_sendmsg+0x11/0x1c)
(___sys_sendmsg+0x1bb/0x1d0)
(__sys_sendmsg+0x39/0x58)
(ret_fast_syscall+0x1/0x28)
Exception stack(0xe1621fa8 to 0xe1621ff0)
1fa0: 00000000 bea1b830 00000009 bea1b830 00000000 00000000
1fc0: 00000000 bea1b830 00000009 00000128 00644084 b6fd6930 00683d30 00645330
1fe0: 00000128 bea1b808 b6a1b3a5 b6a1c6b6
^ permalink raw reply
* Re: KASAN: use-after-free Read in rxrpc_release_call
From: syzbot @ 2019-09-21 17:41 UTC (permalink / raw)
To: MAILER_DAEMON, davem, dhowells, hdanton, linux-afs, linux-kernel,
netdev, syzkaller-bugs
In-Reply-To: <000000000000727bd10590c9cf6c@google.com>
syzbot has bisected this bug to:
commit 2baec2c3f854d1f79c7bb28386484e144e864a14
Author: David Howells <dhowells@redhat.com>
Date: Wed May 24 16:02:32 2017 +0000
rxrpc: Support network namespacing
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16240b09600000
start commit: f97c81dc Merge tag 'armsoc-late' of git://git.kernel.org/p..
git tree: upstream
final crash: https://syzkaller.appspot.com/x/report.txt?x=15240b09600000
console output: https://syzkaller.appspot.com/x/log.txt?x=11240b09600000
kernel config: https://syzkaller.appspot.com/x/.config?x=61f948934213449f
dashboard link: https://syzkaller.appspot.com/bug?extid=eed305768ece6682bb7f
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16cf8ea1600000
Reported-by: syzbot+eed305768ece6682bb7f@syzkaller.appspotmail.com
Fixes: 2baec2c3f854 ("rxrpc: Support network namespacing")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply
* [PATCH] net: dsa: microchip: Always set regmap stride to 1
From: Marek Vasut @ 2019-09-21 17:53 UTC (permalink / raw)
To: netdev
Cc: Marek Vasut, Andrew Lunn, David S . Miller, Florian Fainelli,
George McCollister, Tristram Ha, Vivien Didelot, Woojung Huh
The regmap stride is set to 1 for regmap describing 8bit registers already.
However, for 16/32/64bit registers, the stride is 2/4/8 respectively. This
is not correct, as the switch protocol supports unaligned register reads
and writes and the KSZ87xx even uses such unaligned register accesses to
read e.g. MIB counter.
This patch fixes MIB counter access on KSZ87xx.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: David S. Miller <davem@davemloft.net>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: George McCollister <george.mccollister@gmail.com>
Cc: Tristram Ha <Tristram.Ha@microchip.com>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: Woojung Huh <woojung.huh@microchip.com>
---
drivers/net/dsa/microchip/ksz_common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/microchip/ksz_common.h b/drivers/net/dsa/microchip/ksz_common.h
index a24d8e61fbe7..dd60d0837fc6 100644
--- a/drivers/net/dsa/microchip/ksz_common.h
+++ b/drivers/net/dsa/microchip/ksz_common.h
@@ -303,7 +303,7 @@ static inline void ksz_pwrite32(struct ksz_device *dev, int port, int offset,
{ \
.name = #width, \
.val_bits = (width), \
- .reg_stride = (width) / 8, \
+ .reg_stride = 1, \
.reg_bits = (regbits) + (regalign), \
.pad_bits = (regpad), \
.max_register = BIT(regbits) - 1, \
--
2.23.0.rc1
^ permalink raw reply related
* Re: [PATCH] dt-bindings: net: dwmac: fix 'mac-mode' type
From: Jakub Kicinski @ 2019-09-21 18:46 UTC (permalink / raw)
To: Florian Fainelli
Cc: Alexandru Ardelean, netdev, devicetree, linux-kernel, davem,
robh+dt, peppe.cavallaro, alexandre.torgue, andrew
In-Reply-To: <f189cdbc-b399-7700-a39a-ba185df4af49@gmail.com>
On Fri, 20 Sep 2019 20:02:58 -0700, Florian Fainelli wrote:
> On 9/20/2019 6:11 PM, Jakub Kicinski wrote:
> > On Tue, 17 Sep 2019 13:30:52 +0300, Alexandru Ardelean wrote:
> >> The 'mac-mode' property is similar to 'phy-mode' and 'phy-connection-type',
> >> which are enums of mode strings.
> >>
> >> The 'dwmac' driver supports almost all modes declared in the 'phy-mode'
> >> enum (except for 1 or 2). But in general, there may be a case where
> >> 'mac-mode' becomes more generic and is moved as part of phylib or netdev.
> >>
> >> In any case, the 'mac-mode' field should be made an enum, and it also makes
> >> sense to just reference the 'phy-connection-type' from
> >> 'ethernet-controller.yaml'. That will also make it more future-proof for new
> >> modes.
> >>
> >> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> >
> > Applied, thank you!
> >
> > FWIW I had to add the Fixes tag by hand, either ozlabs patchwork or my
> > git-pw doesn't have the automagic handling there, yet.
>
> AFAICT the ozlabs patchwork instance does not do it, but if you have
> patchwork administrative rights (the jango administration panel I mean)
> then it is simple to add the regular expression to the list of tags that
> patchwork already recognized. Had tried getting that included by
> default, but it also counted all of those tags and therefore was not
> particularly fine grained:
>
> https://lists.ozlabs.org/pipermail/patchwork/2017-January/003910.html
Curious, it did seem to have counted the Fixes in the 'F' field on the
web UI but git-pw didn't pull it down 🤔
linux$ git checkout 92974a1d006ad8b30d53047c70974c9e065eb7df
Note: checking out '92974a1d006ad8b30d53047c70974c9e065eb7df'.
[...]
linux$ git pw patch apply 1163199 --signoff
11:41 linux$ git show
commit ac964661384b93ff3c9839c6d56f293195d54b4e (HEAD)
Author: Alexandru Ardelean <alexandru.ardelean@analog.com>
Date: Tue Sep 17 13:30:52 2019 +0300
dt-bindings: net: dwmac: fix 'mac-mode' type
The 'mac-mode' property is similar to 'phy-mode' and 'phy-connection-type',
which are enums of mode strings.
The 'dwmac' driver supports almost all modes declared in the 'phy-mode'
enum (except for 1 or 2). But in general, there may be a case where
'mac-mode' becomes more generic and is moved as part of phylib or netdev.
In any case, the 'mac-mode' field should be made an enum, and it also makes
sense to just reference the 'phy-connection-type' from
'ethernet-controller.yaml'. That will also make it more future-proof for new
modes.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
11:41 linux$
^ 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