* [PATCH net-next] net/tls: Do not call msg_data_left() twice
From: Vakul Garg @ 2018-07-24 11:11 UTC (permalink / raw)
To: netdev; +Cc: borisp, aviadye, davejwatson, davem, Vakul Garg
In function tls_sw_sendmsg(), msg_data_left() needs to be called only
once. The second invocation of msg_data_left() for assigning variable
try_to_copy can be removed and merged with the first one.
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
net/tls/tls_sw.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 0c2d029c9d4c..fd51ce65b99c 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -377,7 +377,7 @@ int tls_sw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
goto send_end;
}
- while (msg_data_left(msg)) {
+ while ((try_to_copy = msg_data_left(msg))) {
if (sk->sk_err) {
ret = -sk->sk_err;
goto send_end;
@@ -385,7 +385,6 @@ int tls_sw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
orig_size = ctx->sg_plaintext_size;
full_record = false;
- try_to_copy = msg_data_left(msg);
record_room = TLS_MAX_PAYLOAD_SIZE - ctx->sg_plaintext_size;
if (try_to_copy >= record_room) {
try_to_copy = record_room;
--
2.13.6
^ permalink raw reply related
* Re: [PATCH rdma-next v2 0/8] Support mlx5 flow steering with RAW data
From: Leon Romanovsky @ 2018-07-24 5:56 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Yishai Hadas, Saeed Mahameed,
linux-netdev
In-Reply-To: <20180724024236.GA16958@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]
On Mon, Jul 23, 2018 at 08:42:36PM -0600, Jason Gunthorpe wrote:
> On Mon, Jul 23, 2018 at 03:25:04PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > Changelog:
> > v1->v2:
> > * Fix matcher to use the correct size.
> > * Rephrase commit log of the first patch.
> > v0->v1:
> > * Fixed ADD_UVERBS_ATTRIBUTES_SIMPLE macro to pass the real address.
> > ?* Replaced UA_ALLOC_AND_COPY to regular copy_from
> > * Added UVERBS_ATTR_NO_DATA new macro for cleaner code.
> > * Used ib_dev from uobj when it exists.
> > * ib_is_destroy_retryable was replaced by ib_destroy_usecnt
> >
> > >From Yishai:
> >
> > This series introduces vendor create and destroy flow methods on the
> > uverbs flow object by using the KABI infra-structure.
> >
> > It's done in a way that enables the driver to get its specific device
> > attributes in a raw data to match its underlay specification while still
> > using the generic ib_flow object for cleanup and code sharing.
> >
> > In addition, a specific mlx5 matcher object and its create/destroy
> > methods were introduced. This object matches the underlay flow steering
> > mask specification and is used as part of mlx5 create flow input data.
> >
> > This series supports IB_QP/TIR as its flow steering destination as
> > applicable today via the ib_create_flow API, however, it adds also an
> > option to work with DEVX object which its destination can be both TIR
> > and flow table.
> >
> > Few changes were done in the mlx5 core layer to support forward
> > compatible for the device specification raw data and to support flow
> > table when the DEVX destination is used.
> >
> > As part of this series the default IB destroy handler
> > (i.e. uverbs_destroy_def_handler()) was exposed from IB core to be
> > used by the drivers and existing code was refactored to use it.
> >
> > Thanks
> >
> > Yishai Hadas (8):
> > net/mlx5: Add forward compatible support for the FTE match data
> > net/mlx5: Add support for flow table destination number
> > IB/mlx5: Introduce flow steering matcher object
> > IB: Consider ib_flow creation by the KABI infrastructure
> > IB/mlx5: Introduce vendor create and destroy flow methods
> > IB/mlx5: Support adding flow steering rule by raw data
> > IB/mlx5: Add support for a flow table destination
> > IB/mlx5: Expose vendor flow trees
>
> This seems fine to me. Can you send the mlx5 shared branch for the
> first two patches?
I applied two first patches with Acked-by from Saeed to mlx5-next
664000b6bb43 net/mlx5: Add support for flow table destination number
2aada6c0c96e net/mlx5: Add forward compatible support for the FTE match data
Thanks
>
> Thanks,
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH net-next] net/tls: Removed redundant checks for non-NULL
From: Vakul Garg @ 2018-07-24 11:24 UTC (permalink / raw)
To: netdev; +Cc: borisp, aviadye, davejwatson, davem, Vakul Garg
Removed checks against non-NULL before calling kfree_skb() and
crypto_free_aead(). These functions are safe to be called with NULL
as an argument.
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
net/tls/tls_sw.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 0c2d029c9d4c..ef445478239c 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -1044,8 +1044,7 @@ void tls_sw_free_resources_tx(struct sock *sk)
struct tls_context *tls_ctx = tls_get_ctx(sk);
struct tls_sw_context_tx *ctx = tls_sw_ctx_tx(tls_ctx);
- if (ctx->aead_send)
- crypto_free_aead(ctx->aead_send);
+ crypto_free_aead(ctx->aead_send);
tls_free_both_sg(sk);
kfree(ctx);
@@ -1057,10 +1056,8 @@ void tls_sw_release_resources_rx(struct sock *sk)
struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
if (ctx->aead_recv) {
- if (ctx->recv_pkt) {
- kfree_skb(ctx->recv_pkt);
- ctx->recv_pkt = NULL;
- }
+ kfree_skb(ctx->recv_pkt);
+ ctx->recv_pkt = NULL;
crypto_free_aead(ctx->aead_recv);
strp_stop(&ctx->strp);
write_lock_bh(&sk->sk_callback_lock);
--
2.13.6
^ permalink raw reply related
* pull-request: mac80211-next 2018-07-24
From: Johannes Berg @ 2018-07-24 7:25 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Hi Dave,
Also have a few changes for -next, figured I should get this
out too.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit c47078d6a33fd78d882200cdaacbcfcd63318234:
tcp: remove redundant SOCK_DONE checks (2018-07-08 17:14:58 +0900)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2018-07-24
for you to fetch changes up to 133bf90dbb8b873286f8ec2e81ba26e863114b8c:
mac80211: restrict delayed tailroom needed decrement (2018-07-24 09:21:12 +0200)
----------------------------------------------------------------
Only a few things:
* HE (802.11ax) support in HWSIM
* bypass TXQ with NDP frames as they're special
* convert ahash -> shash in lib80211 TKIP
* avoid playing with tailroom counter defer unless
needed to avoid issues in some cases
----------------------------------------------------------------
Ilan Peer (1):
mac80211_hwsim: Add support for HE
Johannes Berg (1):
mac80211: don't put null-data frames on the normal TXQ
Kees Cook (1):
wireless/lib80211: Convert from ahash to shash
Manikanta Pubbisetty (1):
mac80211: restrict delayed tailroom needed decrement
drivers/net/wireless/mac80211_hwsim.c | 123 ++++++++++++++++++++++++++++++++++
net/mac80211/cfg.c | 2 +-
net/mac80211/key.c | 24 ++++---
net/mac80211/tx.c | 2 +-
net/wireless/lib80211_crypt_tkip.c | 55 ++++++++-------
5 files changed, 170 insertions(+), 36 deletions(-)
^ permalink raw reply
* KASAN: use-after-free Read in rfcomm_dlc_exists
From: syzbot @ 2018-07-24 7:27 UTC (permalink / raw)
To: davem, johan.hedberg, keescook, linux-bluetooth, linux-kernel,
marcel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 89cf55353308 Add linux-next specific files for 20180720
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1721408c400000
kernel config: https://syzkaller.appspot.com/x/.config?x=a9641a83a066bb43
dashboard link: https://syzkaller.appspot.com/bug?extid=728bead095cef3335bb6
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+728bead095cef3335bb6@syzkaller.appspotmail.com
EXT4-fs (loop7): VFS: Can't find ext4 filesystem
FAT-fs (loop4): Directory bread(block 2) failed
FAT-fs (loop4): Directory bread(block 3) failed
==================================================================
BUG: KASAN: use-after-free in rfcomm_dlc_get
net/bluetooth/rfcomm/core.c:360 [inline]
BUG: KASAN: use-after-free in rfcomm_dlc_exists+0x1be/0x1f0
net/bluetooth/rfcomm/core.c:549
Read of size 1 at addr ffff8801d2c1b484 by task syz-executor7/26132
FAT-fs (loop4): Directory bread(block 4) failed
CPU: 0 PID: 26132 Comm: syz-executor7 Not tainted 4.18.0-rc5-next-20180720+
#12
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+0x1c9/0x2b4 lib/dump_stack.c:113
FAT-fs (loop4): Directory bread(block 5) failed
print_address_description+0x6c/0x20b mm/kasan/report.c:256
FAT-fs (loop4): Directory bread(block 6) failed
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
__asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
rfcomm_dlc_get net/bluetooth/rfcomm/core.c:360 [inline]
rfcomm_dlc_exists+0x1be/0x1f0 net/bluetooth/rfcomm/core.c:549
__rfcomm_create_dev net/bluetooth/rfcomm/tty.c:413 [inline]
rfcomm_create_dev net/bluetooth/rfcomm/tty.c:486 [inline]
rfcomm_dev_ioctl+0x105e/0x2240 net/bluetooth/rfcomm/tty.c:588
FAT-fs (loop4): Directory bread(block 7) failed
FAT-fs (loop4): Directory bread(block 8) failed
rfcomm_sock_ioctl+0x89/0xb0 net/bluetooth/rfcomm/sock.c:902
sock_do_ioctl+0xe4/0x3e0 net/socket.c:951
FAT-fs (loop4): Directory bread(block 9) failed
FAT-fs (loop4): Directory bread(block 10) failed
sock_ioctl+0x30d/0x680 net/socket.c:1075
FAT-fs (loop4): Directory bread(block 11) failed
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:501 [inline]
do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
attempt to access beyond end of device
loop4: rw=1, want=73, limit=2
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
__do_sys_ioctl fs/ioctl.c:709 [inline]
__se_sys_ioctl fs/ioctl.c:707 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x455ab9
Code: 1d ba fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f46b0b73c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f46b0b746d4 RCX: 0000000000455ab9
RDX: 0000000020000140 RSI: 00000000400452c8 RDI: 0000000000000014
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000004bdaad R14: 00000000004cc4c0 R15: 0000000000000000
Allocated by task 23864:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620
kmalloc include/linux/slab.h:513 [inline]
kzalloc include/linux/slab.h:707 [inline]
rfcomm_dlc_alloc+0xb8/0x490 net/bluetooth/rfcomm/core.c:305
rfcomm_sock_alloc.constprop.6+0x13a/0x420 net/bluetooth/rfcomm/sock.c:286
rfcomm_sock_create+0xf0/0x2b0 net/bluetooth/rfcomm/sock.c:329
bt_sock_create+0x16b/0x2d0 net/bluetooth/af_bluetooth.c:130
__sock_create+0x53c/0x940 net/socket.c:1268
sock_create net/socket.c:1308 [inline]
__sys_socket+0x106/0x260 net/socket.c:1338
__do_sys_socket net/socket.c:1347 [inline]
__se_sys_socket net/socket.c:1345 [inline]
__x64_sys_socket+0x73/0xb0 net/socket.c:1345
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 26096:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xd9/0x260 mm/slab.c:3813
rfcomm_dlc_free+0x1e/0x30 net/bluetooth/rfcomm/core.c:328
rfcomm_dlc_put include/net/bluetooth/rfcomm.h:258 [inline]
__rfcomm_create_dev net/bluetooth/rfcomm/tty.c:417 [inline]
rfcomm_create_dev net/bluetooth/rfcomm/tty.c:486 [inline]
rfcomm_dev_ioctl+0x1dfe/0x2240 net/bluetooth/rfcomm/tty.c:588
rfcomm_sock_ioctl+0x89/0xb0 net/bluetooth/rfcomm/sock.c:902
sock_do_ioctl+0xe4/0x3e0 net/socket.c:951
sock_ioctl+0x30d/0x680 net/socket.c:1075
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:501 [inline]
do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
__do_sys_ioctl fs/ioctl.c:709 [inline]
__se_sys_ioctl fs/ioctl.c:707 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8801d2c1b340
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 324 bytes inside of
512-byte region [ffff8801d2c1b340, ffff8801d2c1b540)
The buggy address belongs to the page:
page:ffffea00074b06c0 count:1 mapcount:0 mapping:ffff8801da800940 index:0x0
flags: 0x2fffc0000000200(slab)
raw: 02fffc0000000200 ffffea00073f55c8 ffffea0007245f88 ffff8801da800940
raw: 0000000000000000 ffff8801d2c1b0c0 0000000100000006 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801d2c1b380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801d2c1b400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801d2c1b480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8801d2c1b500: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffff8801d2c1b580: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: [PATCH 1/5] sh_eth: uninline sh_eth_tsu_get_offset()
From: Geert Uytterhoeven @ 2018-07-24 6:46 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, David S. Miller, Linux-Renesas
In-Reply-To: <837a23c9-38d6-90af-ed0c-3ee2aaaa20f0@cogentembedded.com>
On Mon, Jul 23, 2018 at 8:10 PM Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> sh_eth_tsu_get_offset() is called several times by the driver, remove
> *inline* and move that function from the header to the driver itself
> to let gcc decide whether to expand it inline or not...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/5] sh_eth: make sh_eth_tsu_get_offset() match its name
From: Geert Uytterhoeven @ 2018-07-24 6:48 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, David S. Miller, Linux-Renesas
In-Reply-To: <ccec4eaa-89e8-76be-e5c2-874fcde0b223@cogentembedded.com>
On Mon, Jul 23, 2018 at 8:11 PM Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> sh_eth_tsu_get_offset(), despite its name, returns a TSU register's address,
> not its offset. Make this function match its name and return a register's
> offset from the TSU registers base address instead.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH net-next 3/4] net/tc: introduce TC_ACT_MIRRED.
From: Paolo Abeni @ 2018-07-24 6:48 UTC (permalink / raw)
To: Cong Wang
Cc: Jiri Pirko, Linux Kernel Network Developers, Jamal Hadi Salim,
Daniel Borkmann, Marcelo Ricardo Leitner, Eyal Birger
In-Reply-To: <CAM_iQpXEXkRdZAAne43FbnveqdFTu7ZZLXNMHLVE=JvgDYbY2A@mail.gmail.com>
Hi,
On Mon, 2018-07-23 at 14:12 -0700, Cong Wang wrote:
> On Fri, Jul 20, 2018 at 2:54 AM Paolo Abeni <pabeni@redhat.com> wrote:
> > Note this is what already happens with TC_ACT_REDIRECT: currently the
> > user space uses it freely, even if only {cls,act}_bpf can return such
> > value in a meaningful way, and only from the ingress and the egress
> > hooks.
>
> Yes, my question is why do we give user such a freedom?
>
> In other words, what do you want users to choose here? To scrub or not
> to scrub? To clone or not to clone?
>
> From my understanding of your whole patchset, your goal is to get rid
> of clone, and users definitely don't care about clone or not clone for
> redirections, this is why I insist it doesn't need to be visible to user.
Thank you for your kind reply!
No, my intention is not to expose to the user-space another option. I
added the additional tcfa_action value in response to concerns exposed
vs the v1 version of this series (it changed the act_mirred behaviour
and possibly broke some use-case).
When assembling the v2 I did not implemented the (deserved) isolation
vs user-space because of the already existing TC_ACT_REDIRECT: its
current implementation fooled me to think such considerations were not
relevant.
> If your goal is not just skipping clone, but also, let's say, scrub or not
> scrub, then it should be visible to users. However, I don't see why
> users care about scrub or not, they have to understand what scrub
> is at least, it is a purely kernel-internal behavior.
I agree to hide TC_ACT_REINJECT and any choice about scrubbing to user-
space, as per the code chunk I posted before. I'll send a v3
implementing such schema.
Cheers,
Paolo
^ permalink raw reply
* Re: [PATCH 3/5] sh_eth: call sh_eth_tsu_get_offset() from TSU register accessors
From: Geert Uytterhoeven @ 2018-07-24 6:49 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, David S. Miller, Linux-Renesas
In-Reply-To: <6a15eddc-a30d-a4e8-aa0d-05ee2091e32a@cogentembedded.com>
Hi Sergei,
On Mon, Jul 23, 2018 at 8:13 PM Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> With sh_eth_tsu_get_offset() now actually returning TSU register's offset,
> we can at last use it in sh_eth_tsu_{read|write}(). Somehow this saves 248
> bytes of object code with AArch64 gcc 4.8.5... :-)
Adding two more users may be the trigger for gcc not to inline the
function anymore?
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 4/5] sh_eth: make sh_eth_tsu_write_entry() take 'offset' parameter
From: Geert Uytterhoeven @ 2018-07-24 6:50 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, David S. Miller, Linux-Renesas
In-Reply-To: <1b60d8c8-e06f-6bff-df06-9b1cbe953340@cogentembedded.com>
On Mon, Jul 23, 2018 at 8:15 PM Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> We can add the TSU register base address to a TSU register offset right
> in sh_eth_tsu_write_entry(), no need to do it in its callers...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 5/5] sh_eth: make sh_eth_tsu_{read|write}_entry() prototypes symmetric
From: Geert Uytterhoeven @ 2018-07-24 6:52 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, David S. Miller, Linux-Renesas
In-Reply-To: <93618d2e-86b6-e467-b577-632a25cb2c4c@cogentembedded.com>
On Mon, Jul 23, 2018 at 8:16 PM Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> sh_eth_tsu_read_entry() is still asymmetric with sh_eth_tsu_write_entry()
> WRT their prototypes -- make them symmetric by passing to the former a TSU
> register offset instead of its address and also adding the (now necessary)
> 'ndev' parameter...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] ipvs: fix race between ip_vs_conn_new() and ip_vs_del_dest()
From: Tan Hu @ 2018-07-24 8:12 UTC (permalink / raw)
To: wensong, horms, ja, pablo, kadlec, fw, davem
Cc: netdev, lvs-devel, netfilter-devel, coreteam, linux-kernel,
zhong.weidong, jiang.biao2
We came across infinite loop in ipvs when using ipvs in docker
env.
When ipvs receives new packets and cannot find an ipvs connection,
it will create a new connection, then if the dest is unavailable
(i.e. IP_VS_DEST_F_AVAILABLE), the packet will be dropped sliently.
But if the dropped packet is the first packet of this connection,
the connection control timer never has a chance to start and the
ipvs connection cannot be released. This will lead to memory leak, or
infinite loop in cleanup_net() when net namespace is released like
this:
ip_vs_conn_net_cleanup at ffffffffa0a9f31a [ip_vs]
__ip_vs_cleanup at ffffffffa0a9f60a [ip_vs]
ops_exit_list at ffffffff81567a49
cleanup_net at ffffffff81568b40
process_one_work at ffffffff810a851b
worker_thread at ffffffff810a9356
kthread at ffffffff810b0b6f
ret_from_fork at ffffffff81697a18
race condition:
CPU1 CPU2
ip_vs_in()
ip_vs_conn_new()
ip_vs_del_dest()
__ip_vs_unlink_dest()
~IP_VS_DEST_F_AVAILABLE
cp->dest && !IP_VS_DEST_F_AVAILABLE
__ip_vs_conn_put
...
cleanup_net ---> infinite looping
Fix this by checking whether the timer already started.
Signed-off-by: Tan Hu <tan.hu@zte.com.cn>
Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
---
net/netfilter/ipvs/ip_vs_core.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 0679dd1..ca9e7cc 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -1972,13 +1972,17 @@ static int ip_vs_in_icmp_v6(struct netns_ipvs *ipvs, struct sk_buff *skb,
if (cp->dest && !(cp->dest->flags & IP_VS_DEST_F_AVAILABLE)) {
/* the destination server is not available */
+ /* when timer already started, silently drop the packet.*/
+ if (timer_pending(&cp->timer))
+ __ip_vs_conn_put(cp);
+ else
+ ip_vs_conn_put(cp);
+
if (sysctl_expire_nodest_conn(ipvs)) {
/* try to expire the connection immediately */
ip_vs_conn_expire_now(cp);
}
- /* don't restart its timer, and silently
- drop the packet. */
- __ip_vs_conn_put(cp);
+
return NF_DROP;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] qmi_wwan: fix interface number for DW5821e production firmware
From: Bjørn Mork @ 2018-07-24 8:16 UTC (permalink / raw)
To: Aleksander Morgado; +Cc: davem, netdev, linux-usb, stable
In-Reply-To: <20180723233107.15268-1-aleksander@aleksander.es>
On July 24, 2018 1:31:07 AM GMT+02:00, Aleksander Morgado <aleksander@aleksander.es> wrote:
>The original mapping for the DW5821e was done using a development
>version of the firmware. Confirmed with the vendor that the final
>USB layout ends up exposing the QMI control/data ports in USB
>config #1, interface #0, not in interface #1 (which is now a HID
>interface).
>
>T: Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 16 Spd=480 MxCh= 0
>D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 2
>P: Vendor=413c ProdID=81d7 Rev=03.18
>S: Manufacturer=DELL
>S: Product=DW5821e Snapdragon X20 LTE
>S: SerialNumber=0123456789ABCDEF
>C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
>I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
>I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
>I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
>I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
>I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
>I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
>
>Fixes: e7e197edd09c25 ("qmi_wwan: add support for the Dell Wireless
>5821e module")
>Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
>Cc: stable <stable@vger.kernel.org>
Acked-by: Bjørn Mork <bjorn@mork.no>
^ permalink raw reply
* Re: general protection fault in inet_accept
From: syzbot @ 2018-07-24 7:14 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
In-Reply-To: <0000000000006e1bbe0570bea62e@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: fd800f646402 wan/fsl_ucc_hdlc: use IS_ERR_VALUE() to check..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1579b51c400000
kernel config: https://syzkaller.appspot.com/x/.config?x=acf770f568ef945b
dashboard link: https://syzkaller.appspot.com/bug?extid=2e9616288940d15a6476
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=179e4d62400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10f7a978400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2e9616288940d15a6476@syzkaller.appspotmail.com
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
CPU: 1 PID: 5524 Comm: kworker/1:120 Not tainted 4.18.0-rc5+ #137
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events smc_tcp_listen_work
RIP: 0010:inet_accept+0xf2/0xa00 net/ipv4/af_inet.c:735
Code: 84 d2 74 09 80 fa 03 0f 8e 95 07 00 00 48 8d 78 28 41 c7 46 80 ea ff
ff ff 48 ba 00 00 00 00 00 fc ff df 48 89 f9 48 c1 e9 03 <80> 3c 11 00 0f
85 96 07 00 00 48 b9 00 00 00 00 00 fc ff df 48 8b
RSP: 0018:ffff8801ce71f4b0 EFLAGS: 00010206
RAX: 0000000000000000 RBX: dffffc0000000000 RCX: 0000000000000005
RDX: dffffc0000000000 RSI: ffffffff8677aa46 RDI: 0000000000000028
RBP: ffff8801ce71f598 R08: ffff8801ae2e8480 R09: ffffed0037e1236f
R10: ffffed0037e1236f R11: ffff8801bf091b7b R12: ffff8801bf091ac0
R13: ffff8801ce71f4f0 R14: ffff8801ce71f570 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200024c0 CR3: 0000000008e6a000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
kernel_accept+0x136/0x310 net/socket.c:3251
smc_clcsock_accept net/smc/af_smc.c:832 [inline]
smc_tcp_listen_work+0x222/0xef0 net/smc/af_smc.c:1296
process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
kthread+0x345/0x410 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace de997303bb6ff5f8 ]---
RIP: 0010:inet_accept+0xf2/0xa00 net/ipv4/af_inet.c:735
Code: 84 d2 74 09 80 fa 03 0f 8e 95 07 00 00 48 8d 78 28 41 c7 46 80 ea ff
ff ff 48 ba 00 00 00 00 00 fc ff df 48 89 f9 48 c1 e9 03 <80> 3c 11 00 0f
85 96 07 00 00 48 b9 00 00 00 00 00 fc ff df 48 8b
RSP: 0018:ffff8801ce71f4b0 EFLAGS: 00010206
RAX: 0000000000000000 RBX: dffffc0000000000 RCX: 0000000000000005
RDX: dffffc0000000000 RSI: ffffffff8677aa46 RDI: 0000000000000028
RBP: ffff8801ce71f598 R08: ffff8801ae2e8480 R09: ffffed0037e1236f
R10: ffffed0037e1236f R11: ffff8801bf091b7b R12: ffff8801bf091ac0
R13: ffff8801ce71f4f0 R14: ffff8801ce71f570 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200024c0 CR3: 0000000008e6a000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
^ permalink raw reply
* pull-request: mac80211 2018-07-24
From: Johannes Berg @ 2018-07-24 7:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
After a long delay (I'm still on vacation & bonding leave until
mid August and forgot), here are a few fixes for the current
release cycle.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit d0fbad0aec1df29717fab736eb24c8a49cf2c70b:
Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/shli/md (2018-07-02 12:40:59 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2018-07-24
for you to fetch changes up to e31f6456c01c76f154e1b25cd54df97809a49edb:
cfg80211: never ignore user regulatory hint (2018-07-24 09:11:31 +0200)
----------------------------------------------------------------
Only a few fixes:
* always keep regulatory user hint
* add missing break statement in station flags parsing
* fix non-linear SKBs in port-control-over-nl80211
* reconfigure VLAN stations during HW restart
----------------------------------------------------------------
Amar Singhal (1):
cfg80211: never ignore user regulatory hint
Bernd Edlinger (1):
nl80211: Add a missing break in parse_station_flags
Denis Kenzior (1):
nl80211/mac80211: allow non-linear skb in rx_control_port
mpubbise@codeaurora.org (1):
mac80211: add stations tied to AP_VLANs during hw reconfig
include/net/cfg80211.h | 12 ++++++------
net/mac80211/rx.c | 5 +----
net/mac80211/util.c | 3 ++-
net/wireless/nl80211.c | 25 ++++++++++++++++---------
net/wireless/reg.c | 28 +++-------------------------
net/wireless/trace.h | 18 ++++++++++--------
6 files changed, 38 insertions(+), 53 deletions(-)
^ permalink raw reply
* Re: pull-request: can 2018-07-23
From: Marc Kleine-Budde @ 2018-07-24 7:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kernel, linux-can
In-Reply-To: <20180723.110241.1700809256849434700.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 1174 bytes --]
On 07/23/2018 08:02 PM, David Miller wrote:
> From: Marc Kleine-Budde <mkl@pengutronix.de>
> Date: Mon, 23 Jul 2018 14:58:31 +0200
>
>> this is a pull request of 12 patches for net/master.
>>
>> The patch by Stephane Grosjean for the peak_canfd CAN driver fixes a problem
>> with older firmware. The next patch is by Roman Fietze and fixes the setup of
>> the CCCR register in the m_can driver. Nicholas Mc Guire's patch for the
>> mpc5xxx_can driver adds missing error checking. The two patches by Faiz Abbas
>> fix the runtime resume and clean up the probe function in the m_can driver. The
>> last 7 patches by Anssi Hannula fix several problem in the xilinx_can driver.
>
> Pulled, thanks Marc.
Thanks David. Can you please merge net into next-next, as I've some
patches for net-next that would result in a merge conflict between net
and net-next later.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] bnxt_en: Fix logic of forward the VF MAC address to PF in bnxt_vf_validate_set_mac
From: Michael Chan @ 2018-07-24 7:31 UTC (permalink / raw)
To: YueHaibing, Vasundhara Volam; +Cc: David Miller, open list, Netdev
In-Reply-To: <20180724052454.21524-1-yuehaibing@huawei.com>
On Mon, Jul 23, 2018 at 10:24 PM, YueHaibing <yuehaibing@huawei.com> wrote:
> Based on the comments,req->l2addr must match the VF MAC address
> if firmware spec >= 1.2.2, mac_ok can be true.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
> index a649108..7925964 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
> @@ -954,12 +954,9 @@ static int bnxt_vf_validate_set_mac(struct bnxt *bp, struct bnxt_vf_info *vf)
> if (ether_addr_equal((const u8 *)req->l2_addr, vf->mac_addr))
> mac_ok = true;
> } else if (is_valid_ether_addr(vf->vf_mac_addr)) {
> - if (ether_addr_equal((const u8 *)req->l2_addr, vf->vf_mac_addr))
> + if (ether_addr_equal((const u8 *)req->l2_addr, vf->vf_mac_addr) &&
> + bp->hwrm_spec_code >= 0x10202)
> mac_ok = true;
I'm not sure if this is correct. If firmware spec < 0x10202, the VF
MAC address is not forwarded to the PF and so it doesn't have to match
and mac_ok should still be true. I think we are missing that
condition with this patch.
I need to let my colleague Vasundhara comment on this. She is more
familiar with this logic.
> - } else if (bp->hwrm_spec_code < 0x10202) {
> - mac_ok = true;
> - } else {
> - mac_ok = true;
> }
> if (mac_ok)
> return bnxt_hwrm_exec_fwd_resp(bp, vf, msg_size);
> --
> 2.7.0
>
>
^ permalink raw reply
* [PATCH] netfilter: avoid stalls in nf_ct_alloc_hashtable
From: Li RongQing @ 2018-07-24 7:19 UTC (permalink / raw)
To: netdev, pablo, kadlec, fw
when system forks a process with CLONE_NEWNET flag under the
high memory pressure, it will trigger memory reclaim and stall
for a long time because nf_ct_alloc_hashtable need to allocate
high-order memory at that time. The calltrace as below:
delay_tsc
__delay
_raw_spin_lock
_spin_lock
mmu_shrink
shrink_slab
zone_reclaim
get_page_from_freelist
__alloc_pages_nodemask
alloc_pages_current
__get_free_pages
nf_ct_alloc_hashtable
nf_conntrack_init_net
setup_net
copy_net_ns
create_new_namespaces
copy_namespaces
copy_process
do_fork
sys_clone
stub_clone
__clone
not use the directly memory reclaim flag to avoid stall
Signed-off-by: Ni Xun <nixun@baidu.com>
Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
Signed-off-by: Wang Li <wangli39@baidu.com>
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/netfilter/nf_conntrack_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 8a113ca1eea2..672c5960530d 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -2120,8 +2120,8 @@ void *nf_ct_alloc_hashtable(unsigned int *sizep, int nulls)
return NULL;
sz = nr_slots * sizeof(struct hlist_nulls_head);
- hash = (void *)__get_free_pages(GFP_KERNEL | __GFP_NOWARN | __GFP_ZERO,
- get_order(sz));
+ hash = (void *)__get_free_pages((GFP_KERNEL & ~__GFP_DIRECT_RECLAIM) |
+ __GFP_NOWARN | __GFP_ZERO, get_order(sz));
if (!hash)
hash = vzalloc(sz);
--
2.16.2
^ permalink raw reply related
* Re: [PATCH 2/5] dt-bindings: sunxi-sram: add binding for Allwinner H6 SRAM C
From: Maxime Ripard @ 2018-07-24 8:41 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, David S. Miller, Corentin Labbe,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20180722053955.25266-3-icenowy-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]
On Sun, Jul 22, 2018 at 01:39:52PM +0800, Icenowy Zheng wrote:
> The Allwinner H6 SoC's DE3 needs the SRAM C section being claimed in the
> system controller to work, like A64 DE2.
>
> As H6 and A64 system controller are quite similar, code is reused now,
> and the A64 fallback compatible string is added after the H6 compatible
> string.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> Documentation/devicetree/bindings/sram/sunxi-sram.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/sram/sunxi-sram.txt b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
> index c51ade86578c..6527a1a535a3 100644
> --- a/Documentation/devicetree/bindings/sram/sunxi-sram.txt
> +++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
> @@ -18,6 +18,7 @@ Required properties:
> - "allwinner,sun8i-h3-system-control"
> - "allwinner,sun50i-a64-sram-controller" (deprecated)
> - "allwinner,sun50i-a64-system-control"
> + - "allwinner,sun50i-h6-system-contorl", "allwinner,sun50i-a64-system-control"
^ control
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* selftests: bpf: test_progs: deadlock at trace_call_bpf
From: Naresh Kamboju @ 2018-07-24 9:21 UTC (permalink / raw)
To: netdev, ast, Daniel Borkmann, rostedt
Cc: open list, open list:KERNEL SELFTEST FRAMEWORK
Deadlock warning on x86 machine while testing selftests: bpf:
test_progs and running linux next 4.18.0-rc3-next-20180705 and still
happening on 4.18.0-rc5-next-20180720.
Any one noticed this kernel warning about deadlock ?
selftests: bpf: test_progs
libbpf: incorrect bpf_call opcode
libbpf: incorrect bpf_call opcode
test_pkt_access:FAIL:ipv4 err 0 errno 2 retval 0 duration 126
test_pkt_access:FAIL:ipv6 err 0 errno 2 retval 0 duration 115
test_xdp:FAIL:ipv4 err 0 errno 2 retval 3 size 74
test_xdp:FAIL:ipv6 err 0 errno 2 retval 3 size 114
test_xdp_adjust_tail:FAIL:ipv4 err 0 errno 2 retval 1 size 54
test_xdp_adjust_tail:FAIL:ipv6 err 0 errno 2 retval 3 siz[ 69.901655]
[ 69.903862] ========================================================
[ 69.910213] WARNING: possible irq lock inversion dependency detected
[ 69.916559] 4.18.0-rc3-next-20180705 #1 Not tainted
[ 69.921428] --------------------------------------------------------
[ 69.927774] dd/2928 just changed the state of lock:
[ 69.932643] 0000000022eeb38d (&head->lock){+...}, at:
pcpu_freelist_push+0x28/0x50
[ 69.940208] but this lock was taken by another, HARDIRQ-safe lock
in the past:
[ 69.947420] (&rq->lock){-.-.}
[ 69.947421]
[ 69.947421]
[ 69.947421] and interrupts could create inverse lock ordering between them.
[ 69.947421]
[ 69.961842]
[ 69.961842] other info that might help us debug this:
[ 69.968357] Possible interrupt unsafe locking scenario:
[ 69.968357]
[ 69.975136] CPU0 CPU1
[ 69.979659] ---- ----
[ 69.984184] lock(&head->lock);
[ 69.987406] local_irq_disable();
[ 69.993319] lock(&rq->lock);
[ 69.998882] lock(&head->lock);
[ 70.004618] <Interrupt>
[ 70.007235] lock(&rq->lock);
[ 70.010461]
[ 70.010461] *** DEADLOCK ***
[ 70.010461]
[ 70.016372] 1 lock held by dd/2928:
[ 70.019856] #0: 00000000ab9293c8 (rcu_read_lock){....}, at:
trace_call_bpf+0x37/0x1d0
[ 70.027768]
[ 70.027768] the shortest dependencies between 2nd lock and 1st lock:
[ 70.035586] -> (&rq->lock){-.-.} ops: 1401365 {
[ 70.040204] IN-HARDIRQ-W at:
[ 70.043428] lock_acquire+0xd5/0x1c0
[ 70.048820] _raw_spin_lock+0x2f/0x40
[ 70.054299] scheduler_tick+0x51/0xf0
[ 70.059781] update_process_times+0x47/0x60
[ 70.065779] tick_periodic+0x2b/0xc0
[ 70.071171] tick_handle_periodic+0x25/0x70
[ 70.077168] timer_interrupt+0x15/0x20
[ 70.082731] __handle_irq_event_percpu+0x48/0x320
[ 70.089250] handle_irq_event_percpu+0x32/0x80
[ 70.095505] handle_irq_event+0x39/0x60
[ 70.101157] handle_level_irq+0x7f/0x100
[ 70.106893] handle_irq+0x6f/0x110
[ 70.112112] do_IRQ+0x5c/0x110
[ 70.116982] ret_from_intr+0x0/0x1d
[ 70.122286] _raw_spin_unlock_irqrestore+0x38/0x50
[ 70.128891] __setup_irq+0x45d/0x700
[ 70.134281] setup_irq+0x4c/0x90
[ 70.139324] hpet_time_init+0x25/0x37
[ 70.144803] x86_late_time_init+0xf/0x1c
[ 70.150538] start_kernel+0x40c/0x4ca
[ 70.156017] x86_64_start_reservations+0x24/0x26
[ 70.162445] x86_64_start_kernel+0x6f/0x72
[ 70.168357] secondary_startup_64+0xa4/0xb0
[ 70.174356] IN-SOFTIRQ-W at:
[ 70.177578] lock_acquire+0xd5/0x1c0
[ 70.182970] _raw_spin_lock+0x2f/0x40
[ 70.188448] try_to_wake_up+0x31b/0x540
[ 70.194097] wake_up_process+0x15/0x20
[ 70.199661] swake_up_locked+0x24/0x40
[ 70.205226] swake_up_one+0x1f/0x30
[ 70.210530] rcu_gp_kthread_wake+0x3b/0x40
[ 70.216441] rcu_accelerate_cbs_unlocked+0x9c/0xe0
[ 70.223048] rcu_process_callbacks+0x111/0x10c0
[ 70.229396] __do_softirq+0xbf/0x493
[ 70.234788] irq_exit+0xc3/0xd0
[ 70.239743] smp_apic_timer_interrupt+0x93/0x2a0
[ 70.246176] apic_timer_interrupt+0xf/0x20
[ 70.252084] console_unlock+0x4e8/0x620
[ 70.257737] vprintk_emit+0x254/0x430
[ 70.263214] vprintk_default+0x1f/0x30
[ 70.268776] vprintk_func+0x27/0x60
[ 70.274082] printk+0x52/0x6e
[ 70.278864] native_cpu_up+0x71b/0x7a0
[ 70.284431] bringup_cpu+0x2a/0xb0
[ 70.289648] cpuhp_invoke_callback+0xb2/0xb20
[ 70.295818] _cpu_up+0xae/0x160
[ 70.300776] do_cpu_up+0x8d/0xb0
[ 70.305818] cpu_up+0x13/0x20
[ 70.310602] smp_init+0x67/0xc4
[ 70.315559] kernel_init_freeable+0x134/0x259
[ 70.321731] kernel_init+0xe/0x110
[ 70.326947] ret_from_fork+0x3a/0x50
[ 70.332339] INITIAL USE at:
[ 70.335477] lock_acquire+0xd5/0x1c0
[ 70.340780] _raw_spin_lock_irqsave+0x3a/0x50
[ 70.346864] rq_attach_root+0x1b/0xc0
[ 70.352255] sched_init+0x310/0x432
[ 70.357472] start_kernel+0x26e/0x4ca
[ 70.362861] x86_64_start_reservations+0x24/0x26
[ 70.369207] x86_64_start_kernel+0x6f/0x72
[ 70.375048] secondary_startup_64+0xa4/0xb0
[ 70.380958] }
[ 70.382710] ... key at: [<ffffffff8716faf8>] __key.69482+0x0/0x8
[ 70.389310] ... acquired at:
[ 70.392364] _raw_spin_lock+0x2f/0x40
[ 70.396192] pcpu_freelist_pop+0x7a/0xd0
[ 70.400286] bpf_get_stackid+0x1ca/0x470
[ 70.404383] bpf_get_stackid_tp+0x11/0x20
[ 70.408559] ___bpf_prog_run+0x7f2/0x1090
[ 70.412739] __bpf_prog_run32+0x39/0x50
[ 70.416742] trace_call_bpf+0xc8/0x1d0
[ 70.420659] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.425444] perf_trace_sched_switch+0x116/0x190
[ 70.430227] __schedule+0x6d8/0xa20
[ 70.433883] schedule+0x3d/0x90
[ 70.437194] worker_thread+0xd0/0x410
[ 70.441025] kthread+0x10d/0x140
[ 70.444424] ret_from_fork+0x3a/0x50
[ 70.448165]
[ 70.449658] -> (&head->lock){+...} ops: 61660 {
[ 70.454181] HARDIRQ-ON-W at:
[ 70.457319] lock_acquire+0xd5/0x1c0
[ 70.462536] _raw_spin_lock+0x2f/0x40
[ 70.467841] pcpu_freelist_push+0x28/0x50
[ 70.473492] bpf_get_stackid+0x43a/0x470
[ 70.479054] bpf_get_stackid_tp+0x11/0x20
[ 70.484724] ___bpf_prog_run+0x7f2/0x1090
[ 70.490372] __bpf_prog_run32+0x39/0x50
[ 70.495852] trace_call_bpf+0xc8/0x1d0
[ 70.501243] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.507500] perf_trace_urandom_read+0xbf/0x100
[ 70.513670] urandom_read+0x1ce/0x340
[ 70.518975] __vfs_read+0x37/0x160
[ 70.524027] vfs_read+0xa8/0x150
[ 70.528898] ksys_read+0x58/0xc0
[ 70.533766] __x64_sys_read+0x1a/0x20
[ 70.539092] do_syscall_64+0x4f/0x190
[ 70.544401] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.551092] INITIAL USE at:
[ 70.554143] lock_acquire+0xd5/0x1c0
[ 70.559272] _raw_spin_lock+0x2f/0x40
[ 70.564491] pcpu_freelist_populate+0xb6/0x110
[ 70.570489] htab_map_alloc+0x3b6/0x4c0
[ 70.575878] map_create+0xf0/0x370
[ 70.580836] __x64_sys_bpf+0x10b/0x260
[ 70.586138] do_syscall_64+0x4f/0x190
[ 70.591356] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.597960] }
[ 70.599624] ... key at: [<ffffffff87d4c5a0>] __key.11024+0x0/0x8
[ 70.606142] ... acquired at:
[ 70.609104] mark_lock+0x392/0x570
[ 70.612676] __lock_acquire+0x5cd/0x13c0
[ 70.616767] lock_acquire+0xd5/0x1c0
[ 70.620511] _raw_spin_lock+0x2f/0x40
[ 70.624342] pcpu_freelist_push+0x28/0x50
[ 70.628519] bpf_get_stackid+0x43a/0x470
[ 70.632610] bpf_get_stackid_tp+0x11/0x20
[ 70.636785] ___bpf_prog_run+0x7f2/0x1090
[ 70.640965] __bpf_prog_run32+0x39/0x50
[ 70.644969] trace_call_bpf+0xc8/0x1d0
[ 70.648886] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.653668] perf_trace_urandom_read+0xbf/0x100
[ 70.658366] urandom_read+0x1ce/0x340
[ 70.662199] __vfs_read+0x37/0x160
[ 70.665768] vfs_read+0xa8/0x150
[ 70.669166] ksys_read+0x58/0xc0
[ 70.672562] __x64_sys_read+0x1a/0x20
[ 70.676393] do_syscall_64+0x4f/0x190
[ 70.680223] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.685440]
[ 70.686933]
[ 70.686933] stack backtrace:
[ 70.691283] CPU: 3 PID: 2928 Comm: dd Not tainted 4.18.0-rc3-next-20180705 #1
[ 70.698405] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[ 70.705875] Call Trace:
[ 70.708321] dump_stack+0x68/0x95
[ 70.711631] print_irq_inversion_bug.part.41+0x1a5/0x1b1
[ 70.716935] check_usage_backwards+0x14b/0x160
[ 70.721374] mark_lock+0x392/0x570
[ 70.724771] ? mark_lock+0x392/0x570
[ 70.728340] ? print_shortest_lock_dependencies+0x1a0/0x1a0
[ 70.733904] __lock_acquire+0x5cd/0x13c0
[ 70.737823] ? find_get_entry+0x1a2/0x2f0
[ 70.741825] lock_acquire+0xd5/0x1c0
[ 70.745397] ? lock_acquire+0xd5/0x1c0
[ 70.749141] ? pcpu_freelist_push+0x28/0x50
[ 70.753317] _raw_spin_lock+0x2f/0x40
[ 70.756974] ? pcpu_freelist_push+0x28/0x50
[ 70.761153] pcpu_freelist_push+0x28/0x50
[ 70.765156] bpf_get_stackid+0x43a/0x470
[ 70.769073] bpf_get_stackid_tp+0x11/0x20
[ 70.773077] ___bpf_prog_run+0x7f2/0x1090
[ 70.777083] __bpf_prog_run32+0x39/0x50
[ 70.780912] ? lock_acquire+0xd5/0x1c0
[ 70.784656] trace_call_bpf+0xc8/0x1d0
[ 70.788399] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.793013] perf_trace_urandom_read+0xbf/0x100
[ 70.797544] urandom_read+0x1ce/0x340
[ 70.801202] __vfs_read+0x37/0x160
[ 70.804598] ? security_file_permission+0x8d/0xb0
[ 70.809297] ? security_file_permission+0x8d/0xb0
[ 70.813993] vfs_read+0xa8/0x150
[ 70.817218] ksys_read+0x58/0xc0
[ 70.820442] __x64_sys_read+0x1a/0x20
[ 70.824106] do_syscall_64+0x4f/0x190
[ 70.827764] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.832807] RIP: 0033:0x7f302526f160
[ 70.836378] Code: b6 fe ff ff 48 8d 3d 97 b1 08 00 48 83 ec 08 e8
66 d3 01 00 66 0f 1f 44 00 00 83 3d e9 15 2c 00 00 75 10 b8 00 00 00
00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 7e 94 01 00 48 89
04 24
[ 70.855253] RSP: 002b:00007fff096fd4e8 EFLAGS: 00000246 ORIG_RAX:
0000000000000000
[ 70.862812] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f302526f160
[ 70.869935] RDX: 0000000000000200 RSI: 000000000070f000 RDI: 0000000000000000
[ 70.877060] RBP: 0000000000000200 R08: 000000000070f000 R09: 0000000000711060
[ 70.884183] R10: 0000000000000871 R11: 0000000000000246 R12: 000000000070f000
[ 70.891306] R13: 0000000000000000 R14: 0000000000000200 R15: 0000000000000000
e 54
test_l4lb:FAIL:ipv4 err 0 errno 2 retval 7 size 54 magic 1234
Full kernel selftest test log,
https://lkft.validation.linaro.org/scheduler/job/314724#L2142
Best regards
Naresh Kamboju
^ permalink raw reply
* Copy of: [Shared Post]netdev@vger.kernel.org
From: Midwest Insurance Brokerage @ 2018-07-24 8:01 UTC (permalink / raw)
To: netdev
Copy of:
This is an enquiry e-mail via http://www.mibltd.com/ from:
niushenjia <netdev@vger.kernel.org>
汇聚全球精彩赛事。皇冠/沙巴/波音/欧冠/应有尽有。半场结算，实时返水1%。WWW.2220162.COM
------------------
太学儒生东鲁客，二十辞家来射策。夜书细字缀语言，
^ permalink raw reply
* RE: [net-next v5 3/3] net/tls: Remove redundant array allocation.
From: Vakul Garg @ 2018-07-24 8:22 UTC (permalink / raw)
To: Dave Watson, David Miller
Cc: netdev@vger.kernel.org, borisp@mellanox.com, aviadye@mellanox.com,
Doron Roberts-Kedes
In-Reply-To: <20180723163509.GA91424@davejwatson-mba.local>
> -----Original Message-----
> From: Dave Watson [mailto:davejwatson@fb.com]
> Sent: Monday, July 23, 2018 10:05 PM
> To: David Miller <davem@davemloft.net>
> Cc: Vakul Garg <vakul.garg@nxp.com>; netdev@vger.kernel.org;
> borisp@mellanox.com; aviadye@mellanox.com; Doron Roberts-Kedes
> <doronrk@fb.com>
> Subject: Re: [net-next v5 3/3] net/tls: Remove redundant array allocation.
>
> On 07/21/18 07:25 PM, David Miller wrote:
> > From: Vakul Garg <vakul.garg@nxp.com>
> > Date: Thu, 19 Jul 2018 21:56:13 +0530
> >
> > > In function decrypt_skb(), array allocation in case when sgout is
> > > NULL is unnecessary. Instead, local variable sgin_arr[] can be used.
> > >
> > > Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
> >
> > Hmmm...
> >
> > Dave, can you take a look at this? Do you think there might have been
> > a reason you felt that you needed to dynamically allocate the
> > scatterlists when you COW and skb and do in-place decryption?
> >
> > I guess this change is ok, nsg can only get smaller when the SKB is
> > COW'd.
> >
>
> > > memcpy(iv, tls_ctx->rx.iv, TLS_CIPHER_AES_GCM_128_SALT_SIZE);
> > > if (!sgout) {
> > > nsg = skb_cow_data(skb, 0, &unused) + 1;
> > > - sgin = kmalloc_array(nsg, sizeof(*sgin), sk->sk_allocation);
> > > sgout = sgin;
> > > }
>
> I don't think this patch is safe as-is. sgin_arr is a stack array of size
> MAX_SKB_FRAGS (+ overhead), while my read of skb_cow_data is that it
> walks the whole chain of skbs from skb->next, and can return any number of
> segments. Therefore we need to heap allocate. I think I copied the IPSEC
> code here.
>
> For perf though, we could use the stack array if skb_cow_data returns <=
> MAX_SKB_FRAGS.
>
> This code is slightly confusing though, since we don't heap allocate in the
> zerocopy case - what happens is that skb_to_sgvec returns -EMSGSIZE, and
> we fall back to the non-zerocopy case, and return again to this function,
> where we then hit the skb_cow_data path and heap allocate.
Thanks for explaining.
I am missing the point why MAX_SKB_FRAGS sized local array
sgin has been used in tls_sw_recvmsg(). What is special about MAX_SKB_FRAGS so
that we used it as a size factor for 'sgin'?
Will it be a bad idea to get rid of array 'sgin' on stack and simply kmalloc 'sgin' for
whatever the number the number of pages returned by iov_iter_npages()?
We can allocate for sgout too with the same kmalloc().
(Using a local array based 'sgin' is coming in the way to achieve sending multiple async
record decryption requests to the accelerator without waiting for previous one to complete.)
^ permalink raw reply
* Re: [PATCH net-next] net: remove redundant input checks in SIOCSIFTXQLEN case of dev_ifsioc
From: Tariq Toukan @ 2018-07-24 8:35 UTC (permalink / raw)
To: David Miller, xiyou.wangcong; +Cc: tariqt, netdev, eranbe
In-Reply-To: <20180723.140025.949946162106654052.davem@davemloft.net>
On 24/07/2018 12:00 AM, David Miller wrote:
> From: Cong Wang <xiyou.wangcong@gmail.com>
> Date: Mon, 23 Jul 2018 13:37:22 -0700
>
>> On Sun, Jul 22, 2018 at 12:29 AM Tariq Toukan <tariqt@mellanox.com> wrote:
>>>
>>>
>>>
>>> On 19/07/2018 8:21 PM, Cong Wang wrote:
>>>> On Thu, Jul 19, 2018 at 7:50 AM Tariq Toukan <tariqt@mellanox.com> wrote:
>>>>> --- a/net/core/dev_ioctl.c
>>>>> +++ b/net/core/dev_ioctl.c
>>>>> @@ -282,14 +282,7 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
>>>>> return dev_mc_del_global(dev, ifr->ifr_hwaddr.sa_data);
>>>>>
>>>>> case SIOCSIFTXQLEN:
>>>>> - if (ifr->ifr_qlen < 0)
>>>>> - return -EINVAL;
>>>>
>>>> Are you sure we can remove this if check too?
>>>>
>>>> The other one is safe to remove.
>>>>
>>>
>>> Hmm, let's see:
>>> dev_change_tx_queue_len gets unsigned long new_len, any negative value
>>> passed is interpreted as a very large number, then we test:
>>> if (new_len != (unsigned int)new_len)
>>>
>>> This test returns true if range of unsigned long is larger than range of
>>> unsigned int. AFAIK these ranges are Arch dependent and there is no
>>> guarantee this holds.
>>
>> I am not sure either, you probably have to give it a test.
>> And at least, explain it in changelog if you still want to remove it.
>
> On 64-bit we will fail with -ERANGE. The 32-bit int ifr_qlen will be sign
> extended to 64-bits when it is passed into dev_change_tx_queue_len(). And
> then for negative values this test triggers:
>
> if (new_len != (unsigned int)new_len)
> return -ERANGE;
>
> because:
> if (0xffffffffWHATEVER != 0x00000000WHATEVER)
>
> On 32-bit the signed value will be accepted, changing behavior.
>
> I think, therefore, that the < 0 check should be retained.
Agree.
I am sending a re-spin.
>
> Thank you.
>
^ permalink raw reply
* Re: [PATCH] net/p9/trans_fd.c: fix double list_del()
From: Tomas Bortoli @ 2018-07-24 10:04 UTC (permalink / raw)
To: jiangyiwen, ericvh, rminnich, lucho
Cc: asmadeus, davem, v9fs-developer, netdev, linux-kernel, syzkaller
In-Reply-To: <5B568374.9010507@huawei.com>
On 07/24/2018 03:40 AM, jiangyiwen wrote:
> On 2018/7/23 20:19, Tomas Bortoli wrote:
>> A double list_del(&req->req_list) is possible in p9_fd_cancel() as
>> shown by Syzbot. To prevent it we have to ensure that we have the
>> client->lock when deleting the list. Furthermore, we have to update
>> the status of the request before releasing the lock, to prevent the
>> race.
>>
>> Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
>> Reported-by: syzbot+735d926e9d1317c3310c@syzkaller.appspotmail.com
>> ---
>> net/9p/trans_fd.c | 9 ++++-----
>> 1 file changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
>> index a64b01c56e30..370c6c69a05c 100644
>> --- a/net/9p/trans_fd.c
>> +++ b/net/9p/trans_fd.c
>> @@ -199,15 +199,14 @@ static void p9_mux_poll_stop(struct p9_conn *m)
>> static void p9_conn_cancel(struct p9_conn *m, int err)
>> {
>> struct p9_req_t *req, *rtmp;
>> - unsigned long flags;
>> LIST_HEAD(cancel_list);
>>
>> p9_debug(P9_DEBUG_ERROR, "mux %p err %d\n", m, err);
>>
>> - spin_lock_irqsave(&m->client->lock, flags);
>> + spin_lock(&m->client->lock);
>>
>> if (m->err) {
>> - spin_unlock_irqrestore(&m->client->lock, flags);
>> + spin_unlock(&m->client->lock);
>> return;
>> }
>>
>> @@ -219,7 +218,6 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
>> list_for_each_entry_safe(req, rtmp, &m->unsent_req_list, req_list) {
>> list_move(&req->req_list, &cancel_list);
>> }
>> - spin_unlock_irqrestore(&m->client->lock, flags);
>>
>> list_for_each_entry_safe(req, rtmp, &cancel_list, req_list) {
>> p9_debug(P9_DEBUG_ERROR, "call back req %p\n", req);
>> @@ -228,6 +226,7 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
>> req->t_err = err;
>> p9_client_cb(m->client, req, REQ_STATUS_ERROR);
>> }
>> + spin_unlock(&m->client->lock);
>
> If you want to expand the ranges of client->lock, the cancel_list will not
> be necessary, you can optimize this code.
>
Unfortunately, not. Moving the spin_lock() before the for makes the
crash appear again. This because the calls to list_move() in the for
before delete all the elements from req->req_list, so the list is empty,
another call to list_del() would trigger a double del.
That's why we hold the lock to update the status of all those requests..
otherwise we have again the race with p9_fd_cancel().
Crash log at the bottom.
> Thanks,
> Yiwen.
>
>> }
>>
>> static __poll_t
>> @@ -370,12 +369,12 @@ static void p9_read_work(struct work_struct *work)
>> if (m->req->status != REQ_STATUS_ERROR)
>> status = REQ_STATUS_RCVD;
>> list_del(&m->req->req_list);
>> - spin_unlock(&m->client->lock);
>> p9_client_cb(m->client, m->req, status);
>> m->rc.sdata = NULL;
>> m->rc.offset = 0;
>> m->rc.capacity = 0;
>> m->req = NULL;
>> + spin_unlock(&m->client->lock);
>> }
>>
>> end_clear:
>>
>
>
Crash:
syzkaller login: [ 55.691138] list_del corruption,
ffff88004de337a8->next is LIST_POISON1 (dead000000000100)
[ 55.693058] ------------[ cut here ]------------
[ 55.693910] kernel BUG at lib/list_debug.c:47!
[ 55.695060] invalid opcode: 0000 [#1] SMP KASAN
[ 55.696008] CPU: 1 PID: 9500 Comm: repro1 Not tainted 4.18.0-rc4+ #260
[ 55.696027] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.10.2-1 04/01/2014
[ 55.696027] RIP: 0010:__list_del_entry_valid+0xd3/0x150
[ 55.696027] Code: 00 00 00 49 8b 54 24 08 48 39 f2 75 3b 48 83 c4 08
b8 01 00 00 00 5b 41 5c 5d c3 4c 89 e2 48 c7 c7 80 06 b8 87 e8 21 c6 1d
fe <0f> 0b 48 c7 c7 e0 06 b8 87 e8 13 c6 1d fe 0f 0b 48 c7 c7 40 07 b8
[ 55.696027] RSP: 0018:ffff88004de2f198 EFLAGS: 00010282
[ 55.696027] RAX: 000000000000004e RBX: dead000000000200 RCX:
ffffffff815efe0e
[ 55.696027] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
ffff88006c9265ac
[ 55.696027] RBP: ffff88004de2f1b0 R08: ffffed000d924fc1 R09:
0000000000000001
[ 55.696027] R10: ffffed000cdc94e8 R11: ffff88006c927e07 R12:
dead000000000100
[ 55.696027] R13: ffff880066e4a740 R14: ffff88004de337a8 R15:
ffff88004de2f240
[ 55.696027] FS: 00007efc61d2e700(0000) GS:ffff88006c900000(0000)
knlGS:0000000000000000
[ 55.696027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 55.696027] CR2: 00007efc613ab330 CR3: 000000005e86f000 CR4:
00000000000006e0
[ 55.696027] Call Trace:
[ 55.696027] ? _raw_spin_lock+0x32/0x40
[ 55.696027] p9_fd_cancel+0xf3/0x390
[ 55.696027] ? p9_fd_request+0x238/0x3e0
[ 55.696027] ? p9_fd_close+0x5a0/0x5a0
[ 55.696027] p9_client_rpc+0xacf/0x11b0
[ 55.696027] ? p9_client_prepare_req.part.11+0xd20/0xd20
[ 55.696027] ? __fget+0x378/0x5a0
[ 55.696027] ? iterate_fd+0x400/0x400
[ 55.696027] ? finish_wait+0x4b0/0x4b0
[ 55.696027] ? rcu_read_lock_sched_held+0x108/0x120
[ 55.696027] ? p9_fd_cancel+0x390/0x390
[ 55.696027] p9_client_create+0xa33/0x1600
[ 55.696027] ? v9fs_drop_inode+0x100/0x140
[ 55.696027] ? p9_client_read+0xbe0/0xbe0
[ 55.724517] ? __sched_text_start+0x8/0x8
[ 55.724517] ? find_held_lock+0x35/0x1d0
[ 55.724517] ? __lockdep_init_map+0xe4/0x650
[ 55.724517] ? lockdep_init_map+0x9/0x10
[ 55.724517] ? kasan_check_write+0x14/0x20
[ 55.724517] ? __init_rwsem+0x1ce/0x2b0
[ 55.724517] ? do_raw_write_unlock+0x2a0/0x2a0
[ 55.724517] ? rcu_read_lock_sched_held+0x108/0x120
[ 55.724517] ? __kmalloc_track_caller+0x49f/0x760
[ 55.724517] ? save_stack+0xa3/0xd0
[ 55.724517] v9fs_session_init+0x218/0x1980
[ 55.724517] ? v9fs_session_init+0x218/0x1980
[ 55.724517] ? v9fs_show_options+0x740/0x740
[ 55.724517] ? kasan_check_read+0x11/0x20
[ 55.724517] ? rcu_is_watching+0x8c/0x150
[ 55.724517] ? rcu_pm_notify+0xc0/0xc0
[ 55.736879] ? v9fs_mount+0x62/0x880
[ 55.736879] ? rcu_read_lock_sched_held+0x108/0x120
[ 55.738600] ? kmem_cache_alloc_trace+0x48d/0x740
[ 55.738600] v9fs_mount+0x81/0x880
[ 55.738600] ? v9fs_mount+0x81/0x880
[ 55.738600] mount_fs+0x66/0x2f0
[ 55.738600] vfs_kern_mount.part.26+0xcc/0x4a0
[ 55.738600] ? may_umount+0xa0/0xa0
[ 55.738600] ? _raw_read_unlock+0x22/0x30
[ 55.738600] ? __get_fs_type+0x8a/0xc0
[ 55.738600] do_mount+0xd86/0x2e90
[ 55.738600] ? kasan_check_read+0x11/0x20
[ 55.738600] ? do_raw_spin_unlock+0xa7/0x330
[ 55.738600] ? copy_mount_string+0x40/0x40
[ 55.738600] ? copy_mount_options+0x5f/0x2e0
[ 55.738600] ? rcu_read_lock_sched_held+0x108/0x120
[ 55.738600] ? kmem_cache_alloc_trace+0x48d/0x740
[ 55.738600] ? copy_mount_options+0x1f7/0x2e0
[ 55.738600] ksys_mount+0xab/0x120
[ 55.738600] __x64_sys_mount+0xbe/0x150
[ 55.738600] ? trace_hardirqs_on_caller+0x421/0x5c0
[ 55.738600] do_syscall_64+0x18c/0x760
[ 55.738600] ? finish_task_switch+0x186/0x9f0
[ 55.738600] ? syscall_return_slowpath+0x560/0x560
[ 55.738600] ? syscall_return_slowpath+0x2b0/0x560
[ 55.738600] ? __switch_to_asm+0x34/0x70
[ 55.738600] ? prepare_exit_to_usermode+0x360/0x360
[ 55.738600] ? __switch_to_asm+0x34/0x70
[ 55.738600] ? entry_SYSCALL_64_after_hwframe+0x59/0xbe
[ 55.738600] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 55.738600] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 55.738600] RIP: 0033:0x7efc61442b79
[ 55.763914] Code: f3 fa ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90
48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f
05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8f c2 2a 00 31 d2 48 29 c2 64
[ 55.763914] RSP: 002b:00007efc61d2de88 EFLAGS: 00000246 ORIG_RAX:
00000000000000a5
[ 55.763914] RAX: ffffffffffffffda RBX: 0000000000000000 RCX:
00007efc61442b79
[ 55.769909] RDX: 0000000020000380 RSI: 0000000020000000 RDI:
0000000000000000
[ 55.769909] RBP: 00007efc61d2deb0 R08: 0000000020000240 R09:
00007efc61d2e9c0
[ 55.769909] R10: 0000000000000000 R11: 0000000000000246 R12:
00007ffd68da6aa0
[ 55.773854] R13: 00007efc61d2e9c0 R14: 00007efc61d39040 R15:
0000000000000003
[ 55.773854] Modules linked in:
[ 55.776650] ---[ end trace 8de8057bee332983 ]---
[ 55.777631] RIP: 0010:__list_del_entry_valid+0xd3/0x150
[ 55.778754] Code: 00 00 00 49 8b 54 24 08 48 39 f2 75 3b 48 83 c4 08
b8 01 00 00 00 5b 41 5c 5d c3 4c 89 e2 48 c7 c7 80 06 b8 87 e8 21 c6 1d
fe <0f> 0b 48 c7 c7 e0 06 b8 87 e8 13 c6 1d fe 0f 0b 48 c7 c7 40 07 b8
[ 55.782685] RSP: 0018:ffff88004de2f198 EFLAGS: 00010282
[ 55.783785] RAX: 000000000000004e RBX: dead000000000200 RCX:
ffffffff815efe0e
[ 55.785126] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
ffff88006c9265ac
[ 55.786470] RBP: ffff88004de2f1b0 R08: ffffed000d924fc1 R09:
0000000000000001
[ 55.788007] R10: ffffed000cdc94e8 R11: ffff88006c927e07 R12:
dead000000000100
[ 55.789517] R13: ffff880066e4a740 R14: ffff88004de337a8 R15:
ffff88004de2f240
[ 55.791173] FS: 00007efc61d2e700(0000) GS:ffff88006c900000(0000)
knlGS:0000000000000000
[ 55.792746] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 55.793882] CR2: 00007efc613ab330 CR3: 000000005e86f000 CR4:
00000000000006e0
[ 55.795410] Kernel panic - not syncing: Fatal exception
[ 55.796384] Kernel Offset: disabled
[ 55.796384] Rebooting in 86400 seconds..
^ permalink raw reply
* Re: [PATCH] mwifiex: Fix skipped vendor specific IEs
From: Sergei Shtylyov @ 2018-07-24 9:07 UTC (permalink / raw)
To: roman.stratiienko, akarwar
Cc: nishants, kvalo, linux-wireless, netdev, linux-kernel
In-Reply-To: <1532352699-3232-1-git-send-email-roman.stratiienko@globallogic.com>
Hello!
On 7/23/2018 4:31 PM, roman.stratiienko@globallogic.com wrote:
> From: Roman Stratiienko <roman.stratiienko@globallogic.com>
>
> Only microsoft specific IE is added by FW
> Let other IEs to pass from userspace
"To" not needed here.
>
> Signed-off-by: Roman Stratiienko <roman.stratiienko@globallogic.com>
> ---
> drivers/net/wireless/marvell/mwifiex/ie.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/ie.c b/drivers/net/wireless/marvell/mwifiex/ie.c
> index c488c30..c58b345 100644
> --- a/drivers/net/wireless/marvell/mwifiex/ie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/ie.c
> @@ -353,8 +353,16 @@ static int mwifiex_uap_parse_tail_ies(struct mwifiex_private *priv,
> case WLAN_EID_HT_OPERATION:
> case WLAN_EID_VHT_CAPABILITY:
> case WLAN_EID_VHT_OPERATION:
> - case WLAN_EID_VENDOR_SPECIFIC:
> break;
> + case WLAN_EID_VENDOR_SPECIFIC:
> + /* Skip only Microsoft IE that added by FW
^^^^
That's?
> + * Let other vendor specific IE to pass
"To" not needed here as well...
[...]
MBR, Sergei
^ 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