* Re: [for-next V2 10/10] RDMA/core: Provide RDMA DIM support for ULPs
From: Yamin Friedman @ 2019-06-27 5:28 UTC (permalink / raw)
To: Sagi Grimberg, Saeed Mahameed, David S. Miller, Doug Ledford,
Jason Gunthorpe
Cc: Leon Romanovsky, Or Gerlitz, Tal Gilboa, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Max Gurtovoy
In-Reply-To: <adb3687a-6db3-b1a4-cd32-8b4889550c81@grimberg.me>
On 6/26/2019 12:14 AM, Sagi Grimberg wrote:
>
>
>> +static int ib_poll_dim_handler(struct irq_poll *iop, int budget)
>> +{
>> + struct ib_cq *cq = container_of(iop, struct ib_cq, iop);
>> + struct dim *dim = cq->dim;
>> + int completed;
>> +
>> + completed = __ib_process_cq(cq, budget, cq->wc, IB_POLL_BATCH);
>> + if (completed < budget) {
>> + irq_poll_complete(&cq->iop);
>> + if (ib_req_notify_cq(cq, IB_POLL_FLAGS) > 0)
>> + irq_poll_sched(&cq->iop);
>> + }
>> +
>> + rdma_dim(dim, completed);
>
> Why duplicate the entire thing for a one-liner?
You are right, this was leftover from a previous version where there
were more significant changes. I will remove the extra function.
>
>> +
>> + return completed;
>> +}
>> +
>> static void ib_cq_completion_softirq(struct ib_cq *cq, void *private)
>> {
>> irq_poll_sched(&cq->iop);
>> @@ -105,14 +157,18 @@ static void ib_cq_completion_softirq(struct
>> ib_cq *cq, void *private)
>> static void ib_cq_poll_work(struct work_struct *work)
>> {
>> - struct ib_cq *cq = container_of(work, struct ib_cq, work);
>> + struct ib_cq *cq = container_of(work, struct ib_cq,
>> + work);
>
> Why was that changed?
I will fix this.
>
>> int completed;
>> completed = __ib_process_cq(cq, IB_POLL_BUDGET_WORKQUEUE,
>> cq->wc,
>> IB_POLL_BATCH);
>> +
>
> newline?
Same as above.
>
>> if (completed >= IB_POLL_BUDGET_WORKQUEUE ||
>> ib_req_notify_cq(cq, IB_POLL_FLAGS) > 0)
>> queue_work(cq->comp_wq, &cq->work);
>> + else if (cq->dim)
>> + rdma_dim(cq->dim, completed);
>> }
>> static void ib_cq_completion_workqueue(struct ib_cq *cq, void
>> *private)
>> @@ -166,6 +222,8 @@ struct ib_cq *__ib_alloc_cq_user(struct ib_device
>> *dev, void *private,
>> rdma_restrack_set_task(&cq->res, caller);
>> rdma_restrack_kadd(&cq->res);
>> + rdma_dim_init(cq);
>> +
>> switch (cq->poll_ctx) {
>> case IB_POLL_DIRECT:
>> cq->comp_handler = ib_cq_completion_direct;
>> @@ -173,7 +231,13 @@ struct ib_cq *__ib_alloc_cq_user(struct
>> ib_device *dev, void *private,
>> case IB_POLL_SOFTIRQ:
>> cq->comp_handler = ib_cq_completion_softirq;
>> - irq_poll_init(&cq->iop, IB_POLL_BUDGET_IRQ, ib_poll_handler);
>> + if (cq->dim) {
>> + irq_poll_init(&cq->iop, IB_POLL_BUDGET_IRQ,
>> + ib_poll_dim_handler);
>> + } else
>> + irq_poll_init(&cq->iop, IB_POLL_BUDGET_IRQ,
>> + ib_poll_handler);
>> +
>> ib_req_notify_cq(cq, IB_CQ_NEXT_COMP);
>> break;
>> case IB_POLL_WORKQUEUE:
>> @@ -226,6 +290,9 @@ void ib_free_cq_user(struct ib_cq *cq, struct
>> ib_udata *udata)
>> WARN_ON_ONCE(1);
>> }
>> + if (cq->dim)
>> + cancel_work_sync(&cq->dim->work);
>> + kfree(cq->dim);
>> kfree(cq->wc);
>> rdma_restrack_del(&cq->res);
>> ret = cq->device->ops.destroy_cq(cq, udata);
>> diff --git a/drivers/infiniband/hw/mlx5/main.c
>> b/drivers/infiniband/hw/mlx5/main.c
>> index abac70ad5c7c..b1b45dbe24a5 100644
>> --- a/drivers/infiniband/hw/mlx5/main.c
>> +++ b/drivers/infiniband/hw/mlx5/main.c
>> @@ -6305,6 +6305,8 @@ static int mlx5_ib_stage_caps_init(struct
>> mlx5_ib_dev *dev)
>> MLX5_CAP_GEN(dev->mdev, disable_local_lb_mc)))
>> mutex_init(&dev->lb.mutex);
>> + dev->ib_dev.use_cq_dim = true;
>> +
>
> Please don't. This is a bad choice to opt it in by default.
^ permalink raw reply
* Re: [for-next V2 08/10] linux/dim: Implement rdma_dim
From: Yamin Friedman @ 2019-06-27 5:25 UTC (permalink / raw)
To: Sagi Grimberg, Saeed Mahameed, David S. Miller, Doug Ledford,
Jason Gunthorpe
Cc: Leon Romanovsky, Or Gerlitz, Tal Gilboa, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Max Gurtovoy
In-Reply-To: <bfa2159e-1576-6b3c-c85b-ee98bd4f9a47@grimberg.me>
On 6/26/2019 1:02 AM, Sagi Grimberg wrote:
>
>> +void rdma_dim(struct dim *dim, u64 completions)
>> +{
>> + struct dim_sample *curr_sample = &dim->measuring_sample;
>> + struct dim_stats curr_stats;
>> + u32 nevents;
>> +
>> + dim_update_sample_with_comps(curr_sample->event_ctr + 1,
>> + curr_sample->pkt_ctr,
>> + curr_sample->byte_ctr,
>> + curr_sample->comp_ctr + completions,
>> + &dim->measuring_sample);
>
> If this is the only caller, why add pkt_ctr and byte_ctr at all?
We wanted to keep the API general enough that if someone wants to
implement a different algorithm using the dim library they will be able
to use all the possible statistics. I agree though that in the rdma_dim
function there is no point in making it seem like they are relevant
parameters.
^ permalink raw reply
* Re: BUG: unable to handle kernel paging request in tls_prots
From: syzbot @ 2019-06-27 5:24 UTC (permalink / raw)
To: ast, bpf, daniel, davem, edumazet, john.fastabend, kafai, kuznet,
linux-kernel, netdev, songliubraving, syzkaller-bugs, yhs,
yoshfuji
In-Reply-To: <000000000000d7bcbb058c3758a1@google.com>
syzbot has bisected this bug to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=148e8665a00000
start commit: 904d88d7 qmi_wwan: Fix out-of-bounds read
git tree: net
final crash: https://syzkaller.appspot.com/x/report.txt?x=168e8665a00000
console output: https://syzkaller.appspot.com/x/log.txt?x=128e8665a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=137ec2016ea3870d
dashboard link: https://syzkaller.appspot.com/bug?extid=4207c7f3a443366d8aa2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15576c71a00000
Reported-by: syzbot+4207c7f3a443366d8aa2@syzkaller.appspotmail.com
Fixes: e9db4ef6bf4c ("bpf: sockhash fix omitted bucket lock in sock_close")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply
* [Linux-kernel-mentees][PATCH v3] packet: Fix undefined behavior in bit shift
From: Jiunn Chang @ 2019-06-27 5:04 UTC (permalink / raw)
To: skhan; +Cc: linux-kernel-mentees, netdev, linux-kernel, davem
In-Reply-To: <20190627032532.18374-2-c0d1n61at3@gmail.com>
Shifting signed 32-bit value by 31 bits is undefined. Changing most
significant bit to unsigned.
Signed-off-by: Jiunn Chang <c0d1n61at3@gmail.com>
---
Changes included in v3:
- remove change log from patch description
Changes included in v2:
- use subsystem specific subject lines
- CC required mailing lists
include/uapi/linux/if_packet.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/if_packet.h b/include/uapi/linux/if_packet.h
index 467b654bd4c7..3d884d68eb30 100644
--- a/include/uapi/linux/if_packet.h
+++ b/include/uapi/linux/if_packet.h
@@ -123,7 +123,7 @@ struct tpacket_auxdata {
/* Rx and Tx ring - header status */
#define TP_STATUS_TS_SOFTWARE (1 << 29)
#define TP_STATUS_TS_SYS_HARDWARE (1 << 30) /* deprecated, never set */
-#define TP_STATUS_TS_RAW_HARDWARE (1 << 31)
+#define TP_STATUS_TS_RAW_HARDWARE (1U << 31)
/* Rx ring - feature request bits */
#define TP_FT_REQ_FILL_RXHASH 0x1
--
2.22.0
^ permalink raw reply related
* Re: dm9601: incorrect datasheet URL
From: Corentin Labbe @ 2019-06-27 4:55 UTC (permalink / raw)
To: Arkadiusz Drabczyk; +Cc: netdev, jacmet
In-Reply-To: <20190626141248.GA14356@comp.lan>
On Wed, Jun 26, 2019 at 04:12:48PM +0200, Arkadiusz Drabczyk wrote:
> http://ptm2.cc.utu.fi/ftp/network/cards/DM9601/From_NET/DM9601-DS-P01-930914.pdf
> is gone. In fact, document titled `DM9601-DS-P01-930914.pdf' is
> nowhere to be found online these days but there is
> http://pdf.datasheet.live/74029349/davicom.com.tw/DM9601E.pdf. I'm
> just not sure if this is the same document that the current link was
> pointing to and what does E suffix mean. There is also
> https://www.alldatasheet.com/datasheet-pdf/pdf/119750/ETC1/DM9601.html
> but notice that it says `Version: DM9601-DS-F01' on the bottom of some
> pages and `Version: DM9601-DS-P01' on others - I don't know what that
> means.
>
> Should http://pdf.datasheet.live/74029349/davicom.com.tw/DM9601E.pdf
> be used as a datasheet URL?
>
Hello
I have noticed the same problem some days ago.
The original datasheet could be found using archive.org.
I have downloaded all datasheets and none has the same md5, so it need a more detailled inspection.
Regards
^ permalink raw reply
* [PATCH] net: dsa: mv88e6xxx: wait after reset deactivation
From: Baruch Siach @ 2019-06-27 4:29 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot; +Cc: netdev, Baruch Siach
Add a 1ms delay after reset deactivation. Otherwise the chip returns
bogus ID value. This is observed with 88E6390 (Peridot) chip.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
drivers/net/dsa/mv88e6xxx/chip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index f4e2db44ad91..549f528f216c 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4910,6 +4910,7 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
err = PTR_ERR(chip->reset);
goto out;
}
+ mdelay(1);
err = mv88e6xxx_detect(chip);
if (err)
--
2.20.1
^ permalink raw reply related
* linux-next: manual merge of the mlx5-next tree with the net-next tree
From: Stephen Rothwell @ 2019-06-27 4:09 UTC (permalink / raw)
To: Leon Romanovsky, David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Yevgeny Kliteynik, Saeed Mahameed, Eli Britstein, Jianbo Liu
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]
Hi all,
Today's linux-next merge of the mlx5-next tree got a conflict in:
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
between commits:
955858009708 ("net/mlx5e: Fix number of vports for ingress ACL configuration")
d4a18e16c570 ("net/mlx5e: Enable setting multiple match criteria for flow group")
from the net-next tree and commits:
7445cfb1169c ("net/mlx5: E-Switch, Tag packet with vport number in VF vports and uplink ingress ACLs")
c01cfd0f1115 ("net/mlx5: E-Switch, Add match on vport metadata for rule in fast path")
from the mlx5-next tree.
I fixed it up (I basically used the latter versions) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: KASAN: use-after-free Write in xfrm_hash_rebuild
From: syzbot @ 2019-06-27 3:59 UTC (permalink / raw)
To: davem, herbert, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs
In-Reply-To: <000000000000d028b30588fed102@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 249155c2 Merge branch 'parisc-5.2-4' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10f017c3a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=9a31528e58cc12e2
dashboard link: https://syzkaller.appspot.com/bug?extid=0165480d4ef07360eeda
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16cf37c3a00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0165480d4ef07360eeda@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in __write_once_size
include/linux/compiler.h:221 [inline]
BUG: KASAN: use-after-free in __hlist_del include/linux/list.h:748 [inline]
BUG: KASAN: use-after-free in hlist_del_rcu include/linux/rculist.h:455
[inline]
BUG: KASAN: use-after-free in xfrm_hash_rebuild+0xa0d/0x1000
net/xfrm/xfrm_policy.c:1318
Write of size 8 at addr ffff888095e79c00 by task kworker/1:3/8066
CPU: 1 PID: 8066 Comm: kworker/1:3 Not tainted 5.2.0-rc6+ #7
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events xfrm_hash_rebuild
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113
print_address_description+0x6d/0x310 mm/kasan/report.c:188
__kasan_report+0x14b/0x1c0 mm/kasan/report.c:317
kasan_report+0x26/0x50 mm/kasan/common.c:614
__asan_report_store8_noabort+0x17/0x20 mm/kasan/generic_report.c:137
__write_once_size include/linux/compiler.h:221 [inline]
__hlist_del include/linux/list.h:748 [inline]
hlist_del_rcu include/linux/rculist.h:455 [inline]
xfrm_hash_rebuild+0xa0d/0x1000 net/xfrm/xfrm_policy.c:1318
process_one_work+0x814/0x1130 kernel/workqueue.c:2269
worker_thread+0xc01/0x1640 kernel/workqueue.c:2415
kthread+0x325/0x350 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Allocated by task 8064:
save_stack mm/kasan/common.c:71 [inline]
set_track mm/kasan/common.c:79 [inline]
__kasan_kmalloc+0x11c/0x1b0 mm/kasan/common.c:489
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:503
__do_kmalloc mm/slab.c:3660 [inline]
__kmalloc+0x23c/0x310 mm/slab.c:3669
kmalloc include/linux/slab.h:552 [inline]
kzalloc include/linux/slab.h:742 [inline]
xfrm_hash_alloc+0x38/0xe0 net/xfrm/xfrm_hash.c:21
xfrm_policy_init net/xfrm/xfrm_policy.c:4036 [inline]
xfrm_net_init+0x269/0xd60 net/xfrm/xfrm_policy.c:4120
ops_init+0x336/0x420 net/core/net_namespace.c:130
setup_net+0x212/0x690 net/core/net_namespace.c:316
copy_net_ns+0x224/0x380 net/core/net_namespace.c:439
create_new_namespaces+0x4ec/0x700 kernel/nsproxy.c:103
unshare_nsproxy_namespaces+0x12a/0x190 kernel/nsproxy.c:202
ksys_unshare+0x540/0xac0 kernel/fork.c:2692
__do_sys_unshare kernel/fork.c:2760 [inline]
__se_sys_unshare kernel/fork.c:2758 [inline]
__x64_sys_unshare+0x38/0x40 kernel/fork.c:2758
do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 17:
save_stack mm/kasan/common.c:71 [inline]
set_track mm/kasan/common.c:79 [inline]
__kasan_slab_free+0x12a/0x1e0 mm/kasan/common.c:451
kasan_slab_free+0xe/0x10 mm/kasan/common.c:459
__cache_free mm/slab.c:3432 [inline]
kfree+0xae/0x120 mm/slab.c:3755
xfrm_hash_free+0x38/0xd0 net/xfrm/xfrm_hash.c:35
xfrm_bydst_resize net/xfrm/xfrm_policy.c:602 [inline]
xfrm_hash_resize+0x13f1/0x1840 net/xfrm/xfrm_policy.c:680
process_one_work+0x814/0x1130 kernel/workqueue.c:2269
worker_thread+0xc01/0x1640 kernel/workqueue.c:2415
kthread+0x325/0x350 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
The buggy address belongs to the object at ffff888095e79c00
which belongs to the cache kmalloc-64 of size 64
The buggy address is located 0 bytes inside of
64-byte region [ffff888095e79c00, ffff888095e79c40)
The buggy address belongs to the page:
page:ffffea0002579e40 refcount:1 mapcount:0 mapping:ffff8880aa400340
index:0x0
flags: 0x1fffc0000000200(slab)
raw: 01fffc0000000200 ffffea0002540888 ffffea0002907548 ffff8880aa400340
raw: 0000000000000000 ffff888095e79000 0000000100000020 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888095e79b00: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
ffff888095e79b80: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
> ffff888095e79c00: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
^
ffff888095e79c80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffff888095e79d00: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
==================================================================
^ permalink raw reply
* Reminder: 7 open syzbot bugs in "net/netrom" subsystem
From: Eric Biggers @ 2019-06-27 3:50 UTC (permalink / raw)
To: linux-hams, netdev, Ralf Baechle, David S. Miller
Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 7 of them as possibly being bugs in the "net/netrom" subsystem. I've
listed these reports below, sorted by an algorithm that tries to list first the
reports most likely to be still valid, important, and actionable.
Of these 7 bugs, 1 was seen in mainline in the last week.
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the "net/netrom" subsystem, please let
me know, and if possible forward the report to the correct people or mailing
list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: general protection fault in prepare_to_wait
Last occurred: 1 day ago
Reported: 174 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=c670fb9da2ce08f7b5101baa9426083b39ee9f90
Original thread: https://lkml.kernel.org/lkml/000000000000fa6a2c057e8b7064@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+55f9d3e51d49e20b2ce5@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000fa6a2c057e8b7064@google.com
--------------------------------------------------------------------------------
Title: memory leak in nr_create
Last occurred: 7 days ago
Reported: 30 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=24be997a573ef9d497d6d7302518779b75d8119a
Original thread: https://lkml.kernel.org/lkml/0000000000009412c60589e804d8@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+10f1194569953b72f1ae@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000009412c60589e804d8@google.com
--------------------------------------------------------------------------------
Title: memory leak in nr_rx_frame
Last occurred: 30 days ago
Reported: 30 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=0c00cc3e04fe00ad69ac62fbe8464b2f0fae932a
Original thread: https://lkml.kernel.org/lkml/000000000000da88840589e8fe2c@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+d6636a36d3c34bd88938@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000da88840589e8fe2c@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in lock_sock_nested
Last occurred: 24 days ago
Reported: 175 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=6c137905024f86513297b035845acecb55fa9dab
Original thread: https://lkml.kernel.org/lkml/0000000000007a5aad057e7748c9@google.com/T/#u
This bug has a syzkaller reproducer only.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+500c69d1e21d970e461b@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000007a5aad057e7748c9@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in nr_release
Last occurred: 0 days ago
Reported: 18 days ago
Branches: net
Dashboard link: https://syzkaller.appspot.com/bug?id=5332f4a9ce674d6378f0bd91af752d2be80f3aba
Original thread: https://lkml.kernel.org/lkml/0000000000007e8b70058acbd60f@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+6eaef7158b19e3fec3a0@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000007e8b70058acbd60f@google.com
--------------------------------------------------------------------------------
Title: memory leak in nr_loopback_queue
Last occurred: 28 days ago
Reported: 28 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=20e5b6ff68ec36b9ba8ac5225e560a3a563f343a
Original thread: https://lkml.kernel.org/lkml/000000000000a7f012058a0c7a65@google.com/T/#u
This bug has a syzkaller reproducer only.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+470d1a4a7b7a7c225881@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000a7f012058a0c7a65@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in refcount_inc_not_zero_checked (2)
Last occurred: 70 days ago
Reported: 102 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=b0192a79bb2d222d3e723d7db60dfb5e0ec0e570
Original thread: https://lkml.kernel.org/lkml/000000000000eea12405843bc43c@google.com/T/#u
This bug has a syzkaller reproducer only.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+eff6b596cc8194e2f029@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000eea12405843bc43c@google.com
^ permalink raw reply
* Reminder: 3 open syzbot bugs in "net/rose" subsystem
From: Eric Biggers @ 2019-06-27 3:47 UTC (permalink / raw)
To: linux-hams, netdev, Ralf Baechle, David S. Miller
Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 3 of them as possibly being bugs in the "net/rose" subsystem. I've
listed these reports below, sorted by an algorithm that tries to list first the
reports most likely to be still valid, important, and actionable.
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the "net/rose" subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: general protection fault in rose_send_frame
Last occurred: 0 days ago
Reported: 167 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=f46c94afb217ab49c75350adbd467d86ae2b59a6
Original thread: https://lkml.kernel.org/lkml/00000000000089904d057f1e0ae0@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+7078ae989d857fe17988@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000089904d057f1e0ae0@google.com
--------------------------------------------------------------------------------
Title: INFO: rcu detected stall in rose_loopback_timer (2)
Last occurred: 19 days ago
Reported: 17 days ago
Branches: net
Dashboard link: https://syzkaller.appspot.com/bug?id=42c06438fe5956ab9978486a1898ca2f23b1fc1f
Original thread: https://lkml.kernel.org/lkml/000000000000cf98fa058adf3615@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+d37efb0ca1b82682326e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000cf98fa058adf3615@google.com
--------------------------------------------------------------------------------
Title: INFO: rcu detected stall in rose_connect
Last occurred: 25 days ago
Reported: 22 days ago
Branches: net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=0b258dc8ece5bb93dfb5a137ae25a6db300d5892
Original thread: https://lkml.kernel.org/lkml/00000000000017b026058a785790@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+af81c7a21a31b18bec0e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000017b026058a785790@google.com
^ permalink raw reply
* Reminder: 4 open syzbot bugs in "net/ax25" subsystem
From: Eric Biggers @ 2019-06-27 3:47 UTC (permalink / raw)
To: linux-hams, netdev, Ralf Baechle, David S. Miller
Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 4 of them as possibly being bugs in the "net/ax25" subsystem. I've
listed these reports below, sorted by an algorithm that tries to list first the
reports most likely to be still valid, important, and actionable.
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the "net/ax25" subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: general protection fault in ax25_send_frame
Last occurred: 0 days ago
Reported: 177 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=1cdd5b120f129364fc8e9b2b027826cf99fa696e
Original thread: https://lkml.kernel.org/lkml/0000000000009ea37c057e58d787@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+e0b81535a27b8be39502@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000009ea37c057e58d787@google.com
--------------------------------------------------------------------------------
Title: KASAN: stack-out-of-bounds Write in ax25_getname
Last occurred: 63 days ago
Reported: 179 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=fb195f91dc044978c1b186f1288b1eff61edcc20
Original thread: https://lkml.kernel.org/lkml/000000000000ed4120057e2df0c6@google.com/T/#u
This bug has a syzkaller reproducer only.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+6a29097222b4d3b8617c@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000ed4120057e2df0c6@google.com
--------------------------------------------------------------------------------
Title: inconsistent lock state in ax25_std_heartbeat_expiry
Last occurred: 95 days ago
Reported: 93 days ago
Branches: net
Dashboard link: https://syzkaller.appspot.com/bug?id=9086a8eac930890b2730d6441093bd478e32913f
Original thread: https://lkml.kernel.org/lkml/0000000000001b07250584efbee3@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
The original thread for this bug received 2 replies; the last was 92 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+e350b81e95a6a214da8a@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000001b07250584efbee3@google.com
--------------------------------------------------------------------------------
Title: general protection fault in ax25_send_control
Last occurred: 170 days ago
Reported: 169 days ago
Branches: net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=bacca5f8fe81f2486fb73fd9e130a3035dc46594
Original thread: https://lkml.kernel.org/lkml/00000000000077264c057eec9ddd@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+d0b03d6dbe11a950e0ce@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000077264c057eec9ddd@google.com
^ permalink raw reply
* Re: [Linux-kernel-mentees][PATCH v2] packet: Fix undefined behavior in bit shift
From: Shuah Khan @ 2019-06-27 3:32 UTC (permalink / raw)
To: Jiunn Chang
Cc: linux-kernel-mentees, netdev, linux-kernel, davem,
skh >> Shuah Khan
In-Reply-To: <20190627032532.18374-2-c0d1n61at3@gmail.com>
On 6/26/19 9:25 PM, Jiunn Chang wrote:
> Shifting signed 32-bit value by 31 bits is undefined. Changing most
> significant bit to unsigned.
>
> Changes included in v2:
> - use subsystem specific subject lines
> - CC required mailing lists
>
These version change lines don't belong in the change log.
> Signed-off-by: Jiunn Chang <c0d1n61at3@gmail.com>
> ---
Move them here.
> include/uapi/linux/if_packet.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/if_packet.h b/include/uapi/linux/if_packet.h
> index 467b654bd4c7..3d884d68eb30 100644
> --- a/include/uapi/linux/if_packet.h
> +++ b/include/uapi/linux/if_packet.h
> @@ -123,7 +123,7 @@ struct tpacket_auxdata {
> /* Rx and Tx ring - header status */
> #define TP_STATUS_TS_SOFTWARE (1 << 29)
> #define TP_STATUS_TS_SYS_HARDWARE (1 << 30) /* deprecated, never set */
> -#define TP_STATUS_TS_RAW_HARDWARE (1 << 31)
> +#define TP_STATUS_TS_RAW_HARDWARE (1U << 31)
>
> /* Rx ring - feature request bits */
> #define TP_FT_REQ_FILL_RXHASH 0x1
>
thanks,
-- Shuah
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2019-06-27 3:26 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Stephen Suryaputra, Lawrence Brakmo, Alexei Starovoitov
[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/ipv4/ip_output.c
between commit:
5b18f1289808 ("ipv4: reset rt_iif for recirculated mcast/bcast out pkts")
from the net tree and commit:
956fe2190820 ("bpf: Update BPF_CGROUP_RUN_PROG_INET_EGRESS calls")
from the net-next tree.
I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/ipv4/ip_output.c
index 8c2ec35b6512,cdd6c3418b9e..000000000000
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@@ -322,7 -330,12 +331,26 @@@ static int ip_mc_finish_output(struct n
int ret;
ret = BPF_CGROUP_RUN_PROG_INET_EGRESS(sk, skb);
- if (ret) {
+ switch (ret) {
++ case NET_XMIT_SUCCESS:
++ case NET_XMIT_CN:
++ /* Reset rt_iif so that inet_iif() will return skb->skb_iif.
++ * Setting this to non-zero causes ipi_ifindex in in_pktinfo
++ * to be overwritten, see ipv4_pktinfo_prepare().
++ */
++ new_rt = rt_dst_clone(net->loopback_dev, skb_rtable(skb));
++ if (new_rt) {
++ new_rt->rt_iif = 0;
++ skb_dst_drop(skb);
++ skb_dst_set(skb, &new_rt->dst);
++ }
++ }
++ switch (ret) {
+ case NET_XMIT_SUCCESS:
+ return dev_loopback_xmit(net, sk, skb);
+ case NET_XMIT_CN:
+ return dev_loopback_xmit(net, sk, skb) ? : ret;
+ default:
kfree_skb(skb);
return ret;
}
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [Linux-kernel-mentees][PATCH v2] packet: Fix undefined behavior in bit shift
From: Jiunn Chang @ 2019-06-27 3:25 UTC (permalink / raw)
To: skhan; +Cc: linux-kernel-mentees, netdev, linux-kernel, davem
In-Reply-To: <20190627010137.5612-1-c0d1n61at3@gmail.com>
Shifting signed 32-bit value by 31 bits is undefined. Changing most
significant bit to unsigned.
Changes included in v2:
- use subsystem specific subject lines
- CC required mailing lists
Signed-off-by: Jiunn Chang <c0d1n61at3@gmail.com>
---
include/uapi/linux/if_packet.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/if_packet.h b/include/uapi/linux/if_packet.h
index 467b654bd4c7..3d884d68eb30 100644
--- a/include/uapi/linux/if_packet.h
+++ b/include/uapi/linux/if_packet.h
@@ -123,7 +123,7 @@ struct tpacket_auxdata {
/* Rx and Tx ring - header status */
#define TP_STATUS_TS_SOFTWARE (1 << 29)
#define TP_STATUS_TS_SYS_HARDWARE (1 << 30) /* deprecated, never set */
-#define TP_STATUS_TS_RAW_HARDWARE (1 << 31)
+#define TP_STATUS_TS_RAW_HARDWARE (1U << 31)
/* Rx ring - feature request bits */
#define TP_FT_REQ_FILL_RXHASH 0x1
--
2.22.0
^ permalink raw reply related
* Re: [PATCH v2 0/4] Compile-test UAPI and kernel headers
From: Masahiro Yamada @ 2019-06-27 3:12 UTC (permalink / raw)
To: Linux Kbuild mailing list
Cc: Sam Ravnborg, Tony Luck, open list:DOCUMENTATION, John Fastabend,
Jonathan Corbet, Jakub Kicinski, linux-riscv, Daniel Borkmann,
xdp-newbies, Anton Vorontsov, Palmer Dabbelt, Matthias Brugger,
Song Liu, Yonghong Song, Michal Marek, Jesper Dangaard Brouer,
Martin KaFai Lau, moderated list:ARM/Mediatek SoC support,
linux-arm-kernel, Albert Ou, Colin Cross, David S. Miller,
Kees Cook, Alexei Starovoitov, Networking,
Linux Kernel Mailing List, bpf
In-Reply-To: <20190627014617.600-1-yamada.masahiro@socionext.com>
On Thu, Jun 27, 2019 at 10:49 AM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
>
> 1/4: reworked v2.
>
> 2/4: fix a flaw I noticed when I was working on this series
>
> 3/4: maybe useful for 4/4 and in some other places
>
> 4/4: v2. compile as many headers as possible.
>
If you want to test this series,
please check:
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
header-test-v2
> Changes in v2:
> - Add CONFIG_CPU_{BIG,LITTLE}_ENDIAN guard to avoid build error
> - Use 'header-test-' instead of 'no-header-test'
> - Avoid weird 'find' warning when cleaning
> - New patch
> - New patch
> - Add everything to test coverage, and exclude broken ones
> - Rename 'Makefile' to 'Kbuild'
> - Add CONFIG_KERNEL_HEADER_TEST option
>
> Masahiro Yamada (4):
> kbuild: compile-test UAPI headers to ensure they are self-contained
> kbuild: do not create wrappers for header-test-y
> kbuild: support header-test-pattern-y
> kbuild: compile-test kernel headers to ensure they are self-contained
>
> .gitignore | 1 -
> Documentation/dontdiff | 1 -
> Documentation/kbuild/makefiles.txt | 13 +-
> Makefile | 4 +-
> include/Kbuild | 1134 ++++++++++++++++++++++++++++
> init/Kconfig | 22 +
> scripts/Makefile.build | 10 +-
> scripts/Makefile.lib | 12 +-
> scripts/cc-system-headers.sh | 8 +
> usr/.gitignore | 1 -
> usr/Makefile | 2 +
> usr/include/.gitignore | 3 +
> usr/include/Makefile | 133 ++++
> 13 files changed, 1331 insertions(+), 13 deletions(-)
> create mode 100644 include/Kbuild
> create mode 100755 scripts/cc-system-headers.sh
> create mode 100644 usr/include/.gitignore
> create mode 100644 usr/include/Makefile
>
> --
> 2.17.1
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH net] sctp: not bind the socket in sctp_connect
From: Marcelo Ricardo Leitner @ 2019-06-27 2:59 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Neil Horman, syzkaller-bugs
In-Reply-To: <35a0e4f6ca68185117c6e5517d8ac924cc2f9d05.1561537899.git.lucien.xin@gmail.com>
On Wed, Jun 26, 2019 at 04:31:39PM +0800, Xin Long wrote:
> Now when sctp_connect() is called with a wrong sa_family, it binds
> to a port but doesn't set bp->port, then sctp_get_af_specific will
> return NULL and sctp_connect() returns -EINVAL.
>
> Then if sctp_bind() is called to bind to another port, the last
> port it has bound will leak due to bp->port is NULL by then.
>
> sctp_connect() doesn't need to bind ports, as later __sctp_connect
> will do it if bp->port is NULL. So remove it from sctp_connect().
> While at it, remove the unnecessary sockaddr.sa_family len check
> as it's already done in sctp_inet_connect.
>
> Fixes: 644fbdeacf1d ("sctp: fix the issue that flags are ignored when using kernel_connect")
> Reported-by: syzbot+079bf326b38072f849d9@syzkaller.appspotmail.com
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Please give me another day to review this one. Thanks.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2019-06-27 2:50 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix ppp_mppe crypto soft dependencies, from Takashi Iawi.
2) Fix TX completion to be finite, from Sergej Benilov.
3) Use register_pernet_device to avoid a dst leak in tipc, from Xin
Long.
4) Double free of TX cleanup in Dirk van der Merwe.
5) Memory leak in packet_set_ring(), from Eric Dumazet.
6) Out of bounds read in qmi_wwan, from Bjørn Mork.
7) Fix iif used in mcast/bcast looped back packets, from Stephen
Suryaputra.
8) Fix neighbour resolution on raw ipv6 sockets, from Nicolas Dichtel.
Please pull, thanks a lot!
The following changes since commit c356dc4b540edd6c02b409dd8cf3208ba2804c38:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2019-06-21 22:23:35 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
for you to fetch changes up to 89ed5b519004a7706f50b70f611edbd3aaacff2c:
af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET (2019-06-26 19:38:29 -0700)
----------------------------------------------------------------
Antoine Tenart (1):
net: macb: do not copy the mac address if NULL
Bjørn Mork (1):
qmi_wwan: Fix out-of-bounds read
David S. Miller (2):
Merge branch 'smc-fixes'
Merge branch 'ipv6-fix-neighbour-resolution-with-raw-socket'
Dirk van der Merwe (1):
net/tls: fix page double free on TX cleanup
Dmitry Bogdanov (1):
net: aquantia: fix vlans not working over bridged network
Eiichi Tsukata (1):
net/ipv6: Fix misuse of proc_dointvec "skip_notify_on_dev_down"
Eric Dumazet (1):
net/packet: fix memory leak in packet_set_ring()
Huaping Zhou (1):
net/smc: hold conns_lock before calling smc_lgr_register_conn()
Marek Vasut (1):
net: dsa: microchip: Use gpiod_set_value_cansleep()
Neil Horman (1):
af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET
Nicolas Dichtel (2):
ipv6: constify rt6_nexthop()
ipv6: fix neighbour resolution with raw socket
Petr Oros (1):
be2net: fix link failure after ethtool offline test
Roland Hii (2):
net: stmmac: fixed new system time seconds value calculation
net: stmmac: set IC bit when transmitting frames with HW timestamp
Sergej Benilov (1):
sis900: fix TX completion
Stephen Suryaputra (2):
ipv4: Use return value of inet_iif() for __raw_v4_lookup in the while loop
ipv4: reset rt_iif for recirculated mcast/bcast out pkts
Takashi Iwai (1):
ppp: mppe: Add softdep to arc4
Xin Long (3):
tipc: change to use register_pernet_device
tipc: check msg->req data len in tipc_nl_compat_bearer_disable
sctp: change to hold sk after auth shkey is created successfully
YueHaibing (4):
net/sched: cbs: Fix error path of cbs_module_init
bonding: Always enable vlan tx offload
net/smc: Fix error path in smc_init
team: Always enable vlan tx offload
drivers/net/bonding/bond_main.c | 2 +-
drivers/net/dsa/microchip/ksz_common.c | 6 +++---
drivers/net/ethernet/aquantia/atlantic/aq_filters.c | 10 ++++++++--
drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 1 +
drivers/net/ethernet/aquantia/atlantic/aq_nic.h | 1 +
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c | 19 +++++++++++++------
drivers/net/ethernet/cadence/macb_main.c | 2 +-
drivers/net/ethernet/emulex/benet/be_ethtool.c | 28 ++++++++++++++++++++++------
drivers/net/ethernet/sis/sis900.c | 16 ++++++++--------
drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 22 ++++++++++++++--------
drivers/net/ppp/ppp_mppe.c | 1 +
drivers/net/team/team.c | 2 +-
drivers/net/usb/qmi_wwan.c | 2 +-
drivers/net/vrf.c | 2 +-
include/net/ip6_route.h | 4 ++--
include/net/route.h | 1 +
include/net/tls.h | 15 ---------------
net/bluetooth/6lowpan.c | 4 ++--
net/ipv4/ip_output.c | 12 ++++++++++++
net/ipv4/raw.c | 2 +-
net/ipv4/route.c | 33 +++++++++++++++++++++++++++++++++
net/ipv6/ip6_output.c | 2 +-
net/ipv6/route.c | 5 +++--
net/netfilter/nf_flow_table_ip.c | 2 +-
net/packet/af_packet.c | 23 +++++++++++++++++++----
net/packet/internal.h | 1 +
net/sched/sch_cbs.c | 9 +++++++--
net/sctp/endpointola.c | 8 ++++----
net/smc/af_smc.c | 5 ++++-
net/smc/smc_core.c | 3 +++
net/tipc/core.c | 12 ++++++------
net/tipc/netlink_compat.c | 18 +++++++++++++++---
net/tls/tls_main.c | 3 ++-
34 files changed, 194 insertions(+), 84 deletions(-)
^ permalink raw reply
* Re: [PATCH bpf-next] virtio_net: add XDP meta data support in receive_small()
From: Jason Wang @ 2019-06-27 2:40 UTC (permalink / raw)
To: Yuya Kusakabe, davem
Cc: netdev, ast, daniel, jakub.kicinski, hawk, john.fastabend,
Michael S. Tsirkin
In-Reply-To: <20190627023332.8557-1-yuya.kusakabe@gmail.com>
On 2019/6/27 上午10:33, Yuya Kusakabe wrote:
> This adds XDP meta data support to the code path receive_small().
>
> mrg_rxbuf=off is required on qemu, because receive_mergeable() still
> doesn't support XDP meta data.
What's the reason for this?
>
> Fixes: de8f3a83b0a0 ("bpf: add meta pointer for direct access")
> Signed-off-by: Yuya Kusakabe <yuya.kusakabe@gmail.com>
Could you please cc virtio maintainer through get_maintainer.pl?
Thanks
> ---
> drivers/net/virtio_net.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 4f3de0ac8b0b..14165c5edb7d 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -644,6 +644,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
> unsigned int delta = 0;
> struct page *xdp_page;
> int err;
> + unsigned int metasize = 0;
>
> len -= vi->hdr_len;
> stats->bytes += len;
> @@ -683,8 +684,8 @@ static struct sk_buff *receive_small(struct net_device *dev,
>
> xdp.data_hard_start = buf + VIRTNET_RX_PAD + vi->hdr_len;
> xdp.data = xdp.data_hard_start + xdp_headroom;
> - xdp_set_data_meta_invalid(&xdp);
> xdp.data_end = xdp.data + len;
> + xdp.data_meta = xdp.data;
> xdp.rxq = &rq->xdp_rxq;
> orig_data = xdp.data;
> act = bpf_prog_run_xdp(xdp_prog, &xdp);
> @@ -695,9 +696,11 @@ static struct sk_buff *receive_small(struct net_device *dev,
> /* Recalculate length in case bpf program changed it */
> delta = orig_data - xdp.data;
> len = xdp.data_end - xdp.data;
> + metasize = xdp.data - xdp.data_meta;
> break;
> case XDP_TX:
> stats->xdp_tx++;
> + xdp.data_meta = xdp.data;
> xdpf = convert_to_xdp_frame(&xdp);
> if (unlikely(!xdpf))
> goto err_xdp;
> @@ -735,11 +738,14 @@ static struct sk_buff *receive_small(struct net_device *dev,
> }
> skb_reserve(skb, headroom - delta);
> skb_put(skb, len);
> - if (!delta) {
> + if (!delta && !metasize) {
> buf += header_offset;
> memcpy(skb_vnet_hdr(skb), buf, vi->hdr_len);
> } /* keep zeroed vnet hdr since packet was changed by bpf */
>
> + if (metasize)
> + skb_metadata_set(skb, metasize);
> +
> err:
> return skb;
>
^ permalink raw reply
* Re: [PATCH v4 net] af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET
From: David Miller @ 2019-06-27 2:38 UTC (permalink / raw)
To: nhorman; +Cc: netdev, mcroce, willemdebruijn.kernel
In-Reply-To: <20190625215749.22840-1-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Tue, 25 Jun 2019 17:57:49 -0400
> When an application is run that:
> a) Sets its scheduler to be SCHED_FIFO
> and
> b) Opens a memory mapped AF_PACKET socket, and sends frames with the
> MSG_DONTWAIT flag cleared, its possible for the application to hang
> forever in the kernel. This occurs because when waiting, the code in
> tpacket_snd calls schedule, which under normal circumstances allows
> other tasks to run, including ksoftirqd, which in some cases is
> responsible for freeing the transmitted skb (which in AF_PACKET calls a
> destructor that flips the status bit of the transmitted frame back to
> available, allowing the transmitting task to complete).
>
> However, when the calling application is SCHED_FIFO, its priority is
> such that the schedule call immediately places the task back on the cpu,
> preventing ksoftirqd from freeing the skb, which in turn prevents the
> transmitting task from detecting that the transmission is complete.
>
> We can fix this by converting the schedule call to a completion
> mechanism. By using a completion queue, we force the calling task, when
> it detects there are no more frames to send, to schedule itself off the
> cpu until such time as the last transmitted skb is freed, allowing
> forward progress to be made.
>
> Tested by myself and the reporter, with good results
>
> Appies to the net tree
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Reported-by: Matteo Croce <mcroce@redhat.com>
> CC: "David S. Miller" <davem@davemloft.net>
> CC: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
...
Applied and queued up for -stable.
^ permalink raw reply
* [PATCH bpf-next] virtio_net: add XDP meta data support in receive_small()
From: Yuya Kusakabe @ 2019-06-27 2:33 UTC (permalink / raw)
To: davem
Cc: netdev, ast, daniel, jakub.kicinski, hawk, john.fastabend,
Yuya Kusakabe
This adds XDP meta data support to the code path receive_small().
mrg_rxbuf=off is required on qemu, because receive_mergeable() still
doesn't support XDP meta data.
Fixes: de8f3a83b0a0 ("bpf: add meta pointer for direct access")
Signed-off-by: Yuya Kusakabe <yuya.kusakabe@gmail.com>
---
drivers/net/virtio_net.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4f3de0ac8b0b..14165c5edb7d 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -644,6 +644,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
unsigned int delta = 0;
struct page *xdp_page;
int err;
+ unsigned int metasize = 0;
len -= vi->hdr_len;
stats->bytes += len;
@@ -683,8 +684,8 @@ static struct sk_buff *receive_small(struct net_device *dev,
xdp.data_hard_start = buf + VIRTNET_RX_PAD + vi->hdr_len;
xdp.data = xdp.data_hard_start + xdp_headroom;
- xdp_set_data_meta_invalid(&xdp);
xdp.data_end = xdp.data + len;
+ xdp.data_meta = xdp.data;
xdp.rxq = &rq->xdp_rxq;
orig_data = xdp.data;
act = bpf_prog_run_xdp(xdp_prog, &xdp);
@@ -695,9 +696,11 @@ static struct sk_buff *receive_small(struct net_device *dev,
/* Recalculate length in case bpf program changed it */
delta = orig_data - xdp.data;
len = xdp.data_end - xdp.data;
+ metasize = xdp.data - xdp.data_meta;
break;
case XDP_TX:
stats->xdp_tx++;
+ xdp.data_meta = xdp.data;
xdpf = convert_to_xdp_frame(&xdp);
if (unlikely(!xdpf))
goto err_xdp;
@@ -735,11 +738,14 @@ static struct sk_buff *receive_small(struct net_device *dev,
}
skb_reserve(skb, headroom - delta);
skb_put(skb, len);
- if (!delta) {
+ if (!delta && !metasize) {
buf += header_offset;
memcpy(skb_vnet_hdr(skb), buf, vi->hdr_len);
} /* keep zeroed vnet hdr since packet was changed by bpf */
+ if (metasize)
+ skb_metadata_set(skb, metasize);
+
err:
return skb;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net] sctp: change to hold sk after auth shkey is created successfully
From: David Miller @ 2019-06-27 2:30 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman, syzkaller-bugs
In-Reply-To: <14de0d292dc2fe01ecadaba00feb925b337b558f.1561393305.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Tue, 25 Jun 2019 00:21:45 +0800
> Now in sctp_endpoint_init(), it holds the sk then creates auth
> shkey. But when the creation fails, it doesn't release the sk,
> which causes a sk defcnf leak,
>
> Here to fix it by only holding the sk when auth shkey is created
> successfully.
>
> Fixes: a29a5bd4f5c3 ("[SCTP]: Implement SCTP-AUTH initializations.")
> Reported-by: syzbot+afabda3890cc2f765041@syzkaller.appspotmail.com
> Reported-by: syzbot+276ca1c77a19977c0130@syzkaller.appspotmail.com
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable, thanks Xin.
^ permalink raw reply
* Re: [PATCH v2] flow_dissector: Fix vlan header offset in __skb_flow_dissect
From: David Miller @ 2019-06-27 2:28 UTC (permalink / raw)
To: yuehaibing
Cc: sdf, jianbol, jiri, mirq-linux, willemb, sdf, jiri, linux-kernel,
netdev
In-Reply-To: <20190624034913.40328-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Mon, 24 Jun 2019 11:49:13 +0800
> @@ -998,6 +998,9 @@ bool __skb_flow_dissect(const struct net *net,
> skb && skb_vlan_tag_present(skb)) {
> proto = skb->protocol;
> } else {
> + if (dissector_vlan == FLOW_DISSECTOR_KEY_MAX)
> + nhoff -= sizeof(*vlan);
> +
But this is wrong when we are being called via eth_get_headlen(), in
that case nhoff will be sizeof(struct ethhdr).
^ permalink raw reply
* [PATCH 2/2 nf-next] netfilter:nft_meta: add NFT_META_VLAN support
From: wenxu @ 2019-06-27 2:09 UTC (permalink / raw)
To: pablo, fw; +Cc: netfilter-devel, netdev
In-Reply-To: <1561601357-20486-1-git-send-email-wenxu@ucloud.cn>
From: wenxu <wenxu@ucloud.cn>
This patch provide a meta vlan to set the vlan tag of the packet.
for q-in-q vlan id 20:
meta vlan set 0x88a8:20
set the default 0x8100 vlan type with vlan id 20
meta vlan set 20
Signed-off-by: wenxu <wenxu@ucloud.cn>
---
include/uapi/linux/netfilter/nf_tables.h | 4 ++++
net/netfilter/nft_meta.c | 27 ++++++++++++++++++++++++++-
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/netfilter/nf_tables.h b/include/uapi/linux/netfilter/nf_tables.h
index 0b18646..cf037f2 100644
--- a/include/uapi/linux/netfilter/nf_tables.h
+++ b/include/uapi/linux/netfilter/nf_tables.h
@@ -797,6 +797,7 @@ enum nft_exthdr_attributes {
* @NFT_META_OIFKIND: packet output interface kind name (dev->rtnl_link_ops->kind)
* @NFT_META_BRI_PVID: packet input bridge port pvid
* @NFT_META_BRI_VLAN_PROTO: packet input bridge vlan proto
+ * @NFT_META_VLAN: packet vlan metadata
*/
enum nft_meta_keys {
NFT_META_LEN,
@@ -829,6 +830,7 @@ enum nft_meta_keys {
NFT_META_OIFKIND,
NFT_META_BRI_PVID,
NFT_META_BRI_VLAN_PROTO,
+ NFT_META_VLAN,
};
/**
@@ -895,12 +897,14 @@ enum nft_hash_attributes {
* @NFTA_META_DREG: destination register (NLA_U32)
* @NFTA_META_KEY: meta data item to load (NLA_U32: nft_meta_keys)
* @NFTA_META_SREG: source register (NLA_U32)
+ * @NFTA_META_SREG2: source register (NLA_U32)
*/
enum nft_meta_attributes {
NFTA_META_UNSPEC,
NFTA_META_DREG,
NFTA_META_KEY,
NFTA_META_SREG,
+ NFTA_META_SREG2,
__NFTA_META_MAX
};
#define NFTA_META_MAX (__NFTA_META_MAX - 1)
diff --git a/net/netfilter/nft_meta.c b/net/netfilter/nft_meta.c
index e3adf6a..29a6679 100644
--- a/net/netfilter/nft_meta.c
+++ b/net/netfilter/nft_meta.c
@@ -28,7 +28,10 @@ struct nft_meta {
enum nft_meta_keys key:8;
union {
enum nft_registers dreg:8;
- enum nft_registers sreg:8;
+ struct {
+ enum nft_registers sreg:8;
+ enum nft_registers sreg2:8;
+ };
};
};
@@ -312,6 +315,17 @@ static void nft_meta_set_eval(const struct nft_expr *expr,
skb->secmark = value;
break;
#endif
+ case NFT_META_VLAN: {
+ u32 *sreg2 = ®s->data[meta->sreg2];
+ __be16 vlan_proto;
+ u16 vlan_tci;
+
+ vlan_tci = nft_reg_load16(sreg);
+ vlan_proto = nft_reg_load16(sreg2);
+
+ __vlan_hwaccel_put_tag(skb, vlan_proto, vlan_tci);
+ break;
+ }
default:
WARN_ON(1);
}
@@ -321,6 +335,7 @@ static void nft_meta_set_eval(const struct nft_expr *expr,
[NFTA_META_DREG] = { .type = NLA_U32 },
[NFTA_META_KEY] = { .type = NLA_U32 },
[NFTA_META_SREG] = { .type = NLA_U32 },
+ [NFTA_META_SREG2] = { .type = NLA_U32 },
};
static int nft_meta_get_init(const struct nft_ctx *ctx,
@@ -483,6 +498,13 @@ static int nft_meta_set_init(const struct nft_ctx *ctx,
case NFT_META_PKTTYPE:
len = sizeof(u8);
break;
+ case NFT_META_VLAN:
+ len = sizeof(u16);
+ priv->sreg2 = nft_parse_register(tb[NFTA_META_SREG2]);
+ err = nft_validate_register_load(priv->sreg2, len);
+ if (err < 0)
+ return err;
+ break;
default:
return -EOPNOTSUPP;
}
@@ -521,6 +543,9 @@ static int nft_meta_set_dump(struct sk_buff *skb, const struct nft_expr *expr)
goto nla_put_failure;
if (nft_dump_register(skb, NFTA_META_SREG, priv->sreg))
goto nla_put_failure;
+ if (priv->key == NFT_META_VLAN &&
+ nft_dump_register(skb, NFTA_META_SREG2, priv->sreg2))
+ goto nla_put_failure;
return 0;
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/2 nf-next] netfilter: nft_meta: add NFT_META_BRI_VLAN_PROTO support
From: wenxu @ 2019-06-27 2:09 UTC (permalink / raw)
To: pablo, fw; +Cc: netfilter-devel, netdev
From: wenxu <wenxu@ucloud.cn>
This patch provide a meta to get the bridge vlan proto
nft add rule bridge firewall zones counter meta br_vlan_proto 0x8100
Signed-off-by: wenxu <wenxu@ucloud.cn>
---
include/uapi/linux/netfilter/nf_tables.h | 2 ++
net/netfilter/nft_meta.c | 9 +++++++++
2 files changed, 11 insertions(+)
diff --git a/include/uapi/linux/netfilter/nf_tables.h b/include/uapi/linux/netfilter/nf_tables.h
index 8859535..0b18646 100644
--- a/include/uapi/linux/netfilter/nf_tables.h
+++ b/include/uapi/linux/netfilter/nf_tables.h
@@ -796,6 +796,7 @@ enum nft_exthdr_attributes {
* @NFT_META_IIFKIND: packet input interface kind name (dev->rtnl_link_ops->kind)
* @NFT_META_OIFKIND: packet output interface kind name (dev->rtnl_link_ops->kind)
* @NFT_META_BRI_PVID: packet input bridge port pvid
+ * @NFT_META_BRI_VLAN_PROTO: packet input bridge vlan proto
*/
enum nft_meta_keys {
NFT_META_LEN,
@@ -827,6 +828,7 @@ enum nft_meta_keys {
NFT_META_IIFKIND,
NFT_META_OIFKIND,
NFT_META_BRI_PVID,
+ NFT_META_BRI_VLAN_PROTO,
};
/**
diff --git a/net/netfilter/nft_meta.c b/net/netfilter/nft_meta.c
index 4f8116d..e3adf6a 100644
--- a/net/netfilter/nft_meta.c
+++ b/net/netfilter/nft_meta.c
@@ -248,6 +248,14 @@ void nft_meta_get_eval(const struct nft_expr *expr,
return;
}
goto err;
+ case NFT_META_BRI_VLAN_PROTO:
+ if (in == NULL || (p = br_port_get_rtnl_rcu(in)) == NULL)
+ goto err;
+ if (br_opt_get(p->br, BROPT_VLAN_ENABLED)) {
+ nft_reg_store16(dest, p->br->vlan_proto);
+ return;
+ }
+ goto err;
#endif
case NFT_META_IIFKIND:
if (in == NULL || in->rtnl_link_ops == NULL)
@@ -376,6 +384,7 @@ static int nft_meta_get_init(const struct nft_ctx *ctx,
len = IFNAMSIZ;
break;
case NFT_META_BRI_PVID:
+ case NFT_META_BRI_VLAN_PROTO:
if (ctx->family != NFPROTO_BRIDGE)
return -EOPNOTSUPP;
len = sizeof(u16);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next] can: dev: call netif_carrier_off() in register_candev()
From: Willem de Bruijn @ 2019-06-27 1:56 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Wolfgang Grandegger, Marc Kleine-Budde, David S. Miller,
linux-can@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <838ce911-7205-f828-4fc5-79cebc32322a@prevas.dk>
On Wed, Jun 26, 2019 at 5:19 PM Rasmus Villemoes
<rasmus.villemoes@prevas.dk> wrote:
>
> On 26/06/2019 16.17, Willem de Bruijn wrote:
> > On Wed, Jun 26, 2019 at 5:31 AM Rasmus Villemoes
> > <rasmus.villemoes@prevas.dk> wrote:
> >>
> >> On 24/06/2019 19.26, Willem de Bruijn wrote:
> >>> On Mon, Jun 24, 2019 at 4:34 AM Rasmus Villemoes
> >>> <rasmus.villemoes@prevas.dk> wrote:
> >>>>
> >>>> Make sure the LED always reflects the state of the CAN device.
> >>>
> >>> Should this target net?
> >>
> >> No, I think this should go through the CAN tree. Perhaps I've
> >> misunderstood when to use the net-next prefix - is that only for things
> >> that should be applied directly to the net-next tree? If so, sorry.
> >
> > I don't see consistent behavior on the list, so this is probably fine.
> > It would probably help to target can (for fixes) or can-next (for new
> > features).
> >
> > Let me reframe the question: should this target can, instead of can-next?
>
> Ah, now I see what you meant, but at least I learned when to use
> net/net-next.
>
> I think can-next is fine, especially this late in the rc cycle. But I'll
> leave it to the CAN maintainer(s).
>
> >>> Regardless of CONFIG_CAN_LEDS deprecation,
> >>> this is already not initialized properly if that CONFIG is disabled
> >>> and a can_led_event call at device probe is a noop.
> >>
> >> I'm not sure I understand this part. The CONFIG_CAN_LEDS support for
> >> showing the state of the interface is implemented via hooking into the
> >> ndo_open/ndo_stop callbacks, and does not look at or touch the
> >> __LINK_STATE_NOCARRIER bit at all.
> >>
> >> Other than via the netdev LED trigger I don't think one can even observe
> >> the slightly odd initial state of the __LINK_STATE_NOCARRIER bit for CAN
> >> devices,
> >
> > it's still incorrect, though I guess that's moot in practice.
> Exactly.
>
> >> which is why I framed this as a fix purely to allow the netdev
> >> trigger to be a closer drop-in replacement for CONFIG_CAN_LEDS.
> >
> > So the entire CONFIG_CAN_LEDS code is to be removed? What exactly is
> > this netdev trigger replacement, if not can_led_event? Sorry, I
> > probably miss some context.
>
> drivers/net/can/Kconfig contains these comments
>
> # The netdev trigger (LEDS_TRIGGER_NETDEV) should be able to do
> # everything that this driver is doing. This is marked as broken
> # because it uses stuff that is intended to be changed or removed.
> # Please consider switching to the netdev trigger and confirm it
> # fulfills your needs instead of fixing this driver.
>
> introduced by the commit 30f3b42147ba6 which also marked CONFIG_CAN_LEDS
> as (depends on) BROKEN. So while a .dts for using the CAN led trigger
> might be
>
> cana {
> label = "cana:green:activity";
> gpios = <&gpio0 10 0>;
> default-state = "off";
> linux,default-trigger = "can0-rxtx";
> };
>
> one can achieve mostly the same thing with CAN_LEDS=n,
> LEDS_TRIGGER_NETDEV=y setting linux,default-trigger = "netdev" plus a
> small init script (or udev rule or whatever works) that does
>
> d=/sys/class/leds/cana:green:activity
> echo can0 > $d/device_name
> echo 1 > $d/link
> echo 1 > $d/rx
> echo 1 > $d/tx
>
> to tie the cana LED to the can0 device, plus configure it to show "link"
> state as well as blink on rx and tx.
>
> This works just fine, except for the initial state of the LED. AFAIU,
> the netdev trigger doesn't need cooperation from each device driver
> since it simply works of a timer that periodically checks for changes in
> dev_get_stats().
Thanks, I had to read up on that code. Makes sense.
Acked-by: Willem de Bruijn <willemb@google.com>
^ 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