Re: 回复：general protection fault in ath9k_wmi_event_tasklet

Kalle Valo writes: > Toke Høiland-Jørgensen writes: > >> "Ubisectech Sirius" writes: >> >>>>Hmm, so from eyeballing the code in question, this looks like it is >>>>another initialisation race along the lines of the one fixed in commit: >&g

Re: 回复：general protection fault in ath9k_wmi_event_tasklet

"Ubisectech Sirius" writes: >>Hmm, so from eyeballing the code in question, this looks like it is >>another initialisation race along the lines of the one fixed in commit: >>8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at >>ath9k_htc_tx_get_packet()") >>Could you please test the patch

Re: general protection fault in ath9k_wmi_event_tasklet

"Ubisectech Sirius" writes: > Hello. > We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. > Recently, our team has discovered a issue in Linux kernel > 6.7.0-g9d1694dc91ce. Attached to the email were a POC file of the issue. > Stack dump: > general protection fault,

Re: [PATCH bpf-next v2 3/4] libbpf: add low level TC-BPF API

Daniel Borkmann writes: > On 4/19/21 2:18 PM, Kumar Kartikeya Dwivedi wrote: >> This adds functions that wrap the netlink API used for adding, >> manipulating, and removing traffic control filters. These functions >> operate directly on the loaded prog's fd, and return a handle to the >> filter

Re: [PATCH bpf-next 3/5] libbpf: add low level TC-BPF API

gt;>>> On 4/15/21 1:19 AM, Andrii Nakryiko wrote: >>>>>> On Wed, Apr 14, 2021 at 3:51 PM Toke Høiland-Jørgensen >>>>>> wrote: >>>>>>> Andrii Nakryiko writes: >>>>>>>> On Wed, Apr 14, 2021 at 3:58 AM To

Re: [PATCH bpf-next 3/5] libbpf: add low level TC-BPF API

Andrii Nakryiko writes: > On Wed, Apr 14, 2021 at 3:51 PM Toke Høiland-Jørgensen > wrote: >> >> Andrii Nakryiko writes: >> >> > On Wed, Apr 14, 2021 at 3:58 AM Toke Høiland-Jørgensen >> > wrote: >> >> >> >> Andrii Nakryiko

Re: [PATCH bpf-next 3/5] libbpf: add low level TC-BPF API

Andrii Nakryiko writes: > On Wed, Apr 14, 2021 at 3:58 AM Toke Høiland-Jørgensen > wrote: >> >> Andrii Nakryiko writes: >> >> > On Tue, Apr 6, 2021 at 3:06 AM Toke Høiland-Jørgensen >> > wrote: >> >> >> >> Andrii Nakr

Re: [PATCH bpf-next 3/5] libbpf: add low level TC-BPF API

Andrii Nakryiko writes: > On Tue, Apr 6, 2021 at 3:06 AM Toke Høiland-Jørgensen wrote: >> >> Andrii Nakryiko writes: >> >> > On Sat, Apr 3, 2021 at 10:47 AM Alexei Starovoitov >> > wrote: >> >> >> >> On Sat, Apr 03, 2021 at 12:38

Re: [PATCH bpf-next 3/5] libbpf: add low level TC-BPF API

Andrii Nakryiko writes: > On Sat, Apr 3, 2021 at 10:47 AM Alexei Starovoitov > wrote: >> >> On Sat, Apr 03, 2021 at 12:38:06AM +0530, Kumar Kartikeya Dwivedi wrote: >> > On Sat, Apr 03, 2021 at 12:02:14AM IST, Alexei Starovoitov wrote: >> > > On Fri, Apr 2, 2021 at 8:27 AM Kumar Kartikeya

Re: [PATCH bpf-next 3/5] libbpf: add low level TC-BPF API

Daniel Borkmann writes: > On 3/30/21 10:39 PM, Andrii Nakryiko wrote: >> On Sun, Mar 28, 2021 at 1:11 AM Kumar Kartikeya Dwivedi >> wrote: >>> On Sun, Mar 28, 2021 at 10:12:40AM IST, Andrii Nakryiko wrote: Is there some succinct but complete enough documentation/tutorial/etc that I

Re: [PATCH bpf-next 3/5] libbpf: add low level TC-BPF API

Andrii Nakryiko writes: > On Sun, Mar 28, 2021 at 1:11 AM Kumar Kartikeya Dwivedi > wrote: >> >> On Sun, Mar 28, 2021 at 10:12:40AM IST, Andrii Nakryiko wrote: >> > Is there some succinct but complete enough documentation/tutorial/etc >> > that I can reasonably read to understand kernel APIs

Re: [PATCH net 1/1] xdp: fix xdp_return_frame() kernel BUG throw for page_pool memory model

Jesper Dangaard Brouer writes: > On Mon, 29 Mar 2021 16:00:39 +0800 > Ong Boon Leong wrote: > >> xdp_return_frame() may be called outside of NAPI context to return >> xdpf back to page_pool. xdp_return_frame() calls __xdp_return() with >> napi_direct = false. For page_pool memory model,

Re: [PATCH bpf-next 3/5] libbpf: add low level TC-BPF API

Vlad Buslov writes: > On Thu 25 Mar 2021 at 14:00, Kumar Kartikeya Dwivedi wrote: >> This adds functions that wrap the netlink API used for adding, >> manipulating, and removing filters and actions. These functions operate >> directly on the loaded prog's fd, and return a handle to the filter

Re: [PATCH bpf-next 5/5] libbpf: add selftests for TC-BPF API

Alexei Starovoitov writes: > On Sat, Mar 27, 2021 at 09:32:58PM -0700, Andrii Nakryiko wrote: >> > I think it's better to start with new library for tc/xdp and have >> > libbpf as a dependency on that new lib. >> > For example we can add it as subdir in tools/lib/bpf/. >> > >> > Similarly I

Re: [PATCH bpf-next 5/5] libbpf: add selftests for TC-BPF API

Alexei Starovoitov writes: > On Thu, Mar 25, 2021 at 05:30:03PM +0530, Kumar Kartikeya Dwivedi wrote: >> This adds some basic tests for the low level bpf_tc_* API and its >> bpf_program__attach_tc_* wrapper on top. > > *_block() apis from patch 3 and 4 are not covered by this selftest. > Why

Re: [PATCH] PCI: Disallow retraining link for Atheros QCA98xx chips on non-Gen1 PCIe bridges

change it is > possible to trigger PCI_EXP_LNKCTL_RL bit without causing issues on > problematic Atheros QCA98xx cards. > > Currently only PCIe ASPM kernel code triggers this PCI_EXP_LNKCTL_RL bit, > so quirk check is added only into pcie/aspm.c file. > > Signed-off-by: Pali Rohár &g

Re: [RFC v2] net: sched: implement TCQ_F_CAN_BYPASS for lockless qdisc

Cong Wang writes: > On Mon, Mar 15, 2021 at 2:07 PM Jakub Kicinski wrote: >> >> I thought pfifo was supposed to be "lockless" and this change >> re-introduces a lock between producer and consumer, no? > > It has never been truly lockless, it uses two spinlocks in the ring buffer >

Re: [PATCH bpf-next v2] libbpf: use SOCK_CLOEXEC when opening the netlink socket

-by: Kumar Kartikeya Dwivedi Acked-by: Toke Høiland-Jørgensen

Re: [PATCH] libbpf: use SOCK_CLOEXEC when opening the netlink socket

Kumar Kartikeya Dwivedi writes: > Otherwise, there exists a small window between the opening and closing > of the socket fd where it may leak into processes launched by some other > thread. > > Signed-off-by: Kumar Kartikeya Dwivedi FYI, you should be tagging patches with the tree they are

Re: [PATCH] fs: 9p: add generic splice_write file operation

Dominique Martinet writes: > The default splice operations got removed recently, add it back to 9p > with iter_file_splice_write like many other filesystems do. > > Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops") > Cc: Toke Høilan

Re: [V9fs-developer] [PATCH] fs: 9p: add generic splice_read file operations

Dominique Martinet writes: > Toke Høiland-Jørgensen wrote on Tue, Dec 01, 2020: >> > This made me test copy_file_range, and it works with both as well (used >> > not to) >> > >> > interestingly on older kernels this came as default somehow? I have >>

Re: [V9fs-developer] [PATCH] fs: 9p: add generic splice_read file operations

Dominique Martinet writes: > Dominique Martinet wrote on Tue, Dec 01, 2020: >> > Since generic_file_splice_read() seems to just implement splice_read in >> > terms of the read_iter operation, I simply added the generic implementation >> > to the file operations, which fixed the error I was

[PATCH] fs: 9p: add generic splice_read file operations

implement read_iter, but those are only compile tested. Signed-off-by: Toke Høiland-Jørgensen --- fs/9p/vfs_file.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c index b177fd3b1eb3..01026b47018c 100644 --- a/fs/9p/vfs_file.c +++ b/fs/9p/vfs_file.c

Re: [PATCH bpf-next v8 06/34] bpf: prepare for memcg-based memory accounting for bpf maps

Roman Gushchin writes: > On Thu, Nov 26, 2020 at 01:21:41AM +0100, Daniel Borkmann wrote: >> On 11/25/20 4:00 AM, Roman Gushchin wrote: >> > In the absolute majority of cases if a process is making a kernel >> > allocation, it's memory cgroup is getting charged. >> > >> > Bpf maps can be

Re: [PATCH bpf-next v3 0/4] bpf: verifier: use target program's type for access verifications

strictions > for some map types such sockmap. Thanks for fixing this! For the series: Acked-by: Toke Høiland-Jørgensen

Re: [PATCH] MAINTAINERS: XDP: restrict N: and K:

Joe Perches writes: > On Fri, 2020-07-10 at 20:18 +0200, Alexander A. Klimov wrote: >> >> Am 10.07.20 um 18:12 schrieb Toke Høiland-Jørgensen: >> > Joe Perches writes: >> > >> > > On Fri, 2020-07-10 at 17:14 +0200, Daniel Borkmann wrote: >>

Re: [PATCH] MAINTAINERS: XDP: restrict N: and K:

Joe Perches writes: > On Fri, 2020-07-10 at 17:14 +0200, Daniel Borkmann wrote: >> On 7/10/20 8:17 AM, Alexander A. Klimov wrote: >> > Am 09.07.20 um 22:37 schrieb Daniel Borkmann: >> > > On 7/9/20 9:42 PM, Alexander A. Klimov wrote: >> > > > Rationale: >> > > > Documentation/arm/ixp4xx.rst

Re: [PATCH] xdp_rxq_info_user: Replace malloc/memset w/calloc

Joe Perches writes: > On Fri, 2020-06-12 at 08:42 +0200, Jesper Dangaard Brouer wrote: >> On Thu, 11 Jun 2020 20:36:40 -0400 >> Gaurav Singh wrote: >> >> > Replace malloc/memset with calloc >> > >> > Fixes: 0fca931a6f21 ("samples/bpf: program demonstrating access to >> > xdp_rxq_info") >> >

Re: unregister_netdevice: waiting for DEV to become free (2)

Alexei Starovoitov writes: > On Fri, Oct 11, 2019 at 3:15 AM Tetsuo Handa > wrote: >> >> Hello. >> >> I noticed that syzbot is reporting that refcount incremented by >> bpf(BPF_MAP_UPDATE_ELEM) >> syscall is not decremented when unregister_netdevice() is called. Is this a >> BPF bug? > >

Re: [PATCH] tools: libbpf: Add bpf_object__open_buffer_xattr

Andrii Nakryiko writes: > On Fri, Sep 27, 2019 at 6:11 AM KP Singh wrote: >> >> From: KP Singh >> >> Introduce struct bpf_object_open_buffer_attr and an API function, >> bpf_object__open_xattr, as the existing API, bpf_object__open_buffer, >> doesn't provide a way to specify neither the

Re: WireGuard to port to existing Crypto API

"Jason A. Donenfeld" writes: > Hi folks, > > I'm at the Kernel Recipes conference now and got a chance to talk with > DaveM a bit about WireGuard upstreaming. His viewpoint has recently > solidified: in order to go upstream, WireGuard must port to the > existing crypto API, and handle the Zinc

Re: [PATCH] bpf: validate bpf_func when BPF_JIT is enabled

Sami Tolvanen writes: > On Thu, Sep 12, 2019 at 3:52 AM Toke Høiland-Jørgensen > wrote: >> I think it would be good if you do both. I'm a bit worried that XDP >> performance will end up in a "death by a thousand paper cuts" situation, >> so I'd rather

Re: [PATCH] bpf: validate bpf_func when BPF_JIT is enabled

Sami Tolvanen writes: > On Wed, Sep 11, 2019 at 5:09 AM Toke Høiland-Jørgensen > wrote: >> >> Björn Töpel writes: >> > I ran the "xdp_rxq_info" sample with and without Sami's patch: >> >> Thanks for doing this! > > Yes, thanks for testin

Re: [PATCH] bpf: validate bpf_func when BPF_JIT is enabled

Björn Töpel writes: > On 2019-09-11 09:42, Yonghong Song wrote: >> I am not an expert in XDP testing. Toke, Björn, could you give some >> suggestions what to test for XDP performance here? > > I ran the "xdp_rxq_info" sample with and without Sami's patch: Thanks for doing this! > $ sudo

[PATCH bpf-next] xdp: Fix race in dev_map_hash_update_elem() when replacing element

1432052e8d...@syzkaller.appspotmail.com Signed-off-by: Toke Høiland-Jørgensen --- kernel/bpf/devmap.c | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c index 9af048a932b5..d27f3b60ff6d 100644 --- a/kernel/bpf/devmap.c +++ b/

Re: general protection fault in dev_map_hash_update_elem

Hillf Danton writes: >> syzbot has found a reproducer for the following crash on Sat, 07 Sep 2019 >> 18:59:06 -0700 >> >> HEAD commit:a2c11b03 kcm: use BPF_PROG_RUN >> git tree: bpf-next >> console output: https://syzkaller.appspot.com/x/log.txt?x=13d46ec160 >> kernel config:

Re: general protection fault in dev_map_hash_update_elem

Jesper Dangaard Brouer writes: > On Thu, 5 Sep 2019 14:44:37 -0700 > Alexei Starovoitov wrote: > >> On Thu, Sep 5, 2019 at 1:08 PM syzbot >> wrote: >> > >> > Hello, >> > >> > syzbot found the following crash on: >> > >> > HEAD commit:6d028043 Add linux-next specific files for 20190830 >> >

Re: [v1] net_sched: act_police: add 2 new attributes to support police 64bit rate and peakrate

"David Z. Dai" writes: > On Thu, 2019-08-29 at 10:32 +0200, Eric Dumazet wrote: >> >> On 8/29/19 12:51 AM, David Dai wrote: >> > For high speed adapter like Mellanox CX-5 card, it can reach upto >> > 100 Gbits per second bandwidth. Currently htb already supports 64bit rate >> > in tc utility.

Re: [PATCH bpf] bpf: fix the check that forwarding is enabled in bpf_ipv6_fib_lookup

gt;forwarding flag. Change it to behave as expected. > > Signed-off-by: Anton Protopopov Thanks! Acked-by: Toke Høiland-Jørgensen

RE: [PATCH] net: can: Increase tx queue length

Appana Durga Kedareswara Rao writes: > Hi Andre, > > >> >> On 3/9/19 3:07 PM, Appana Durga Kedareswara rao wrote: >> > While stress testing the CAN interface on xilinx axi can in loopback >> > mode getting message "write: no buffer space available" >> > Increasing device tx queue length

Re: [PATCH 4.20 161/183] mac80211: Change default tx_sk_pacing_shift to 7

Greg Kroah-Hartman writes: > On Tue, Feb 26, 2019 at 10:55:45AM +0100, Toke Høiland-Jørgensen wrote: >> Greg Kroah-Hartman writes: >> >> > 4.20-stable review patch. If anyone has any objections, please let me >> > know. >> >> LGTM. Any chance

Re: [PATCH 4.20 161/183] mac80211: Change default tx_sk_pacing_shift to 7

Greg Kroah-Hartman writes: > 4.20-stable review patch. If anyone has any objections, please let me > know. LGTM. Any chance of getting this into 4.19 as well? It doesn't apply as-is, but I can send an equivalent patch (where?). -Toke

Re: [PATCH] net: wireless: ath: ath9k: Fix a possible data race in ath_chanctx_set_next

Kalle Valo writes: > Jia-Ju Bai writes: > >> The write operation to "sc->next_chan" is protected by >> the lock on line 1287, but the read operation to >> this data on line 1262 is not protected by the lock. >> Thus, there may exist a data race for

Re: [PATCH] net: wireless: ath: ath9k: Fix a possible data race in ath_chanctx_set_next

Kalle Valo writes: > Jia-Ju Bai writes: > >> The write operation to "sc->next_chan" is protected by >> the lock on line 1287, but the read operation to >> this data on line 1262 is not protected by the lock. >> Thus, there may exist a data race for "sc->next_chan". >> >> To fix this data race,

Re: linux-next: build failure after merge of the mac80211-next tree

Kalle Valo <kv...@codeaurora.org> writes: > Toke Høiland-Jørgensen <t...@toke.dk> writes: > >>> Sorry for the inconvenience, I hadn't realized mt76 went in now. >> >> Yeah, hadn't expected these streams to cross either. > > I did ask[1] if everyone

Re: linux-next: build failure after merge of the mac80211-next tree

Kalle Valo writes: > Toke Høiland-Jørgensen writes: > >>> Sorry for the inconvenience, I hadn't realized mt76 went in now. >> >> Yeah, hadn't expected these streams to cross either. > > I did ask[1] if everyone are ok that I apply mt76 and I didn't get any &

Re: linux-next: build failure after merge of the mac80211-next tree

Johannes Berg writes: > Hi Stephen, > > Thanks! > > Felix made me aware of this yesterday evening and said he's going to > work out the required changes to mt76. > > Kalle and I will make sure to submit the trees to Dave one by one so he > doesn't have to deal with it

Re: linux-next: build failure after merge of the mac80211-next tree

Johannes Berg writes: > Hi Stephen, > > Thanks! > > Felix made me aware of this yesterday evening and said he's going to > work out the required changes to mt76. > > Kalle and I will make sure to submit the trees to Dave one by one so he > doesn't have to deal with it :) > > Unfortunately, this

Re: [PATCH RFC] remove custom Michael MIC implementation

"Tobin C. Harding" writes: > Except one: do you know off the top of your head of a canonical > implementation of a softmac wi-fi driver. I'll suggest taking a look at the ath9k driver :) -Toke

Re: [PATCH RFC] remove custom Michael MIC implementation

"Tobin C. Harding" writes: > Except one: do you know off the top of your head of a canonical > implementation of a softmac wi-fi driver. I'll suggest taking a look at the ath9k driver :) -Toke